Thanks Roland. I have been thinking the whole day on how to set the limit to recognize the capacity. Moreover how many actors should I spawn (secretaries in above case) to get the best output.
In normal concurrency world, you get a rough prediction from Amadahl's law to set the pool size. Thinking of the same as to set the # of actor's to spawn for time-management. (From whatever small akka experience I have had, I have realized that the main bottleneck is actually not CPU nor memory but bandwith) Secondly, I have observed this behavior: When I accept too many messages, my number of messages sent per second drastically drops. i.e. my remote actor receives messages at a very slow rate. Has it got to do anything with dispatcher? During profiling my CPU and memory utilization goes super high but messages are sent at very slow rate. I can see too many "Envelope" objects living many generations. Thanks On Saturday, 18 January 2014 19:46:21 UTC+5:30, rkuhn wrote: > > Hi Jatin, > > nicely done, that is a good visualization! For the last step—when load > grows beyond your capacity limit—you will have to respond to the incoming > events immediately with a negative reply. Every system has a limit, and > while it may be painful it is very instructive to admit that and make it > part of the design. > > Regards, > > Roland > > 18 jan 2014 kl. 07:45 skrev Jatin Puri <[email protected] <javascript:>>: > > Hello Viktor, > > Oops. At first I thought it was sarcasm :D > > This is what I would: > > Say I have 10 friends who need to be notified for an event. The friends > need to confirm in less than 5 minutes else I might consider them as > "not-attending" and let my boss know that my friends are not attending. (He > might release those passes for someone else) > > Plan-1: > ------- > At first, I would call them individually to confirm their attendance. But > during the call, I realize that I have received another event message and > that again needs to be told to others. And so I have to call the remaining > again. This process is time consuming so I turn to SMS rather than call. > > Plan-2: > ------- > When I receive an event, I send an sms to my 10 friends. > 1) In the SMS, I also include the rext "Please reply back Yes/No as > confirmation" > 2) But with time, I keep receiving more event messages. So I will maintain > a document where I keep track on who has replied back and not. The document > will be something like: > Event "A" (Received at time: 11 AM)- 1,2,3,4,5,6,7 > Event "B" (Received at time 11:05 AM)- 2,5 > > When all have replied back, I remove that Event from document. > 3) Perodically every 5 minutes, I scan through the document and for all > events for which I haven't received the notification from friends for last > 5 minutes, I manually call them to get confirmation. If even that is a > failure, I mark it as <dead> > 3) As more Events keep coming in, I realize that I am taking quite > sometime to read the confirmation from my friends and updating the sheet. > And my message-box is just getting flooded. > > Simple Queueing theory problem, my intake is more than my processing > capacity. So I need to increase my intake capacity or stop intaking > messages. > So I hire more people (Secretary). When I receive an event, I pass that > event to a secretary who is relatively free and they take care of informing > my friends. They do the same as discussed above and maintaining sheet. > > Plan-3: > ------- > With more events, I hire more people. But hey I have a budget and cant > exceed to more than 5 people. So I go clueless here. Small Ideas here and > there but I know they wont improve a lot. > > This sounds a lot like Congestion Control from TCP. > > > On Saturday, 18 January 2014 01:34:01 UTC+5:30, √ wrote: >> >> Hi Jatin, >> >> You didn't answer my question :( >> >> Cheers, >> V >> On Jan 17, 2014 8:45 PM, "Jatin Puri" <[email protected]> wrote: >> >>> Hi Viktor, >>> >>> An another alternative instead of scheduling messages with time >>> managemen,t would be to use `ask` pattern and later with `Future.sequence` >>> to do the job. >>> This way I might have more control over parallelism. I haven't written >>> test cases to compare them. But what do you think? >>> >>> On Friday, 17 January 2014 21:27:21 UTC+5:30, √ wrote: >>>> >>>> Let's just take a step back. Let's ignore Akka for now, this is a >>>> classic problem in distributed communication: >>>> >>>> If you were to model this in the real world, with people instead of >>>> actors, and communications can, as always, fail—how would you solve it? >>>> >>>> Cheers, >>>> √ >>>> >>>> >>>> On Fri, Jan 17, 2014 at 4:40 PM, Jatin Puri <[email protected]> wrote: >>>> >>>>> Hmm. I thought about that But I don't see how the problem is solved as >>>>> the bottleneck is still exerted by a single actor again. You mean spawn >>>>> an >>>>> actor for each message? >>>>> >>>>> Or actually I can have a Router with say 5 actors which manage time >>>>> management thing. This might slightly help I guess. >>>>> >>>>> Any architectural advice? How do people handle such cases? >>>>> >>>>> -- >>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>> >>>>>>>>>> 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/groups/opt_out. >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> √ >>>> >>>> * Viktor Klang* >>>> *Concurrent, Distributed* >>>> >>>> Twitter: @viktorklang >>>> >>> >>> -- >>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>> >>>>>>>>>> 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/groups/opt_out. >>> >> > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> 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] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > *Dr. Roland Kuhn* > *Akka Tech Lead* > Typesafe <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/rolandkuhn> > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
