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.

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.

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.