Re: ZODB redis/memcache client cache

On Thu, 4 Feb 2016 06:38:37 -0500, Jim Fulton <[email protected]>
wrote:
> I wonder how NEO approaches caching.

On the level of cache visibilitylevel, it is the same as in ZEO:
each client has its own cache.
On the level of cache features, NEO uses multi-queue algorithm, and the
cache is TID-aware: there may be more than one revision of any object
present in the cache.

All the nice details are here:
  https://lab.nexedi.com/nexedi/neoppod/blob/master/neo/client/cache.py

I'm not too happy with the current default values (20MB cache is way too
small for average current hardware).

On the somewhat related topic of proxy storages, I'm not sure which
approach is best for compression:
- application-level compression (knows best about what is compressible,
  but likely to duplicate functionality a lot)
- NEO-level (as is currently implemented, optional) factorises code,
  but may waste a bit of time trying to compress data for which no gain
  could be expected
- proxy storage for compression (which appeared a bit after we decided
  implementing it in NEO - or at least we became aware of its existence
  after), with the obvious advantage of being storage-independent
- down to the storage level (applies to NEO and relStorage): have the
  underlying database handle compression - IIRC Julien had very good
  results with TokuDB's compression under NEO.

Regards,
-- 
Vincent Pelletier

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.