[Bese-devel] Re: LISP for web

[Marco Baringer]

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Brad Anderson <brad at dsource.dot.org> writes:

> Ideas on how to store this information centrally for all of the app
> servers?  I would love to see either a RDBMS (Postgres) or Memcached
> (http://www.danga.com/memcached/) option.
>
> [snip]
>
> This would allow me to use UCW not only in personal projects, but at
> work as well.  Any timeline?  I can do some testing, although I'm a
> bit of a newb.

we're talking about two different things:

1) scalability. can you increase the performance of a ucw app by
   adding hardware? two options:

   a) manage sessions with cookies and use pound for load balancing
      (www.apsis.ch/pound/). this is by far the simplest solution and
      is doable today with the current ucw code base. you still run
      the risk of losing data and sessions if one of the machines goes
      down and, if you're unlucky, you could still end up with one
      machine serving lots of busy sessions and another sitting
      idly. if you can't use cookies then you'd need to change some of
      ucw's form handling code (to make sure session ids are always
      passed in the url), this is fairly easy but hasn't been done yet
      (and won't get done unless i need it or someone else contributes
      it).

   b) store the sessions in a memcache (thanks for the link btw) or an
      rdbms and use lvs (www.linuxvirtualserver.org) to balance the
      work on the machines. this has the advantage that you won't end
      up with one busy machine and one idle machine and lvs deals hot
      swapping of machines and dead nodes transparently. this has the
      major disadvantage that, as of now, you can't do it since
      there's no way to store a session in anything but local
      ram. once sessions are completly serializable then this requires
      modifying find-session, expire-session and adding a new :after
      method on service (to store the changed session back in the
      db). since each and every request will require first fetching
      the session object and then, just before sending back the html,
      puting the session object back into the store (it has changed in
      the mean time) we will need to make sure session serialization
      doesn't become a bootleneck.

2) high availablity. can you create a ucw app which is resistent to
   hardware failures? not currently. the load-balancing solution in
   (1.b) can deal with hardware failures an the app servers but this
   leaves the db as a spof. the only 'real' solutions to this is to
   use a db which supports replication and store sessions in the db. i
   think postrgesql can but i haven't checked in a while and i know
   berkeleydb does (though i've never actually used it)).

as far as ucw is concerned the only thing missing is fast session
serialization and this will happen as soon as I convince someone to
pay me for it (hint hint hint :)).

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen