> Since then, what surprises me is that this project continues to be a useful, possibly necessary tool for measuring and tuning Lambda performance.
Is performance tuning a relevant topic for AWS Lambda though? It's my understanding that lambdas are recommended only for:
* glue code for AWS events,
* Run fire-and-forget workers that are neither that complex nor executed often enough to justify the work of putting up a dedicated service, which already takes no work at all.
None of these use cases is exactly performance-critical. To put it differently, if any lambda starts to handle enough executions that performance and cost starts to become a concern, the standard approach is to just handle it in a service.
Beyond the choice of the lambda runtime and how much RAM is provisioned, what else is there that's worth being tuned?
Is performance tuning a relevant topic for AWS Lambda though? It's my understanding that lambdas are recommended only for:
* glue code for AWS events,
* Run fire-and-forget workers that are neither that complex nor executed often enough to justify the work of putting up a dedicated service, which already takes no work at all.
None of these use cases is exactly performance-critical. To put it differently, if any lambda starts to handle enough executions that performance and cost starts to become a concern, the standard approach is to just handle it in a service.
Beyond the choice of the lambda runtime and how much RAM is provisioned, what else is there that's worth being tuned?