Actors in Lift

[Bill Atkins]

I've been spending some of my spare time reading through Lift's source. A lot of websites that describe Lift emphasize that its architecture is based on actors an that actors are what give Lift its legendary performance.

But reading through the source, I found scant reference to actors. I did some further research and found this thread (http://groups.google.com/group/liftweb/browse_thread/thread/2a6590c341b11faa/8f7b298308c6ade4?) which confirmed what I'd begun to suspect: that actors in Lift are mostly used for Comet support.

So if it's not actors all the way down, how is Lift able to handle so much traffic? Or is it only the Comet subsystem that blows other frameworks out of the water and the standard HTTP request processing has more or less average performance?

[DoomPirate]

i think alot of the performance stems from the fact that lift is based on scala which runs about as fast as native java code.  The documentation will give you a better overall understanding of lift.

The actors part of lift is just another tool you can use in your web application. I think alot of people with large, complex, multiserver webapps migrate to akka actors instead of the default lift actors. 

lift actors isn't mandatory, i have a medium sized app that doesnt have any actors, but has plenty of ajax.

[DoomPirate]

everything is super fast in lift (and astonishly simple to code). I would say if a webapp cares deeply about performance, it should use lift.

[Naftoli Gugenheim]

Any quotes or links?

Just curious if these websites' wording is ambiguous/misleading or misinformed...

[Noel Welsh]

On Tue, May 31, 2011 at 4:13 AM, Bill Atkins <batk...@gmail.com> wrote:
> I've been spending some of my spare time reading through Lift's source. A
> lot of websites that describe Lift emphasize that its architecture is based
> on actors an that actors are what give Lift its legendary performance.

I can't address what you've been reading, but certainly the JVM blows
away the VMs of common web programming languages PHP, Python, and
Ruby. You have a much higher performance ceiling in Scala than those
languages, and furthermore the abstractions you need to build scalable
sites (non-blocking IO, memory mapped IO, etc.)

N.

--
Noel Welsh
Untyped Ltd                 http://www.untyped.com/
UK company number    06226466

[David Pollak]

On Mon, May 30, 2011 at 8:13 PM, Bill Atkins <batk...@gmail.com> wrote:

I've been spending some of my spare time reading through Lift's source. A lot of websites that describe Lift emphasize that its architecture is based on actors an that actors are what give Lift its legendary performance.

Don't believe everything you read. ;-)
 

But reading through the source, I found scant reference to actors. I did some further research and found this thread (http://groups.google.com/group/liftweb/browse_thread/thread/2a6590c341b11faa/8f7b298308c6ade4?) which confirmed what I'd begun to suspect: that actors in Lift are mostly used for Comet support.

So if it's not actors all the way down, how is Lift able to handle so much traffic?

Lift is JVM based (that's about 80% of it).  Lift does its best not to have any global locks or global dependencies (which results in being able to use more cores on a multicore machine).  But most importantly, Lift doesn't need filters on both sides of the request.  Many web frameworks that were not coded with security and type safety in mind have a request filter which parses and digests the input to make sure it's not malicious and then parses and tests the outgoing HTTP response for malicious content (e.g., XSS).  With Lift, you get predictable performance and a clear request/response path which means that you get predictable deployment and scaling characteristics.
 

Or is it only the Comet subsystem that blows other frameworks out of the water and the standard HTTP request processing has more or less average performance?

First, Actors are not magic.  Actors are a concurrency paradigm that simplifies multi-threaded code by reducing the cross-thread traffic to asynchronous messages.  Actors do not in and of themselves speed up the performance of a system and if you care about micro-benchmarks, I could write hand-tuned cross-thread communication that's faster than Actors.  This is not dis-similar from the fact that you can hand-code assembly language to always outperform a higher level language, but the limit of the complexity of an assembly-based system means that you get fast with simple, but as your system grows to be more complex, you need a higher level language to deal with the complexity (and these days, assembler on one generation of process may be much slower on another generation because of instruction sequencing which is why having a good optimizing compiler means that the compiler takes care of the current best practices in a given instruction set).

Lift has the most stable Comet implementation of any web framework that I know of.  That's why Novell selected Lift.  Part of this is because we could build more complex logic on top of the Actor paradigm and that more complex logic allows Lift to deal with the different failure modes that can be experienced between the browser and the server.

Lift's performance is very predictable and there are usually ways to tune performance in "hot spots".  Having predictable performance means you have manageable scalability and with manageable scalability, you have stable systems.  Thus Foursquare has been very stable compared with other services that have grown at the same rate as Foursquare.  The UK Guardian has also had very manageable, predictable performance (that's much faster than their Python app.)

In terms of actual performance, I've built Lift apps that render a full page with database access, access control testing, etc. that can serve 2,000 requests per second on my very fast i7 Quad core development box over a very clean network... that's tuning every little bit of the page generation.  The common "number" I hear is 100 pages per second on Lift apps deployed on EC2 instances.  So, getting 100 pages per second in a production app that's been written by a team where the optimization knob is turned toward "features and stability" rather than performance.  In any event, these kind of sustained performance numbers from a single server mean that you've got traffic in the top 1% (or maybe top 0.1%) of all sites on the net.
 

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net

Simply Lift http://simply.liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[batkins]

This is the one I remember most distinctly:

http://stackoverflow.com/questions/648964/why-is-the-lift-web-framework-scalable/742124#742124

[David Pollak]

On Tue, May 31, 2011 at 11:21 AM, batkins <batk...@gmail.com> wrote:

This is the one I remember most distinctly:

  http://stackoverflow.com/questions/648964/why-is-the-lift-web-framework-scalable/742124#742124

Yeah... every answer on that thread is flawed or downright wrong (like the top answer... it's wrong in terms of Lift and it's wrong in terms of an ideal description of computing.)

Please read http://lift.la/lift-state-and-scaling  It's an accurate description of Lift's tradeoffs.
 

On May 31, 12:10 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote:
> Any quotes or links?
> Just curious if these websites' wording is ambiguous/misleading or
> misinformed...
>
>
>

> On Mon, May 30, 2011 at 11:13 PM, Bill Atkins <batkin...@gmail.com> wrote:
> > A lot of websites that describe Lift emphasize that its architecture is
> > based on actors an that actors are what give Lift its legendary performance.

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[batkins]

Thanks for the detailed reply!

On May 31, 1:06 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> On Mon, May 30, 2011 at 8:13 PM, Bill Atkins <batkin...@gmail.com> wrote:
> > I've been spending some of my spare time reading through Lift's source. A
> > lot of websites that describe Lift emphasize that its architecture is based
> > on actors an that actors are what give Lift its legendary performance.
>
> Don't believe everything you read. ;-)
>
>
>
> > But reading through the source, I found scant reference to actors. I did
> > some further research and found this thread (

> >http://groups.google.com/group/liftweb/browse_thread/thread/2a6590c34...)

> Simply Lifthttp://simply.liftweb.net