Improve SDK cold-start latency about aws-sdk-java-v2 HOT 13 CLOSED

@lwis, have you tested with the latest version? Configured correctly, it should show improvement over v1.

To minimize cold start you should:

• Use the UrlConnectionHttpClient
• Specify a region
• Specify the environment variables credential provider

We are still working to remove Jackson from two more places which should give better cold start times once done.

from aws-sdk-java-v2.

Yep! I put together a very basic Lambda that handles an S3 Event, performs a couple operations on S3 objects and then puts some messages on an SQS queue. Using the default Lambda timeouts of 6s I get timeouts. It turns out first-time invocation actually takes about 7.5s. Doing some experimentation with different data serializers leads me to attribute most of this to Jackson.
The data serializer library that had the fastest startup times was square/moshi, which had startup times that were about 10% of Jackson's when it was using the reflection serializers and 7% when using compile-time generation.
I realize that changing data serializer libraries at this point is maybe not feasible.
For reference, a cold invocation of the same lambda written in node.js was 1100ms.

from aws-sdk-java-v2.

We've found big improvements with Jackson-jr as well. Once we can switch over to it for region metadata loading, we'll be able to get using Jackson off of our startup path.

We'll still be using it for unmarshalling JSON exceptions, but removing that is also on our pre-GA plan.

from aws-sdk-java-v2.

@millems do you have any progress share regarding this? I'm amongst many users that are currently suffering unacceptable cold start times for serverless.

from aws-sdk-java-v2.

@spfink thanks for the response!

Something like;

SnsClient.builder()
            .region(Region.EU_WEST_2)
            .httpClient(UrlConnectionHttpClient.builder().build())
            .credentialsProvider(EnvironmentVariableCredentialsProvider.create())
            .build()

I'm unfortunately still seeing 3.5s request to response 😞

Edit: I'm aware that UrlConnection eats up to a second of that time, and network maybe accounts for a small chunk.

from aws-sdk-java-v2.

What size of a Lambda are you getting 3.5 seconds on?

Removing the last few Jackson use cases should help us cut another second or so off.

from aws-sdk-java-v2.

@spfink 1536MB. I can put together a little test project if that's helpful?

from aws-sdk-java-v2.

related:

• #748
• #749

from aws-sdk-java-v2.

This is very promising. We are seeing over 50% improvement compared to the old lambda client when initializing the new like so:

LambdaClient.builder()
                .region(Region.EU_CENTRAL_1)
                .httpClient(UrlConnectionHttpClient.builder().build())
                .build();

with sdk v2 and a lambda with 1024MB of memory that takes around 1000ms. Instantiating the old one with AWSLambdaClientBuilder.standard().withRegion("eu-central-1").build() and the same amount of memory takes about 2300ms.

from aws-sdk-java-v2.

Glad that you're seeing some of the benefits already! We still have a few more changes planned, so hopefully we'll be able to get it even lower.

from aws-sdk-java-v2.

@Sandmania which version of the SDK are you using and seeing those results on?

from aws-sdk-java-v2.

@spfink this is with 2.0.0-preview-12 vs 1.11.443. I'm guessing most of the improvement comes from using UrlConnectionHttpClient, as just instantiating the AmazonHttpClient in 1.11.443 (which I think relies on ApacheHttpClient?) takes 1700ms.

from aws-sdk-java-v2.

see #2527 for details of cold-start improvements with a lightweight java client.

from aws-sdk-java-v2.