Posts

Lambda Cold Start for ASP.NET (Part 3)

In this final post I’ll list a few additional optimizations for reducing the first invocation times. See part one and two for more details.

Burst CPU

According to this video Lambda functions get additional CPU during the initialization phase. That extra CPU can help with JIT compilation but .NET lazy compiles code as it encounters it. Therefore, the function handler is not compiled until it’s executed, which is after the CPU is constrained.

Lambda Cold Start for ASP.NET (Part 2)

In part one, I looked at what happens the first time an ASP.NET application is invoked in Lambda. When we left off, we had a roughly 3 second initial response time. In this post I’ll focus on the initialization phase and part three will focus on invocation.

ReadyToRun

As I mentioned earlier, one cause of long cold start times in .NET is Just In Time (JIT) compilation. As each .NET assembly is loaded, the runtime converts the Intermediate Language (IL) into machine code for the specific platform it is running on. ReadyToRun tells the compiler to generate machine code at compile time. This allows us to skip that step during initialization. Note that you must compile on the same platform you plan to run on. Therefore, we must build on a Linux machine for this to work in Lambda. I am using CodeBuild to build my project. I can enable ReadyToRun by adding the following to the PropertyGroup of my project file.

Lambda Cold Start for ASP.NET (Part 1)

The ability to host an ASP.NET project in AWS Lambda is a great way to get started with serverless. However, cold starts can result in a slow first invocation of the ASP.NET function. In this post I’ll set up a typical, albeit simple, application to gather benchmarks. In part two and three, I will explore a few options to speed up initialization and invocation respectively.

Background

A Lambda function is fundamentally different from a traditional application. Most important to the topic of Cold Starts is how an application is initialized. On a traditional web server, the application is initialized before it goes into service. The first invocation may be a little slower as caches warm up, but the application itself was already running. In Lambda, the application is initialized when the first invocation arrives. The request is enqueued, Lambda copies your application into a container, initializes the application, and then forwards the request to the container. The same thing happens as Lambda scales out and adds new containers. For subsequent invocations the application is already running the response is much faster. Often one or two orders of magnitude faster.