Наверно стоит объяснить почему логику кеширования мы вынесли на бекенд и минимально используем конфиг Nginx. Нашим бекендом, пользуются не только браузеры но и мобил приложения, у них логика кеширования очень продвинуby S.A.N - Nginx Mailing List - Russian
> Если я правильно понял этот поток текста, то на выходе вы хотите > получить что-то вроде "The stale-if-error Cache-Control > Extension", http://tools.ietf.org/html/rfc5861#section-4. Т.е. > возможность задать в заголовках ответа - можно ли этот отвby S.A.N - Nginx Mailing List - Russian
> >Но все эти детали лучше не говорить тем кто только начинает изучать > механизмы кеширования в Nginx ) > Почему? Чтобы не пугать, раньше времени )by S.A.N - Nginx Mailing List - Russian
> "логика кеширования в Nginx такая же как в браузерах", - есть и > отличия: > > http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cac > he_bypass > > если выполняется условие fastcgi_cache_bypass и не выполняется > условие fastcgi_no_cache - тоby S.A.N - Nginx Mailing List - Russian
> >С этого и надо было начинать, они нужны обязательно если вы хотите > клиенту отдавать 304 без контента. > А можно ли создавать ETag и Last-Modified на стороне nginx и для > статики и для динамики? > > есть директива etag on;by S.A.N - Nginx Mailing List - Russian
> >Я имел виду, ревалидация В приложении это - RESTful стиль. > > Не знал, насколько я знаю, обычно REST преподносят, как набор > методов(действий), которые можно выполнить с объектом и путь к этому > объекту. Да, но неby S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > >Это понятно, ревалидировать кеш на в приложении - это стиль RestFull > приложений, > НЕ в приложении? Я имел виду, ревалидация В приложении это - RESTful стиль.by S.A.N - Nginx Mailing List - Russian
> >те кто обновляет страницу в ручную будут получать 304 статус без > контента, > Только если в запросе, который должен закэшироваться, был > заголовок-валидатор(ETag, Last-Modified) иначе нечего будет > сравнивать. > Уby S.A.N - Nginx Mailing List - Russian
> Значит моя схема вполне жизнеспособна и не выглядит нормально? Кладём > основную нагрузку на nginx и немного на браузер. Я думаю да, но лучше проконсультироватся у разработчиков Nginx, как реагирует Nginx если кеш файлы иby S.A.N - Nginx Mailing List - Russian
> Я нажимал не F5, а кнопку браузера, что видимо эквивалентно. Но я > тогда не понимаю, когда вообще юзеру поможет браузерный кэш? > Когда он будет по ссылкам ходить, только тогда из кэша браузера будет > доставаться?by S.A.N - Nginx Mailing List - Russian
> >Эта схема защитит ваше приложения от нагрузки, но она никак не сможет > актуализировать кеш быстрей чем это указанно в max-age. > Я же сказал, что мы можем чистить кэш nginx когда нам это нужно. Если у вас есть стороннby S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > >Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к > серверу вообще, потому что вы ему сказали, что кеш можно использовать > без ревалидации на протяжении 600 сеby S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > >В этом случаи приложения должно уметь очень быстро проверять > If-Modified-Since с текущим Last-Modified, если они равны отдавать > 304, если нет отдавать новый контент и статус 200. > &gby S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > Большое спасибо за ответ, теперь понял. > > А если браузер присылает в запросе Cache-Control: no-cache(или > max-age=0), что часто бывает, а я хочу отдавать кэш, мне как-то > игнорироватьby S.A.N - Nginx Mailing List - Russian
Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к серверу вообще, потому что вы ему сказали, что кеш можно использовать без ревалидации на протяжении 600 секунд. После истечения 600 секунд, браузер сделает запрby S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > >Зачем вы выбрали такое значения Cache-Control: max-age=600 no-cache? > > Этой строчкой я хотел сказать браузеру: держи у себя кэш 600 секунд, > но при каждом запросе отправляй заголовки(by S.A.N - Nginx Mailing List - Russian
Лучше управлять кешированием из приложения, это более правильное решения и более гибкое, таким образом приложения самостоятельно решает какой контент на какой период кешировать и эти же заголовки отправятся в браузеby S.A.N - Nginx Mailing List - Russian
Да, директивы uwsgi_cache_valid для этого и придумали, чтобы управлять кешированием, если бекенд приложения не может самостоятельно отправить правильные заголовки.by S.A.N - Nginx Mailing List - Russian
Если так uwsgi_ignore_headers X-Accel-Expires Expires Cache-Control Set-Cookie; uwsgi_hide_header Set-Cookie; uwsgi_cache_valid 200 10m; Тогда не важно какие заголовки отправил проксируемый сервер (бекенд), ответ будет закеширован на 10 минут, этим занимается директива httby S.A.N - Nginx Mailing List - Russian
>Я хочу принять ответ от uwsgi, > добавить в него пару заголовков и отдать клиенту. > Фактически добавить заголовки в ответ nginx. > Я таким образом хочу управлять кэшем. Вы таким образом сможете управлять только кешеby S.A.N - Nginx Mailing List - Russian
Nginx 1.7.3, отличная версия, в ней полностью решен вопрос с ETag. Но есть мелочи которых очень не хватает, их всего две ) 1. Нельзя получить от клиента валидаторы (“If-Modified-Since” и “If-None-Match”) если файла кеша нет, эта ситуация воby S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > >Pragma - это костыльный заголовок который вообще не стоит > использовать для кеширования > Он для HTTP 1.0 Костыльность Pragma, заключается в том что это заголовок запроса а не оby S.A.N - Nginx Mailing List - Russian
Cache-Control: max-age=сколько секунд, кеш считается валидным, после истечения этого времени проводится ревалидации Expires: GMT дата, после истечения этой даты проводится ревалидации Pragma - это костыльный заголовок который вообще нby S.A.N - Nginx Mailing List - Russian
Да, это дата модификации контента, она может и не быть равна дате создания кеша, зачем вам именно дата создания кеша?by S.A.N - Nginx Mailing List - Russian
Если приложения отдает заголовок Last-Modified, он сохраняется в кеше, его значения можно получить в заголовке If-Modified-Since или в конфиге Nginx переменная $upstream_cache_last_modified.by S.A.N - Nginx Mailing List - Russian
> Просто я пока не знаю других способов, кроме как монтировать в память, > но может они есть? Если у вас SSD, или отдача статика происходит за 5-15ms, смысла забирать память под статику я особо не вижу, лучше её отдать прилby S.A.N - Nginx Mailing List - Russian
> Поставил, вырубил приложение, на главной странице 502, а статика > отдаётся, прикольно. Так может быть, есть смысл и все остальные страницы кешировать, опыт у вас уже есть. > Мне ещё нужно рассмотреть вариант хранеby S.A.N - Nginx Mailing List - Russian
> В итоге без этой строчки не работает proxy_ignore_headers > Cache-Control; > > Похоже, приложение говорит так nginx не кешить и он не кэшит. > А эта строчка игнорирует заголовок и nginx кэшит. Да, так и есть. > А как проверить, чтоby S.A.N - Nginx Mailing List - Russian
Спрятать Pragma:no-cache, можно директивой proxy_hide_header http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_hide_header Так с кешем все нормально, все что нужно кешится?by S.A.N - Nginx Mailing List - Russian
Budulianin Wrote: ------------------------------------------------------- > Ваш ключ недопустим, поставил такой proxy_cache_key > $scheme$proxy_host$uri$is_args$args; Страно, у меня fastcgi_cache_key стоит "$host$uri$is_args$args" и все норм > > Ответ: > > Cache-Control:max-age=5184000 > Connectiby S.A.N - Nginx Mailing List - Russian