Есть ли причина не использовать USE_ETAGS с CommonMiddleware в Django?

Question

Единственная причина, по которой я могу думать, это то, что вычисление ETag может быть дорогим. Если страницы меняются очень быстро, кеш браузера, вероятно, будет аннулирован ETag. В этом случае вычисление ETag было бы пустой тратой времени. С другой стороны, предоставление ответа 304, когда это возможно, минимизирует количество времени, затрачиваемого на передачу. Каковы хорошие рекомендации, когда ETag могут быть чистыми победителями при реализации с CommonMiddleware?

в Django?

Answer 1

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

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

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

Опять же, будет полезно попытаться профилировать это с вашими реальными данными, а не обобщать, чтобы «делать или не использовать».

Answer 2

Существует много способов обработки кэширования, и часто это зависит от приложения, в первых сценариях я предлагаю, как вы можете рассмотреть возможность использования USE_ETAGS из django.middleware.common.CommonMiddleware:

1. Разделите ваше приложение между кешируемым и не кешируемым экземплярами gunicorn. Соедините сайт с обратным прокси. Затем продолжите,

2. Написание кода, который делает недействительным кеш при сохранении модели. В качестве следующего шага,

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

Answer 3

Я не понимаю, почему вы ищете причину не делать что-то. Однако ваш анализ далек от завершения: условные запросы / 304 ответа могут на самом деле заставить ваше приложение работать значительно медленнее, чем если бы вы удалили if-Modified-Since / If-None-Match, однако они действительно удовлетворяют поисковые системы и имеют преимущество репликация сервер-сервер (например, в CDN)

С