.Net Core Web API on AWS Lambda Performance

In order to understand what I’m going to talk about, you must know what is AWS Lambda, I talked about in this blog post where I went through getting started with Visual studio code and AWS Lambda, go through the intro section of that post before you proceed if you are new Lambda.

I know what is AWS Lambda, but .Net? Isn’t that very window’ey?

If you hate windows and hence hated .Net even more, I won’t blame you, .Net wasn’t modular, it forced you to stay on Windows (server costs!) and although it was always a fantastic platform to do whatever you wanted.. the ability of the platform to let you code an application the shittiest way possible and also the best way possible (believe it or not) led to a lot of people who were led astray to its dark side to think that .Net can simply never perform as well, at least not in the cost effective way that some other frameworks can.

All this changed with the introduction of .Net core which made the platform modular, open source and more importantly became cross-platform. .Net core therefore allowed people to develop using .Net core framework on Linux, Mac or Windows using the newly released Visual studio code which is also cross-platform (and free!). You can still use Visual Studio on Windows to get the full powered IDE on Windows and now there is even a preview mode of the same on Mac.

Web API is the Microsoft’s de facto solution for building http based services (REST services).

The actual blog, sans introductions

When I first heard about the AWS announcement regarding preview support for launching .Net core Web API’s on AWS Lambda, I was blown away. Although there has been first class support for .Net core in Lambda since 1st December, 2016 where you could make a single input Lambda function receiving binary/json data it is a whole another ball game if you can just put your existing .Net core Web API’s on Lambda with just a few tweaks, follow this AWS guide in how to do that.

How does it work.. Lambda..a single function hosting a Web API suite with lots of controllers?

Lambda is still the same, AWS now calls a function in your code defined in a base class called Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction available via the nuget package Amazon.Lambda.AspNetCoreServer which is in preview mode. The function then bootstraps the ASP.NET core framework allowing the rest of the request to flow through the Web API pipeline. Here is a trivialistic overview of the same for your pleasure:

.Net core web api on AWS Lambda

In between my euphoria I also thought that what will be the startup latency of such a function, basically since Lambda functions are spun up on demand (while you pay by the 100ms blocks of your function execution time) and it has to bootstrap the entire Web API pipeline, how much will be the cold start time (when your function is called after a long/first time) and the warm up time (your function is continuously being called).

so…what are the performance numbers?

We will be talking about only the integration latency here which is the latency between when API gateway received the request and the time it took to allocate a Lambda function for that request till the time the latter successfully receives the command.

I ran a free load test from Load Impact and went upto 25 users on a step load. The code that I used was .Net core Web API (of course) with a single controller returning hardcoded values serializing in JSON and no compression was enabled. Here are the results:

User vs load time

The load test runner was in south Brazil and the API was in Oregon (US).

integration latency

Average Integration latency: 89ms

Total number of requests sent: 139

I warmed up the function by only calling it once, the first call generally took > 2 seconds after 5-10 minutes of inactivity.

The load numbers isn’t in thousands, sure, couldn’t do more than that on a free account, it gives me a very good idea though.

In short, I am impressed and can’t wait for the package to come out from preview, thank you AWS!

If you liked this article, you can choose to follow this blog/subscribe to email alerts (top of sidebar or below comments in mobile) so that you know when any future posts come about.

Advertisements

15 thoughts on “.Net Core Web API on AWS Lambda Performance

  1. Pingback: .Net Core Web API Lambda, tested for Performance | Ace Infoway

  2. Hello,

    Great article, very interesting. Is there any chance you could do another where you go a bit more in depth in regards to performance?

    Thanks

    Like

    • What do you have in mind? Do you want me to talk about what all constitutes performance in the aws Lambda world like latency between isp’s to api gateway–lambda–impact of stateless code in Lambda for performance – – – back to gateway, the latter’s caching options etc? Or simply more numbers around what I wrote already?

      Like

  3. Pingback: .Net Core Web API on AWS Lambda Performance

  4. Pingback: .Net Core Web API on AWS Lambda Performance | ExtendTree

  5. Pingback: .Net Core Web API on AWS Lambda Performance - How to Code .NET

    • I didn’t load it up fully.. But I didn’t need to.. Lambda would internally spin off a new instance according to this formula:
      Instances = requests/ sec * time taken per request

      Lambda essentially gives unlimited throughput, it’s only the latency that you need to care about.

      In the graph that you see in the post, the bump in the response time was due to a new instance spinning off internally and the bump happened because I suddenly loaded lambda before it could anticipate it (which is what I wanted to know)… Does this answer your question?

      Like

      • It reached a max of .75 req/sec… I agree it won’t be constant, the bump in the graph indicated the same, I read your blog by the way… Great job and excellent comparison! However, AWS publishes the formula I gave in the previous comment… The throughput would lower when the Scaling happens (until its finished) according to the latter mentioned formula after which the throughput would go up again.. The time it takes to correct is in the graph in this post.

        Like

  6. Pingback: Best practices – AWS Lambda function | cloudncode

  7. .

    In the graph that you see in the post, the bump in the response time was due to a new instance spinning off internally and the bump happened because I suddenly loaded lambda before it could anticipate it (which is what I wanted to know)… Does this answer your question?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s