Lambda Layer
Bundle all your Java class files and any additional required Java libraries, and then upload it to the AWS Lambda console using the “Upload a.zip file” option for the code entry type. Note that Thundra dependencies are not expected to be in the artifact to be uploaded, as they come with a layer that will be utilized at a later point.
Add the API key to the environment variables on Amazon Lambda console.
Next, add the Thundra layer by clicking on the Layers option in the Designer tab on your Lambda function console. Then select the “Add Layer” button and add the Thundra layer's ARN.
arn:aws:lambda:${region}:269863060030:layer:thundra-lambda-java-layer:${layer-version}
You can use the latest layer version (shown below) instead of the${layer-version} above.
Note that the region of the ARN is dynamic, so you need to change it accordingly to the region where you deploy your function. So let’s say that you deploy your Lambda function to the Oregon (us-west-2) region. The layer ARN will be:arn:aws:lambda:us-west-2:269863060030:layer:thundra-lambda-java-layer:${layer-version}
Configure handler: Set the handler to
io.thundra.agent.lambda.core.handler.ThundraLambdaHandler. Set thethundra_agent_lambda_handlerenvironment variable value to your handler.
Clicking on the “Test” button, which is located on the top right of the AWS console, will result in an invocation of your function (after you have configured test data per the specifications of your function).
After generating your first invocation, the “Next” button will appear in the Invocation Monitor bar. Simply click the button to see monitoring data from your invocation.
Using Thundra's custom Java runtime, you can integrate Thundra to your Java Lambda functions with zero code and configuration changes. Once you add the Thundra layer as described above, all you have to do is change your Lambda function's runtime to Custom runtime in the AWS Lambda Console. No Handler configuration change is needed.
If you are using a serverless framework, you can set your function’s runtime to “provided” in your serverless.ymlfile. This will set your function to the custom runtime.
Java is one of the languages that suffers the most from cold start overhead on AWS Lambda. Until now, with managed Java runtime, it was not feasible to optimize a Java process to start faster. AWS Lambda does have some optimizations to start processes faster for Java runtime, such as enabling class data-sharing with -Xshare:on so that classes are loaded from a shared memory-mapped file in a pre-parsed format. However, there are still some other options to fine-tune a Java application’s startup time.
With Thundra’s custom Java runtime, you already get these optimizations out of the box by setting the thundra_agent_lambda_jvm_optimizeForFastStartup environment variable to true. We use AWS Lambda’s JVM, which is pre-installed on the custom runtime environment and enables applications to start faster in addition to giving you a lower cold start overhead. If you’re having trouble with the cold start overhead for your Java-based Lambda function, give it a try and see the effects instantly.