With this in place, restart the server and point your browser to the URL you specified in the URL configuration file (e.g. /status/cache), and provided that you’re logged in as a “staff member”, you’ll get something like:

cache status

memory usage: 11.3 MB

keys in cache: 2867 of 14624

cache hits: 24025 of 38102: 63%

cache traffic: 62.0 MB in, 129.4 MB out

uptime: 2:18:54

The memory usage and hit rate figures are probably what’s most interesting here.

When you use small caches, memcached has a tendency to grab noticably more memory than it’s allowed to use, and usage grows somewhat over time even after the cache has filled up; I’m not sure if this is a bug, or if it’s just including I/O buffers and other extra structures in the reported memory usage, but not in the cache size checks.

The hit rate depends a lot on your site’s characteristics, user access patterns, and cache timeouts. The higher the value, the less work your Django server has to do. But there’s a trade-off here, of course: you can reach nearly 100% hit rate by making the cache large enough and setting CACHE_MIDDLEWARE_SECONDS
to something really big, but that’ll make your server extremely static — even if you change things, old versions will keep being served from your cache, and will be stuck in caches around the net, for a very long time.

I recommend values from a few minutes for commonly updated sites to one hour for more static sites. For highly dynamic sites, with lots of user interaction, you should probably not use the cache middleware at all; let your views use the cache to store individual page fragments and database result sets instead.