Show all posts by user
Discussions in German
Наверно стоит объяснить почему логику кеширования мы вынесли на бекенд и минимально используем конфиг 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.
>
&g
by
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 минут, этим занимается директива
htt
by
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
> Connecti
by
S.A.N
-
Nginx Mailing List - Russian