Do you run with one connection to MySQL? Are there any other request
going on at the same time?
If not (or too few of the other requests) the following might happen:
* What comes into play with MySQL Cluster is network latency.
* If you have one connection doing SELECT, you will do only one SELECT
at a time.
* Network latency then determines how long time it takes to perform a
Moreover, the data nodes when receiving the request will try to be smart
and buffer data before sending it on/back.
It tries to buffer 32KB of data, IIRC. If it cannot fill up 32KB , it
will wait for more data to process, and if no more data is coming it
will send send the contents in its send buffer. This extra "wait for
more data" can take 10ms (unless Oracle has changed this) and the
results you get sounds like what you describe.
To overcome this you must simply drive more load on the cluster.
MySQL Cluster likes a lot of short transaction, happening in parallel.
If you can have 10 threads to the mysqld doing these SELECTs you will
most likely see completely other results, unless you have a slow network
or are swapping, or a wrongly configured cluster.
twitter : http://twitter.com/#!/severalnines
On 2011-10-20 15.31, paul@stripped wrote:
> I'm evaluating MySQL Cluster as a replacement for our current "normal"
> MySQL Server. The current server is processing many "update" queries per
> second, sent by a client application that always stays connected to the
> server. On the other hand, the server is serving "select" queries on the
> same table, using clients that disconnect after each query (i.e.,
> requests coming from a web server, without connection pooling).
> In my evaluation I have observed that MySQL Cluster with two data nodes
> offers a superior "update" performance compared to a MySQL Server
> instance running on identical hardware. However, performance for the
> "select" queries is much worse on MySQL Cluster (using MYSQLD as API).
> Apparently MySQL Cluster has much more "overhead" setting up a session
> (connection). The difference between MySQL Server and MySQL Cluster is
> quite dramatic: In our test set-up MySQL Cluster could only server about
> 65 connect-select-disconnect cycles, whereas MySQL Server can easily
> handle 1000 and more cycles per second. This is quite a show-stopper for
> our purposes...
> Note that all queries are done using the primary key, and all updates
> and selects work on exactly one row. In total our test table contains
> 100,000 rows. The MySQL Server version used to test was 5.1 and MySQL
> Cluster was version 7.2.1 with MySQLD 5.5.
> Does anyone else has the same experience with MySQL Cluster? Is there
> any way to improve this connect-select-disconnect cycles?
> Thanks for your help,