On Tue, 15 Jan 2008, Tobias Schlitt wrote: > I started a small design doc for issue #10531 (ezcCacheStorageFile is > inefficient when reading the same cache repeatedly), because it is not as easy > to solve as desribed in the issue (in terms on consitency). > > Please take a look and comment. Find the document attached or in > Cache/trunk/design-1.4.txt.
Some comments: - I don't think that "store" should store anything in the memory cache. It wouldn't make much sense because this data is in memory already anyway, and secondly, I don't think you store and restore the same cache data in the same request. - Your proposed memory cache is something specifically implemented for the file storage backend. And the memory cache is only in-memory for the duration of one request. Now that we have memcache and apc caches, wouldn't it make more sense to allow for a fallback cache of some sorts, so that you basically can tie two cache backends together. That would allow a "fast memory, slow disk mechanism" (such as you proposed) but also a "fast in-memory, slower memcached, slow disk mechanism", or a "apc cache cache, and a slow disk mechanism". That'd mean that we'd need a normal memory cache backend too. - For all in-memory caches (also for apc/memcached backends to some extend) we should have some sort of mechanism the limits the amount of memory to be used. I think APC and Memcached have an internal limit already, but a new in-memory cache does not have easy limits there. Something like an LRU/LFU mechanism f.e. regards, Derick -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
