Database connection pool issue with serverless lambda function

If you are using serverless lambda functions with Relational database, you may have come across the issues when number of connection with the database gets exhausted.

In this blog, I will be explaining what could be the causes that may lead to such a situation and how can we overcome this.

So, before diving into the issue directly, I would like you to understand the life cycle of a Lambda function. Please go through this link to understand the lifecycle.

Now that you have gone through the above link you know that “A single Lambda function container can only serve one invoke at a time, so concurrent requests will trigger AWS to fetch and launch additional containers for response.”

You can also read more on this link to understand how a container gets reused in AWS lambda.

Now, let’s see different scenarios where I will configure database connection pool to different size and hit the lambda function with different number of concurrent users and figure out why max number of connections are getting exhausted even where a considerably less number of concurrent users are hitting the endpoint.

Note:

For our case I am using `db.t2.micro` instance, from AWS RDS, which allows around 85 max connection.

Also, I am using sequelize ORM whose pool configuration script would look like as mentioned in each scenario. Other ORM may have similar syntax please look out for that.

Scenario-01

Pool Configuration

     pool: {

          max: 20,

          min: 0,

          idle: 10000

      }

When we hit the endpoint with the above pool configuration by only 5 concurrent users.

Spot the red oval/circle in the graph below which, is showing max number of connection that could be made with Relational database.

Scenario-02

Pool Configuration

     pool: {

          max: 10,

          min: 0,

          idle: 10000

      }

When we hit the endpoint with the above pool configuration by only 10 concurrent users.

Scenario-03

Pool Configuration

     pool: {

          max: 5,

          min: 0,

          idle: 10000

      }

On hitting the endpoint with the above pool configuration by 20 concurrent users.

Scenario-04

Pool Configuration

    pool: {

          max: 1,

          min: 0,

          idle: 10000

     }

On hitting the endpoint with the above pool configuration by 100 concurrent users.

After seeing these many scenarios, you might have noticed a pattern with the pool size and number of concurrent users.

Yes, when we increase the size of pool, it is able to serve less number of users simultaneously because when we hit an endpoint, AWS launches a container and it creates connections with the database with the specified pool size but could only use one connection per container. Hence, the rest of the connections remain open (until the container dies) but are of no use.

Using the pool with max size, more than one is useful when not using serverless. In case of server oriented backend (where we need to take care of server unlike the AWS serverless where we mostly focus on writing functions than worrying about the infrastructure) once connection is created with the database it will use the connections from the pool when new requests arrive rather than creating connection every time, which is very costly in terms of resources.

So, in short if you want to utilize all available connections when using serverless lambda functions, you should configure max pool size to 1.

Hope you enjoyed this article. Feel free to leave comments and send us suggestions!

 

About CauseCode: We are a technology company specializing in Healthtech related Web and Mobile application development. We collaborate with passionate companies looking to change health and wellness tech for good. If you are a startup, enterprise or generally interested in digital health, we would love to hear from you! Let's connect at bootstrap@causecode.com

Leave a Reply

Your email address will not be published. Required fields are marked *

STAY UPDATED!

Do you want to get articles like these in your inbox?

Email *

Interested groups *
Healthtech
Business
Technical articles

Archives