Nsryjdtyk

We use the Akka.net Framework for highly scaling applications in the energy sector.

We use Akka.net for various tasks, mostly in the following form:

var system=ActorSystem.Create("actorSystem");

var props=Props.Create<UpdateActor>();

               .WithRouter(new SmallesMailboxPool(100));

var actorRef=system.ActorOf(props,"UpdateActor");

foreach(var timerow in timeRowList)

   actorRef.Tell(timerow)

Unfortunately the Akka.net framework scales very badly in many cases.
The CPU load is only 12%.
Obviously only one thread or a few threads are used.

How can you configure Akka.Net to use multiple threads for processing the actors?

This is an educated guess, but if you're using SmallestMailboxPool, keep in mind that it works pretty badly with non-blocking I/O and terribly with stashing.

First thing is usually to check, if there are no blocking operations (like synchronous I/O, calling AsyncMethod().Result or Thread.Sleep), which will block current thread, effectively preventing it from being used by other actors.

Another issue is very specific to smallest mailbox router, and it's related to stashing and persistent actors.

Stashing

Stashing is one of the popular ways to work with multi-step operations. This pattern can be represented as bellow.

  public class MyActor : ActorBase, IWithUnboundedStash

  {

     public IStash Stash { get; set; }



     public Receive Active(State workUnit) => message =>

     {

        switch(message)

        {

           case DoWork: 

              // stash all messages not related to current work

              Stash.Stash(message); 

              return true;

           case WorkDone done:

              // when current unit of work is done, unstash pending messages

              Stash.UnstashAll();

              Become(Idle);

              return true;

        }

     };



     public bool Idle(object message)

     {

        switch(message)

        {

           case DoWork work: 

              StartWork(work.State);

              Become(Active(work.State)); //continue work in new behavior

              return true;

           default: 

              return false;

        }

     } 



     public bool Receive(object message) => Idle(message);

  }

This case is pretty common i.e. persistent actors use it during their recovery process. Problem is that, it's cleaning up the mailbox, which gives SmallestMailbox routers a false sense that this actor's mailbox is empty, while in practice it's just stashing all incoming message.

This is also a reason why peristent actors should not be routed using SmallestMailbox routers! Tbh. I cannot think of any scenario where putting persistent actors behind router of any kind is a valid option.