Show all posts by user
Introduce yourselves
> а вот лог 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" и им
> > подобные в заголовке запроса клиента передаются бэкенду при
> &g
by
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_cache
by
S.A.N
-
Nginx Mailing List - Russian