Optimize Java Lambda Performance: A Guide to Lambda Priming with CRaC

Want to boost the performance of your Java Lambda functions? This guide explores how to use CRaC (Coordinated Restore at Checkpoint) runtime hooks for Lambda priming, significantly reducing latency and improving the responsiveness of your serverless applications. Learn how to leverage beforeCheckpoint() and afterRestore() hooks for optimized performance.

Why Use Lambda Priming for Java Functions?

Lambda priming is a powerful optimization technique to minimize cold starts and ensure consistent low latency, especially crucial for:

• APIs
• Real-time data processing services

By proactively initializing resources before a snapshot and restoring them efficiently after, you can dramatically improve the speed and efficiency of your Java Lambda functions.

Prerequisites for Lambda Priming

Before diving in, ensure you have the following:

• An AWS account with sufficient IAM permissions.
• AWS CLI, Git, and AWS Cloud Development Kit (CDK) installed.
• Java 21 and Maven.
• curl
• Docker and AWS SAM (for local testing purposes)

Step-by-Step Deployment Guide

Follow these steps to deploy and test Lambda functions with CRaC priming using the provided CDK project:

1. Clone the Repository:

   git clone https://github.com/aws-samples/lambda-priming-crac-java-cdk
   cd lambda-priming-crac-java-cdk/infrastructure
   

   Copy

2. Deploy the CDK Stack:

   cdk deploy --require-approval never --all 2>&1 | tee cdk_output.txt
   

   Copy

3. Extract Endpoint URLs: This command will capture the necessary URLs from the CDK output for testing.

   ONDEMAND_URL=$(grep -oE 'https://[a-zA-Z0-9.-]+\.execute-api\.[a-zA-Z0-9-]+\.amazonaws\.com/prod/' "cdk_output.txt" | head -n 1)
   NOPRIMING_URL=$(grep -oE 'https://[a-zA-Z0-9.-]+\.execute-api\.[a-zA-Z0-9-]+\.amazonaws\.com/prod/' "cdk_output.txt" | head -n 2 | tail -n 1)
   INVOKEPRIMING_URL=$(grep -oE 'https://[a-zA-Z0-9.-]+\.execute-api\.[a-zA-Z0-9-]+\.amazonaws\.com/prod/' "cdk_output.txt" | head -n 3 | tail -n 1)
   CLASSPRIMING_URL=$(grep -oE 'https://[a-zA-Z0-9.-]+\.execute-api\.[a-zA-Z0-9-]+\.amazonaws\.com/prod/' "cdk_output.txt" | head -n 4 | tail -n 1)
   SETUP_URL=$(grep -oE 'https://[a-zA-Z0-9.-]+\.execute-api\.[a-zA-Z0-9-]+\.amazonaws\.com/prod/' "cdk_output.txt" | head -n 5 | tail -n 1)
   

   Copy

4. Initialize the Database:

   curl "$SETUP_URL"
   

   Copy

   Expect a successful response: {"message":"Database schema initialized and data loaded"}

Testing Your Primed Lambda Functions

Evaluate the performance improvements with these load tests.

1. Run Load Tests: Use Artillery to simulate traffic and measure the impact of Java Lambda SnapStart and CRaC.

   artillery run -t "$ONDEMAND_URL" -v '{ "url": "/unicorn" }' ./loadtest.yaml && \
   artillery run -t "$NOPRIMING_URL" -v '{ "url": "/unicorn" }' ./loadtest.yaml && \
   artillery run -t "$INVOKEPRIMING_URL" -v '{ "url": "/unicorn" }' ./loadtest.yaml && \
   artillery run -t "$CLASSPRIMING_URL" -v '{ "url": "/unicorn" }' ./loadtest.yaml
   

   Copy

2. Measure Results with CloudWatch Insights: Use the following query to analyze the duration of your SnapStart Lambda functions:

   filter @type = "REPORT"
   | parse @log /\d+:\/aws\/lambda\/(?<function>.*)/
   | parse @message /Restore Duration: (?<restoreDuration>.*?) ms/
   | stats
   count(*) as invocations,
   pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as p50,
   pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as p90,
   pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99) as p99,
   pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99.9) as p99.9
   group by function, (ispresent(@initDuration) or ispresent(restoreDuration)) as coldstart
   | sort by function asc | sort by coldstart desc
   

   Select these log groups:

   • /aws/lambda/PrimingLogGroup-1_ON_DEMAND
   • /aws/lambda/PrimingLogGroup-2_SnapStart_NO_PRIMING
   • /aws/lambda/PrimingLogGroup-3_SnapStart_INVOKE_PRIMING
   • /aws/lambda/PrimingLogGroup-4_SnapStart_CLASS_PRIMING

Local Testing Setup

For development and test pourposes, you could configure lambda functions locally.

1. Start Postgres with Docker:

   docker-compose --file local/docker-compose.yml up
   

   Copy

2. Initialize Database:

   sam local invoke PrimingJavaLambdaFunction-5_DB_LOADER --env-vars local/env-vars.json --template cdk.out/LambdaPrimingCracJavaCdkStack.template.json --docker-network host
   

   Copy

3. Test Lambda Functions Locally:

   sam local invoke PrimingJavaLambdaFunction-1_ON_DEMAND --env-vars local/env-vars.json --template cdk.out/LambdaPrimingCracJavaCdkStack.template.json --docker-network host
   sam local invoke PrimingJavaLambdaFunction-2_SnapStart_NO_PRIMING --env-vars local/env-vars.json --template cdk.out/LambdaPrimingCracJavaCdkStack.template.json --docker-network host
   sam local invoke PrimingJavaLambdaFunction-3_SnapStart_INVOKE_PRIMING --env-vars local/env-vars.json --template cdk.out/LambdaPrimingCracJavaCdkStack.template.json --docker-network host
   sam local invoke PrimingJavaLambdaFunction-4_SnapStart_CLASS_PRIMING --env-vars local/env-vars.json --template cdk.out/LambdaPrimingCracJavaCdkStack.template.json --docker-network host
   

   Copy

Clean Up Resources

Once you're finished, remember to destroy the deployed resources:

cdk destroy --require-approval never --all

By following this guide, you can effectively implement Lambda priming with CRaC and significantly improve the performance of your Java Lambda functions. Embrace these techniques to build faster, more responsive serverless applications.