On May 31, 2006, at 9:47 PM, Peter Wilkinson wrote:
> Definitely. This is one thing we find very useful about Durus, our
> access pattern is very much driven by site customisation done via
> templates and Durus allows for this much better than SQL which
> suffers dramatically if you can't optimise/plan the access pattern
> before hand.
>
> We currently run Medusa and are very happy with what a single
> process running asynchronously can do to ease memory pressure. When
> QP runs with its own HTTPRequestHandler presumably each of the
> workers it creates gets a client connection cache. Is this correct?

Yes.  You should see how much RAM a client connection needs if it is
holding
every object in your database, loaded.  We did that for our 550k
object database
the other day and found that it took about 500 MB.

> I think what I might try and do is:
>
> * For each customer have a set of QP sites as you mention with one
> as the admin site.
> * Allow for QP to specify whether it should create its own db or
> rather connect to another sites db, this looks like it would be
> very simple, a couple of changes to bin/qp and a subclass of Site
> to add some extra options.
>
> This way we should have something like:
>
> admin.example.com -> QP site A -> Durus DB A
> www.example.com -> QP site B -> Durus DB A
> another.example.com -> QP site C -> Durus DB A
>
> This way we shouldn't need to run an extern Durus instance, QP site
> A can manage that for us, we get the benefits of being able to
> manage sites individually and don't require any changes to QP to
> fake the domains we sit in, request paths etc.
>
> Can you see any problems with that kind of setup?

It seems like it would work.
You'll need to remember to restart all sites if
the  Durus server for A is restarted.