On Sat, Feb 04, 2006 at 11:05:31AM +0100, Agustin Lopez wrote:

> Andrew Piskorski wrote:
> >On Fri, Feb 03, 2006 at 12:49:43PM -0500, Nima wrote:
> >>Dossy..when you look at the hardware would you say that I need more 
> >>dynamic servers and can I run serveral dynamic servers against on 
> >>postgresql? Using pound I add some more aolservers behind the scenes 
> >>connected to one databse.
> >
> >Of course you can - in fact that's the whole point, typically there is
> >no other way to do it.
> Are you sure? We try it but every aolserver (with OpenACS /dorLrn) has 
> his own cache and the sync among then was very bad.

Yes.  The cache management you're talking about is one of the
potential issues to overcome.  This HAS been made to work well enough
in the past for some users, and OpenACS has had code to facilitate
clustering that for a long, long time.

But MOST users of OpenACS don't care about support for multiple
AOLservers, and I would bet that many OpenACS developers pay no
attention to cluster support either, so I'm not surprised to hear that
it doesn't work correctly out of the box for some applications.

> Other related question: Are there any way to cluster the database 
> (Postgres) part?

That's much harder.  What you really need for that is PostgreSQL
multi-master replication, which does not exist, so the general answer
is no.  However, you might be able to get significant speed-ups by
sending non-transactional read-only queries to read-only PostgreSQL
slaves kept almost up to date with Slony.  How well that works
probably depends strongly on how Slony is implemented.

But of course, if you have a read-only query where it's ok for the
answer to be a bit out of data, you might prefer to just hit the
mastter db and then cache the result in RAM, even RAM on a remote
machine, with say Memcached.  Which you want to do depends on the

I don't know of anyone who's tried to use Slony with OpenACS for query
speed up.  At least a couple people have used Memcached.  Either
approach requires special code in your application.

See also:


AFAIK, a fully transparent, "Just run my database on a cluster of
machines, and my application code can't tell the difference except
that everything is faster" solution does not exist for ANY production
worthy disk-backed RDBMS.  E.g. Oracle has multi-master clustering but
it is useful only for fail-over, it does NOT help performance.

The closest thing for PostgreSQL was probably Postgres-R.  If I
remember right, it was multi-master (I think?), and let you add more
database machines to scale somewhat with increasing client load, while
keeping everything transactional.  But of course the scaling was
sub-linear, and it did NOT let you scale with increasing database size
- everything was replicated to every machine.  More importantly, it
was strictly research-ware to begin with and it only worked with
PostgreSQL 6.4.2 - incredibly ancient at this point.

There are projects trying to make disk-backed RDBMSs really work on
clusters of machines, but AFAIK they are all at the early research
stage.  Backplane and (to a lesser extent) Clusgres come to mind.

Production grade distributed multi-master databases that are mostly in
memory but can periodically write to disk do exist.  E.g., Mnesia in
Erlang, but I've never used it (nor Erlang, for that matter).

Backplane is certainly ambitious, but I've no idea how well it might
work, or if it will even work at all.  From Matt Dillon's 2002 lecture
slides, I think Backplane works it's magic by being a temporal
database, which could itself be a useful feature.  It looks dead
though, you can download a tarball of the code but it hasn't been
touched since May 2003, and its author, Dillon, is working on other


Btw, I'd never heard of it before, but that Firefly BSD project is
interesting.  Among a whole bunch of other ambitious goals, they plan
a package system which fully and mostly automatically supports
installing multiple versions of ANY package.  Cool.

Andrew Piskorski <[EMAIL PROTECTED]>

AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to