3 ms·

We happily connection pool using sequelize by leveraging the fact that lambdas run in reusable containers. If the next lambda invocation happens within minutes

We happily connection pool using sequelize by leveraging the fact that lambdas run in reusable containers. If the next lambda invocation happens within minutes of the previous one ending, you can carry forward a db connection from the older lambda, no magic needed. Just place your db connection object in global scope (nodejs).

Aeolun 6y ago
Yeah, they can use the same connection for a while. The problem is that 1000 lambdas cannot use 50 connections while waiting their turn. Each of them wants a connection to the DB server. Now if you somehow get a spike of requests to some endpoint that goes over your DB connection limit, suddenly all your newly scaled functions fail because they cannot get a connection to the database. AWS added a service for RDS to deal with this, but it all just feels like a big kludge to deal with a problem that shouldn’t have to exist in the first place.
- jacques_chester 6y ago
  My view is that logic shouldn't be retrieving or storing data. Separation of Church and state, so to speak.
- saimiam 6y ago
  If you are expecting one thousand simultaneous requests, serverless or not, you will need a db and an appserver which support one thousand simultaneous connections. There is no getting around that. You will have to analyze your burst rate and the lifetime of each request to figure out the size of your connection pool. I also am not clear how AWS introduced the problem of not being able to connect to the DB. We've known about the need for connection pools and connection reuse from before AWS was a thing, no?
  - ec109685 6y ago
    If your function spends 80% of its time on logic and 20% on database time, with a server app, you can get by with 200 DB connections to handle that throughout, but will need 1000 connections in a serverless setup.
    - saimiam 6y ago
      I don't think connection pooling works this way. Happy to be corrected. A process is given a connection from a pool when it requests the connection and holds it until it relinquishes the connection regardless of whether the process was in the logic or data access portions of their lifecycle. It is up to you as the developer to ask for the connection and to return it on an as-needed basis...Which is exactly what you should be doing in a lambda as well. Just because a lambda container is persistent does not mean the connection given to it is stuck to that lambda even after that lambda returns the connection.
      - ec109685 6y ago
        Lambda does hold onto it in order improve response time. It connects to the database in a handler outside the context of a request, so you do hold onto N connections persistently (at least until the lambda scales down). With a connection pool, you don’t need to hold onto a connection longer than necessary, but you are right that you could implement it in such a way that you hold it for life of the request.

Aeolun 6y ago

Yeah, they can use the same connection for a while. The problem is that 1000 lambdas cannot use 50 connections while waiting their turn. Each of them wants a connection to the DB server. Now if you somehow get a spike of requests to some endpoint that goes over your DB connection limit, suddenly all your newly scaled functions fail because they cannot get a connection to the database. AWS added a service for RDS to deal with this, but it all just feels like a big kludge to deal with a problem that shouldn’t have to exist in the first place.

jacques_chester 6y ago
My view is that logic shouldn't be retrieving or storing data. Separation of Church and state, so to speak.
saimiam 6y ago
If you are expecting one thousand simultaneous requests, serverless or not, you will need a db and an appserver which support one thousand simultaneous connections. There is no getting around that. You will have to analyze your burst rate and the lifetime of each request to figure out the size of your connection pool. I also am not clear how AWS introduced the problem of not being able to connect to the DB. We've known about the need for connection pools and connection reuse from before AWS was a thing, no?
- ec109685 6y ago
  If your function spends 80% of its time on logic and 20% on database time, with a server app, you can get by with 200 DB connections to handle that throughout, but will need 1000 connections in a serverless setup.
  - saimiam 6y ago
    I don't think connection pooling works this way. Happy to be corrected. A process is given a connection from a pool when it requests the connection and holds it until it relinquishes the connection regardless of whether the process was in the logic or data access portions of their lifecycle. It is up to you as the developer to ask for the connection and to return it on an as-needed basis...Which is exactly what you should be doing in a lambda as well. Just because a lambda container is persistent does not mean the connection given to it is stuck to that lambda even after that lambda returns the connection.
    - ec109685 6y ago
      Lambda does hold onto it in order improve response time. It connects to the database in a handler outside the context of a request, so you do hold onto N connections persistently (at least until the lambda scales down). With a connection pool, you don’t need to hold onto a connection longer than necessary, but you are right that you could implement it in such a way that you hold it for life of the request.