Skip to content

django-pylibmc/django-pylibmc

Repository files navigation

pylibmc cache backend for Django

The PyPI package

TravisCI Build Status

This package provides a memcached cache backend for Django using pylibmc. You want to use pylibmc because it's fast.

Do you need django-pylibmc?

Django now has a built-in pylibmc backend, and as of Django 1.11 also supports the binary, username and password options natively. As such, in most cases the built-in backend should be used instead of django-pylibmc, since it will be more actively maintained.

To use Django's own backend, configure CACHES like so:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        'LOCATION': '127.0.0.1:11211',
    }
}

See the Django documentation for details about using this cache backend.

Reasons to use django-pylibmc instead, are:

  • You would like to use pylibmc's compression feature
  • You would rather pylibmc connection/server exceptions be caught/logged and not raised (though this may be added upstream soon).
  • You're using Django <1.11 and need to:
    • use the binary protocol.
    • use a username and password to access the memcached server (such as with Memcachier on Heroku).

Requirements

django-pylibmc requires pylibmc 1.4.1 or above. It supports Django 1.8 through 2.0, and Python versions 2.7, 3.4, 3.5, and 3.6.

Installation

Get it from pypi:

pip install django-pylibmc

or github:

pip install -e git://github.com/django-pylibmc/django-pylibmc.git#egg=django-pylibmc

Usage

Your cache backend should look something like this:

CACHES = {
    'default': {
        'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
        'LOCATION': 'localhost:11211',
        'TIMEOUT': 500,
        'BINARY': True,
        'OPTIONS': {  # Maps to pylibmc "behaviors"
            'tcp_nodelay': True,
            'ketama': True
        }
    }
}

To use a memcached local socket connection, set LOCATION to the path to the file, i.e. '/var/run/memcached/memcached.sock'.

If you want to use the memcached binary protocol, set the BINARY key's value to True as shown above. BINARY is False by default.

If you want to control pylibmc behaviors, use the OPTIONS. OPTIONS is an empty dict by default.

Pylibmc supports compression and the minimum size (in bytes) of values to compress can be set via the Django setting PYLIBMC_MIN_COMPRESS_LEN. The default is 0, which is disabled.

Pylibmc 1.3.0 and above allows to configure compression level, which can be set via the Django setting PYLIBMC_COMPRESS_LEVEL. It accepts the same values as the Python zlib module. Please note that pylibmc changed the default from 1 (Z_BEST_SPEED) to -1 (Z_DEFAULT_COMPRESSION) in 1.3.0.

Configuration with Environment Variables

Optionally, the memcached connection can be configured with environment variables (on platforms like Heroku). To do so, declare the following variables:

  • MEMCACHE_SERVERS
  • MEMCACHE_USERNAME
  • MEMCACHE_PASSWORD

Caching Timouts

When setting a cache value, memcache allows you to set an expiration for the value. Commonly, the value is set to a timeout in seconds. However, other values are allowed including Unix timestamps and 0 for "never expire". The highest number of seconds is 30 days - more than that, and the value is treated like a timestamp.

Django instead tries to work with cache timeouts in seconds after the current time. 0 is treated as 0 seconds, meaning the item should expire immediately. A timeout of None signals that the item should not expire. There is some support for memcache-style Unix timestamps as well.

In the distant past (Django 1.3?), a timeout of 0 was converted to the default timeout.

The current django-pylibmc behaviour is to pass 0 to the backend, which should be interpreted as "never expire". Omiting the timeout will get the Django default.

In the future, django-pylibmc will adopt the latest Django behaviour. The safest solution for your own code is to omit the timeout parameter (and get the default timeout), or set it to a timeout in seconds (less than 30 days). This way, your code will work when the Django behaviour is adopted. Avoid using a timeout of 0, None, or a negative number.

Testing

Install tox:

pip install tox

Run the tests like this:

tox