Have you ever felt the need to run multiple Django projects on the same memcached server? How about other cache backends? To scope the cache keys, you simply need to prefix. However, since a lot of Django's internals rely on `django.core.cache.cache`, you cannot easily replace it everywhere.
This will automatically upgrade the `django.core.cache.cache` object if `settings.CACHE_PREFIX` is set to a string and the Middleware contains `ScopeCacheMiddleware`.
A thread discussing the merging of this functionality into Django is available on [the dev mailing list](http://groups.google.com/group/django-developers/browse_thread/thread/d45edaafec56da2a).
However, (as of now) nowhere in the thread does anyone mention the reason why this sort of treatment is needed: Many of Django's internal caching helpers use `django.core.cache.cache`, and will then conflict if multiple sites run on the same cache stores.
Example Usage:
>>> from django.conf import settings
>>> from django.core.cache import cache
>>> from scoped_caching import prefix_cache_object
>>> settings.CACHE_PREFIX
'FOO_'
# Do this once a process (e.g. on import or Middleware)
>>> prefix_cache_object(settings.CACHE_PREFIX, cache)
>>> cache.set("pi", 3.14159)
>>> cache.get("pi")
3.14159
>>> cache.get("pi", use_global_namespace=True)
>>> cache.get("FOO_pi", use_global_namespace=True)
3.14159
>>> cache.set("FOO_e", 2.71828, use_global_namespace=True)
>>> cache.get("e")
2.71828
To Install: Simply add `ScopeCacheMiddleware` as a middleware and define `settings.CACHE_PREFIX` and enjoy!
cache_smart template tag is a drop in replacement for default cache tag by Django but with the added bonus to be more resistant against dog-pile/stampeding effect.
This snippet uses a extra cache entry to store a stale time so we don't have to pickle/unpickle to store this extra value.
If this cache entry returns None, as in expired it will reset the stale timeout 30 seconds in the future so further calls will just return the old value while this request is regenerating the new value.
**warning**
Don't use both cache template tags!
This mixin is intended for small lookup-style models that contain mostly static data and referenced by foreign keys from many other places. A good example is a list of Payment options in an e-shop that is referenced from Orders and is hitting database `order.payment` at least one time for an order.
The idea is to cache entire table in a dict in memory that will live for entire life of a whole process serving many requests.
The downside is that you need to restart the server when a cached lookup table changes.
Put this code somewhere in one of your INSTALLED_APPS `__init__.py` file. This code will replace the django.template.loader.get_template with cached version. Standard get_template function from django reads and parses the template code every time it's called. This version calls (if DEBUG set to False) it only once per template. After that it gets a Template object from template_cache dictionary. On django http server with template code like that:
{% extends "index.html" %}
{% block content %}
{% if form.has_errors %}
<p>Your username and password didn't match. Please try again.</p>
{% endif %}
<form method="post" action=".">
<table>
<tr><td><label for="id_username">Username:</label></td><td>{{ form.username }}</td></tr>
<tr><td><label for="id_password">Password:</label></td><td>{{ form.password }}</td></tr>
</table>
<input type="submit" value="login" />
<input type="hidden" name="next" value="{{ next }}" />
</form>
{% endblock %}
ab -n 100 on mac os x 10.5 core 2 duo 2 ghz with 2 GB of RAM gives
forge-macbook:~ forge$ ab -n 100 http://127.0.0.1:8000/login/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /login/
Document Length: 934 bytes
Concurrency Level: 1
Time taken for tests: 0.432934 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 120200 bytes
HTML transferred: 93400 bytes
Requests per second: 230.98 [#/sec] (mean)
Time per request: 4.329 [ms] (mean)
Time per request: 4.329 [ms] (mean, across all concurrent requests)
Transfer rate: 270.25 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 3 3 1.5 4 12
Waiting: 3 3 1.2 3 12
Total: 3 3 1.5 4 12
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 5
98% 10
99% 12
100% 12 (longest request)
without template caching, and
forge-macbook:~ forge$ ab -n 100 http://127.0.0.1:8000/login/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /login/
Document Length: 934 bytes
Concurrency Level: 1
Time taken for tests: 0.369860 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 120200 bytes
HTML transferred: 93400 bytes
Requests per second: 270.37 [#/sec] (mean)
Time per request: 3.699 [ms] (mean)
Time per request: 3.699 [ms] (mean, across all concurrent requests)
Transfer rate: 316.34 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 3 3 0.9 3 9
Waiting: 2 3 0.9 3 8
Total: 3 3 0.9 3 9
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 5
98% 8
99% 9
100% 9 (longest request)
with caching enabled.
In both cases DEBUG is set to False.
I had a problem: too many fetches from the DB.
So, how to reduce load on the database without major changes to the code?
Cache Manager is the answer. I've managed to reduce number of DB hits as much as 80% in some cases (dictionaries, complex relations). It is using standard cache mechanisms. I'm using it with mathopd.
This is a very simple solution, instead of standard Manager, put this in your model definition as:
`objects = CacheManager()`
Then everythere elase in the code instead of all() or get(...) call all_cached() or get_cached().
I've kept original methods intact, to have an dual access, when you really, really must have frest data from the DB, and you can't wait for cache to expire.
This is much easier to work with, then manually getting fetched data from the cache.No change to your existing code 9except model) and voila!
Additionally if you have some data, you would like to store with your serialized object (e.g. related data, dynamic dictionaries), you can do this in the model method '_init_instance_cache').
Drop me an email if you find this useful. :)
I've been working with a data set where a single object won't fit into memcached's 1 Mb slab limit. The two functions have been useful to me for debugging the size of the data structure once pickled, and if said pickled data structure is greater than 1 Mb.
These functions assume CACHE_BACKEND is memcached, obviously.
I like the per-site caching offered by Django (it's simple) and I like the cache to be dependent on the chosen language. Unfortunately with the current `CacheMiddleware` you can either have the one or the other but not both at the same time.
`VaryOnLangCacheMiddleware` is a small wrapper around `CacheMiddleware`. It looks at the `request.LANGUAGE_CODE` (set by `LocaleMiddleware`) and appends it to your `CACHE_MIDDLEWARE_KEY_PREFIX`. So "mysiteprefix" becomes "mysiteprefix_en" or "mysiteprefix_de-AT" depending on the user's chosen language. Site-wide, so no messing with per-view decorators and stuff.
To use this, make sure `VaryOnLangCacheMiddleware` comes below `LocaleMiddleware` in your settings.py. If you haven't set your `CACHE_MIDDLEWARE_KEY_PREFIX`, it's works, too.
**Update:** Replaced `super()` calls with `CacheMiddleware.xxx(self, ...)`.
This is a special URL patterns replacement that prevents caching of any URL listed within it. We needed this in Review Board to prevent the JSON API function results from being cached in Internet Explorer.
This takes advantage of a recently added feature to django, being able to give it real functions as the view instead of having it be a string that is has to look up itself.
It takes advantage of how decorators work and how `cache_control` works, normally you'd do something like this:
@cache_control(private=True, public=False)
def view_stuff(request):
# ...
return response
Which is equal to doing `view_stuff = cache_control(private=True, public=False)(view_stuff)` after definition. `cache_control` is a function factory, more or less, which we use to our advantage.
A couple of utility `Node` subclasses that will automatically cache thier contents.
Use `CachedNode` for template tags that output content into the template:
class SomeNode(CachedNode):
def get_cache_key(self, context):
return "some-cache-key"
def get_content(self, context):
return expensive_operation()
Use `CachedContextUpdatingNode` for tags that update the context:
class AnotherNode(CachedContextUpdatingNode):
# Only cache for 60 seconds
cache_timeout = 60
def get_cache_key(self, context);
return "some-other-cache-key"
def get_content(self, context):
return {"key" : expensive_operation()}
MintCache is a caching engine for django that allows you to get by with stale data while you freshen your breath, so to speak.
The purpose of this caching scheme is to avoid the dog-pile effect. Dog-piling is what normally happens when your data for the cache takes more time to generate than your server is answering requests per second. In other words if your data takes 5 seconds to generate and you are serving 10 requests per second, then when the data expires the normal cache schemes will spawn 50 attempts a regenerating the data before the first request completes. The increased load from the 49 redundant processes may further increase the time it takes to generate the data. If this happens then you are well on your way into a death spiral
MintCache works to prevent this scenario by using memcached to to keep track of not just an expiration date, but also a stale date The first client to request data past the stale date is asked to refresh the data, while subsequent requests are given the stale but not-yet-expired data as if it were fresh, with the undertanding that it will get refreshed in a 'reasonable' amount of time by that initia request
I don't think django has a mechanism for registering alternative cache engines, or if it does I jumped past it somehow. Here's an excerpt from my cache.py where I'v just added it alongside the existing code. You'll have to hook it in yourself for the time being. ;-)
More discussion [here](http://www.hackermojo.com/mt-static/archives/2007/03/django-mint-cache.html).