Search code examples
mysqlamazon-web-servicesexpressamazon-rds

AWS: Too many connections

I have an RDS instance hosting a mySQL database. Instance size is db.t2.micro

enter image description here

I also have an ExpressJS backend connecting to the mySQL RDS instance via a connection pool:

enter image description here

Additionally i have a mobile app, the client, feeding off the ExpressJS API.

The issue i'm facing is, either via the mobile app or via Postman, there are times where i get a 'Too many connections' error and therefore several requests fail:

enter image description here

On the RDS instance. On current activity i sometimes get 65 connections, showing it's reaching the limit. What i need clarity on is:

  1. When 200 mobile app instances connect to the API, to the RDS instance, does it register as 200 connections or 1 connection from ExpressJS?
  2. Is it normal to be reaching the RDS instance 65 connection limit?
  3. Is this just a matter of me using db.t2.micro instance size which is not recommended for prod? Will upgrading the instance size resolve this issue?
  4. Is there something i'm doing wrong with my requests?

Thank you and your feedback is appreciated.

Solution

  • If your app creates a connection pool of 100, that's the number of database connections it will try to open. It must be lower than your MySQL connection limit.

    Typically connection pools open all the connections for the pool, so they are ready when a client calls the http API. The connections might normally be running no SQL queries, if there are not many clients using the API at a given moment. The database connections are nevertheless connected.

    Sort of like when you ssh to a remote linux server but you just sit there at a shell prompt for a while before running any command. You're still connected.

    You asked if a db.t2.micro instance was not recommended for production. Yes, I would agree with that. It's tempting to use the smallest instance possible to save money, but a db.t2.micro is too small for anything but light testing, in my opinion.

    In fact, I would not use any t2 instance for production, regardless of size. The t2 type uses "burstable" performance. This means it can provide only brief periods of good performance. Once the instance depletes its performance credits, they recharge slowly, and while they recharge, the performance of that instance is very low. This is okay for testing, but not for production, if you expect to provide consistent performance at any time.