Skip to main content
Help us improve PyPI by participating in user testing. All experience levels needed!

Drop-in replacement for Django's template fragment caching. Provides automatic cache invalidation.

Project description

Django Ultracache

Drop-in replacement for Django’s template fragment caching. Cache views and Django Rest Framework viewsets. Automatic cache invalidation and reverse caching proxy purging.

Travis

Installation

  1. Install or add django-ultracache to your Python path.
  2. Add ultracache to your INSTALLED_APPS setting.
  3. Ensure django.template.context_processors.request is in the context processors setting.

Features

  1. Caches template fragments, views, Django Rest Framework viewsets.
  2. It takes the sites framework into consideration, allowing different caching per site.
  3. Crucially, it is aware of model objects that are subjected to its caching. When an object is modified all affected cache key are automatically expired. This allows the user to set longer expiry times without having to worry about stale content.
  4. The cache invalidation can be extended to issue purge commands to Varnish, Nginx or other reverse caching proxies.

Usage

The ultracache template tag

django-ultracache provides a template tag {% ultracache %} that functions like Django’s standard cache template tag, with these exceptions.

Simplest use case:

{% load ultracache_tags %}
{% ultracache 3600 "my_identifier" object 123 undefined "string" %}
    {{ object.title }}
{% endultracache %}

The tag can be nested. ultracache is aware of all model objects that are subjected to its caching. In this example cache keys outer and inner_one are expired when object one is changed but cache key inner_two remains unaffected:

{% load ultracache_tags %}
{% ultracache 1200 "outer" %}
    {% ultracache 1200 "inner_one" %}
        title = {{ one.title }}
    {% endultracache %}
    {% ultracache 1200 "inner_two" %}
        title = {{ two.title }}
    {% endultracache %}
{% endultracache %}

The cached_get view decorator

django-ultracache also provides a decorator cached_get to cache your views. The parameters follow the same rules as the ultracache template tag except they must all resolve. request.get_full_path() is always implicitly added to the cache key:

from ultracache.decorators import cached_get


class CachedView(TemplateView):
    template_name = "ultracache/cached_view.html"

    @cached_get(300, "request.is_secure()", 456)
    def get(self, *args, **kwargs):
        return super(CachedView, self).get(*args, **kwargs)

The cached_get decorator can be used in an URL pattern:

from ultracache.decorators import cached_get

url(
    r"^cached-view/$",
    cached_get(3600)(TemplateView.as_view(
        template_name="myproduct/template.html"
    )),
    name="cached-view"
)

Do not indiscriminately use the cached_get decorator. It only ever operates on GET requests but cannot know if the code being wrapped retrieves data from eg. the session. In such a case it will cache things it is not supposed to cache.

If your view is used by more than one URL pattern then it is highly recommended to apply the cached_get decorator in the URL pattern. Applying it at class level may lead to cache collisions, especially if get_template_names is overridden.

Django Rest Framework viewset caching

Cache list and retrieve actions on viewsets:

# Cache all viewsets
ULTRACACHE = {
    "drf": {"viewsets": {"*": {}}}

}

# Cache a specific viewset by name
ULTRACACHE = {
    "drf": {"viewsets": {"my.app.MyViewset": {}}}

}

# Cache a specific viewset by class
ULTRACACHE = {
    "drf": {"viewsets": {MyViewset: {}}}

}

# Timeouts default to 300 seconds
ULTRACACHE = {
    "drf": {"viewsets": {"*": {"timeout": 1200}}}

}

# Evaluate code to append to the cache key. This example caches differently
# depending on whether the user is logged in or not.
ULTRACACHE = {
    "drf": {"viewsets": {"*": {"evaluate": "request.user.is_anonymous"}}}

}

# Evaluate code to append to the cache key via a callable.
def mycallable(viewset, request):
    if viewset.__class__.__name__ == "foo":
        return request.user.id

ULTRACACHE = {
    "drf": {"viewsets": {"*": {"evaluate": mycallable}}}

}

Purgers

You can create custom reverse caching proxy purgers. See purgers.py for examples:

ULTRACACHE = {
    "purge": {"method": "myproduct.purgers.squid"}
}

The most useful purger is broadcast. As the name implies it broadcasts purge instructions to a queue. Note that you need celery running and configured to write to a RabbitMQ instance for this to work correctly.

The purge instructions are consumed by the cache-purge-consumer.py script. The script reads a purge instruction from the queue and then sends a purge instruction to an associated reverse caching proxy. To run the script:

virtualenv ve
./ve/bin/pip install -e .
./ve/bin/python cache-purge-consumer.py -c config.yaml

The config file has these options:

#. rabbit-url Specify RabbitMQ connection parameters in the AMQP URL format amqp://username:password@host:port/<virtual_host>[?query-string]. Optional. Defaults to ``amqp://guest:guest@127.0.0.1:5672/%2F``. Note the URL encoding for the path.

#. host A reverse caching proxy may be responsible for many domains (hosts), and ultracache will keep track of the host that is involved in a purge request; however, if you have a use case that does not supply a hostname, eg. doing a PURGE request via curl, then forcing a hostname solves the use case. Optional.

#. proxy-address The IP address or hostname of the reverse caching proxy. Optional. Defaults to 127.0.0.1.

#. logfile Set to a file to log all purge instructions. Specify stdout to log to standard out. Optional.

Other settings

Automatic invalidation defaults to true. To disable automatic invalidation set:

ULTRACACHE = {
    "invalidate": False
}

django-ultracache maintains a registry in Django’s caching backend (see How does it work). This registry can”t be allowed to grow unchecked, thus a limit is imposed on the registry size. It would be inefficient to impose a size limit on the entire registry so a maximum size is set per cached value. It defaults to 1000000 bytes:

ULTRACACHE = {
    "max-registry-value-size": 10000
}

It is highly recommended to use a backend that supports compression because a larger size improves cache coherency.

If you make use of a reverse caching proxy then you need the original set of request headers (or a relevant subset) to purge paths from the proxy correctly. The problem with the modern web is the sheer amount of request headers present on every request would lead to a large number of entries having to be stored by django-ultracache in Django’s caching backend. Your proxy probably has a custom hash computation rule that considers only the request path (always implied) and Django’s sessionid cookie, so define a setting to also consider only the cookie on the Django side:

ULTRACACHE = {
    "consider-headers": ["cookie"]
}

If you only need to consider some cookies then set:

ULTRACACHE = {
    "consider-cookies": ["sessionid", "some-other-cookie"]
}

How does it work?

django-ultracache monkey patches django.template.base.Variable._resolve_lookup to make a record of model objects as they are resolved. The ultracache template tag inspects the list of objects contained within it and keeps a registry in Django’s caching backend. A post_save signal handler monitors objects for changes and expires the appropriate cache keys.

Tips

  1. If you are running a cluster of Django nodes then ensure that they use a shared caching backend.

Authors

Praekelt Consulting

  • Hedley Roos

Changelog

1.11.10

  1. Ensure a working error message if pika is not found.
  2. cached_get now considers any object accessed in get_context_data and not just objects accessed in the view template.
  3. The original request headers are now sent to the purgers along with the path. This enables fine-grained proxy invalidation.
  4. Django 2.0 and Python 3 compatibility. Django 1.9 support has been dropped.

1.11.9

  1. Simplify the DRF caching implementation. It also now considers objects touched by sub-serializers.

1.11.8

  1. The DRF settings now accept dotted names.
  2. The DRF setting now accepts a callable whose result forms part of the cache key.

1.11.7

  1. Use pickle to cache DRF data because DRF uses a Decimal type that isn’t recognized by Python’s json library.

1.11.6

  1. Adjust the DRF decorator so it can be used in more places.

1.11.5

  1. Django Rest Framework caching does not cache the entire response anymore, only the data and headers.

1.11.4

  1. Move the twisted work to django-ultracache-twisted.
  2. Clearly raise exception if libraries are not found.

1.11.3

  1. Move the twisted directory one lower.

1.11.2

  1. Package the product properly so all directories are included.

1.11.1

  1. More defensive code to ensure we don’t interfere during migrations in a test run.

1.11.0

  1. Introduce rabbitmq-url setting for use by broadcast_purge task.
  2. Django 1.11 support.
  3. Deprecate Django 1.6 support.

1.10.2

  1. Remove logic that depends on SITE_ID so site can also be inferred from the request.

1.10.1

  1. Add caching for Django Rest Framework viewsets.
  2. Django 1.10 compatibility.

1.9.1

  1. Add missing import only surfacing in certain code paths.
  2. Invalidate setting was not being loaded properly. Fixed.
  3. Handle content types RuntimeError when content types have not been migrated yet.

1.9.0

  1. Move to tox for tests.
  2. Django 1.9 compatibility.

0.3.8

  1. Honor the raw parameter send along by loaddata. It prevents redundant post_save handling.

0.3.7

  1. Revert the adding of the template name. It introduces a performance penalty in a WSGI environment.
  2. Further reduce the number of writes to the cache.

0.3.6

  1. Add template name (if possible) to the caching key.
  2. Reduce number of calls to set_many.

0.3.5

  1. Keep the metadata cache size in check to prevent possibly infinite growth.

0.3.4

  1. Prevent redundant sets.
  2. Work around an apparent Python bug related to di[k].append(v) vs di[k] = di[k] + [v]. The latter is safe.

0.3.3

  1. Handle case where one cached view renders another cached view inside it, thus potentially sharing the same cache key.

0.3.2

  1. The ultracache template tag now only caches HEAD and GET requests.

0.3.1

  1. Trivial release to work around Pypi errors of the day.

0.3

  1. Replace cache.get in for loop with cache.get_many.

0.2

  1. Do not automatically add request.get_full_path() if any of request.get_full_path(), request.path or request.path_info is an argument for cached_get.

0.1.6

  1. Also cache response headers.

0.1.5

  1. Explicitly check for GET and HEAD request method and cache only those requests.

0.1.4

  1. Rewrite decorator to be function based instead of class based so it is easier to use in urls.py.

0.1.3

  1. cached_get decorator now does not cache if request contains messages.

0.1.2

  1. Fix HTTPResponse caching bug.

0.1.1

  1. Handle case where a view returns an HTTPResponse object.

0.1

  1. Initial release.

Project details


Release history Release notifications

This version
History Node

1.11.10

History Node

1.11.9

History Node

1.11.8

History Node

1.11.7

History Node

1.11.6

History Node

1.11.5

History Node

1.11.4

History Node

1.11.3

History Node

1.11.2

History Node

1.11.1

History Node

1.11.0

History Node

1.10.2

History Node

1.10.1

History Node

1.9.1

History Node

1.9.0

History Node

0.3.8

History Node

0.3.7

History Node

0.3.6

History Node

0.3.5

History Node

0.3.4

History Node

0.3.3

History Node

0.3.2

History Node

0.3.1

History Node

0.3

History Node

0.2

History Node

0.1.6

History Node

0.1.5

History Node

0.1.4

History Node

0.1.3

History Node

0.1.2

History Node

0.1.1

History Node

0.1

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Filename, size & hash SHA256 hash help File type Python version Upload date
django_ultracache-1.11.10-py2.7.egg (95.4 kB) Copy SHA256 hash SHA256 Egg 2.7 Apr 13, 2018
django-ultracache-1.11.10.tar.gz (62.8 kB) Copy SHA256 hash SHA256 Source None Apr 13, 2018

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging CloudAMQP CloudAMQP RabbitMQ AWS AWS Cloud computing Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page