3 ms·

How does Aurora Serverless help with the issue of having to reconnect for every lambda? (I am unfamiliar with the Aurora Serverless offering) Also, can you ela

How does Aurora Serverless help with the issue of having to reconnect for every lambda? (I am unfamiliar with the Aurora Serverless offering) Also, can you elaborate/ point me to info on 2?

ersiees 8y ago
You don’t need a reconnect for every invocation actually, only per instance. I know you don’t want to think about instances with lambda, but actually they just run on some VM and you can just open one connection per VM.
lostcolony 8y ago
Really quickly then - 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.
- staticassertion 8y ago
  Interesting. I'd considered this, but was worried about failure cases. Seems tricky.
- philliphaydon 8y ago
  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.
  - lostcolony 8y ago
    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.

How does Aurora Serverless help with the issue of having to reconnect for every lambda? (I am unfamiliar with the Aurora Serverless offering) Also, can you elaborate/ point me to info on 2?

ersiees 8y ago

You don’t need a reconnect for every invocation actually, only per instance. I know you don’t want to think about instances with lambda, but actually they just run on some VM and you can just open one connection per VM.

lostcolony 8y ago

Really quickly then - 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.

staticassertion 8y ago
Interesting. I'd considered this, but was worried about failure cases. Seems tricky.
philliphaydon 8y ago
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.
- lostcolony 8y ago
  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.