I have been setting up caching in Django using a database cache. There are two settings TIMEOUT and CACHE_MIDDLEWARE_SECONDS that control how long a page is cached for. What is the difference between these two settings?
3 Answers
Indeed the respective documentation does not adequately explain the differences.
The first option, CACHES
: TIMEOUT
is introduced in Django cache framework, Cache arguments. It is the default expiration time that is used in functions such as cache.set()
, if none else is provided. This is later documented in the low-level cache API usage.
The latter, CACHE_MIDDLEWARE_SECONDS
is introduced in Django cache framework, The per-site cache. Therefore it might be safe to assume that it is the default expiration time for all pages, as if the @cache_page(settings.CACHE_MIDDLEWARE_SECONDS)
would have been used on a per-view basis.

- 18,848
- 11
- 103
- 80
-
`TIMEOUT` only affects server-side caching, whereas `CACHE_MIDDLEWARE_SECONDS` affects both client-side and server-side caching. Am I correct? – Flimm Jul 08 '16 at 09:50
I had the same question and the existing answers still didn't clear it up for me. So I decided to dive into the source code. Yay for open source!
CACHE_MIDDLEWARE_SECONDS
gets used by the UpdateCacheMiddleware
middleware. It sets the Cache-Control
(max-age
) header to the value of CACHE_MIDDLEWARE_SECONDS
if the view didn't already set it, affecting the client-side cache. Here's the code:
self.cache_timeout = settings.CACHE_MIDDLEWARE_SECONDS
# ...
timeout = get_max_age(response)
if timeout is None:
timeout = self.cache_timeout
patch_response_headers(response, timeout)
(Note that I'm cutting out some code and edge-corners to make this quicker to read, you can read the full source code yourself of course.)
It also saves the response in the server-side cache, using the same timeout value which originates from MIDDLEWARE_CACHE_SECONDS
, overriding the TIMEOUT
setting if it had been set: (context)
if timeout:
cache_key = learn_cache_key(request, response, timeout, self.key_prefix, cache=self.cache)
self.cache.set(cache_key, response, timeout)
The middleware FetchFromCacheMiddleware
goes with UpdateCacheMiddleware
, and it uses the server-side cache values set by the latter, so it is indirectly affected by CACHE_MIDDLEWARE_SECONDS
.
The alternative middleware CacheMiddleware
also uses CACHE_MIDDLEWARE_SECONDS
. This shouldn't affect you unless you're using CacheMiddleware
.
So what's the point of the TIMEOUT
setting? I suppose it's the default value that's used if you're writing to the cache directly, but it isn't used by the previously mentioned middleware. For example:
from django.core.cache import cache
cache.set('my_key', 'my_value') # uses TIMEOUT value as default
-
sorry, but what is the default timeout here? for example `cache.set("my_key", ''my_value", timeout=none)` this code means that data in cache will stay for unlimited time? – Karam Qusai Sep 03 '19 at 07:04
-
1@KaramQusai The default timeout for `cache.set` is the [`TIMEOUT` setting](https://docs.djangoproject.com/en/stable/ref/settings/#timeout). – Flimm Sep 03 '19 at 09:56
According to http://www.djangobook.com/en/2.0/chapter15.html, TIMEOUT is the timeout for connecting to the cache backend and CACHE_MIDDLEWARE_SECONDS is the number of seconds to cache a page. So TIMEOUT is not necessarily useful for all backends.

- 6,296
- 4
- 30
- 31
-
Thanks for the answer but I'm not sure I understand the distinction. According the docs https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-CACHES-TIMEOUT Timeout is 'The number of seconds before a cache entry is considered stale'. Does that mean the same thing as 'TIMEOUT is the timeout for connecting to the cache backend'? – Alexander Feb 05 '15 at 22:39
-
You're right my bad. The reference I gave is, in its own words, "extremely out of date." Since the Django cache provides access to finer granularity than entire pages, I'd guess that is what TIMEOUT is for. CACHE_MIDDLEWARE can only handle entire pages, so you might want different timeouts for that. We'll have to consult the code to be sure. – Joseph Sheedy Feb 05 '15 at 23:09