Yan Cui
I help clients go faster for less using serverless technologies.
This article is brought to you by
Don’t reinvent the patterns. Catalyst gives you consistent APIs for messaging, data, and workflow with key microservice patterns like circuit-breakers and retries for free.
To find the answer to this question I put together a very simple test, but before we go into it..
Disclaimer: this test and its result should be taken at face value only, it is intended to illustrate that posting messages to an agent is super lightweight, but in a real world application there will be many other constraints and considerations (such as latency, etc.) that should be taken into account before you decide to use F# agent instead of other alternatives.
So, back to the test itself, here’s the test code:
the line that posts 30 million messages (4 byte integers in this case) to the agent returned in 0.983 second, but the agent actually took just over 12 seconds to receive and process all the messages.
Suffice to say that in most cases trying to get messages to a F# agent is unlikely to be the bottleneck in your system at a solid 30 million messages a second 
However, processing of those messages takes significantly longer, and if the backlog continues to build then eventually you will be hit with an OutOfMemoryException. Also, if you’re depending on a sync/async reply from the agent, latency can also be a big problem if the agent is allowed to build up a huge backlog of messages. Keep these in mind when you’re designing your application around F#’s agents.
Finally, for the question of ‘how many messages can you post to a F# agent in one second?’, on my Corei7 3.3GHz, the answer is a cool 30 million 
Whenever you’re ready, here are 3 ways I can help you:
- 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.
- 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.
- Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.
That is awesome. Probably a better question might be steady state, throttled where the garbage collector can keep up. Very nice.
I once experimented with re-writing Async and doing CML-style channels in F#. Got 1M ping/pong interactions a second, on i3. Would be fun if you could run and compare on your machine. Code here:
http://t0yv0.blogspot.com/2011/12/making-async-5x-faster.html
Interesting benchmark!
I’ve been working on a library for F#, named Hopac, that aims to make it easier to write efficient parallel, asynchronous and concurrent programs. You can find the library at:
https://github.com/VesaKarvonen/Hopac
I took the liberty of implementing similar benchmarks using various primitives of the Hopac library. You can find that benchmark at:
https://github.com/VesaKarvonen/Hopac/tree/master/Benchmarks/PostMailbox
As for the results, on my test runs, it seems that, in this benchmark, Hopac’s synchronous message passing primitives achieve up to about 6x better throughput. Also, Hopac’s asynchronous Mailbox primitive, which supports asynchronous message passing, seems to achieve, at peak, slightly better posting performance and about 5x better throughput than MailboxProcessor.
@Vesa – that’s amazing! It’s so good to see you and Anton bringing over your expertise from CML to the .Net world, I’ll check it out and let you know if I run into any problems. We have quite a few components and libraries in our stack which depend upon the F# mailbox abstraction, so it’d be of great interest to us to be able to significantly improve upon its performance.
Do you plan to release Hopac as a nuget package?
Thanks! Do note that Anton is not responsible for any potential problems in Hopac. :)
I do plan to release Hopac as a NuGet package, but there are still a couple of things, including both documentation and a couple of implementation issues, I want to do on the library before first release. It will probably take a week or two before first release depending on how much time I can put into working on the library.
It would be great to get feedback on potential problems when trying to use Hopac. The actually application I’m using Hopac for was structured with Hopac in mind. If you have an existing architecture using MailboxProcessors and Asyncs, then it probably won’t be as simple as replacing them with Hopac’s Mailboxes or Chs and Jobs, because there are some deeper differences between those. But I’m definitely looking forward to hearing about potential problems you might encounter. If you have any questions don’t hesitate to ask me.
@Vesa – thanks for the heads up, look forward to when the project hits Nuget. I had a look at the project last night and as you said, the abstractions offered by Hopac is quite different from the MailboxProcessor and will probably take a bit of work to adapt into our existing solutions, but the potentials are quite exciting and we’ll definitely try it out once our iPad launch is out of the way. I’m sure I will have plenty of questions for you when the time comes ;-)