On 01/06/2006, at 8:03 PM, David Binger wrote:

> 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.

Thanks, that's what I thought. Thankfully there is likely to be only
around 40k or so 'active' objects, ie. ones that are read back often
after writing.

Also, I've noticed in stress testing with large databases, 5m+
objects, that Cache.shrink becomes less successful as the count of
current objects gets bigger than .size. I think there is a missing abs.
The line:
          slice_size = max(min(self.size - current, current / 4),
current / 64)
maybe should be:
         slice_size = max(min(abs(self.size - current), current / 4),
current / 64)

Peter W.