El sistema de cache requiere sólo una pequeña configuración. A saber, tendrás que decirle donde vivirán los datos de tu cache, si es en una base de datos, en el sistema de archivos, o directamente en memoria. Esta es una decisión importante que afecta el rendimiento de tu cache (si, algunos tipos de cache son más rápidos que otros). La cache en memoria generalmente será mucho más rápida que la cache en el sistema de archivos o la cache en una base de datos, porque carece del trabajo de tocar los mismos.
Tus preferencias acerca de la cache van en CACHE_BACKEND en tu archivo de
configuración. Si usas cache y no especificas CACHE_BACKEND, Django usará
simple:/// por omisión. Las siguientes secciones explican todos los valores
disponibles para CACHE_BACKEND.
13.1.1. Memcached
Por lejos la más rápida, el tipo de cache más eficiente para Django, Memcached es un framework de cache enteramente en memoria, originalmente desarrollado para manejar grandes cargas en LiveJournal y subsecuentemente por Danga Interactive. Es usado por sitios como Slashdot y Wikipedia para reducir el acceso a bases de datos e incrementar el rendimiento dramáticamente.
Memcached está libremente disponible en http://danga.com/memcached/. Corre como un demonio y se le asigna una cantidad específica de memoria RAM. Su característica principal es proveer una interfaz — una super-liviana-y-rápida interfaz — para añadir, obtener y eliminar arbitrariamente datos en la cache. Todos los datos son guardados directamente en memoria, por lo tanto no existe sobrecarga de uso en una base de datos o en el sistema de archivos.
Después de haber instalado Memcached, es necesario que instales los bindings
Python para Memcached, los cuales no vienen con Django. Dichos bindings
vienen en un módulo de Python, memcache.py, el cual está disponible en
http://www.tummy.com/Community/software/python-memcached/.
Para usar Memcached con Django, coloca CACHE_BACKEND como
memcached://ip:puerto/, donde ip es la dirección IP del demonio de
Memcached y puerto es el puerto donde Memcached está corriendo.
En el siguiente ejemplo, Memcached está corriendo en localhost (127.0.0.1) en el puerto 11211:
CACHE_BACKEND = 'memcached://127.0.0.1:11211/'Una muy buena característica de Memcached es su habilidad de compartir la cache
en varios servidores. Esto significa que puedes correr demonios de Memcached en
diferentes máquinas, y el programa seguirá tratando el grupo de diferentes
máquinas como una sola cache, sin la necesidad de duplicar los valores de la
cache en cada máquina. Para sacar provecho de esta característica con Django,
incluye todas las direcciones de los servidores en CACHE_BACKEND, separados
por punto y coma.
En el siguiente ejemplo, la cache es compartida en varias instancias de Memcached en las direcciones IP 172.19.26.240 y 172.19.26.242, ambas en el puerto 11211:
CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11211/'En el siguiente ejemplo, la cache es compartida en diferentes instancias de Memcached corriendo en las direcciones IP 172.19.26.240 (puerto 11211), 172.19.126.242 (puerto 11212) y 172.19.26.244 (puerto 11213):
CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11212;172.19.26.244:11213/'Una última observación acerca de Memcached es que la cache basada en memoria tiene una importante desventaja. Como los datos de la cache son guardados en memoria, serán perdidos si los servidores se caen. Más claramente, la memoria no es para almacenamiento permanente, por lo tanto no te quedes solamente con una cache basada en memoria. Sin duda, ninguno de los sistemas de cache de Django debe ser utilizado para almacenamiento permanente — son todos una solución para la cache, no para almacenamiento — pero hacemos hincapié aquí porque la cache basada en memoria es particularmente temporaria.
13.1.2. Cache en Base de datos
Para usar una tabla de una base de datos como cache, tienes que crear una tabla en tu base de datos y apuntar el sistema de cache de Django a ella.
Primero, crea la tabla de cache corriendo el siguiente comando:
python manage.py createcachetable [nombre_tabla_cache]
Donde [nombre_tabla_cache] es el nombre de la tabla a crear. Este nombre
puede ser cualquiera que desees, siempre y cuando sea un nombre válido para una
tabla y que no esté ya en uso en tu base de datos. Este comando crea una única
tabla en tu base de datos con un formato apropiado para el sistema de cache de
Django.
Una vez que se hayas creado la tabla, coloca la propiedad CACHE_BACKEND como
"db://nombre_tabla", donde nombre_tabla es el nombre de la tabla en la
base de datos. En el siguiente ejemplo, el nombre de la tabla para el cache es
mi_tabla_cache:
CACHE_BACKEND = 'db://mi_tabla_cache'El sistema de cache usará la misma base de datos especificada en el archivo de configuración. No podrás usar una base de datos diferente para tal.
13.1.3. Cache en Sistema de Archivos
Para almacenar la cache en el sistema de archivos, coloca el tipo "file://"
en la propiedad CACHE_BACKEND, especificando el directorio en tu sistema de
archivos que debería almacenar los datos de la cache.
Por ejemplo, para almacenar los datos de la cache en /var/tmp/django_cache,
coloca lo siguiente:
CACHE_BACKEND = 'file:///var/tmp/django_cache'Observa que hay tres barras invertidas en el comienzo del ejemplo anterior. Las
primeras dos son para file://, y la tercera es el primer caracter de la ruta
del directorio, /var/tmp/django_cache. Si estás en Windows, coloca la letra
correspondiente al disco después de file://, como aquí:: file://c:/foo/bar.
La ruta del directorio debe ser absoluta — debe comenzar con la raíz de tu sistema de archivos. No importa si colocas una barra al final de la misma.
Asegúrate que el directorio apuntado por esta propiedad exista y que pueda ser leído y escrito por el usuario del sistema usado por tu servidor Web para ejecutarse.
Continuando con el ejemplo anterior, si tu servidor corre como usuario
apache, asegúrate que el directorio /var/tmp/django_cache exista y
pueda ser leído y escrito por el usuario apache.
Cada valor de la cache será almacenado como un archivo separado conteniendo los
datos de la cache serializados, usando el módulo Python pickle.
Cada nombre de archivo es una clave de la cache, modificado convenientemente
para que pueda ser usado por el sistema de archivos.
13.1.4. Cache en Memoria local
Si quieres la ventaja que otorga la velocidad de la cache en memoria pero no tienes la capacidad de correr Memcached, puedes optar por el cache de memoria-local. Esta cache es por proceso y thread-safe, pero no es tan eficiente como Memcache dada su estrategia de bloqueo simple y reserva de memoria.
Para usarla, coloca CACHE_BACKEND como 'locmem:///', por ejemplo:
CACHE_BACKEND = 'locmem:///'13.1.5. Cache Simple (para desarrollo)
Una cache simple, y de un solo proceso en memoria, está disponible como
'simple:///', por ejemplo:
CACHE_BACKEND = 'simple:///'Esta cache apenas guarda los datos en proceso, lo que significa que sólo debe ser usada para desarrollo o testing.
13.1.6. Cache Dummy (o estúpida)
Finalmente, Django incluye una cache "dummy" que no realiza cache; sólo implementa la interfaz de cache sin realizar ninguna acción.
Esto es útil cuando tienes un sitio en producción que usa mucho cache en varias
partes y en un entorno de desarrollo/prueba en cual no quieres hacer cache. En
ese caso, usa CACHE_BACKEND como 'dummy:///' en el archivo de
configuración para tu entorno de desarrollo, por ejemplo:
CACHE_BACKEND = 'dummy:///'Como resultado de esto, tu entorno de desarrollo no usará cache, pero tu entorno de producción si lo hará.
13.1.7. Argumentos de CACHE_BACKEND
Cada tipo de cache puede recibir argumentos. Estos son dados como una
query-string en la propiedad CACHE_BACKEND. Los argumentos válidos son:
timeout: El tiempo de vida por omisión, en segundos, que usará la cache. Este argumento tomará el valor de 300 segundos (5 minutos) si no se lo especifica.max_entries: Para la cache simple, la cache de memoria local, y la cache de base de datos, es el número máximo de entradas permitidas en la cache a partir del cual los valores más viejos serán eliminados. Tomará un valor de 300 si no se lo especifica.cull_frequency: La proporción de entradas que serán sacrificadas cuando la cantidad demax_entrieses alcanzada. La proporción real es1/cull_frequency, si quieres sacrificar la mitad de las entradas cuando se llegue a una cantidad demax_entriescolocacull_frequency=2.
Un valor de `0` para `cull_frequency` significa que toda la cache será limpiada cuando se llegue a una cantidad de entradas igual a `max_entries`. Esto hace que el proceso de limpieza de la cache sea *mucho* más rápido pero al costo de perder más datos de la cache. Este argumento tomará un valor de 3 si no se especifica.
En este ejemplo, timeout se fija en 60:
CACHE_BACKEND = "locmem:///?timeout=60"En este ejemplo, timeout se fija en 30 y max_entries en 400:
CACHE_BACKEND = "locmem:///?timeout=30&max_entries=400"Tanto los argumentos desconocidos asi como los valores inválidos de argumentos conocidos son ignorados silenciosamente.