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 email@example.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 -~----------~----~----~----~------~----~------~--~---