AWS Lambda – comparing platform performances

As Lambda adds nodejs 6.10 to its supported platforms I wondered if there’s any performance differences between the platforms. Thankfully the templates in the Serverless framework make it a relative breeze to test it out with a simple HelloWorld function.


The Test

see the test code here.

I created a simple Lambda function for each platform that will respond to an API Gateway event and return “hello”. This is the nodejs version.

I decided to use API Gateway as the trigger as it allows me to invoke the function and apply a constant load using standard load testing tools for HTTP. I chose Artillery because you can get going with minimal fuzz and I had used it before.

For each platform, I ran a test with 10 virtual users sending 1 request per second (ie. a total of 10 req/s) for an hour.

artillery quick duration 3600 rate 10 n 1 http://my.lambda.backed.api/

Since we’re interested in the performance characteristics of the different Lambda platforms, we’ll only be looking at the function Duration metric, and we’ll ignore the initial cold start times.


Observation 1 – C# is slower?

Unsurprisingly the invocation duration is fairly consistent across the functions, although C# is sticking out like a sore thumb.

Take this 10 mins window for instance – where there were no spikes that looked like cold starts – the C# platform is consistently higher than the rest.


Observation 2 – Java has very consistent performance

If you look at the max duration for the same 10 mins window – for whatever reason, I didn’t get any percentile metrics from CloudWatch for the entire duration of the test so had to settle for max instead – the Java platform was both lower and had less variance, by some distance.

If you compare the average and max duration for the Java platform over a longer time window, you’ll also see that there’s very little difference between the two (if you ignore the spike at 01:38 which might be down to GC pause as opposed to cold start) which suggests the performance of the Java platform is very consistent.


Observation 3 – static languages has more consistent performance?

Following on from the previous observation, it seems that both C# and Java shows less variance when it comes to max duration, so perhaps it’s because both are compiled languages?


Observation 4 – Java packages are big…

One of the benefits with using nodejs and Python to write Lambda functions is that they produce much smaller packages, which we know translates to lower code start time. Now, the fault might lie with the Serverless template for aws-java-maven, but my HelloWorld Java example produces a whooping 2MB package, which is orders of magnitude bigger than the nodejs and Python functions. I expected it to be bigger than nodejs, but perhaps closer to the size of the C# package.



Take these results with a pinch of salt. Things are evolving at an incredible pace and whatever performance discrepancies we’re seeing today can change quickly as AWS improves all the platforms behind the scenes.

Even as I observe that the C# platform appears to be slower in this test, we’re talking about sub-millisecond difference for a HelloWorld example, hardly representative of a real world application. The DotNetCore platform itself (which C# Lambda functions run on) is also evolving quickly, and any future performance improvements in that underlying platform will be transferred to you at no cost, so don’t let this post dissuade you from writing Lambda functions in C#.

MS Bond benchmark updated

DISCLAIMER : as always, you should bench­mark against your pay­load and use case, the bench­mark num­bers I have pro­duced here is unlikely to be rep­re­sen­ta­tive of your use cases and nei­ther is any­body else’s bench­mark numbers.

You can use the sim­ple test har­ness I cre­ated and see these exam­ple code to bench­mark against your par­tic­u­lar payload.


I recently added MS Bond to my benchmark and found some interesting numbers, which prompted a question on their repo.

Adam Sapek explained that the slow serialization speed I was seeing was down to the default buffer size being 64KB which is not suitable for the payload I was testing with.

Adjusting the buffer size to 256 bytes resulting in some pretty amazing result:



Fastest serialization & deserialization, and smallest payload.



Have a look at the performance tuning guide, there’s quite a few tweaks you can do to improve performance further but it’ll depend on your payload.

MS Bond and Chiron benchmarked

DISCLAIMER : as always, you should bench­mark against your pay­load and use case, the bench­mark num­bers I have pro­duced here is unlikely to be rep­re­sen­ta­tive of your use cases and nei­ther is any­body else’s bench­mark numbers.

You can use the sim­ple test har­ness I cre­ated and see these exam­ple code to bench­mark against your par­tic­u­lar payload.


I updated my binary and JSON serializers benchmark earlier this week, and got some feedbacks on new serializers that I have missed, namely Chiron and Microsoft’s Bond. Here, we’ll have a look how the two fared in the benchmark.


MS Bond

Microsoft announced their answer to Google’s Protocol Buffer with Bond this time last year (Jan 2015). Finally I’ve got around to actually test it out (after an ex-Gamesys colleague commented on the last update – thanks Rob!).

First, you define you contract with a .bond file (see tutorial here), for example…


Now you run the Bond compiler tool, gbc, against this file to generate a C# class that looks like this…


To serialize and deserialize data, you also need to add the Bond C# nuget package to your project and follow the examples in the aforementioned tutorial.

Here’s how Bond fared against other binary serializers on my list.

NOTE: there’s an updated benchmark test that uses a different initial buffer size which makes a huge difference in performance for Bond. Please read the linked post for more info.



The result makes for an interesting reading…

  • Bond produced the smallest payload, and is the fastest at deserializing the payload by some distance.
  • It is also the slowest at serializing the payload!



I read about Chiron in Marcus Griep‘s F# advent post but then forgot about it (totally my bad… too many hours on Bloodborne over xmas, such an awesome game ).

Anyways, Chiron has a F#-friendly API but because it uses statically resolved type parameters you can’t use it from C#.

In order to serialize/deserialize a type, the type needs to define the static methods ToJson and FromJson. The inlined serialize and deserialize functions can then constraint your type to have those static members and invoke them in the corresponding function. I used the same technique in MBrace.AWS and honestly, I’m not happy with the amount of work this pushes onto the user, especially when they end up having to write uninteresting plumbing code…

On the API front, I’m not thrilled with the custom operators either, even though there are only 3 of them so I’m probably just over-reacting. In general I find custom operators get in the way of discovery.

Reading through the post, this paragraph suggests a lot of intermediate JsonResult<‘a> and Json objects are created during the serialization process. Whilst this might be an idiomatic functional approach, it’s also likely to hurt our performance..

The *> operator that we used in ToJson discards the JsonResult<'a> (which is only used when writing), but continues to build upon the Json object from the previous operation. By chaining these operations together, we build up the members of a Json.Object.

Unsurprisingly, the cost of immutability proved really costly under the benchmark.




So that’s it folks, another 2 serializers added to our stable. If there any other serializers that you think I should include here, please give me a shout and I’ll do my best to accommodate.

Binary and Json benchmarks updated

It’s been a while since I last updated my binary and JSON serializer benchmarks, so here I round up the latest versions of the serializers on here.


DISCLAIMER : as always, you should bench­mark against your pay­load and use case, the bench­mark num­bers I have pro­duced here is unlikely to be rep­re­sen­ta­tive of your use cases and nei­ther is any­body else’s bench­mark numbers.

You can use the sim­ple test har­ness I cre­ated and see these exam­ple code to bench­mark against your par­tic­u­lar payload.



Only FsPickler was updated for this benchmark so there are no significant changes in numbers here (with the exception of the BinaryWriter!).





Quite a few of the JSON serializers have been updated:

  • FsPickler
  • Jil
  • MongoDB Driver
  • NetJson
  • Newtonsoft.Json (aka Json.Net)
  • ServiceStack.Text

Jil seems to have made the biggest gains since the last time.



*protobuf-net is in this list purely as a benchmark to show how the test JSON serializers compare to one of the fastest binary serializers (both in terms of speed and payload size)

Fasterflect vs HyperDescriptor vs FastMember vs Reflection

The other day I had a small task to inspect return values of methods and if the following property exists then set it to empty array.

        public long[] Achievements { get; set; }

This needed to happen once on every web request, and I decided to implement it as a PostSharp attribute. WHY I needed to do this is another interesting discussion, but broadly speaking boils down to assumptions baked into base class’s control flows  no longer holds true but is inflexible to change.

A major refactoring is in order, but given we have a deadline to meet, let’s take a technical debt and make sure it’s in the backlog so we know to come back to it.


So I went about finding a more efficient way of doing this than hand-writing some reflection code.

There’s Jon Skeet’s famous reflection post but to make it work across all types and incorporating IL emit is more complex than this task warrants.

sidebar : if you’re still interested in seeing how Jon’s technique can be applied, check out FSharpx.Reflection to see how it’s used to make reflection over F# types fast.

Then there’s Marc Gravell’s HyperDescriptor although the Nuget  package itself was authored by someone else. Plus Marc’s follow-up to HyperDescriptorFastMember.

I also came across a package called Fasterflect which I wasn’t aware of before, from its project page the API looks pretty clean.


Test 1 – 1M instances of MyTypeA

Suppose I have a type, with the Achievements property that I want to set to empty whenever I see it returned by a method.


To do this with reflection is pretty straight forward:


With Fasterflect, this becomes:


I do like this API, it’s very intuitive.

And here’s how it looks with HyperDescriptor and FastMember:


Now let’s run this across 1M instance of MyTypeA and see how they do. Both Fasterflect and FastMember did really well although HyperDescriptor was 3x slower than basic reflection!



Test 2 – 1M instances of MyTypeA and MyTypeB

Ok, but since this code has to work across many types, so we have to expect both

  • types that has this property, and
  • types that don’t

To simulate that, let’s introduce another type into the test.


Instead of working with an array of MyTypeA, now we have a mixed array of both MyTypeA and MyTypeB for our test.


and the result over 1M objects makes for interesting readings:


some observations from this set of results:

  • we need to invoke the setter on only half the objects, so reflection is faster (almost halved) than before, makes sense;
  • both FastMember and HyperDescriptor are faster due to the same reason as above;
  • having less work to do had much smaller impact on FastMember suggests some caching around the call site (and indeed it does);
  • WTF is going on with Fasterflect!



The morale of this story is that – always verify claims against your particular use case.

Another perfect example of this is Kyle Kingsbury’s work with Jepsen. Where he uses a generative testing approach to verify whether NoSQL databases actually provide the consistency model that they claims to offer. His findings are very interesting to read, and in many cases pretty worrying

Oh, and stick with FastMember or reflection