Tino Wildenhain wrote at 2005-6-3 22:48 +0200:
> ...
>Would be nice to optionally have the posibility to define
>finer grained cache policy (e.g. reserve 80% of cache
>mem to objects <5k and 20% for all the others - or something
>the like - much like altq does for ip-traffic shaping).
>
>E.g. some
Chris Withers wrote at 2005-6-3 08:24 +0100:
> ...
>I don't suppose there's any way that, as part of this work, the size of
>the cache could also be limited DURING a transaction?
I am a big user of "_v_" variables
and I am interested that they disappear only at transaction
boundaries.
Therefore,
Am Donnerstag, den 02.06.2005, 19:28 +0200 schrieb Dieter Maurer:
> Currently, the ZODB cache can only be controlled via the maximal number
> of objects. This makes configuration complex as the actual limiting
> factor is the amount of available RAM and it is very difficult to
> estimate the size o
[Chris Withers]
> I don't suppose there's any way that, as part of this work, the size of
> the cache could also be limited DURING a transaction? ...
That didn't look like part of Dieter's proposal to me .
It carries its own risks, and I'd rather not tie them together. For
example, _v_ attribute
[Michel Pelletier]
> ...
> I have some performance experiences from this that'd I'd love to share if
> I ever had the time, which I might soon, but for now I have no hard
> numbers so I won't elaborate on the cache issue being the cause, but
> increasing the cache size has a definite improvement in
sorry about the digest subject in the last email...
> Message: 4
> Date: Thu, 2 Jun 2005 19:28:34 +0200
> From: Dieter Maurer <[EMAIL PROTECTED]>
> Subject: [ZODB-Dev] [Proposal] Size controlled ZODB cache
> To: zodb-dev@zope.org
> Message-ID: <[EMAIL PROTECTED]&
Dieter Maurer wrote:
Currently, the ZODB cache can only be controlled via the maximal number
of objects. This makes configuration complex as the actual limiting
factor is the amount of available RAM and it is very difficult to
estimate the size of the objects in the cache.
I therefore propose t
Shane Hathaway wrote:
Dieter Maurer wrote:
Currently, the ZODB cache can only be controlled via the maximal number
of objects. This makes configuration complex as the actual limiting
factor is the amount of available RAM and it is very difficult to
estimate the size of the objects in the cache.
Dieter Maurer wrote:
> Currently, the ZODB cache can only be controlled via the maximal number
> of objects. This makes configuration complex as the actual limiting
> factor is the amount of available RAM and it is very difficult to
> estimate the size of the objects in the cache.
>
> I therefore
Currently, the ZODB cache can only be controlled via the maximal number
of objects. This makes configuration complex as the actual limiting
factor is the amount of available RAM and it is very difficult to
estimate the size of the objects in the cache.
I therefore propose the implementation of cac
10 matches
Mail list logo
