On Fri, Jul 10, 2009 at 6:50 AM, David Pollak <feeder.of.the.be...@gmail.com > wrote:
> > > On Fri, Jul 10, 2009 at 12:40 AM, DFectuoso <santiago1...@gmail.com>wrote: > >> >> Thanks, that was very useful, to enable sticky variables i would do >> something like (explain here >> http://wiki.stax.net/w/index.php/Application_Clustering >> ) that? >> >> So bottom line? An actor can send a message an actor that is living in >> another JVM > > > Scala's remote actors are very, very fragile and have not been used in any > kind of production or load environment to my knowledge. They rely of Java's > serialization mechanism which has a series of problems (fragile in the face > of different class versions on different nodes, the tendency to serialize > the world because of references to globals, and the unsolved problem of > serializing Scala singleton objects). > > I'm addressing these issues with Goat Rodeo (http://goatrodeo.org), but it > won't be ready for other people to mess with for a couple of months. > And a follow up... what kind of application do you have that requires more throughput than a single JVM can handle? In benchmarks that I've done, a big RDBMS gets saturated around the same time that a single Lift app gets saturated. A big RDBMS can handle about 10K requests per second if most of those requests are reads and they come from cache. If you have ACID enabled (so every write goes to disk), best case is 2K writes per second. A well tuned Lift app can serve 2K dynamically generated pages on a quad core box. If each page has a couple of read queries and a write query, you're pretty close to saturating you RDBMS. So, unless you're at Twitter/Facebook/LinkedIn levels of traffic, you'd be best designing your app for a single JVM. Once you get to the 100+ pages per second range, call me and we'll figure out how to distribute your app across more than 1 server. > > > >> using sticky variables(or anything else) (sorry i don't >> know if that terracota, don't know what that is) >> >> On Jul 9, 11:53 pm, "marius d." <marius.dan...@gmail.com> wrote: >> > Actors are local to the JVM. Scala also has RemoteActors but we don't >> > really use them. For a lift app in a cluster environment we have to >> > have sticky sessions concept and the reason is that functions bound to >> > a session and mostly the references they are holding are not >> > serialized & distributed. So assuming: >> > >> > 1. Session 1 is created on Node 1 >> > 2. If on a subsequent request (pertaining to the Session 1) load >> > balancer decides to dispatch the request on Node 2 you are loosing all >> > session context including bound functions etc. >> > >> > This is why the load balancer must guarantee that all requests >> > pertaining to the same session needs to be dispatched on the same >> > node. >> > >> > There were some efforts in the past to integrate Terracotta but I >> > guess there was a dead end somewhere. >> > >> > You can of course build you own app to not use functions bound to a >> > session and only rely on DispatchPf style (somehow similar with Spring >> > controllers) but that's not very lift-ish. But in this case you can >> > persist your state in DB (which is common to all nodes) and when a >> > request comes you just fetch the context data from DB and set your >> > SessionVars. The problem with functions kept on the session is that >> > those function can be lambda expression referencing members from other >> > classes which are not serializable etc. And even if they somehow were >> > Java serialization is bad for performance. >> > >> > The bottom line is that sticky sessions have the benefit of the >> > performance because there is no state that needs to be distributed and >> > replicated among all cluster nodes OR no need to persist the session >> > state. But the drawback is that requests pertaining to the same >> > session needs to be processed by the same node. >> > >> > IMHO using Lift apps in a cluster env. without sticky sessions can be >> > a very tricky thing to achieve. >> > >> > Br's, >> > Marius >> > >> > On Jul 10, 6:32 am, DFectuoso <santiago1...@gmail.com> wrote: >> > >> > > I'm hosting some experiments on Stax and right now im pondering over >> > > the idea of checking out how to have a database backed session so the >> > > SessionVars work in a cluster of 5 boxes; With that in mind, have >> > > anyone worked with actors and clustering? Is there some documentation >> > > around that? should it work out of the box, or some works of >> > > encouragement to try working on this terrain? >> >> >> >> > > > -- > 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 > -- 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 -~----------~----~----~----~------~----~------~--~---
