Setting a cache by periodic management command or asynchronous task

[bretth]

The main problem I have with most caching methods is the first request. My experience on services like Heroku and other virtualized databases is that 'some' queries/pages can be slower than an arthritic snail if the database is not warmed into memory, so that first cold request on a new or expiring cache can be a problem (particularly on Heroku which times-out after 30 seconds). You can fudge it for the user by ajax but I just want to do it right for every user every time not just the second person through the door.

To solve this problem I'm keen to crawl slow pages by scheduled management command at periodic intervals to refresh the cache. The second part of that is that I want to always set the cache when the management command is run so that I can control when the page is refreshed regardless of the timeout. So for example when an object is updated that is part of a complex query I can asynchronously pass off to a job queue the task of setting the cache.

My first thought was to simply create static pages and serve them up via reverse proxy/CDN, but my second thought was to customise the django cache middleware to consume a GET key/value pair like /path/?setcache=some-api-key. Given the key and the correct value the cache is always updated (assuming it uses a cache decorator).

Since this is a lovely fresh iteration on the stock django caching methods I wanted to get your thoughts as someone who has dug into the caching middleware recently as to a) it's feasibility as a feature and b) whether it is a feature you might accept if I did the work on it.

[bretth]

Nevermind. I worked it out. I'll put it in a pull request with tests if you're interested.