Кеширование в Django

Фундаментальный компромисс динамических веб-сайтов в том, что они динамические. Каждый раз, когда пользователь запрашивает страницу, веб-сервер выполняет всевозможные вычисления - от запросов к базе данных до рендеринга шаблонов и бизнес-логики - для создания страницы, которую видит посетитель вашего сайта. Это намного дороже с точки зрения накладных расходов на обработку, чем ваша стандартная конфигурация сервера чтения файла файловой системы.

Для большинства веб-приложений эти накладные расходы не имеют большого значения. Большинство веб-приложений не являются «washtonpost.com» или «slashdot.org»; это просто сайты малого и среднего размера со средним трафиком. Но для сайтов со средним и высоким трафиком важно сократить как можно больше накладных расходов.

Вот тут и пригодится кеширование.

Кэшировать что-либо - значит сохранить результат дорогостоящих вычислений, чтобы вам не пришлось выполнять вычисления в следующий раз. Вот псевдокод, объясняющий, как это будет работать для динамически генерируемой веб-страницы:

given a URL, try finding that page in the cache
if the page is in the cache:
    return the cached page
else:
    generate the page
    save the generated page in the cache (for next time)
    return the generated page

Django поставляется с надежной системой кеширования, которая позволяет сохранять динамические страницы, поэтому их не нужно рассчитывать для каждого запроса. Для удобства Django предлагает разные уровни детализации кеширования: вы можете кэшировать вывод определенных представлений, вы можете кэшировать только те части, которые сложно создать, или вы можете кэшировать весь свой сайт.

Django also works well with «downstream» caches, such as Squid and browser-based caches. These are the types of caches that you don’t directly control but to which you can provide hints (via HTTP headers) about which parts of your site should be cached, and how.

См.также

В Философия проектирования Cache Framework объясняются некоторые проектные решения этой платформы.

Настройка кеша

Система кеширования требует небольшой настройки. А именно, вы должны указать ему, где должны находиться ваши кэшированные данные - будь то в базе данных, в файловой системе или непосредственно в памяти. Это важное решение, которое влияет на производительность вашего кеша; да, некоторые типы кешей быстрее других.

Ваши предпочтения кеширования находятся в параметре CACHES в вашем файле настроек. Вот объяснение всех доступных значений для CACHES.

Memcached

Memcached - это самый быстрый и наиболее эффективный тип кеша, изначально поддерживаемый Django. Это полностью основанный на памяти кеш-сервер, изначально разработанный для обработки высоких нагрузок на LiveJournal.com, а затем открытый Danga Interactive. Он используется такими сайтами, как Facebook и Wikipedia, для уменьшения доступа к базе данных и значительного повышения производительности сайта.

Memcached работает как демон, и ему выделяется определенный объем оперативной памяти. Все, что он делает, - это быстрый интерфейс для добавления, извлечения и удаления данных в кеше. Все данные хранятся непосредственно в памяти, поэтому нет накладных расходов на использование базы данных или файловой системы.

После установки самого Memcached вам необходимо установить привязку Memcached. Доступно несколько привязок Python Memcached; два поддерживаемых Django - это pylibmc и` pymemcache`_.

Чтобы использовать Memcached с Django:

  • Установите BACKEND на django.core.cache.backends.memcached.PyMemcacheCache или django.core.cache.backends.memcached.PyLibMCCache (в зависимости от выбранного вами привязки)
  • Установите LOCATION на значения ip:port, где ip - это IP-адрес демона Memcached, а port - это порт, на котором работает Memcached, или в значение unix:path, где path - это путь к файлу сокета Memcached Unix.

В этом примере Memcached работает на порту 11211 localhost (127.0.0.1) с использованием привязки pymemcache:

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

В этом примере Memcached доступен через локальный файл сокета Unix /tmp/memcached.sock с использованием привязки pymemcache:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': 'unix:/tmp/memcached.sock',
    }
}

Отличной особенностью Memcached является возможность совместного использования кеша на нескольких серверах. Это означает, что вы можете запускать демоны Memcached на нескольких машинах, и программа будет рассматривать группу машин как один кеш, без необходимости дублировать значения кеша на каждой машине. Чтобы воспользоваться этой функцией, включите все адреса серверов в LOCATION либо в виде строки, разделенной точкой с запятой или запятой, либо в виде списка.

В этом примере кеш совместно используется экземплярами Memcached, работающими на IP-адресах 172.19.26.240 и 172.19.26.242, оба на порту 11211:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': [
            '172.19.26.240:11211',
            '172.19.26.242:11211',
        ]
    }
}

В следующем примере кеш совместно используется экземплярами Memcached, работающими на IP-адресах 172.19.26.240 (порт 11211), 172.19.26.242 (порт 11212) и 172.19.26.244 (порт 11213):

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': [
            '172.19.26.240:11211',
            '172.19.26.242:11212',
            '172.19.26.244:11213',
        ]
    }
}

Последний момент, касающийся Memcached, заключается в том, что кэширование на основе памяти имеет недостаток: поскольку кэшированные данные хранятся в памяти, данные будут потеряны, если ваш сервер выйдет из строя. Очевидно, что память не предназначена для постоянного хранения данных, поэтому не полагайтесь на кэширование на основе памяти в качестве единственного хранилища данных. Без сомнения, ни один бэкэнд кэширования Django не должен использоваться для постоянного хранения - все они предназначены для решения кэширования, а не хранения - но мы указываем на это здесь, потому что кэширование на основе памяти является особенно временным.

Changed in Django Development version:

Добавлен бэкэнд PyMemcacheCache.

Не рекомендуется, начиная с версии 3.2: Бэкэнд MemcachedCache устарел, так как у python-memcached есть некоторые проблемы, и, похоже, он не поддерживается. Вместо этого используйте PyMemcacheCache или PyLibMCCache.

Кэширование в базе данных

Django может хранить свои кэшированные данные в вашей базе данных. Это лучше всего работает, если у вас есть быстрый, хорошо индексируемый сервер базы данных.

Чтобы использовать таблицу базы данных в качестве бэкэнда кеша:

  • Установите BACKEND на django.core.cache.backends.db.DatabaseCache
  • Установите LOCATION в значение tablename, имя таблицы базы данных. Это имя может быть любым, если это допустимое имя таблицы, которое еще не используется в вашей базе данных.

В этом примере имя таблицы кеша - my_cache_table:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}

В отличие от других бэкендов кэша, кэш базы данных не поддерживает автоматическую очистку истекших записей на уровне базы данных. Вместо этого просроченные записи кэша удаляются каждый раз при вызове add(), set() или touch().

Создание таблицы кеша

Перед использованием кеша базы данных вы должны создать таблицу кеша с помощью этой команды:

python manage.py createcachetable

Это создает таблицу в вашей базе данных, которая имеет правильный формат, который ожидает система кеширования базы данных Django. Имя таблицы взято из LOCATION.

Если вы используете несколько кешей базы данных, createcachetable создает по одной таблице для каждого кеша.

Если вы используете несколько баз данных, createcachetable наблюдает за методом allow_migrate() ваших маршрутизаторов баз данных (смотрите ниже).

Например migrate, createcachetable не затрагивает существующую таблицу. Это только создаст недостающие таблицы.

Чтобы распечатать SQL, который будет запущен, а не запускать его, используйте параметр createcachetable --dry-run.

Несколько баз данных

Если вы используете кэширование базы данных с несколькими базами данных, вам также необходимо настроить инструкции маршрутизации для таблицы кеширования базы данных. Для целей маршрутизации таблица кэша базы данных отображается как модель с именем CacheEntry в приложении с именем django_cache. Эта модель не появится в кэше моделей, но детали модели могут использоваться для целей маршрутизации.

Например, следующий маршрутизатор направит все операции чтения из кеша в cache_replica, а все операции записи - в cache_primary. Таблица кеша будет синхронизироваться только с cache_primary:

class CacheRouter:
    """A router to control all database cache operations"""

    def db_for_read(self, model, **hints):
        "All cache read operations go to the replica"
        if model._meta.app_label == 'django_cache':
            return 'cache_replica'
        return None

    def db_for_write(self, model, **hints):
        "All cache write operations go to primary"
        if model._meta.app_label == 'django_cache':
            return 'cache_primary'
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        "Only install the cache model on primary"
        if app_label == 'django_cache':
            return db == 'cache_primary'
        return None

Если вы не укажете направления маршрутизации для модели кэша базы данных, серверная часть кеша будет использовать базу данных по умолчанию.

И если вы не используете бэкэнд кеширования в базе данных, вам не нужно беспокоиться о предоставлении инструкций по маршрутизации для модели кеширования базы данных.

Кеширование в файловой системе

Серверная часть на основе файлов сериализует и сохраняет каждое значение кэша как отдельный файл. Чтобы использовать этот бэкэнд, установите BACKEND на django.core.cache.backends.filebased.FileBasedCache и LOCATION в подходящий каталог. Например, чтобы хранить кэшированные данные в /var/tmp/django_cache, используйте этот параметр:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
    }
}

Если вы работаете в Windows, поместите букву диска в начало пути, например:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': 'c:/foo/bar',
    }
}

Путь к каталогу должен быть абсолютным, то есть он должен начинаться с корня вашей файловой системы. Неважно, поставили ли вы косую черту в конце настройки.

Убедитесь, что каталог, на который указывает этот параметр, либо существует и доступен для чтения и записи, либо он может быть создан пользователем системы, под которым работает ваш веб-сервер. Продолжая приведенный выше пример, если ваш сервер работает от имени пользователя apache, убедитесь, что каталог /var/tmp/django_cache существует и доступен для чтения и записи пользователю apache или что он может быть создан пользователем apache.

Предупреждение

Когда параметр cache LOCATION содержится в MEDIA_ROOT, STATIC_ROOT или STATICFILES_FINDERS, конфиденциальные данные могут быть раскрыты.

Злоумышленник, получивший доступ к файлу кеша, может не только фальсифицировать HTML-контент, которому ваш сайт будет доверять, но и удаленно выполнить произвольный код, поскольку данные сериализуются с помощью pickle.

Кэширование в локальной памяти

Это кеш по умолчанию, если другой не указан в вашем файле настроек. Если вам нужны преимущества скорости кэширования в памяти, но у вас нет возможности запускать Memcached, подумайте о бэкэнде кеширования в локальной памяти. Этот кеш предназначен для каждого процесса (смотрите ниже) и ориентирован на потоки. Чтобы использовать его, установите BACKEND в "django.core.cache.backends.locmem.LocMemCache". Например:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'unique-snowflake',
    }
}

Параметр LOCATION используется для идентификации отдельных хранилищ памяти. Если у вас только один кеш locmem, вы можете опустить LOCATION; однако, если у вас более одного кэша локальной памяти, вам нужно будет присвоить имя хотя бы одному из них, чтобы они оставались отдельными.

Кэш использует стратегию отбраковки наименее недавно использовавшихся (LRU).

Обратите внимание, что у каждого процесса будет свой собственный экземпляр частного кеша, что означает невозможность межпроцессного кэширования. Это, очевидно, также означает, что кэш локальной памяти не особенно эффективен с точки зрения памяти, поэтому, вероятно, это не лучший выбор для производственных сред. Но подходит для разработки.

Фиктивное кеширование (для разработки)

Наконец, Django поставляется с «фиктивным» кешем, который на самом деле не кеширует - он просто реализует интерфейс кеша, ничего не делая.

Это полезно, если у вас есть производственный сайт, который использует усиленное кэширование в различных местах, но в среде разработки/тестирования, где вы не хотите кэшировать и не хотите менять свой код на особый случай последнего. Чтобы активировать фиктивное кеширование, установите BACKEND вот так:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
    }
}

Использование собственного бэкэнда кеширования

Хотя Django включает в себя готовую поддержку ряда серверных модулей кеширования, иногда вам может потребоваться использовать собственный серверный модуль кеширования. Чтобы использовать внешний кэш-бэкэнд с Django, используйте путь импорта Python в качестве BACKEND параметра CACHES, например:

CACHES = {
    'default': {
        'BACKEND': 'path.to.backend',
    }
}

Если вы создаете собственный бэкэнд, вы можете использовать стандартные бэкенды кеширования в качестве эталонных реализаций. Вы найдете код в каталоге django/core/cache/backends/ исходного кода Django.

Примечание: без действительно веских причин, таких как хост, который их не поддерживает, вам следует придерживаться бэкэндов кеширования, включенных в Django. Они хорошо протестированы и просты в использовании.

Аргументы кеша

Каждому бэкэнду кеширования можно дать дополнительные аргументы для управления поведением кеширования. Эти аргументы предоставляются как дополнительные ключи в настройке CACHES. Допустимые аргументы:

  • TIMEOUT: Тайм-аут по умолчанию в секундах, используемый для кеширования. По умолчанию этот аргумент равен 300 секундам (5 минутам). Вы можете установить для TIMEOUT значение None, чтобы по умолчанию ключи кеша никогда не истекали. Значение 0 вызывает немедленное истечение срока действия ключей (фактически «не кэшировать»).

  • OPTIONS: Любые параметры, которые должны быть переданы в серверную часть кеша. Список допустимых параметров будет варьироваться в зависимости от серверной части, а серверные части кеша, поддерживаемые сторонней библиотекой, будут передавать свои параметры непосредственно в базовую библиотеку кеша.

    Бэкэнды кеширования, которые реализуют свою собственную стратегию отбраковки (т.е. бэкэнды locmem, filesystem и database), будут учитывать следующие параметры:

    • MAX_ENTRIES: максимальное количество записей, разрешенных в кеш-памяти до удаления старых значений. По умолчанию этот аргумент равен 300.

    • CULL_FREQUENCY: доля записей, которые отбираются при достижении MAX_ENTRIES. Фактическое соотношение - 1 / CULL_FREQUENCY, поэтому установите CULL_FREQUENCY на 2, чтобы отбирать половину записей при достижении MAX_ENTRIES. Этот аргумент должен быть целым числом и по умолчанию равен 3.

      Значение 0 для CULL_FREQUENCY означает, что весь кеш будет сброшен при достижении MAX_ENTRIES. На некоторых бэкэндах (в частности, в базе данных) это делает отсечение намного быстрее за счет большего количества промахов в кеше.

    Бэкенды Memcached передают содержимое OPTIONS в качестве аргументов ключевого слова конструкторам клиента, что позволяет более эффективно управлять поведением клиента. Пример использования смотрите ниже.

  • KEY_PREFIX: строка, которая будет автоматически добавлена (добавлена по умолчанию) ко всем ключам кеша, используемым сервером Django.

    Дополнительную информацию смотрите в документации кеша.

  • VERSION: Номер версии по умолчанию для ключей кеша, сгенерированных сервером Django.

    Смотрите cache documentation для получения дополнительной информации.

  • KEY_FUNCTION Строка, содержащая пунктирный путь к функции, которая определяет, как составить префикс, версию и ключ в окончательный ключ кеша.

    Дополнительную информацию смотрите в документации кеша.

В этом примере серверная часть файловой системы настраивается с таймаутом 60 секунд и максимальной емкостью 1000 элементов:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
        'TIMEOUT': 60,
        'OPTIONS': {
            'MAX_ENTRIES': 1000
        }
    }
}

Вот пример конфигурации бэкэнда на основе pylibmc, который включает двоичный протокол, аутентификацию SASL и режим поведения ketama:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        'LOCATION': '127.0.0.1:11211',
        'OPTIONS': {
            'binary': True,
            'username': 'user',
            'password': 'pass',
            'behaviors': {
                'ketama': True,
            }
        }
    }
}

Вот пример конфигурации бэкэнда на основе pymemcache, который позволяет объединять клиентов в пул (что может повысить производительность за счет сохранения подключенных клиентов), обрабатывает ошибки кэша памяти/сети как пропуски кеша и устанавливает флаг TCP_NODELAY на сокете соединения:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': '127.0.0.1:11211',
        'OPTIONS': {
            'no_delay': True,
            'ignore_exc': True,
            'max_pool_size': 4,
            'use_pooling': True,
        }
    }
}

Кеширование на уровне сайта

После настройки кеша самый простой способ использовать кеширование - это кэшировать весь сайт. Вам нужно будет добавить 'django.middleware.cache.UpdateCacheMiddleware' и 'django.middleware.cache.FetchFromCacheMiddleware' в ваш параметр MIDDLEWARE, как в этом примере:

MIDDLEWARE = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

Примечание

Нет, это не опечатка: промежуточное ПО «update» должно быть первым в списке, а промежуточное ПО «fetch» должно быть последним. Детали немного неясны, но если вам нужна полная история, смотрите Порядок MIDDLEWARE ниже.

Затем добавьте следующие необходимые настройки в файл настроек Django:

  • CACHE_MIDDLEWARE_ALIAS – Псевдоним кеша, используемый для хранения.
  • CACHE_MIDDLEWARE_SECONDS – Количество секунд, в течение которых каждая страница должна быть кэширована.
  • CACHE_MIDDLEWARE_KEY_PREFIX – Если кеш используется на нескольких сайтах, использующих одну и ту же установку Django, задайте здесь имя сайта или другую строку, уникальную для этого экземпляра Django, чтобы предотвратить конфликты ключей. Если вам все равно, используйте пустую строку.

FetchFromCacheMiddleware кэширует ответы GET и HEAD со статусом 200, если это позволяют заголовки запроса и ответа. Ответы на запросы одного и того же URL с разными параметрами запроса считаются уникальными страницами и кэшируются отдельно. Это промежуточное ПО ожидает, что на запрос HEAD ответят те же заголовки, что и на соответствующий запрос GET; в этом случае он может вернуть кешированный ответ GET на запрос HEAD.

Кроме того, UpdateCacheMiddleware автоматически устанавливает несколько заголовков в каждом HttpResponse, которые влияют на downstream caches:

  • Устанавливает заголовок Expires на текущую дату/время плюс определенный CACHE_MIDDLEWARE_SECONDS.
  • Устанавливает заголовок Cache-Control, чтобы указать максимальный возраст для страницы - опять же, из параметра CACHE_MIDDLEWARE_SECONDS.

Смотрите Middleware для получения дополнительной информации о промежуточном программном обеспечении.

Если представление устанавливает собственное время истечения срока действия кеша (т.е. оно имеет раздел max-age в заголовке Cache-Control), то страница будет кэшироваться до истечения срока действия, а не CACHE_MIDDLEWARE_SECONDS. Используя декораторы в django.views.decorators.cache, вы можете легко установить время истечения срока действия представления (используя декоратор cache_control()) или отключить кеширование для представления (используя декоратор never_cache()). Смотрите раздел using other headers для получения дополнительной информации об этих декораторах.

Если USE_I18N имеет значение True, то сгенерированный ключ кеша будет включать имя активного языка – смотрите также Как Django обнаруживает языковые предпочтения). Это позволяет легко кэшировать многоязычные сайты без необходимости создавать ключ кеширования самостоятельно.

Ключи кэша также включают current time zone, когда USE_TZ имеет значение True.

Кеш на уровне представлений

django.views.decorators.cache.cache_page()

Более детальный способ использования фреймворка кэширования - кэширование вывода отдельных представлений. django.views.decorators.cache определяет декоратор cache_page, который автоматически кэширует ответ представления для вас. Легко использовать:

from django.views.decorators.cache import cache_page

@cache_page(60 * 15)
def my_view(request):
    ...

cache_page принимает единственный аргумент: тайм-аут кеша в секундах. В приведенном выше примере результат просмотра my_view() будет кэшироваться на 15 минут. (Обратите внимание, что мы написали его как 60 * 15 для удобства чтения. 60 * 15 будет оцениваться как 900, то есть 15 минут, умноженные на 60 секунд в минуту.)

Тайм-аут кеширования, установленный параметром cache_page, имеет приоритет над директивой max-age из заголовка Cache-Control.

Кэш для каждого представления, как и для каждого сайта, не связан с URL-адресом. Если несколько URL-адресов указывают на одно и то же представление, каждый URL-адрес будет кэшироваться отдельно. Продолжая пример my_view, если ваш URLconf выглядит так:

urlpatterns = [
    path('foo/<int:code>/', my_view),
]

тогда запросы к /foo/1/ и /foo/23/ будут кэшироваться отдельно, как и следовало ожидать. Но как только конкретный URL-адрес (например, /foo/23/) был запрошен, последующие запросы к этому URL-адресу будут использовать кеш.

cache_page также может принимать необязательный аргумент ключевого слова, cache, который указывает декоратору использовать определенный кеш (из вашего параметра CACHES) при кэшировании результатов просмотра. По умолчанию будет использоваться кеш default, но вы можете указать любой кеш, который хотите:

@cache_page(60 * 15, cache="special_cache")
def my_view(request):
    ...

Вы также можете переопределить префикс кеша для каждого представления. cache_page принимает необязательный ключевой аргумент, key_prefix, который работает так же, как параметр CACHE_MIDDLEWARE_KEY_PREFIX для промежуточного программного обеспечения. Его можно использовать так:

@cache_page(60 * 15, key_prefix="site1")
def my_view(request):
    ...

Аргументы key_prefix и cache могут быть указаны вместе. Аргумент key_prefix и параметр KEY_PREFIX, указанные в параметре CACHES, будут объединены.

Кроме того, cache_page автоматически устанавливает заголовки Cache-Control и Expires в ответе, которые влияют на downstream caches.

Changed in Django 3.1:

В более старых версиях директива max-age из заголовка Cache-Control имела приоритет над таймаутом кеширования, установленным параметром cache_page.

Указание кеша для каждого представления в URLconf

Примеры в предыдущем разделе жестко запрограммировали тот факт, что представление кэшируется, потому что cache_page изменяет функцию my_view на месте. Этот подход связывает ваше представление с системой кеширования, что не идеально по нескольким причинам. Например, вы можете захотеть повторно использовать функции представления на другом сайте без кеша или распространить представления среди людей, которые могут захотеть использовать их без кеширования. Решением этих проблем является указание кеша для каждого представления в URLconf, а не рядом с самими функциями представления.

Вы можете сделать это, заключив функцию просмотра в cache_page при обращении к ней в URLconf. Вот старый URLconf из более раннего:

urlpatterns = [
    path('foo/<int:code>/', my_view),
]

Вот то же самое с my_view, заключенным в cache_page:

from django.views.decorators.cache import cache_page

urlpatterns = [
    path('foo/<int:code>/', cache_page(60 * 15)(my_view)),
]

Кеширование фрагментов шаблона

Если вам нужен еще больший контроль, вы также можете кэшировать фрагменты шаблона с помощью тега шаблона cache. Чтобы предоставить вашему шаблону доступ к этому тегу, поместите {% load cache %} в верхней части шаблона.

Тег шаблона {% cache %} кэширует содержимое блока на заданный промежуток времени. Требуется как минимум два аргумента: тайм-аут кеша в секундах и имя для присвоения фрагмента кеша. Фрагмент кэшируется навсегда, если тайм-аут равен None. Имя будет принято как есть, не используйте переменную. Например:

{% load cache %}
{% cache 500 sidebar %}
    .. sidebar ..
{% endcache %}

Иногда вам может потребоваться кэшировать несколько копий фрагмента в зависимости от некоторых динамических данных, которые появляются внутри фрагмента. Например, вам может понадобиться отдельная кешированная копия боковой панели, использованной в предыдущем примере, для каждого пользователя вашего сайта. Сделайте это, передав один или несколько дополнительных аргументов, которые могут быть переменными с фильтрами или без них, в тег шаблона {% cache %}, чтобы однозначно идентифицировать фрагмент кеша:

{% load cache %}
{% cache 500 sidebar request.user.username %}
    .. sidebar for logged in user ..
{% endcache %}

Если USE_I18N установлен в True, кеш промежуточного программного обеспечения для каждого сайта будет учитывать активный язык. Для тега шаблона cache вы можете использовать одну из специфичных для перевода переменных, доступных в шаблонах, для достижения того же результата:

{% load i18n %}
{% load cache %}

{% get_current_language as LANGUAGE_CODE %}

{% cache 600 welcome LANGUAGE_CODE %}
    {% translate "Welcome to example.com" %}
{% endcache %}

Тайм-аут кеширования может быть переменной шаблона, если переменная шаблона разрешается в целочисленное значение. Например, если для переменной шаблона my_timeout установлено значение 600, следующие два примера эквивалентны:

{% cache 600 sidebar %} ... {% endcache %}
{% cache my_timeout sidebar %} ... {% endcache %}

Эта функция полезна, чтобы избежать повторения в шаблонах. Вы можете установить время ожидания в переменной в одном месте и повторно использовать это значение.

По умолчанию тег кеша будет пытаться использовать кеш с именем «template_fragments». Если такого кеша не существует, он вернется к использованию кеша по умолчанию. Вы можете выбрать альтернативный бэкэнд кеша для использования с аргументом ключевого слова using, который должен быть последним аргументом тега.

{% cache 300 local-thing ...  using="localcache" %}

Указание не настроенного имени кэша считается ошибкой.

django.core.cache.utils.make_template_fragment_key(fragment_name, vary_on=None)

Если вы хотите получить ключ кеша, используемый для кэшированного фрагмента, вы можете использовать make_template_fragment_key. fragment_name - это то же самое, что и второй аргумент тега шаблона cache; var_on - это список всех дополнительных аргументов, переданных тегу. Эта функция может быть полезна для аннулирования или перезаписи кэшированного элемента, например:

>>> from django.core.cache import cache
>>> from django.core.cache.utils import make_template_fragment_key
# cache key for {% cache 500 sidebar username %}
>>> key = make_template_fragment_key('sidebar', [username])
>>> cache.delete(key) # invalidates cached template fragment
True

API низкоуровневого кеширования

Иногда кеширование всей отображаемой страницы не приносит вам особой выгоды и, на самом деле, является неудобным излишеством.

Возможно, например, на вашем сайте есть представление, результаты которого зависят от нескольких дорогостоящих запросов, результаты которых меняются с разной периодичностью. В этом случае было бы не идеально использовать полностраничное кэширование, которое предлагают стратегии кеширования для каждого сайта или для каждого просмотра, потому что вы не захотите кэшировать весь результат (поскольку некоторые данные часто меняются), но вы все равно захотите кэшировать результаты, которые редко меняются.

Для подобных случаев Django предоставляет простой низкоуровневый API кеширования. Вы можете использовать этот API для хранения объектов в кэше с любым уровнем детализации, который вам нравится. Вы можете кэшировать любой объект Python, который можно безопасно обработать: строки, словари, списки объектов модели и так далее. (Наиболее распространенные объекты Python можно упаковывать; дополнительную информацию об этом смотрите в документации Python.)

Доступ к кешу

django.core.cache.caches

Вы можете получить доступ к кешам, настроенном в параметре CACHES, через dict-подобный объект: django.core.cache.caches. Повторные запросы одного и того же псевдонима в одном потоке вернут один и тот же объект.

>>> from django.core.cache import caches
>>> cache1 = caches['myalias']
>>> cache2 = caches['myalias']
>>> cache1 is cache2
True

Если именованный ключ не существует, будет вызвана ошибка InvalidCacheBackendError.

Чтобы обеспечить безопасность потоков, для каждого потока будет возвращен другой экземпляр бэкэнда кеша.

django.core.cache.cache

В качестве ярлыка кеш по умолчанию доступен как django.core.cache.cache:

>>> from django.core.cache import cache

Этот объект эквивалентен caches['default'].

Основное использование

Базовый интерфейс:

cache.set(key, value, timeout=DEFAULT_TIMEOUT, version=None)
>>> cache.set('my_key', 'hello, world!', 30)
cache.get(key, default=None, version=None)
>>> cache.get('my_key')
'hello, world!'

key должен быть str, а value может быть любым выбираемым объектом Python.

Аргумент timeout является необязательным и по умолчанию равен аргументу timeout соответствующего серверного модуля в настройке CACHES (объяснено выше). Это количество секунд, в течение которых значение должно храниться в кеше. Передача None в качестве timeout приведет к кешированию значения навсегда. Значение тайм-аута, равное 0, не кэшируется.

Если объект не существует в кеше, cache.get() вернет None:

>>> # Wait 30 seconds for 'my_key' to expire...
>>> cache.get('my_key')
None

Если вам нужно определить, существует ли объект в кеше, и вы сохранили буквальное значение None, используйте объект-дозорный по умолчанию:

>>> sentinel = object()
>>> cache.get('my_key', sentinel) is sentinel
False
>>> # Wait 30 seconds for 'my_key' to expire...
>>> cache.get('my_key', sentinel) is sentinel
True

MemcachedCache

Из-за ограничения python-memcached невозможно различить сохраненное значение None и промах кеша, обозначенный возвращаемым значением None на устаревшем бэкэнде MemcachedCache.

cache.get() может принимать аргумент default. Это указывает, какое значение вернуть, если объект не существует в кеше:

>>> cache.get('my_key', 'has expired')
'has expired'
cache.add(key, value, timeout=DEFAULT_TIMEOUT, version=None)

Чтобы добавить ключ, только если он еще не существует, используйте метод add(). Он принимает те же параметры, что и set(), но не будет пытаться обновить кеш, если указанный ключ уже присутствует:

>>> cache.set('add_key', 'Initial value')
>>> cache.add('add_key', 'New value')
>>> cache.get('add_key')
'Initial value'

Если вам нужно знать, хранит ли add() значение в кеше, вы можете проверить возвращаемое значение. Он вернет True, если значение было сохранено, в противном случае - False.

cache.get_or_set(key, default, timeout=DEFAULT_TIMEOUT, version=None)

Если вы хотите получить значение ключа или установить значение, если ключа нет в кеше, существует метод get_or_set(). Он принимает те же параметры, что и get(), но по умолчанию устанавливается как новое значение кеша для этого ключа, а не просто возвращается:

>>> cache.get('my_new_key')  # returns None
>>> cache.get_or_set('my_new_key', 'my new value', 100)
'my new value'

Вы также можете передать любой вызываемый объект как значение по умолчанию:

>>> import datetime
>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)
datetime.datetime(2014, 12, 11, 0, 15, 49, 457920)
cache.get_many(keys, version=None)

Также есть интерфейс get_many(), который попадает в кеш только один раз. get_many() возвращает словарь со всеми запрошенными вами ключами, которые действительно существуют в кеше (и срок их действия не истек):

>>> cache.set('a', 1)
>>> cache.set('b', 2)
>>> cache.set('c', 3)
>>> cache.get_many(['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}
cache.set_many(dict, timeout)

Чтобы установить несколько значений более эффективно, используйте set_many() для передачи словаря пар ключ-значение:

>>> cache.set_many({'a': 1, 'b': 2, 'c': 3})
>>> cache.get_many(['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}

Как и cache.set(), set_many() принимает необязательный параметр timeout.

В поддерживаемых серверных модулях (memcached) set_many() возвращает список ключей, которые не удалось вставить.

cache.delete(key, version=None)

Вы можете удалить ключи явно с помощью delete(). Это простой способ очистить кеш для определенного объекта:

>>> cache.delete('a')
True

touch() возвращает True, если ключ был получен успешно, в противном случае - False.

Changed in Django 3.1:

Добавлено логическое возвращаемое значение.

cache.delete_many(keys, version=None)

Если вы хотите очистить сразу несколько ключей, delete_many() может взять список ключей, которые нужно очистить:

>>> cache.delete_many(['a', 'b', 'c'])
cache.clear()

Finally, if you want to delete all the keys in the cache, use cache.clear(). Be careful with this; clear() will remove everything from the cache, not just the keys set by your application.

>>> cache.clear()
cache.touch(key, timeout=DEFAULT_TIMEOUT, version=None)

cache.touch() устанавливает новый срок действия ключа. Например, чтобы обновить ключ, срок действия которого истекает через 10 секунд:

>>> cache.touch('a', 10)
True

Как и другие методы, аргумент timeout является необязательным и по умолчанию соответствует параметру TIMEOUT соответствующего бэкэнда в настройке CACHES.

touch() возвращает True, если ключ был поулчен успешно, в противном случае - False.

cache.incr(key, delta=1, version=None)
cache.decr(key, delta=1, version=None)

Вы также можете увеличивать или уменьшать уже существующий ключ с помощью методов incr() или decr() соответственно. По умолчанию существующее значение кэша будет увеличиваться или уменьшаться на 1. Другие значения увеличения/уменьшения могут быть указаны путем предоставления аргумента для вызова увеличения/уменьшения. Ошибка ValueError будет вызвана, если вы попытаетесь увеличить или уменьшить несуществующий ключ кеша.:

>>> cache.set('num', 1)
>>> cache.incr('num')
2
>>> cache.incr('num', 10)
12
>>> cache.decr('num')
11
>>> cache.decr('num', 5)
6

Примечание

Нет гарантии, что методы incr()/decr() являются атомарными. На тех бэкэндах, которые поддерживают атомарное увеличение/уменьшение (в первую очередь, бэкэнд memcached), операции увеличения и уменьшения будут атомарными. Однако, если серверная часть изначально не обеспечивает операцию увеличения/уменьшения, она будет реализована с использованием двухэтапного извлечения/обновления.

cache.close()

Вы можете закрыть соединение с вашим кешем с помощью close(), если это реализовано серверной частью кеша.

>>> cache.close()

Примечание

Для кешей, которые не реализуют методы закрытия close, это не работает.

Префикс ключа кеширования

Если вы разделяете экземпляр кеша между серверами или между производственной средой и средой разработки, данные, кэшированные одним сервером, могут использоваться другим сервером. Если формат кэшированных данных на разных серверах различается, это может привести к очень трудным для диагностики проблемам.

Чтобы предотвратить это, Django предоставляет возможность добавлять префиксы ко всем ключам кеша, используемым сервером. Когда определенный ключ кеша сохраняется или извлекается, Django автоматически добавит префикс ключа кеша со значением параметра KEY_PREFIX.

Убедившись, что каждый экземпляр Django имеет разные KEY_PREFIX, вы можете гарантировать, что не будет конфликтов в значениях кеша.

Управление версиями кеша

При изменении выполняемого кода, использующего кэшированные значения, вам может потребоваться очистить все существующие кэшированные значения. Самый простой способ сделать это - очистить весь кеш, но это может привести к потере значений кеша, которые остаются действительными и полезными.

Django предоставляет лучший способ нацеливания на отдельные значения кеша. Структура кеширования Django имеет общесистемный идентификатор версии, указанный с помощью параметра кеширования VERSION. Значение этого параметра автоматически комбинируется с префиксом кэша и предоставленным пользователем ключом кэша для получения окончательного ключа кэша.

По умолчанию любой ключевой запрос будет автоматически включать версию ключа кэша сайта по умолчанию. Однако все примитивные функции кеширования включают аргумент version, поэтому вы можете указать конкретную версию ключа кеша, которую нужно установить или получить. Например:

>>> # Set version 2 of a cache key
>>> cache.set('my_key', 'hello world!', version=2)
>>> # Get the default version (assuming version=1)
>>> cache.get('my_key')
None
>>> # Get version 2 of the same key
>>> cache.get('my_key', version=2)
'hello world!'

Версия определенного ключа может увеличиваться и уменьшаться с помощью методов incr_version() и decr_version(). Это позволяет перенести определенные ключи на новую версию, не затрагивая другие ключи. Продолжая наш предыдущий пример:

>>> # Increment the version of 'my_key'
>>> cache.incr_version('my_key')
>>> # The default version still isn't available
>>> cache.get('my_key')
None
# Version 2 isn't available, either
>>> cache.get('my_key', version=2)
None
>>> # But version 3 *is* available
>>> cache.get('my_key', version=3)
'hello world!'

Преобразование ключа кеша

Как описано в предыдущих двух разделах, ключ кеша, предоставленный пользователем, не используется дословно - он комбинируется с префиксом кеша и версией ключа для получения окончательного ключа кеша. По умолчанию три части соединяются двоеточиями для получения финальной строки:

def make_key(key, key_prefix, version):
    return '%s:%s:%s' % (key_prefix, version, key)

Если вы хотите объединить части по-разному или применить другую обработку к финальному ключу (например, взяв хеш-дайджест ключевых частей), вы можете предоставить настраиваемую ключевую функцию.

Параметр KEY_FUNCTION указывает путь через точки к функции, соответствующей прототипу make_key() выше. Если предоставляется, эта настраиваемая функция клавиш будет использоваться вместо функции объединения клавиш по умолчанию.

Предупреждения о ключах кеширования

Memcached, наиболее часто используемый бэкэнд производственного кеша, не позволяет использовать ключи кеша длиной более 250 символов или содержащие пробелы или управляющие символы, и использование таких ключей вызовет исключение. Чтобы поощрять переносимый кэш-код и минимизировать неприятные сюрпризы, другие встроенные серверные части кеша выдают предупреждение (django.core.cache.backends.base.CacheKeyWarning), если используется ключ, который может вызвать ошибку в memcached.

Если вы используете производственный бэкэнд, который может принимать более широкий диапазон ключей (пользовательский бэкэнд или один из встроенных бэкэндов без memcached), и хотите использовать этот более широкий диапазон без предупреждений, вы можете отключить CacheKeyWarning с этим кодом в модуле management одного из ваших INSTALLED_APPS:

import warnings

from django.core.cache import CacheKeyWarning

warnings.simplefilter("ignore", CacheKeyWarning)

Если вы хотите вместо этого предоставить настраиваемую логику проверки ключей для одного из встроенных бэкэндов, вы можете создать его подкласс, переопределить только метод validate_key и следовать инструкциям по использованию пользовательского бэкэнда кеширования. Например, чтобы сделать это для бэкэнда locmem, поместите этот код в модуль:

from django.core.cache.backends.locmem import LocMemCache

class CustomLocMemCache(LocMemCache):
    def validate_key(self, key):
        """Custom validation, raising exceptions or warnings as needed."""
        ...

…и используйте разделенный точками путь Python к этому классу в части BACKEND вашей настройки CACHES.

Последующие кеши

До сих пор этот документ был сосредоточен на кэшировании ваших собственных данных. Но другой тип кэширования также актуален для веб-разработки: кэширование, выполняемое «нисходящими» кэшами. Это системы, которые кэшируют страницы для пользователей еще до того, как запрос достигнет вашего веб-сайта.

Вот несколько примеров нижестоящих кешей:

  • When using HTTP, your ISP may cache certain pages, so if you requested a page from http://example.com/, your ISP would send you the page without having to access example.com directly. The maintainers of example.com have no knowledge of this caching; the ISP sits between example.com and your Web browser, handling all of the caching transparently. Such caching is not possible under HTTPS as it would constitute a man-in-the-middle attack.
  • Ваш веб-сайт Django может находиться за прокси-кешем, таким как Squid Web Proxy Cache (http://www.squid-cache.org/), который кэширует страницы для повышения производительности. В этом случае каждый запрос сначала будет обрабатываться прокси, и он будет передан вашему приложению только в случае необходимости.
  • Ваш веб-браузер также кэширует страницы. Если веб-страница отправляет соответствующие заголовки, ваш браузер будет использовать локальную кэшированную копию для последующих запросов к этой странице, даже не обращаясь к веб-странице снова, чтобы увидеть, изменилась ли она.

Нисходящее кэширование - хороший прирост эффективности, но в нем есть опасность: содержимое многих веб-страниц различается в зависимости от аутентификации и множества других переменных, а системы кеширования, которые слепо сохраняют страницы, основанные исключительно на URL-адресах, могут предоставлять неверные или конфиденциальные данные последующим посетители этих страниц.

Например, предположим, что вы используете веб-систему электронной почты, и содержимое страницы «Входящие», очевидно, зависит от того, какой пользователь вошел в систему. Если интернет-провайдер слепо кэширует ваш сайт, то первый пользователь, который вошел в систему через этого интернет-провайдера, получит пользовательскую страница почтового ящика, которая закэшируется для последующих посетителей сайта. Это не круто.

К счастью, HTTP предоставляет решение этой проблемы. Существует ряд заголовков HTTP, чтобы дать указание нижестоящим кэшам различать их содержимое в зависимости от назначенных переменных и сообщить механизмам кэширования не кэшировать определенные страницы. Мы рассмотрим некоторые из этих заголовков в следующих разделах.

Использование заголовков Vary

Заголовок Vary определяет, какие заголовки запросов механизм кеширования должен учитывать при построении своего ключа кеша. Например, если содержимое веб-страницы зависит от языковых предпочтений пользователя, говорят, что страница «зависит от языка».

По умолчанию система кеширования Django создает свои ключи кеша, используя запрошенный полный URL-адрес, например, "https://www.example.com/stories/2005/?order_by=author". Это означает, что каждый запрос к этому URL-адресу будет использовать одну и ту же кешированную версию, независимо от различий между пользовательскими агентами, таких как файлы cookie или языковые предпочтения. Однако, если эта страница создает различный контент в зависимости от некоторой разницы в заголовках запросов, таких как файл cookie, язык или пользовательский агент, вам необходимо использовать заголовок Vary, чтобы сообщить механизмы кэширования. что вывод страницы зависит от этих вещей.

Для этого в Django используйте удобный декоратор представлений django.views.decorators.vary.vary_on_headers(), например:

from django.views.decorators.vary import vary_on_headers

@vary_on_headers('User-Agent')
def my_view(request):
    ...

В этом случае механизм кэширования (например, собственное промежуточное ПО кеширования Django) будет кэшировать отдельную версию страницы для каждого уникального пользовательского агента.

Преимущество использования декоратора var_on_headers вместо того, чтобы вручную устанавливать заголовок Vary (используя что-то вроде response.headers ['Vary'] = 'user-agent'), заключается в том, что декоратор добавляется к заголовку Vary (который может уже существовать) вместо того, чтобы устанавливать его с нуля и потенциально отменять все, что уже было там.

Вы можете передать несколько заголовков в var_on_headers():

@vary_on_headers('User-Agent', 'Cookie')
def my_view(request):
    ...

Это указывает нисходящим кэшам, чтобы они менялись для обоих, что означает, что каждая комбинация пользовательского агента и cookie будет иметь собственное значение кеша. Например, запрос с пользовательским агентом Mozilla и значением cookie foo=bar будет считаться отличным от запроса с пользовательским агентом Mozilla и значением cookie foo = ham.

Поскольку изменение файлов cookie является обычным явлением, существует декоратор django.views.decorators.vary.vary_on_cookie(). Эти два представления эквивалентны:

@vary_on_cookie
def my_view(request):
    ...

@vary_on_headers('Cookie')
def my_view(request):
    ...

Заголовки, которые вы передаете в var_on_headers, не чувствительны к регистру; "User-Agent" - это то же самое, что "user-agent".

Вы также можете напрямую использовать вспомогательную функцию django.utils.cache.patch_vary_headers(). Эта функция устанавливает или дополняет заголовок Vary. Например:

from django.shortcuts import render
from django.utils.cache import patch_vary_headers

def my_view(request):
    ...
    response = render(request, 'template_name', context)
    patch_vary_headers(response, ['Cookie'])
    return response

patch_vary_headers принимает экземпляр HttpResponse в качестве первого аргумента и список/кортеж имен заголовков без учета регистра в качестве второго аргумента.

Дополнительные сведения о заголовках Vary смотрите в official Vary spec.

Управление кешем: использование других заголовков

Другие проблемы с кешированием - это конфиденциальность данных и вопрос о том, где данные должны храниться в каскаде кешей.

Пользователь обычно сталкивается с двумя типами кешей: их собственный кеш браузера (частный кеш) и кеш поставщика (общедоступный кеш). Публичный кеш используется несколькими пользователями и контролируется кем-то другим. Это создает проблемы с конфиденциальными данными - например, вы не хотите, чтобы номер вашего банковского счета хранился в общедоступном кэше. Таким образом, веб-приложениям необходим способ сообщать кешам, какие данные являются частными, а какие общедоступными.

Решение состоит в том, чтобы указать, что кеш страницы должен быть «частным». Для этого в Django используйте декоратор представлений cache_control(). Пример:

from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request):
    ...

Этот декоратор заботится об отправке соответствующего HTTP-заголовка за кулисами.

Обратите внимание, что параметры управления кешем «частный» и «общедоступный» являются взаимоисключающими. Декоратор гарантирует, что директива «public» будет удалена, если необходимо установить «private» (и наоборот). Примером использования двух директив может быть сайт блога, который предлагает как частные, так и публичные записи. Общедоступные записи могут храниться в любом общем кэше. В следующем коде используется patch_cache_control(), ручной способ изменения заголовка элемента управления кешем (он вызывается изнутри декоратором cache_control()):

from django.views.decorators.cache import patch_cache_control
from django.views.decorators.vary import vary_on_cookie

@vary_on_cookie
def list_blog_entries_view(request):
    if request.user.is_anonymous:
        response = render_only_public_entries()
        patch_cache_control(response, public=True)
    else:
        response = render_private_and_public_entries(request.user)
        patch_cache_control(response, private=True)

    return response

Вы можете управлять кэшем нисходящего потока и другими способами (подробности о кэшировании HTTP смотрите в RFC 7234). Например, даже если вы не используете инфраструктуру кеширования на стороне сервера Django, вы все равно можете указать клиентам кэшировать представление на определенное время с помощью max-age директивы:

from django.views.decorators.cache import cache_control

@cache_control(max_age=3600)
def my_view(request):
    ...

(Если вы действительно используете промежуточное ПО для кэширования, оно уже устанавливает max-age со значением параметра CACHE_MIDDLEWARE_SECONDS. В этом случае пользовательский max_age из декоратора cache_control() будет иметь приоритет, и значения заголовков будут правильно объединены.)

Любая допустимая директива ответа Cache-Control действительна в cache_control(). Вот еще несколько примеров:

  • no_transform=True
  • must_revalidate=True
  • stale_while_revalidate=num_seconds
  • no_cache=True

Полный список известных директив можно найти в реестре IANA (обратите внимание, что не все из них применимы к ответам).

Если вы хотите использовать заголовки для полного отключения кеширования, never_cache() - это декоратор представления, который добавляет заголовки, чтобы гарантировать, что ответ не будет кэшироваться браузерами или другими кешами. Пример:

from django.views.decorators.cache import never_cache

@never_cache
def myview(request):
    ...

Последовательность MIDDLEWARE

Если вы используете промежуточное ПО кэширования, важно поместить каждую часть в нужное место в параметре MIDDLEWARE. Это связано с тем, что промежуточное программное обеспечение кеширования должно знать, какие заголовки можно использовать для изменения хранилища кеша. Промежуточное ПО всегда добавляет что-то в заголовок ответа Vary, когда это возможно.

UpdateCacheMiddleware запускается на этапе ответа, где промежуточное ПО запускается в обратном порядке, поэтому элемент в верхней части списка запускается последним на этапе ответа. Таким образом, вам необходимо убедиться, что UpdateCacheMiddleware появляется перед любым другим промежуточным программным обеспечением, которое может что-то добавить в заголовок Vary. Следующие промежуточные модули делают это:

  • SessionMiddleware добавляет Cookie
  • GZipMiddleware добавляет Accept-Encoding
  • LocaleMiddleware добавляет Accept-Language

FetchFromCacheMiddleware, с другой стороны, запускается на этапе запроса, где промежуточное программное обеспечение применяется от первого до последнего, поэтому элемент в верхней части списка запускается первым на этапе запроса. FetchFromCacheMiddleware также необходимо запускать после того, как другое промежуточное ПО обновляет заголовок Vary, поэтому FetchFromCacheMiddleware должно быть после любого элемента, который это делает.

Вернуться на верх