Could you give an illustrative example of what the SELECT query looks
like and what is the data model - roughly what the table(s) look like,
and how it is indexed, and sizes, and if blobs/texts etc are used.
I can try it then on my cluster.
On 2011-10-20 17.38, paul@stripped wrote:
> Attached are the config.ini file (for the management nodes), my.cnf file
> (for the MySQLD API nodes, in this case for node 55), and the ndbd.cnf
> file (for the data nodes).
> Unfortunately I am not allowed to share the source code of my test
> program, I'm sorry.
> Thanks for your help, Paul
>> -------- Original Message --------
>> Subject: Re: Slow session (connection) set-up using MySQLD API
>> From: Jonas Oreland<jonas.oreland@stripped>
>> Date: Thu, October 20, 2011 4:06 pm
>> To: paul@stripped
>> Cc: cluster@stripped
>> On 10/20/11 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,
>> Hi Paul,
>> Could you share your my.cnf and maybe your application (that does the SELECT) so
>> I can test for my self ?