On 7/6/07, Clint Ecker <[EMAIL PROTECTED]> wrote: ... > When I set up caching I then just cache this_month_detail for 15 > minutes and previous_month_detail for 10 years or so.
What cache backend are you using? Note that memcached has an LRU expiry policy, so that if there is pressure on the cache, it'll toss out an un-accessed item to make room for a new key. So that 10 years might be significantly shorter. ... > Do you mean by "baking the requests", caching the output to a file on > disk/db or by pickling the request object (pretty sure you don't mean > this). If the first is what you mean, how does this differ from using > file-based caching in Django? The difference is that Django only supports one backend at a time, and file-based caching breaks down if you're doing lots of writes (that is, cache misses) or other disk IO that flushes the OS buffers. It sounds like your data changes very rarely, and unless the page is quite large, that number of items sounds reasonable (to me) to use disk-based on your own. (I'm assuming, here, that you're using memcache for your write-heavy stuff.) ... > In another vein, how does everyone deal with invalidating the cache It's a hard problem, in that your needs are your needs, and the common ground is generally pretty fine-grained. There's a SoC project right now to do queryset-based caching, and David Cramer hacked up a CachedManager to do similar. With those approaches, the cache key is basically the queryset parameters themselves, and the cache miss/regen branch I outlined is hidden in the QuerySet implementation. Cache invalidation isn't done, AFAIK, in David's hack, but it is a goal of the SoC projec to void any querysets that contain an updated model. (I think the SoC project is using signals for the invalidation; I have no idea how they're going to deal with model updates out of the cached process.) If you're looking for something coarser, because, for example, you need to combine multiple querysets or outside data in a complex way, then that's something that it unlikely to be a common need for Django. The basic idea is, keep a key for the expensive thing itself, and then keep a key for each unit-of-invalidation that is a dict of all final keys which depend on the invalidated thing. When the component becomes invalid, you look up all the keys that depend on it, and go delete those. I suppose you could recurse there-- checking to see if the things depending on the invalid component are themselves components on which other things depend. I personally haven't needed this strategy yet. :) > can I trigger what I might call an > automated rebuild of that template? I just make HTTP requests for all the expensive views to keep the cache warm. Just pace the rebuild-- it's easy to affect a site's performance when specifically calling a bunch of expensive views. HTH, Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
