AWS SnapStart - Part 24 Measuring cold and warm starts with Java 21 using Lambda layer (1)

Introduction

In the blog post How to create, publish and use layers for Java 21 Lambda functions we published our first Lambda layer with Java 21. In this article we'll create the application using this Lambda layer and then measure cold and warm start times without SnapStart enabled, with SnapStart enabled and also applied DynamoDB invocation priming optimization. We’ll also compare the results with our measurements without using the Lambda layers and providing all dependencies in the POM file which we did in the article Measuring cold and warm starts with Java 21 using different Lambda memory settings.

Measuring cold and warm starts with Java 21 using Lambda layer

In our experiment we'll use the sample application. There are basically 2 Lambda functions defined in the AWS SAM template which both respond to the API Gateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function GetProductByIdWithPureJava21LambdaWithCommonLayer can be used with and without SnapStart and the second one GetProductByIdWithPureJava21LambdaAndPrimingWithCommonLayer uses SnapStart and DynamoDB request invocation priming.

Dependencies provided via the Lambda layer have the scope “provided” in the pom.xml file of our application.

In order to attach the Lambda layer created in the article How to create an publish and use layers for Java 21 Lambda functions for the Lambda functions in the AWS SAM template we have to add Layers parameter to the Lambda function like this:

    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21LambdaWithCommonLayer
      AutoPublishAlias: liveVersion
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest

Please replace the Layer ARN (including the version) with your own one which is the output of the publish layer command (aws lambda publish-layer-version).

The results of the experiment below were based on reproducing more than 100 cold and approximately 100.000 warm starts with experiment which ran for approximately 1 hour. For it (and experiments from my previous article) I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman.
I ran all these experiments by giving our Lambda functions 1024 MB memory and by passing the following compilation option via the environment variable: JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" (client compilation without profiling) which provides a very good trade-off between the cold and warm start times.

In the tables below I'll also provide the results with our measurements without using the Lambda layers taken from the article Measuring cold and warm starts with Java 21 using different Lambda memory settings to directly have the comparison between both.
Abbreviation c is for the cold start and w is for the warm start.

Cold (c) and warm (w) start times without SnapStart in ms:

Cold (c) and warm (w) start times with SnapStart without Priming in ms:

Cold (c) and warm (w) start times with SnapStart and with DynamoDB invocation Priming in ms:

Conclusion

In this article we created the application using the Lambda layer with common dependencies and then measured cold and warm start times without SnapStart enabled, with SnapStart enabled and also applied DynamoDB invocation priming optimization and compared the results with our measurements without using the Lambda layers and providing all dependencies in the POM file which we did in the article Measuring cold and warm starts with Java 21 using different Lambda memory settings.

I’ve performed measurements with the usage of the common Lambda layers multiple times to really confirm the result of my experiment. Even if I had some deviations in the results between those measurements, the trend was always the same: When not enabling SnapStart or enabling it but not using priming of the DynamoDB invocation the cold starts with the usage of common Lambda layer was several hundred milliseconds higher compared to package all dependencies only in the POM file. Only when SnapStart was enabled for the Lambda function and DynamoDB invocation priming was applied the cold starts with both approaches were very close, probably due to the fact that everything was already in the created snapshot.

The warm starts of the Lambda function were quite close for both use cases (with and without the usage of the Lambda layers) and for all experiments (with and without SnapStart enabled) for nearly all percentiles, but I've always got higher results for the maximal value with the usage of common Lambda layer.

In the next article I'll continue my experiments with the Lambda layers. This time I’ll create, publish and use the Lambda layer containing not only common dependencies (like in this article) but all dependencies required to run this application and then compare the results of both experiments.