3 ms·
I found this reply from Amazon helpful. TL;DR don't use a connection pool in Lambda > Now I see that you mentioned in one of the github posts: "The Lambda doe
by Xeoncross 9y ago
I found this reply from Amazon helpful.
TL;DR don't use a connection pool in Lambda
> Now I see that you mentioned in one of the github posts: "The Lambda does seem to use the pool, but if I make maybe 3 / 4 quick requests to the lambda, new connections are opened up despite there being all of those connections already."
> 3/4 quick requests would mean concurrent invocations, and concurrent invocations will execute in new containers. Containers are not aware of each other and cannot share state information so if an execution occurs in new container, it will open a new connection if there are none in this new container, despite there being existing connections from different containers. This can also cause your RDS instance to have too many open connections, because another container may have all the connections saturated, and if a new container is required to handle the load it may not be able to create the new RDS connection it needs to do it's work.
- https://github.com/sequelize/sequelize/issues/4938#issuecomment-245211042 https://github.com/sequelize/sequelize/issues/4938#issuecomm...
- mjb 9y agoFor most uses, database connection pooling (or, more accurately, keeping a connection per container), is the right practice to follow in Lambda. For many databases, creating a connection is expensive and slow, and amortizing those costs over multiple container uses (see https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/ https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...) helps reduce latency and cost. Lambda allows you to configure a per-function concurrency limit, which you can use to make sure that the number of containers doesn't exceed your maximum database connections.