Re: LISP for web
- From: Brad Anderson <brad@xxxxxxxxxxxxxxx>
- Date: Mon, 13 Jun 2005 13:03:10 -0500
Marco Baringer wrote:
> Brad Anderson <brad@xxxxxxxxxxxxxxx> 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 is what we have in production at work. LVS with session
persistence allowed us to remove the affinity settings by class C
address (keep sessions on one app server) and move to more of a
round-robin or least weighted connections.
> 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.
Fast session serialization is the feature I'm interested in. You can
even store the sessions in memcached *and* the database, and if you get
a cache miss, go to the slower database. A new thread can take care of
the session writing to the store, if you can live with 'dirty session
writes' (can't think of a better name). This gets you to sending back
the html faster.
>
> 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)).
Agreed, and we have an active/active database cluster (MS SQL Server).
I would like to re-create this with Postgres (and use Slony, maybe?? I
think we'd need to use LVS at this level too, after the replication is
working.)
>
> 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 :)).
>
For now, I'm using UCW on a small personal site, but with these
features, it would be much more attractive to use at work. I'm afraid I
can't pay you yet. I'd need to make some inroads w/ Lisp in other
places first. I'm attempting to displace a J2EE system piece-by-piece,
and I'm starting with the core classes, not the presentation layer.
BA
.
- References:
- LISP for web
- From: Damir
- Re: LISP for web
- From: drewc
- Re: LISP for web
- From: R. Mattes
- Re: LISP for web
- From: Marco Baringer
- Re: LISP for web
- From: Peter Scott
- Re: LISP for web
- From: Marco Baringer
- Re: LISP for web
- From: Marco Baringer
- Re: LISP for web
- From: Brad Anderson
- Re: LISP for web
- From: Marco Baringer
- LISP for web
- Prev by Date: Re: I've thought better of Linux
- Next by Date: Re: I've thought better of Linux
- Previous by thread: Re: LISP for web
- Next by thread: Re: LISP for web
- Index(es):
Relevant Pages
|