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
-~----------~----~----~----~------~----~------~--~---

Reply via email to