> а вот лог backend, видно что при ревалидации отдает не только 304, но > и полную сущность, а не только заголовок Бекенд, не должен отдавать тело ответа со статусом 304, вам достаточно отдать только заголовки и статус 304.by S.A.N - Nginx Mailing List - Russian
> в чем тут проблема? как не загружать с бекенда полностью весь ответ > (1048769 bytes), а только обновить данные что кеш валидный затратив на > это всего 4096 bytes Если if-Modified-Since/If-None-Match валидные, отдавайте 304 статус, без телаby S.A.N - Nginx Mailing List - Russian
> Extension", http://tools.ietf.org/html/rfc5861#section-4. Т.е. > возможность задать в заголовках ответа - можно ли этот ответ в > дальнейшем использовать при ошибках Chrome, реализовал директиву stale-while-revalidate, опция пока что экспериментальby S.A.N - Nginx Mailing List - Russian
> На фронте имеется n-ое количество nginx которые выступают в качестве > балансировщиков. > Нужно наладить единый кэш для всех фронтенд nginxов. Какие есть > возможности > в nginx для реализации этой задачи? Если я правby S.A.N - Nginx Mailing List - Russian
> Изменения в nginx 1.7.8, > 02.12.2014: > > *) Изменение: теперь строки "If-Modified-Since", "If-Range" и им > подобные в заголовке запроса клиента передаются бэкенду при > включённом кэшировании, если nginx заранее зby S.A.N - Nginx Mailing List - Russian
Здравствуйте. Если счетчик cache_min_uses, будет срабатывать только на ответы бекенда в которых нет запрета на публичное кеширования, тогда ответ с заголовков Cache-Control: private, не должен изменить счетчик cache_min_uses, Nginx должен переby S.A.N - Nginx Mailing List - Russian
Валентин Бартенев Wrote: ------------------------------------------------------- > Конечно, у задачи сжатия перед кэшированиям тоже есть свои юзкейсы, но > её реализация не так проста, как может показаться. Скорее всего для > этого > придетby S.A.N - Nginx Mailing List - Russian
Валентин Бартенев Wrote: ------------------------------------------------------- > nginx - это такой веб-сервер, с помощью которого можно измерить > производительность ab, но не наоборот. :) Вот по этому, компрессию лучше производить в Nginx, в кеше сby S.A.N - Nginx Mailing List - Russian
Gena Makhomed Wrote: ------------------------------------------------------- > Каким образом скорость соединения с клиентом > влияет на время *блокировки* воркера nginx ? > > nginx работает с сетью в неблокирующем режиме. Да, вы правы, медленный клиентby S.A.N - Nginx Mailing List - Russian
Gena Makhomed Wrote: ------------------------------------------------------- > Совершенно не понятно, почему лучше будеть сжимать ответы бекенда > на стороне nginx, а не на самом бекенде, особенно если учесть, что: > > 1) любая "долгоиграющая" опеby S.A.N - Nginx Mailing List - Russian
При кешировании ответов бекенда, нужно научить Nginx предварительно сжимать ответ бекенда, если данный ответ соответствует указанному gzip_types. Раньше это было сложно по многим причинам, не было модуля gunzip и не было weak ETag,by S.A.N - Nginx Mailing List - Russian
Михаил Монашёв Wrote: ------------------------------------------------------- > Здравствуйте, Maxim. > > > *) Изменение: теперь строки "If-Modified-Since", "If-Range" и им > > подобные в заголовке запроса клиента передаются бэкенду при > &gby S.A.N - Nginx Mailing List - Russian
> Изменения в nginx 1.7.7 > 28.10.2014 > > *) Изменение: теперь nginx учитывает при кэшировании строку "Vary" > в > заголовке ответа бэкенда. Где можно почитать подробности влияния Vary, на кешby S.A.N - Nginx Mailing List - Russian
Евгений Удовихин Wrote: ------------------------------------------------------- > В общем разобрался, просто в header функция time в принципе > некорректно > себя ведет, если вывести time()+1 в отдельную переменную и > подставлять, то > тогда все раby S.A.N - Nginx Mailing List - Russian
Вы указываете временную дельту равной 1 секунде, относительно от последнего запроса к РНР бекенду. Возможно вам больше подойдет вариант указывать абсолютный unix time. Как-то так header('X-Accel-Expires: @'.time() + 1);by S.A.N - Nginx Mailing List - Russian
> В nginx 1.7.3+ при включении ssi_last_modified не удаляются weak > entity tags (а strong преобразуются в weak), что позволяет > ревалидировать SSI-ответы по ETag в том числе. Ok, спасибоby S.A.N - Nginx Mailing List - Russian
В документации не нашел, описания как включить ревалидацию по ETag, для модуля SSI, аналог SSIETag в Apache . В Nginx, ssi_etag уже есть, или пока что в разработке?by S.A.N - Nginx Mailing List - Russian
> Надо только - чтобы Epoch у пакетов из репозиториев nginx.org был выше > чем у пакета nginx из репозитория EPEL и других сторонних > репозиториев. > > Потому что EPEL содержит много полезных пакетов и его очень часто > подкby S.A.N - Nginx Mailing List - Russian
> > Да, думаю будет правильным если Nginx из ветке mainline, будет иметь > Epoch > > выше чем у ветки stable. > > Нет. Epoch не надо применять там, где достаточно будет версии пакета. > Если значение Epoch одинаково - rpm тогда смотby S.A.N - Nginx Mailing List - Russian
> 2. с помощью плагина yum-plugin-priorities настроить приоритеты > репозиториев таким образом, чтобы у EPEL был более низкий приоритет. > это в любом случае полезно настроить для всех используемых > репозиториев Спасибо, тby S.A.N - Nginx Mailing List - Russian
> Пакеты для CentOS 7 доступны. > > http://nginx.org/en/linux_packages.html#mainline После, выхода EPEL репозитория для CentOS 7, наблюдается проблема с обновлением Nginx. http://ftp.tlk-l.net/pub/mirrors/fedora-epel/7/x86_64/repoview/epel-release.html yum update - постоянно пытается обнby S.A.N - Nginx Mailing List - Russian
> Всегда их включать? Они так постоянно будут уходить к клиенту. > Или только, когда нужно, добавлять в конфиг. Включать всегда их не нужно. Включать нужно только на стадии разработки, для удобства дебага. Так удобнby S.A.N - Nginx Mailing List - Russian
> Эти заголовки будут содержаться в закэшированном ответе, но как они > могут мне помочь? Нет, эти заголовки не попадают в файл кеша Nginx. Заголовки пойдут в браузер, вы сможете их посмотреть в браузере и точно знать,by S.A.N - Nginx Mailing List - Russian
> Всеравно nginx отдаст 304 ответ из своего кеша еще быстрее, > чем веб-приложение на которое он проксирует запросы клиентов. Да, конечно. Но вы не сможете постоянно хранить ответы в кеше, их придется когда-то ревалидироby S.A.N - Nginx Mailing List - Russian
> Я собираюсь иногда чистить его самостоятельно, никаких проблем не > должно возникнуть? Скорей всего всё будет без проблем. Проблемы будут если вы начнете редактировать файлы кеша, особенно в новых версиях Nginx. Наby S.A.N - Nginx Mailing List - Russian
> Причина в бекенде, да. Но переписать весь софт "правильно" > - не хватит времени и сил. Например, вот та же MediaWiki. Кстати MediaWiki, использует переменую $_SERVER['HTTP_HOST'] без всякой проверки. Если вы используете MediaWiki, совby S.A.N - Nginx Mailing List - Russian
> В результате: минимальный overhead, максимальная производительность. В целом я с вами согласен. С удалением валидаторов, можно мирится, ради производительности. Так же можно настроить в конфиге все нужные location в которby S.A.N - Nginx Mailing List - Russian
> Это у вас тоже layering violation, только уже в другую сторону. Возможно, но в моей практике, нередко были моменты когда что-то описывается в конфиге Nginx, потом что-то меняется в логике бекенда, все уже забыли что там в конфигаby S.A.N - Nginx Mailing List - Russian
> Есть один способ: > http://www.lexa.ru/nginx-ru/msg30320.html > > И второй способ: просто не включать кеширование > на стороне nginx в тех location`ах, где оно не нужно. Есть и третий способ if ($upstream_status = 304) { set no_cache = 1; } fastcgi_no_cache $no_cacheby S.A.N - Nginx Mailing List - Russian
> Пакеты для CentOS 7 доступны. > > http://nginx.org/en/linux_packages.html#mainline Да, спасибо!by S.A.N - Nginx Mailing List - Russian