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 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?
And wouldn't that lead to the decision to use two actors for the task? one for the handling and one for the work? Best regards Flo Am Donnerstag, 19. November 2015 20:45:32 UTC+1 schrieb Jim Hazen: > > 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 of your posts you were afraid that actors "doing too > much" could be causing things to slow down. If your actors are blocking on > IO or some other lengthy task, a single actor won't be able to process > message 2 until the receive block from message 1 has completed. By > delegating heavy work to a different "heavy work" dispatcher, your Actor's > dispatcher can start to process more requests from the mailbox. This > allows more heavy/blocking tasks to be inflight. It doesn't make long > tasks take less time, but hopefully will allow you to maximize your > remaining resources either queuing up blocking work or processing the > results as they return. > > To Patrik's point. 20000 actors is already a lot of concurrency. Unless > you broadcast 5 messages to each while the first message waits for 10s on a > remote Geo call. Then you've spent some CPU queuing 100k requests, started > the blocking IO for 20k of those and then wait for 10s. This is an > exaggeration, but the idea here is that the time you spend waiting for IO > drives down your overall CPU utilization. If you're looking to maximize > CPU utilization you want all of your 100k requests in flight, saturating > your IO pipe, and then processing results as they return. After a window > of delay you should be processing results at the max speed of your network, > which ought to keep your CPU busier than it is now. > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
