Search Unity

Advanced Servers: MS Orleans vs Akka.NET vs java Akka review

Discussion in 'Multiplayer' started by snacktime, Sep 20, 2017.

  1. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Thought this might be useful, since it includes information you won't know before you use both of them to some extent. I will be assuming that you know the basics of what these frameworks do. This is mainly for those that are actually evaluating which one to use and have done at least a basic level of research.

    So preface, I am the author of Game Machine, which was one of the first frameworks to use the actor model for realtime game architectures. Since then most medium to large studios have adopted this architecture on new games.

    FYI Game Machine is dead, this isn't a plug. At the time creating it in .Net simply wasn't an option, the tools weren't available. I've since moved on to using .Net, although have not released anything there as open source and it's likely I won't (time considerations being why).

    So I have considerable experience and time testing java Akka. Akka.NET, and Orleans against similar workloads. In most cases the hot paths are basically the same code just ported to one of the 3 frameworks.

    Ok so to the meat of it....

    First a note on one of the most common problems faced with realtime games at any scale. Generally you want things local. Clients in the same visual range/zone/region/whatever your boundaries are, it's ideal to have all of those on the same server. Both to keep latencies lower and to avoid extra serialization cost. GC pressure from serialization becomes a real bottleneck, and one you can't solve by just throwing more memory or cpu at the problem.

    Most of the tests I did were against a common hotpath. Messages that deal with position updates, the ones you are generally sending 20 times a second or so.

    MS Orleans
    Orleans has what they call the virtual actor model. In a nutshell the main difference is you can create an actor in a cluster with a unique id, and you don't have to care or know where it's at. It's all managed for you. This model is very nice, it fits most of what we do in realtime games.

    So that's a big pro.

    The main con is that Orleans is slow in the single machine case. Calls to actors (grains) take around 10x longer and chew up considerably more cpu time then Akka.Net. It's a very significant absolute difference.
    That said, it's not actually a huge deal in a lot of cases. You are trading the cost of extra hardware, for time and complexity you would face with another framework. And for a small studio, that can be a really good trade off.

    Another point to make is that how I fixed this, was simply moving the hot path outside of grains. So there are always creative ways to solve the problem.

    Another difference is if you don't want a message to a grain to go through deep serialization for local calls, you have to opt out by wrapping your messages in an Immutable wrapper they provide. Akka does not serialize local calls, it assumes if you want immutable, your message will be immutable.

    A minor but very irritating con is that Orleans scans your entire project for classes to serialize, vs letting you configure which classes via a config. They are fixing this in an upcoming release, but the impact is it takes around 40 seconds to start the server (vs 1-2 with akka). Which is really annoying when iterating on code changes.

    Akka.NET

    Akka.NET compared to Orleans is more like a tool set. It has the advantage of building on the experiences of akka, and overall it's better designed then Orleans. But there is a significant amount of up front architecture you have to build to get what Orleans gives you for free. The virtual actor abstraction is one I usually create on top of Akka when I'm using it. And in the Akka world that is by design. It gives you the building blocks but doesn't assume a lot of specific use cases.

    Building the virtual actor model yourself, if you know how is easy. It takes me a day to whip it out. But if you haven't done it before it would take a lot longer and you would most likely not get it right the first time around.

    Another pain point in akka is managing cluster nodes. You have to build that yourself. You need special deployment tools to manage it. Orleans requires a little bit of tooling but nothing like Akka.

    The pro's of akka is that it performs considerably better all the way around, and you can twist it to do anything you want.

    Java Akka
    To a large extent it's the same as Akka.NET. The main difference is that it performs better then Akka.NET. Mainly because while .NET is getting better, there are still many more people running high performance, scalable stuff in java then .NET, so from the language to the framework, you will find that overall it's optimized better. This is a generalization of course, but at a general level it holds true. Is it a difference that matters? Well when compared to the benefits of using the same language on client and server, my answer is no. It's why Game Machine is dead.


    Conclusion
    If you are a smaller studio who doesn't have a true backend expert, I highly recommend Orleans. I'm using Orleans on a game I'm building right now myself. Because it has fewer pain points that matter for an indie context. And I know I can fix the performance, even if it's by avoiding parts of the framework.

    At the same time, When I'm talking to funded startups who can afford high quality backend engineers, I generally suggest Akka.NET. Because while the short term cost is higher, long term costs will generally be lower.