[ZODB-Dev] ZEO client persistent disk cache freshness

[Tim Peters]

[Florent Guillaume]
> Tim, first let me thank you for your invariably helpful and detailed
> responses.

You're welcome.  An answer merely reflects the excellence of the question
<wink>.

> To followup on your answer, it seems to mean that having a big persistent
> ZEO cache (say, 1GB) is not necessarily the best way to have a fast
> startup of the ZEO client, as it will have to verify its objects upon
> restart (if there's been a sufficiently long delay between stop and
> restart).

There's definitely tension of that nature.  If startup time is most
important to you, using a non-persistent ZEO cache is the way to go.  Then
it can be big without having any effect on startup time.  Of course you may
(or may not) more than lose that savings, by the extra time it takes to
refetch, from the server, all the objects the client references soon after
startup.  Depends on the app, how many objects, how big they are, how often
they're modified, startup reference patterns -- no slick answer here.

> Hmm, I'll have to bench...

That's the right approach.  If possible, it would be great if you shared
what you learn.  Note that the specific ZODB version in use may also have a
large effect.  For example, ZODB's NEWS file for 3.2 says (in part):

    The performance of full cache verification has improved
    dramatically.
    XXX Get measurements from Jim -- somewhere in 2x-5x recall.  The
    implementation was fixed to use the very-fast getSerial() method
    on the storage instead of the comparatively slow load().

and

    The ZEO cache verification protocol was revised to require many
    fewer messages in cases where a client or server restarts quickly.

It would be good to exploit modern disk capacities by using even larger ZEO
client cache files.  I wouldn't be surprised if a future release sped
verification for persistent caches again, and/or grew a tuning knob meaning
"on verification, don't try to verify more than N objects in cache -- if you
reach N, just throw the rest away" or "don't spend more than N seconds on
cache verification -- if you reach N seconds, just throw the rest away".
OTOH, that may be a feature nobody really wants (for example, there's no
guarantee that the objects verified before a cutoff was reached will be of
use to the client, so such a knob may just add more seemingly random noise
to an already muddy config optimization task).