Lift only uses event-based Actors for supporting CometActors.  All parts of
the standard HTTP request/response cycle (except for the CometActors) are
handled on a single thread.
Having a single thread handle an HTTP request is not materially less
efficient in terms of multi-core CPU utilization than an event-based Actor.
 The reason for using event-based Actors is to not consume an OS thread
during very long wait periods.  Handing the thread back to the thread pool
means that you're not consuming stack or OS thread-based resources during a
long wait.  Waiting for a query to execute is not a long wait and one would
likely take more of a performance hit to put the thread back into the thread
pool and then get a new thread once the query was done than to block the
thread on IO during the query.

I should point out that JVM-based threading sits directly on top of OS
threading, so you can use as many cores as you have and have a fairness
algorithm that is OS based when you use JVM threads (which Scala does.)
 This contrasts markedly from Python and Ruby (MRI) which cannot use more
than 1 CPU per program (Python because of the global lock and Ruby because
them implementation is pure crap.)  Erlang implements its own threading
model and does better with IO than the JVM because its threading model is
optimized for giving slices to processes that have available IO resources.

When I did a recent benchmark of Lift, I was seeing that all 8 CPUs (4 cores
with 2 hyper-threads each) were being used to serve content because the
requests were parallel and the web container allocated one thread to each
request.

In terms of Lift's use of Scala Actors, it currently does use Scala Actors
for some pieces, but that's changing.  Given the persistent problems with
Scala actors, we are switching over to our own Actor implementation that
avoids Scala Actors' memory retention, etc. problems.

On Mon, Sep 21, 2009 at 12:01 PM, espeed <james.thorn...@gmail.com> wrote:

>
> I have been researching Web frameworks that will take advantage of
> multi-core chips, and I'm trying to get a picture for how Lift uses
> Scala's event-based actors for incoming page requests and how an
> application developer would use actors in Lift to make concurrent Web
> service or DB requests.
>
> From what I understand, incoming page requests are initially handled
> by a thread and then passed off to an event-based actor so the thread
> isn't tied up during the entire page request. For pages that are
> composed of data from multiple Web services or multiple DB calls, the
> page's app developer would create multiple event-based actor requests
> to the different Web services or the DB, depending on where the data
> is located. Correct? -- And if so, is there an example of how to do
> this the Lift way?
>
> Also, does Lift use the Scala event-based actors library its own?
>
> Thank you.
>
> James
>
>
>
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

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