How does Orleans Performance Compare to AKKA?

[ukcoderj]

I've started to look at Orleans - looks great so far!

I'm trying to work out how Orleans compares to AKKA in terms of performance.

It seems AKKA can handle 50 million requests/second.

I'm struggling to find anything on Orleans - though I did find an article, in which a user hits 70 thousand requests/second.

Judging from the uses of Orleans (such as Microsoft Studios for gaming, Teams, Skype, Via + Parts of Azure), I'm sure it must be able to scale massively with high throughput (much higher than the 70K/s from the ticket).

What are the limits please?
What are the limiting factors wrt throughput please?
Is it possible to get to a similar performance as AKKA (even if using Azure/cloud infra to help get there)?

[ukcoderj]

I can't see how to close this.

Following a discussion with the team on Discord, I'm going to prototype both and compare them.

From my experience so far, Orleans is certainly a lot easier to use.

[Aaronontheweb]

Akka.NET can do ~350k msg/s per connection on my machine, and in 1.5 we're going to get that into the 1m+/s ballpark.

In terms of CPU utilization, I scaled this 200 node cluster https://github.com/petabridge/AkkaDotNet.LargeNetworkTests from ~20k msg/s to 700k msg/s without noticeable change in CPU. If there's anything we can do to make the Akka.NET experience easier to palette, please let me know.

[ukcoderj]

Hi @Aaronontheweb

Thanks for the response. I'm way off your marks here... I can only get 3k/s on a non-clustered, SQL persistent remoting demo (local machine, 5-10 console clients) and Im having trouble getting clustering working when calling outside the cluster (serialization). Not at a computer for a few days, but will message you when I'm back.

I'm keen to get the two demos going so the team can decide what works best.

Thanks again. J

[Aaronontheweb]

3k msg/s with a blocking Persist call in-between sounds about right for small groups of actors that use Persist calls as you're going to be rate-limited by the head-of-line blocking between sequential database calls (by design). I haven't profiled our SQL implementations for persistence in a while but you can see some figures we ran for Redis last year here: akkadotnet/Akka.Persistence.Redis#128 - you can see how the different method calls have impacts on end to end throughput there. These impacts are similar for every journal implementation.

When working with Akka.Persistence your performance is going to come down to largely flow control decisions, not the inherent overhead of the framework. i.e. changing from Persist to PersistAsync will result in a significant throughput increase (because interleaving + non-blocking), but it will be harder to reason about effects to your stateful actors since persistence completion orders are no longer guaranteed.

Most of the end to end requests in my large scale sample use Akka.Persistence (against Azure table storage) but there's large number of them running in parallel, so for any individual entity it doesn't effect total throughput much. Happy to help.

[ukcoderj]

That's really helpful. Thanks for the info. I'll look into some updates next week.