Hi Raymond,
Note that work isn't serialised on each of those connections and so it's very rare for
people to actually have it throttle their throughput.
Having said that, it is a high priority item on our list to improve in this area - we
want to keep ahead of demand.
Regards, Andrew.
Andrew Morgan - MySQL High Availability Principal Product Manager
+44-7833483595
andrew.morgan@stripped
@andrewmorgan
www.clusterdb.com
> -----Original Message-----
> From: Raymond Peachey [mailto:raypeachey@stripped]
> Sent: 01 March 2013 12:46
> To: cluster@stripped
> Subject: MySQL Cluster Connection Pool
>
> Hello,
>
> I have a 2 Mgmt nodes, 4 data nodes, and 2 mysql servers. I have configured
> the mysql servers to use 30 API node slots each (32 core).
>
> The current limit of 255 total nodes (inclusive of mgmt, data, and api) seems
> low. Am I wrong in my thinking, am I missing something here? All of our load
> tests that have a concurrency of 60 or below (the sum of the api
> nodes) runs fast! However, once we go over 60 concurrency, the
> performance suffers exponentially. 60 concurrency seems a bit low.
>
> Assuming you use up all 48 data nodes, 2 management servers, that leaves
> you with 205 api nodes, which from my understanding is equivalent to 205
> simultaneous connections to the cluster, theoretically. With normal MySQL
> server, we've experienced anywhere up to 1000+ connections (during peak
> load) on a single machine. So a total of 205 connections seems low for scaling
> out in the future.
>
> Any recommendations/best practices here?
>
> Thank you for any help you can provide!
>
> -Ray
