On Sun, Mar 8, 2009 at 8:42 PM, mathieu <[email protected]> wrote: > > The CacheInvalidation issue being tackled here is solely related to > the current database-backed implementation of the caching API. > Using Memcache is indeed a very interesting solution, particularly > from the resource use efficiency and the response time point of view. > But it introduces a new dependency over an external server, which > makes it an unlikely default option for caching. > > I think that in the end, the end-user should be able to choose about > how caching is handled (with, indeed, a sensible default). > Django, for example, provides a simple caching API, several cache > backend configured using the CACHE_BACKEND setting which can take > values such as : > dummy:/// (dummy implementation, no caching actually done) > db://my_cache_table > memcached://127.0.0.1:11211/ > Documentation is here : http://docs.djangoproject.com/en/dev/topics/cache/ > > The implementation for a memcached cache backend is pretty > straightforward, and could alleviate the need for too involved > refactorings in the currend db-backed caching implementation. > I don't suggest keeping the db-based implementation as-is neither. But > the heavy users are very likely to switch to the best performing > caching option anyway, so that puts a lot of pressure off the db- > backed implementation, and keeping it simple could prove more > beneficial in the long term. > > The Django caching system implementation is very neat and can be seen > here : http://code.djangoproject.com/browser/django/trunk/django/core/cache > > What do you think of a little refactoring allowing different caching > backends to be used ? Don't that seem a good candidate for a plugin > extension point ? > > -- Mathieu
I rather like the idea proposed on the CacheInvalidation page. I implemented something similar a couple years ago to cache user permissions. I have a somewhat complex custom permission system that was often taking a couple dozen queries per request to compute a user's permissions, depending on how many groups they belong to (note, I did not write this system). Besides refactoring it a bit to cut down the number of required queries in the first place, using a DB-backed cache implementation like this I was able to cut it down to one query per request, which really does not affect performance noticeably. Anyways, between my permission cache, the new ticket cache, and the need I'll have soon to cache certain user meta-data, it would be great to have a general central cache interface like this. I have considered using memcached, but if I can avoid another dependency that would be preferable. I don't think Trac *needs* to go so far as to have a pluggable cache interface like Django. If I understand correctly there's a resistance (understandably) from some of the Trac developers to make Trac into yet another web framework (though I often use it sort of like one, as it's just so easy to work with). Between multiple DB backends and multiple interfaces to Apache (both of which I would consider necessary) Trac is already giving a lot of configuration flexibility. On the other hand, I looked at the Django cache interface you linked to, and it's pretty damn simple. I'm sure if someone wanted to work on something similar for Trac it couldn't hurt too much. I just don't know that it's necessary. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
