MS Bond benchmark updated

Yan Cui

I help clients go faster for less using serverless technologies.

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:

image

image

Fastest serialization & deserialization, and smallest payload.

Wow.

 

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.

Whenever you’re ready, here are 4 ways I can help you:

  1. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
  2. Do you want to know how to test serverless architectures with a fast dev & test loop? Check out my latest course, Testing Serverless Architectures and learn the smart way to test serverless.
  3. I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
  4. Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.

3 thoughts on “MS Bond benchmark updated”

  1. Pingback: MS Bond and Chiron benchmarked | theburningmonk.com

  2. The two graphs don’t use the same scale or order, so it’s kind of hard to tell, but it looks like everything else received a decent speedup, too.

  3. I ran them on different machines, which is why all the numbers are different. It’s the relative difference that is important here though (I would make that more prominent in future benchmarks).

Leave a Comment

Your email address will not be published. Required fields are marked *