How PyLucid used the django cache backend
↑ page cache #
The current usage of the django cache is very simple: We cached the complete page for any anonymous user with a own middleware which works like django cache middleware.
We used a own middleware, because we don't want to vary on cookies and don't want cache the cookies. This is very ineffective. See also discussion on django-developers group: The state of per-site/per-view middleware caching in Django
Ower own solution is very fast, but has also some disadvantage, see:
↑ disadvantage #
- The content of a cached page can't contain any dynamic content, see ticket: dynamic elements in the page for anonymous users
- Keep cache up-to-date: We cleaned the cache completely after page data changed. So the cache is always up-to-date. But this is not really effective for big sites.
↑ problems #
↑ language in url == language of content #
We must distinguish between the language of the content and the language of gettext (the 'source code translations').
We can't serve the content and the gettext in different languages, because both are stored with the same cache keys (the current url).
↑ sharing #
Important is, that the cache should not shared between:
- sites
- users
See also discussion on django-developers group:
There are a few solutions to separate the caches: Add username/SITE_ID to:
We do this by adding Username and SITE_ID to cache backend location. See also: local_settings.py example
↑ local cache data #
We add some information to a simple dict to cache something. e.g.: urls from PageTree/PageMeta
Such caches are very effective, but has problems in multi-threaded environments.
We used a solution from django-tools: Local sync cache