Björn thankyou for taking the time to comment. *Hadn't appreciated the lower number of threads / reduced context switching overhead so very useful.*
*Jon* On Tuesday, March 3, 2015 at 5:11:27 PM UTC, jamiex...@gmail.com wrote: > > > Sorry if perhaps too general for this group but I've been struggling with > somewhere appropriate to ask. > I have done quite a bit of reading but haven't found anywhere yet that > answers my questions in a way my small brain can understand. > > > I understand what Asynchronous and Non-Blocking I/O means, *what I am > trying to understand is when I can expect to see improvements in > performance by adopting an Asynchronous and NIO framework such as Akka.* > > > > *I have the following assumptions - it would be great if anyone could > agree/disagree (Assume a Request/Response in a Web Application that has > some blocking calls in the business tier):* > > > 1. Even though some actors will process their messages and quickly > delegate to other child actors asynchronously, there will be some child > actors that will eventually have to deal with blocking I/O at the > boundaries of an application right? > > These actors will still be running in a thread which will block for the IO > right? > > Such Actors would (at high level) be equivalent to the Workers in > languages such as Node right? > > > > 2. In an asynchronous architecture, I'm assuming that I will only see > improvements in the speed of a request/response round trip if there are > several transactions (as part of the request) that I can now parallize > (assuming multi-cores available). > > *ie. Lets say I have the following scenarios for my request/response:* > > *1 Single blocking call to do * - Even though messages used to deal > with this transaction will largely be passed around the system > asynchronously, I will likely not see an improvement in speed of the > request/response round trip since the single piece of I/O work will still > take as long as it takes right? > > > *Multiple Blocking calls to do that I can run in parallel * - if > (in servicing the request) I have several pieces of blocking work to do > (maybe 1 web service call, 1 DB transaction, 1 cache call) AND I can run > them in parallel then I will likely see an improvement in speed of the > round trip based on the divide and conquer approach of the I/O stuff > > > *Multiple Blocking calls to do that I CANNOT run in parallel * - > if the several pieces of blocking work need to run in sequence then I am > still unlikely to see an improvement in speed since I cannot parallelize > the I/O right? > > > > > Many thanks > James > > > -- >>>>>>>>>> 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+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
