How much context-switching overhead does Akka have?

[Amy O' Leary]

When you execute code in another thread there's a certain amount of overhead in context switching. Is there any additional overhead with context switching in Akka when sending messages between actors?

To follow on, would you recommend that wherever possible, we use actors instead of regular classes for each self-contained piece of work, even when the work cannot be done in parallel and we're dealing with CPU intensive tasks - i.e. not blocking on IO?

[Akka Team]

Hi Amy,

On Thu, Oct 2, 2014 at 6:34 PM, Amy O' Leary <amybl...@gmail.com> wrote:

When you execute code in another thread there's a certain amount of overhead in context switching. Is there any additional overhead with context switching in Akka when sending messages between actors?

There is some additional overhead from enqueueing the message in the mailbox and dequeueing it and the dispatcher assigning an available thread to the target actor if this have not happened yet.

You can reduce some of the overhead if you set the throughput setting of the dispatcher to a higher value: the default is 5, but once can go up to 1024. A higher value means that one actor will grab a thread for a longer time therefore reducing context switches but reducing fairness (latency deviation grows).

 

To follow on, would you recommend that wherever possible, we use actors instead of regular classes for each self-contained piece of work, even when the work cannot be done in parallel and we're dealing with CPU intensive tasks - i.e. not blocking on IO?

This is a question of granularity which cannot be answered easily -- it is something that comes with experience. It is not worth to put every little piece of functionality to its own actor, not just because of the inter-thread communication costs but also because it is harder to deal with asynchronous APIs than with synchronous ones. The other dimension to consider is failure recovery.

Actors are units of

 - Consistency: code inside of actors runs sequentially

 - Failure handling: actors can be stopped, restarted, etc on failure as opposed to usual Exception handling

Personally, in my projects there are usually four main types of entities

 - Immutable utility classes which are small and self-contained, and many times used inside messages

 - Mutable utility classes which can be unit tested separately and encode a unit of synchronous behavior (mutating API). These are never shared or passed between actors.

 - Actors that package up elements of the above types and aggregate them into a unit that

  * either benefits from the parallelization effects

  * and/or the state encapsulated inside the actor on failure must be either: completely dropped (Stop) or restored to a known initial state (Restart)

  * or implement time related behavior, timers, need timeouts, etc.

 - Actors that supervise a bunch of related actors and/or watch other actors, possibly remote. These actors represent a compound service aggregated from subsystems (other actors)

-Endre

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Akka Team

Typesafe - The software stack for applications that scale

Blog: letitcrash.com
Twitter: @akkateam