Max connection pool size and autoscaling group

Question

In Sequelize.js you should configure the max connection pool size (default 5). I don't know how to deal with this configuration as I work on an autoscaling platform in AWS.

The Aurora DB cluster on r3.2xlarge allows 2000 max connections per read replica (you can get that by running SELECT @@MAX_CONNECTIONS;).

The problem is I don't know what should be the right configuration for each server hosted on our EC2s. What should be the right max connection pool size as I don't know how many servers will be launched by the autoscaling group? Normally, the DB MAX_CONNECTIONS value should be divided by the number of connection pools (one by server), but I don't know how many server will be instantiated at the end.

Our concurrent users count is estimated to be between 50000 and 75000 concurrent users at our release date.

Did someone get previous experience with this kind of situation?

Answer 1

It has been 6 weeks since you asked, but since I got involved in this recently I thought I would share my experience.

The answer various based on how the application works and performs. Plus the characteristics of the application under load for the instance type.

1) You want your pool size to be > than the expected simultaneous queries running on your host.
2) You never want your a situation where number of clients * pool size approaches your max connection limit.

Remember though that simultaneous queries is generally less than simultaneous web requests since most code uses a connection to do a query and then releases it.

So you would need to model your application to understand the actual queries (and amount) that would happen for your 75K users. This is likely a lot LESS than 75K/second db queries a second.

You then can construct a script - we used jmeter - and run a test to simulate performance. One of the items we did during our test was to increase the pool higher and see the difference in performance. We actually used a large number (100) after doing a baseline and found the number made a difference. We then dropped it down until it start making a difference. In our case it was 15 and so I set it to 20.

This was against t2.micro as our app server. If I change the servers to something bigger, this value likely will go up.

Please note that you pay a cost on application startup when you set a higher number...and you also incur some overhead on your server to keep those idle connections so making larger than you need isn't good.

Hope this helps.