A few months back I posted my findings from troubleshooting a resource leak in a Java application that had been lifted and shifted to become a lambda rather than a long-running app on AWS.
The resource leak turned out to be the setup of a fresh pool of connections to the back-end cache on each invocation of the lambda, without any corresponding clean up call to close those connections.
Yesterday I attended the Redis Day conference in London during which a presentation happened to include some code for a much simpler use case involving connecting to a similar back end cache - Redis - but with a different approach to initialisation.
The lambda from the presentation was extremely lightweight, so there was no bloated microservice framework involved. Just a single method to perform a single task. The initialisation of the connection to the Redis system was performed in a static block and had no corresponding call to close it. I believe that this approach would ensure that the Redis client is reused between invocations of the lambda, and appears to be a recommended pattern for setting up connection pools for other resources such as database connections - relying on the receiving end to clean up resources if / when the lambda's container is shut down terminating the connection.
The static initialisation approach reduces the startup time for all but the first invocation of the lambda.
No comments:
Post a Comment