Re: Bug – 304 status - Cache-Control
S.A.N
nginx-forum at nginx.us
Sat Jan 4 10:13:55 UTC 2014
> > Есть более красивые решения этой проблемы?
> А в чем, собственно, состоит проблема?
>
> Я вот даже не могу понять - если вы все равно пропускаете все запросы
> на бекенд для ревалидации по e-tag - зачем у вас включено кеширование
> на nginx?
Не все запросы всегда идут на бекенд, многие из них кешируются на
определенный интервал времени, от 1 до 10000 секунд, всё зависит от
функционала конкретного скрипта.
Есть скрипты которые генерят, страницы под сесию юзера, такие страницы
удобно кешить на стороне клиента т.е. в браузере.
По этому и возникает проблема, в Nginx все гладко если бекенд использует
только Nginx кеширования, или только клиент кеширования при выключенном
Nginx кешировании. Наша задача, в рамках одного server{} добится корректной
работы клиентского и серверного кеширования.
Немного статистики, чтобы показать что это эффективно, ниже цифры выполнения
запросов без учета времени на конект
2 ms - Nginx отдает ответ из своего кеша
7 ms - Nginx отправляет запрос на бекенд для ревалидации, бекенду достаточно
5 ms, чтобы отдать 304 статус
60 ms - 800 ms, необходимо РНР для генерации страницы, все зависит от
сложности логики срипта и наличии SQL кеша в Memcache.
Как видите, разница в скорости в десятки раз отличается, главный плюс
ревалидации в том что скорость её выполнения практически не зависит от
сложности скрипта который создал эту страницу, потому что алгоритмы
ревалидации очень просты и эффективны.
Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246010#msg-246010
Подробная информация о списке рассылки nginx-ru