Использование отдельного сайта для разработки всегда очень хорошая вещь.Тем не менее, возможность легко отключить кэширование на производственной площадке может принести некоторые дополнительные преимущества:
- , чтобы исследовать тонкие ошибки, связанные с кэшированием
- , чтобы измерить эффективный прирост производительности с реальными производственными данными
Я верю, что это можно успешно решить с помощью небольшого количества кода, обеспечивающего тонкий пользовательский бэкэнд для кэширования.
В основном:
- Джанго создает экземпляркешировать объект «по умолчанию» один раз при запуске, обрабатывая его как одноэлементный, и использовать его навсегда
- В нашем пользовательском бэкэнде кэша мы будем хранить внутренний экземпляр двух отдельных объектов («пустышка» и «файл»)на основе кэша) и выставить только один из них через необходимые методы интерфейса
- Таким образом, мы фактически действуем как прокси класса либо для FileBasedCache, либо для DummyCache
- Мы можем легко контролировать, какой объектактивен с переменной, таким образом переключая поведение во время выполнения, без необходимости перезапуска Django
Следующее POC было проверено в небольшом тестовом проекте с положительными результатами.
Сначала напишите класс «proxy», который ведет себя как FileBasedCache или DummyCache:
file 'project / mycache.py ':
from django.core.cache.backends.filebased import FileBasedCache
from django.core.cache.backends.dummy import DummyCache
from django.core.cache.backends.base import DEFAULT_TIMEOUT
from constance import config
class MyCache(DummyCache):
def __init__(self, *args, **kwargs):
self.dummy_cache = DummyCache(*args, **kwargs)
self.file_cache = FileBasedCache(*args, **kwargs)
def _active_cache(self):
"""
Select either DummyCache or FileBasedCache based on configuration
"""
return self.file_cache if config.CACHING_ENABLED else self.dummy_cache
def add(self, key, value, timeout=DEFAULT_TIMEOUT, version=None):
return self._active_cache().add(key, value, timeout, version)
def get(self, key, default=None, version=None):
return self._active_cache().get(key, default, version)
def set(self, key, value, timeout=DEFAULT_TIMEOUT, version=None):
self._active_cache().set(key, value, timeout, version)
def touch(self, key, timeout=DEFAULT_TIMEOUT, version=None):
return self._active_cache().touch(key, timeout, version)
def delete(self, key, version=None):
self._active_cache().delete(key, version)
def has_key(self, key, version=None):
return self._active_cache().has_key(key, version)
def clear(self):
self._active_cache().clear()
и ссылаться на него в настройках проекта следующим образом:
CACHES = {
'default': {
'BACKEND': 'project.mycache.MyCache',
'LOCATION': '/var/www/mysite.com/cache,
}
}
Обратите внимание, что фактические действия делегированы одному из двух внутренних объектов,в соответствии с текущим значением config.CACHING_ENABLED .Логика кэширования не была повторно реализована в прокси-модели.
Наконец, для управления флагом переключения от администратора (простая часть) определите логическое значение 'CACHING_ENABLED' для django-constance (популярное приложение, которое предоставляет интерфейс администратора для редактирования динамических настроек).
Добавьте это в настройки проекта:
INSTALLED_APPS = [
...
'constance',
'constance.backends.database',
]
CONSTANCE_BACKEND = 'constance.backends.database.DatabaseBackend'
CONSTANCE_CONFIG = {
'CACHING_ENABLED': (True, 'Set to False to disable caching'),
}
затем:
pip install django-constance[database]
python manage.py migrate