SBN

Serverless Performance Boost with SnapStart

2 minutes read


POSTED Nov, 2022

dot
IN
Serverless

Serverless Performance Boost with SnapStart

Oguzhan Ozdemir

Written by Oguzhan Ozdemir

Solutions Engineer @Thundra

linkedin-share

 X

One of the biggest challenges for running latency-sensitive applications on Lambda is cold-start issues. It’s especially difficult to choose when the runtime is something heavy, like Java.

People are working constantly to improve the performance of serverless Java applications. One of the recent and biggest improvements to this problem is coming from the AWS Lambda team that introduces the SnapStart feature for Java, a capability that delivers up to 10x faster startup performance for latency-sensitive Java functions. With AWS Lambda Snapstart, your function code initializes once when you publish your code and AWS Lambda takes a snapshot of this execution environment to resume the new invocations from this persisted snapshot.

This approach improves the performance and latency of your function dramatically. Comparing to the current state of AWS Lambda where a Lambda invocation waits for an available sandbox environment to execute and prepare it in the case of none being available, AWS Lambda SnapStart, optimizes the initialization overhead of preparing the sandbox and allowing your functions to start running your handler code much faster.

There are some situations where the developer should be careful. You might assume the environment where your function runs is unique every time. However, it’s possible for your Lambda to use the same snapshot to create multiple execution environments. In this case, some aspects of your function code might produce the same results; when in reality, it shouldn’t. One example of this could be random number generation. To maintain the uniqueness in all cases, your Lambda must be tolerant to such cases.

To learn more about the details of AWS Lambda SnapStart, you should visit the AWS documentation.

Testing SnapStart

To test this feature, we want to expand one of the examples we did before. In the past, we worked on a feature at Thundra that allowed our users to migrate their SpringBoot applications to AWS Lambda without making any code changes, as well as improving their cold-start performance.

For AWS Lambda SnapStart, we took advantage of this feature and using the same approach, we created an environment where we can compare the performance of a SpringBoot application where the initialization is much more difficult than a regular lambda. With this, we were able to reduce the cold start substantially.

For the example we’ve prepared, the average cold start was around 20 seconds. With SnapStart, the total duration of a cold start execution dropped down to around a couple of seconds.

Just to show something visual, the following chart is generated from a sample of invocation duration data of the SpringBoot application that’s deployed to AWS Lambda.

 

When we enable SnapStart, the first thing we notice is the RESTORE DURATION which can be considered as the init duration of a cold lambda at this point. However, since it’s now starting from a snapshot of the execution environment, this duration is really small compared to the regular lambda.

Compared to the environment where SnapStart is disabled;

Conclusion

It’s always good to push the boundaries of our existing toolset and give people the ability to save time and improve their application’s overall performance. The AWS Lambda SnapStart feature certainly made it easier to run latency-sensitive serverless applications on Lambda.

×

SUBSCRIBE TO OUR BLOG

Get our new blogs delivered straight to your inbox.

 

THANKS FOR SIGNING UP!

We’ll make sure to share the best materials crafted for you!

2 minutes read


POSTED Nov, 2022

dot
IN
Serverless

Serverless Performance Boost with SnapStart

Oguzhan Ozdemir

Written by Oguzhan Ozdemir

Solutions Engineer @Thundra

linkedin-share

 X

One of the biggest challenges for running latency-sensitive applications on Lambda is cold-start issues. It’s especially difficult to choose when the runtime is something heavy, like Java.

People are working constantly to improve the performance of serverless Java applications. One of the recent and biggest improvements to this problem is coming from the AWS Lambda team that introduces the SnapStart feature for Java, a capability that delivers up to 10x faster startup performance for latency-sensitive Java functions. With AWS Lambda Snapstart, your function code initializes once when you publish your code and AWS Lambda takes a snapshot of this execution environment to resume the new invocations from this persisted snapshot.

This approach improves the performance and latency of your function dramatically. Comparing to the current state of AWS Lambda where a Lambda invocation waits for an available sandbox environment to execute and prepare it in the case of none being available, AWS Lambda SnapStart, optimizes the initialization overhead of preparing the sandbox and allowing your functions to start running your handler code much faster.

There are some situations where the developer should be careful. You might assume the environment where your function runs is unique every time. However, it’s possible for your Lambda to use the same snapshot to create multiple execution environments. In this case, some aspects of your function code might produce the same results; when in reality, it shouldn’t. One example of this could be random number generation. To maintain the uniqueness in all cases, your Lambda must be tolerant to such cases.

To learn more about the details of AWS Lambda SnapStart, you should visit the AWS documentation.

Testing SnapStart

To test this feature, we want to expand one of the examples we did before. In the past, we worked on a feature at Thundra that allowed our users to migrate their SpringBoot applications to AWS Lambda without making any code changes, as well as improving their cold-start performance.

For AWS Lambda SnapStart, we took advantage of this feature and using the same approach, we created an environment where we can compare the performance of a SpringBoot application where the initialization is much more difficult than a regular lambda. With this, we were able to reduce the cold start substantially.

For the example we’ve prepared, the average cold start was around 20 seconds. With SnapStart, the total duration of a cold start execution dropped down to around a couple of seconds.

Just to show something visual, the following chart is generated from a sample of invocation duration data of the SpringBoot application that’s deployed to AWS Lambda.

 

When we enable SnapStart, the first thing we notice is the RESTORE DURATION which can be considered as the init duration of a cold lambda at this point. However, since it’s now starting from a snapshot of the execution environment, this duration is really small compared to the regular lambda.

Compared to the environment where SnapStart is disabled;

Conclusion

It’s always good to push the boundaries of our existing toolset and give people the ability to save time and improve their application’s overall performance. The AWS Lambda SnapStart feature certainly made it easier to run latency-sensitive serverless applications on Lambda.

One of the biggest challenges for running latency-sensitive applications on Lambda is cold-start issues. It’s especially difficult to choose when the runtime is something heavy, like Java.

People are working constantly to improve the performance of serverless Java applications. One of the recent and biggest improvements to this problem is coming from the AWS Lambda team that introduces the SnapStart feature for Java, a capability that delivers up to 10x faster startup performance for latency-sensitive Java functions. With AWS Lambda Snapstart, your function code initializes once when you publish your code and AWS Lambda takes a snapshot of this execution environment to resume the new invocations from this persisted snapshot.

This approach improves the performance and latency of your function dramatically. Comparing to the current state of AWS Lambda where a Lambda invocation waits for an available sandbox environment to execute and prepare it in the case of none being available, AWS Lambda SnapStart, optimizes the initialization overhead of preparing the sandbox and allowing your functions to start running your handler code much faster.

There are some situations where the developer should be careful. You might assume the environment where your function runs is unique every time. However, it’s possible for your Lambda to use the same snapshot to create multiple execution environments. In this case, some aspects of your function code might produce the same results; when in reality, it shouldn’t. One example of this could be random number generation. To maintain the uniqueness in all cases, your Lambda must be tolerant to such cases.

To learn more about the details of AWS Lambda SnapStart, you should visit the AWS documentation.

Testing SnapStart

To test this feature, we want to expand one of the examples we did before. In the past, we worked on a feature at Thundra that allowed our users to migrate their SpringBoot applications to AWS Lambda without making any code changes, as well as improving their cold-start performance.

For AWS Lambda SnapStart, we took advantage of this feature and using the same approach, we created an environment where we can compare the performance of a SpringBoot application where the initialization is much more difficult than a regular lambda. With this, we were able to reduce the cold start substantially.

For the example we’ve prepared, the average cold start was around 20 seconds. With SnapStart, the total duration of a cold start execution dropped down to around a couple of seconds.

Just to show something visual, the following chart is generated from a sample of invocation duration data of the SpringBoot application that’s deployed to AWS Lambda.

 

When we enable SnapStart, the first thing we notice is the RESTORE DURATION which can be considered as the init duration of a cold lambda at this point. However, since it’s now starting from a snapshot of the execution environment, this duration is really small compared to the regular lambda.

Compared to the environment where SnapStart is disabled;

Conclusion

It’s always good to push the boundaries of our existing toolset and give people the ability to save time and improve their application’s overall performance. The AWS Lambda SnapStart feature certainly made it easier to run latency-sensitive serverless applications on Lambda.

One of the biggest challenges for running latency-sensitive applications on Lambda is cold-start issues. It’s especially difficult to choose when the runtime is something heavy, like Java.

People are working constantly to improve the performance of serverless Java applications. One of the recent and biggest improvements to this problem is coming from the AWS Lambda team that introduces the SnapStart feature for Java, a capability that delivers up to 10x faster startup performance for latency-sensitive Java functions. With AWS Lambda Snapstart, your function code initializes once when you publish your code and AWS Lambda takes a snapshot of this execution environment to resume the new invocations from this persisted snapshot.

This approach improves the performance and latency of your function dramatically. Comparing to the current state of AWS Lambda where a Lambda invocation waits for an available sandbox environment to execute and prepare it in the case of none being available, AWS Lambda SnapStart, optimizes the initialization overhead of preparing the sandbox and allowing your functions to start running your handler code much faster.

There are some situations where the developer should be careful. You might assume the environment where your function runs is unique every time. However, it’s possible for your Lambda to use the same snapshot to create multiple execution environments. In this case, some aspects of your function code might produce the same results; when in reality, it shouldn’t. One example of this could be random number generation. To maintain the uniqueness in all cases, your Lambda must be tolerant to such cases.

To learn more about the details of AWS Lambda SnapStart, you should visit the AWS documentation.

Testing SnapStart

To test this feature, we want to expand one of the examples we did before. In the past, we worked on a feature at Thundra that allowed our users to migrate their SpringBoot applications to AWS Lambda without making any code changes, as well as improving their cold-start performance.

For AWS Lambda SnapStart, we took advantage of this feature and using the same approach, we created an environment where we can compare the performance of a SpringBoot application where the initialization is much more difficult than a regular lambda. With this, we were able to reduce the cold start substantially.

For the example we’ve prepared, the average cold start was around 20 seconds. With SnapStart, the total duration of a cold start execution dropped down to around a couple of seconds.

Just to show something visual, the following chart is generated from a sample of invocation duration data of the SpringBoot application that’s deployed to AWS Lambda.

 

When we enable SnapStart, the first thing we notice is the RESTORE DURATION which can be considered as the init duration of a cold lambda at this point. However, since it’s now starting from a snapshot of the execution environment, this duration is really small compared to the regular lambda.

Compared to the environment where SnapStart is disabled;

Conclusion

It’s always good to push the boundaries of our existing toolset and give people the ability to save time and improve their application’s overall performance. The AWS Lambda SnapStart feature certainly made it easier to run latency-sensitive serverless applications on Lambda.

*** This is a Security Bloggers Network syndicated blog from Thundra blog authored by Oguzhan Ozdemir. Read the original post at: https://blog.thundra.io/serverless-performance-boost-with-snapstart