4 ms·
> Since then, what surprises me is that this project continues to be a useful, possibly necessary tool for measuring and tuning Lambda performance. Is performa
by faller 4y ago
> 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?
- rytrix 4y ago> Is performance tuning a relevant topic for AWS Lambda though? Lambdas are also used for request/response workflows, not necessarily just async background tasks. Another use case is lambda resolvers with AppSync if you need some sort of data that can't be obtained with the native resolvers (i.e. DynamoDB) > Beyond the choice of the lambda runtime and how much RAM is provisioned, what else is there that's worth being tuned? The amount of RAM being allocated to a lambda function also controls the vCPU granted to the lambda function. There's a nice balance that can be struck with power tuning where you're paying more per millisecond for a higher RAM configuration but the duration of each invocation improves enough to the point where you're actually paying less.