Re: [akka-user] Re: CPU-usage and a lot of actors with cluster-systems

But! It is important for me that the work of message 1 is done before > message 2 is handled. And isn't one of the benefits for the actor model and > akka itself, that I have the garantee to that message 1 is done before > message 2? > > Yes. And you might be in trouble there. In which

[akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Hi, I think you (and probably everyone else here) need more data to figure out why your system is behaving as it is. Above, you write the configuration with four machines exposes the behaviour you describe. Does that mean with 12 machines the CPUs are fully utilized? What about a single

Re: [akka-user] Re: CPU-usage and a lot of actors with cluster-systems

I'm not saying use a lot of dispatchers. I'm saying that you should delegate to maybe 1 more dispatcher for your heavy work to unblock your actor's dispatching thread (and definitely another for blocking IO) allowing it to put more of your Actor's mailbox entries to work concurrently. In one

Re: [akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Thanks Hazen for your explanation and your comment. I hope I understood everything right! :) You want to split the work inside an actor and use e. g. two executors, one for the actor stuff and one for the heavy work (io...). But! It is important for me that the work of message 1 is done

[akka-user] Re: CPU-usage and a lot of actors with cluster-systems

That's possible. Your actor won't be able to get more work until it completes its receive. You could: A: look into actor pool/routers. This will give you more receive blocks to work with, increasing concurrency. B: look into spending less time within your receive block, maybe by delegating

[akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Am Mittwoch, 18. November 2015 00:39:46 UTC+1 schrieb Jim Hazen: > > Also, the default akka-remoting utilizing Java serialization is dog slow. > There are other threads that discuss swapping out the serializer with much > faster ones. So if you're doing a lot of cluster sharding, your

[akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Thanks again for your interesting points, jim I already have a separate dispatcher for the actors and one for the system. Am Mittwoch, 18. November 2015 18:30:13 UTC+1 schrieb Jim Hazen: > > That's possible. Your actor won't be able to get more work until it > completes its receive. You

Re: [akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Be sure you aren't just separating your actors onto their own collective executor, but put the work each actor is doing onto an executor. The goal is to drive as much work as possible into these executors, and free up akka's executors to simply drive this work into to those other executors as

Re: [akka-user] Re: CPU-usage and a lot of actors with cluster-systems

What kind of work is performed by the actors? If you already have 2 actors I don't think the advice about delegating to futures will help. /Patrik ons 18 nov. 2015 kl. 20:36 skrev : > Be sure you aren't just separating your actors onto their own collective >

Re: [akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Thank both of you for your answers, @Jim; so your solution would be to use a lot of dispatchers/executors to resolve the problem; doesn't this lead to a lot of overhead and makes the application more complex than it should be? @Patrik; Hello Patrik, each actor has a geo-locaiton condition to

[akka-user] Re: CPU-usage and a lot of actors with cluster-systems

Also, the default akka-remoting utilizing Java serialization is dog slow. There are other threads that discuss swapping out the serializer with much faster ones. So if you're doing a lot of cluster sharding, your throughput may be bottlenecked on the remote inter-node IO. -- >>