Hi John, On 28 Aug 2015 17:15, "John" <[email protected]> wrote: > > I have two Akka 2.3.9 actor systems that interact via remoting using the netty tcp transport. > > One system is essentially a resource manager. It maintains a large list of resources and responds to CheckIn and CheckOut messages. Operations performed within this actor are not cpu or memory intensive. (It's moving resources from one list to another, sorting list, etc.) Its actors use the default UnboundedMailbox > > Client systems are actually doing work with the resources they checkout from the resource manager. Currently I'm just running one client system on the same machine as the resource manager, but the goal is to have multiple client systems and one resource manager. > > Even with just one client system, message volume back and forth is fairly high -- at least 10's if not 100's of messages per second. > > As far as I can tell right now, the biggest bottleneck in the client system is waiting for a response to a CheckOut message.
What you are describing is not a bottleneck, you're describing a symptom. Do you know _why_ it is waiting? (i.e. what the bottleneck is) > > Adding a BufferedResourceManager actor to the client system which ChecksOut pools of resources in advance alleviates the bottleneck, but it kind of goes against the purpose of the resource manager: ideally I'd like it be tracking when and how things are actually used, not when one client assigned them to a pool. It also won't scale with multiple clients. (One greedy client could easily pre-fetch entire resource pool and block all others.) > > Is the fact that I need to do pre-fetching a sign that my design is broken? Once the CheckOut message is receive by the resource manager it is processed in ms (if that), so the latency all seems to be in going back and forth over the transport, waiting in the mailbox, etc. One optimization would be spin up multiple ResourceManager actors that can respond to requests in parallel (in a pool or something), but then I'm back to all the headaches of dealing with a single resources from multiple threads concurrently. > > I know this is a very vague question. Perhaps some more specific ones might be: > > * Is there a faster transport than netty tcp? > * Given the basic problem: I'd like to respond to 10's, 100's or even 1000's of easily-processed messages every second where processing each message involves access to shared, non-thread-safe, resources. What are some standard strategies? I have the sinking feeling that I'm just going to have to bite the bullet and make the resource management stuff thread-safe. (Current setup seems like a weird fit for akka -- I can't really take advantage of easy-to-reason-about-concurrency if I'm trying to totally avoid concurrency for the key segment of the system.) > > -John > > -- > >>>>>>>>>> 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. -- >>>>>>>>>> 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.
