Thanks for the feedback David... I have also created a pool of actors and dispatch requests round-robin style to it. Oddly enough, I see absolutely no difference in the performance characteristics - in both cases 95% of the time is spent between the suspend and the actor receiving the request, but the mailbox never grows past a size of 1 or 2. I will try and send along a simplified version of my code to illustrate what I'm doing.
Thanks, Lincoln On Sun, Nov 8, 2009 at 11:02 PM, David Pollak <feeder.of.the.be...@gmail.com> wrote: > If you have all your requests going to 1 actor, then you've reduced your > application to a single threaded app. > > If you're using Scala Actors, there are all kinds of wacky things that > happen with the Fork-Join library that the Actors use for scheduling and a > whole lot of knobs to turn to get the scheduling right depending on your > number of CPUs, etc. > > But, at the end of the day, if you're just pushing work from one thread (the > thread that the HTTP request comes in on) to another thread (the thread > that's waiting for the RDBMS request), you're not saving any time or > threads, in fact you're only increasing the amount of thrash between > scheduling the Actor, suspending the HTTP request thread, etc. > > But, without seeing your code, it's hard to give you a better analysis. > > On Sun, Nov 8, 2009 at 7:08 PM, Lincoln <linxbet...@gmail.com> wrote: >> >> Hi, >> >> Currently I have a jetty webapp that uses continuations and actors to >> scale to many connections. While this isn't a lift question per se I >> was hoping the folks on this list could help since it's my >> understanding that Lift does similar stuff under certain setups. >> >> Basically, the functionality that I'm testing receives a request, >> suspends it via jetty continuations, and fires it off to an actor for >> processing. Once the work is done (some benchmark database requests, >> usually on the order of 10 to 100ms) the continuation is resumed and >> results are returned. >> >> As I scale up to 1000+ concurrents in apache benchmark, I notice that >> the vast majority of time from receipt of the request to response, is >> between when the continuation is suspended and when my actor receives >> the message. This strikes me as bizarre since I'm monitoring the >> mailbox and it never grows to a size larger than 1 or 2. It gets to >> the point where requests are taking 10 seconds to come back and 9.5 of >> those seconds are my actor waiting to receive the work request. >> >> Throughout the load test the database does not become stressed. >> >> Any thoughts on this? I guess I'm hoping there is something basic >> that I'm doing wrong. Just in case, I've tried creating an actor pool >> to receive the work requests but that apparently has no effect on the >> results. >> >> My only speculation at this point is that perhaps the reason messages >> are taking so long to get to my actor is because jetty itself is >> overloaded trying to queue requests but that is just a guess. >> >> Thanks, >> Lincoln >> >> > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---