mercredi 12 juin 2019

Should we really reuse global variables in AWS lambda runtime?

I'm quoting this very shady paragraph from here regarding performance tips on AWS-lambda service.

According to AWS team:

Take advantage of Execution Context reuse to improve the performance of your function. Make sure any externalized configuration or dependencies that your code retrieves are stored and referenced locally after initial execution. Limit the re-initialization of variables/objects on every invocation. Instead use static initialization/constructor, global/static variables and singletons. Keep alive and reuse connections (HTTP, database, etc.) that were established during a previous invocation

let's ignore for a second the evil idea of intentionally declaring variables as global, static and opt for singletones* (personally speaking, this is one of the most irresponsible advises one can give) my main concern is the use of open connections.

My questions are:

  1. what happens if , eg, the connection times out between one lambda invocations to another? how does the AWS runtime "knows" no to re-use that connection?

  2. what happens if the connection is buffered? meaning there are residues from a previous invocations?

  3. is this advice (re-using connections across invocations) really holds in real life? it's seems very buggish to me.




Aucun commentaire:

Enregistrer un commentaire