Стандартное поведение Varni sh соответствует рекомендациям по кэшированию HTTP.
Это означает:
- Только вызовы HTTP GET и HTTP HEAD для кэширования
- Не обслуживать ответы из кэша, когда запрос содержит
cookie
заголовки - Не обслуживать ответы из кэша, если запрос содержит
authorization
заголовки - Не хранить ответы в кеше, когда присутствуют
set-cookie
заголовки - Не хранить ответы в кеше, когда заголовок
cache-control
равен нулю TTL или когда он содержит следующее: no-cache
, или no-store
, или private
При любых обстоятельствах Varni sh будет пытаться обслуживать из кэша или сохранять в кэше.
Это поведение, записанное в VCL: https://github.com/varnishcache/varnish-cache/blob/6.0/bin/varnishd/builtin.vcl
Адаптация к реальному миру
Хотя эти лучшие практики кэширования имеют смысл, они не Реалист c, когда вы смотрите на реальный мир . В реальном мире мы постоянно используем куки.
Поэтому вам, вероятно, придется написать код VCL , чтобы изменить поведение кэша. Для этого вы должны быть хорошо знакомы с конечными точками HTTP вашего приложения, а также с частями, в которых используются файлы cookie.
- Части вашего приложения, в которых используются значения cook ie на стороне сервера будет необходимо исключить из кэширования
- Части вашего приложения, в которых значения cook ie не используются, будут храниться в кэше
- Отслеживание файлов cookie, которые используются только в клиентская часть должна быть удалена
Как проверить, что происходит
Двоичный файл varnishlog
поможет вам понять, какой трафик c проходит через Варни sh и как Varni sh ведет себя с этим трафиком c.
Я написал подробное сообщение в блоге об этом, пожалуйста, посмотрите: https://feryn.eu/blog/varnishlog-measure-varnish-cache-performance/
Написание VCL
После того, как вы выяснили, что вызывает снижение производительности, вы можете написать VCL для смягчения. Пожалуйста, загляните на сайт документации, чтобы узнать о VCL: https://varnish-cache.org/docs/6.0/index.html
Справочный материал, руководство пользователя и даже учебник.
Хорошо удачи