Re:Serverless Best Practices
by philliphaydon on Sunday September 02, 2018 @09:21PM
(#17899626)
Keeping connections open on a lambda isn’t a good thing. If you have a lot of Lambdas and a lot of load you can end up hitting max connection limits. Better to open late and close early and take a hit rather than risk taking your db offline.
Re:Serverless Best Practices
by lostcolony on Sunday September 02, 2018 @11:48PM
(#17900177)
Oh, agreed; it doesn't bottleneck on the connection but instead keeps creating them which can take performance down when you spike. Hence why the original article speaks of using something other than a RDBMS, such as Dynamo, since there really is no way of addressing that issue (since you can't set a concurrency limit on one kind of function; else you could have one function that has high concurrency invoke one that is far lower, that exists just to keep connections pooled).
If you absolutely must hit an RDBMS, be quick about it to free up the connection, and definitely consider if the latency matters that much; a few dozen ms more to initialize and close the connection is going to be a LOT cleaner.
But that said, how badly it penalizes you for scaling connections up depends on the DB.
Re:Serverless Best Practices
by staticassertion on Sunday September 02, 2018 @08:04PM
(#17899349)
Interesting. I'd considered this, but was worried about failure cases. Seems tricky.
Background info: A lambda that spins up stays live for a while, and can continue to handle requests. The function handler is called again, so anything scoped to it, will disappear with the function, but anything scoped outside of the function will persist.
Ergo, move your connection creation outside of your handler.
Realistically you may need some abstraction to properly close and reopen the connection in the event of failure (so you can't have a 'bad' lambda, where something has happened to the connection and you can't fix it without deploying code again, to trigger a lambda refresh), but for the most part it just works.