[Paul Winkler]
> Heh. Well, I had a site that under some usage patterns would
> occasionally slow to a crawl with cache flips every few minutes. That
> was with the old default 20 MB cache size. I think I left it at
> 500 MB or so and that site's been fine since. But the performance
> demands wer
On Tue, Apr 18, 2006 at 02:12:15PM -0400, Tim Peters wrote:
> [Paul Winkler]
> > Interesting. Is there a recommended way now to judge whether your
> > ZEO cache is "big enough"?
>
> Was there a recommended way before? If so, it probably sucked too ;-)
Heh. Well, I had a site that under some usag
Chris Withers wrote at 2006-4-18 08:34 +0100:
> ...
>If having two isn't acceptable, then why do we have an I and O BTree's,
>not to mention the special ones used for in-memory ZODB indexes? Surely
>we should just have one BTree class?
Using "I" versus "O" BTrees makes a huge difference for mass
[Tim Peters]
>> That's an example: the post-MVCC ZEO cache is a single file, and
>> there are no cache flips; flips are unique to the pre-MVCC two-file
>> ZEO cache design.
[Paul Winkler]
> Interesting. Is there a recommended way now to judge whether your
> ZEO cache is "big enough"?
Was there a
On Tue, Apr 18, 2006 at 01:25:59PM -0400, Tim Peters wrote:
> That's an example: the post-MVCC ZEO cache is a single file, and
> there are no cache flips; flips are unique to the pre-MVCC two-file
> ZEO cache design.
Interesting. Is there a recommended way now to judge whether your
ZEO cache is "
[Gfeller, Martin]
> I'm further along the upgrade road and have found that starting up my
> app under ZEO is *much slower* than it used to be with Zope 2.7, >10
> minutes vs. <1 minute.
>
> I have relatively large temporary cache files
Beause you're comparing a pre-MVCC ZEO (3.2) with a post-MVCC
Hi,
I'm further along the upgrade road and have found that starting up my
app under ZEO is *much slower* than it used to be with Zope 2.7, >10
minutes vs. <1 minute.
I have relatively large temporary cache files (generous enough to to
avoid cache flips, even if I don't know the DB size beforehand
Philipp von Weitershausen wrote:
in memory. Dieter estimates 20% to 35% slowdown for the C algorithms
(whatever that means), Tim seems to think it won't have such a big
effect. I guess we'll only know after some benchmarks.
Can we please not make any definite decisions until this issue has been
