Diabl0 wrote:
Hi
As i seen this topic was discussed later, but i have new idea that IMHO
can throw new light.
What about combining memory cache backends with file cache fallback for
tags? Ofcorse optional if someone wants this.
This should give us benefits from fast memory cache and tagging system
with only small drawback on performance needed to update (or retreive)
tags cache from filesystem.
And what you think about this idea?
It's interesting but why use the filesystem? Why not use the cache
itself but use a different key structure to track this (e.g. cache an
array of keys that match the tag "wibble" under the key name
"Zend_Cache-keymap-wibble"? This approach could be implemented in a base
class and those backends not supporting tags could simple extend it.
I've not looked at the intricacies of this from a data integrity point
of view so there could be several reasons why this wouldn't work :)
Also as a related issue, would it be possible to implement a cache
invalidation queue system backed by a database? The reason I say this is
when considering multi-server environments (let's assume there is one
database for all servers).
Say someone has a blog system (standard example!!) and has various
articles. The articles are cached but when someone leaves a new comment,
we want to invalidate the cache so it can be regenerated. A nice way to
do this would be via the tag system (e.g. the cached article is tagged
with the article id - the cache key being more complex than just the id
alone).
When someone leaves their comment, the tag is invalided *on the current
server*. This is fine, but what if we are running multiple servers? We
would like a method to clear out the caches on these servers also
wouldn't we?
If we had a kind of db-backed "invalidation operation" queue, some kind
of garbage collector style routine could be built into the cache system
so that the action of invalidating a cache based on tag in one server
would put this invalidation into a db queue so that it could also be
propagated to other servers within a short time frame too. The GC
approach would take a "x in y" probability likilihood of running
approach that other similar GC routines take (e.g. the session GC). When
it is triggered it would query the queue and see if any new events have
come in since last run, if there are, it processes them and then store a
timestamp (in the cache of course!) of when it was last run.
I've perhaps not explained the problem too well above, so if anyone is
intrigued but thinks I must be smoking crack please ask. Also if I've
missed something in the zend_cache system that can cope with multiple
servers, please let me know (and I know e.g. memcached could be used on
a multi-server setup, but there are times when APC and filesystem would
be preferred).
WDYT?
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
