The AWS SDK variant that is available by default on Lambda runtime's is v2. This version creates and closes a new TCP connection for each network request. For backwards compatibility reasons, they didn't change that default behavior in v2, but they did in v3.

However, this can be manually set in by passing in a configured http Agent to the AWS SDK with keepAlive set to true or by simply setting the AWS_NODEJS_CONNECTION_REUSE_ENABLED environment variable.

While this shouldn't really impact cold starts much, the performance difference when measuring warm starts can be pretty significant. This is a relevant excerpt from the AWS documentation:

By default, the default Node.js HTTP/HTTPS agent creates a new TCP connection for every new request. To avoid the cost of establishing a new connection, you can reuse an existing connection.

For short-lived operations, such as DynamoDB queries, the latency overhead of setting up a TCP connection might be greater than the operation itself. Additionally, since DynamoDB encryption at rest is integrated with AWS KMS, you may experience latencies from the database having to re-establish new AWS KMS cache entries for each operation.

If you compile the golang example with go build -tags lambda.norpc you can deploy the go version, without changes, to a "lambda custom runtime" and you will create a lambda that doesn't have amazon linux 2 in the image, making it smaller and faster to load.

https://github.com/aws/aws-lambda-go/blob/main/lambda/entry.go#L64-L66

Nice to see others profiling runtimes.

I ran into this issue with AWS Lambdas written in NodeJS being bizarrely slow a while back. It’s a legacy issue with how the AWS SDK for JavaScript works. If you have time, I suggest you try again with this one simple fix. I think you’ll be impressed.

https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/node-reusing-connections.html

A multithreaded only adds overhead with no technical benefit in an AWS Lambda environment, where lambdas are invoked without per-instance concurrency or parallelism.

Reference to original note.

Reference to relevant tokio docs.

The previous PR https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-performance/pull/8 changed the usage of Newtonsoft to System.Text.Json in the actual Lambda function. This PR registers the System.Text.Json based Lambda serializer as the serializer for Lambda event and return objects.

A big thing to help reduce .NET cold starts is remove all usages of Newtonsoft because loading that large assembly is very costly.

Requiring aws-sdk package (which is AWS SDK V2) will load entire AWS Service Clients (e.g. CloudWatch, EC2, ECS, Kinesis, S3, ... etc.), not only DynamoDB Client.

You will see better start-up performance if you load DynamoDB client only (e.g. const DynamoDB = require('aws-sdk/clients/dynamodb').

Also, AWS Javascript SDK V3 is currently in GA. AWS Javascript SDK V3 is modular, and can be optimized using bundlers to eliminate dead codes, reducing its size, and also reduces startup-performance (Also it's faster than using individual service client!). See https://aws.amazon.com/ko/blogs/developer/modular-packages-in-aws-sdk-for-javascript/ for details.

AWS has launched their Node 18 runtime along with AWS SDK 3. It would be great to have some numbers on Node 18 performance, as it offers a lot of improvements over 14.x.

https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/

Thanks for this great project!

Use serde "zero-copy deserialisation" feature to reduce string allocations. The idea is to use a borrowed string &str instead of owned String. A borrowed string points to a already existing allocation (our request).