Вопрос

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

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

Проверка наличия устаревших данных - не очень безопасный метод тестирования IMO.

Это было полезно?

Решение

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

<!-- component_name {{host}} {{timestamp}} -->

Имя_компонента просто упрощает просмотр и поиск этой строки.

Все наши представления, которые являются страницами сведений об объектах, определяют переменную контекста " page_object " и у нас это есть в верхней части шаблона шаблона base.html:

<!-- {{page_object.class_id}} @ {{timestamp}} -->

class_id () - это метод из суперкласса, используемый всеми нашими основными классами контента. Это просто:

def class_id(self):
    "%s.%s.%s" % (self.__class__._meta.app_label,
                    self.__class__.__name__, self.id)

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

Другие советы

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

 <!-- {% now "jS F Y H:i" %} --> 

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top