Lambda may not be a magic reliability wand, you definitely still need to manage downstream pressure.
That said:
> The code creates a MySQL connection during each invocation.
This is not a correct implementation for Lambda.
You shouldn't recreate a connection on every invocation. Instead, create your connection outside of your handler code. Then each invocation of a warm container will re-use the same handler. (1)
This will help cut down on cold start time, as well as help manage running out of connections.
You should limit your maximum number of concurrent invocations to be equal to the limit of your database threadpool. This is all in their documentation, as well as several blog posts. (2, 3, 4)
> Your function code is cleaner, simpler, and easier to maintain.
I don't think your post covers the nuances. "Not a correct implementation"? We weren't trying for lowest latency, we were trying for highest reliability / simplest code / easiest to test. How do you test that your reused connections handle the "timed out right as next request comes in" case?
I mean not correct in the literal sense. It's not about reliability nor simplicity nor testability - the code is wrong. It has a bug. The code is written without understanding that lambda containers can be re-used, thus, it's exhausting a finite resource unintentionally.
You handle the "timed out right as next request comes in" case by memoizing the connection in a variable and checking if it's null in the handler. If it is, re-establish the connection.
3 comments
[ 5.1 ms ] story [ 15.2 ms ] thread> The code creates a MySQL connection during each invocation.
This is not a correct implementation for Lambda.
You shouldn't recreate a connection on every invocation. Instead, create your connection outside of your handler code. Then each invocation of a warm container will re-use the same handler. (1)
This will help cut down on cold start time, as well as help manage running out of connections.
You should limit your maximum number of concurrent invocations to be equal to the limit of your database threadpool. This is all in their documentation, as well as several blog posts. (2, 3, 4)
[1] https://docs.aws.amazon.com/lambda/latest/dg/services-rds-tu...
[2] https://www.jeremydaly.com/reuse-database-connections-aws-la...
[3] https://medium.com/faun/reusing-connections-lambda-functions...
> Your function code is cleaner, simpler, and easier to maintain.
I don't think your post covers the nuances. "Not a correct implementation"? We weren't trying for lowest latency, we were trying for highest reliability / simplest code / easiest to test. How do you test that your reused connections handle the "timed out right as next request comes in" case?
You handle the "timed out right as next request comes in" case by memoizing the connection in a variable and checking if it's null in the handler. If it is, re-establish the connection.