> Откуда такая арифметика?
Цифры условные - допустим многопоточный бекенд, имеет 10 потоков, каждый
поток может работать со скоростью 1к RPS.
Задача получить от одного бекенда 10к RPS
На НТТР1.1 нужно как минимум открыть 10 конектов, тогда бекенду очень просто
привязать каждый конект к своему отде
> А откуда в вашем случае приросту вообще взяться? Он у вас скорее даст
> не
> прирост, а наоборот медленнее станет.
>
> Само по себе мультиплексирование не заставляет сигналы быстрее по
> проводам
> передаваться, а вот накладных расходов добавляет.
Ну это смотря как считать, если в HTTP 1.1 оди
> Также как и h2 внутри датацентра не нужен. Это протокол заточенный
> под общение
> браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с
> относительно
> высокой задержкой и в условиях крайне ограниченного количества
> параллельных
> соединений.
>
> Не стоит забивать микроскопы гво
Меня интересует H2 в модуле ngx_http_proxy_module (исходящие запросы к
бекенду), вы написали про модуль ngx_http_v2_module (входящие запросы от
клиентов)
Возможно вы хотели сказать что должно работать так:
proxy_http_version h2c;
но это к сожалению не работает.
Posted at Nginx Forum:
https://for
Наш бекенд работает на HTTP/1.1 в режиме Keep-Alive, но в пикоквые нагрузки,
нам приходится держать много открытых конектов.
Демон асинхронный, но если один запрос выполняется дольше обычного конект
параллельно использовать для других запросов уже не выйдет он просто ждет,
хотелось бы попробовать
VovansystemS Wrote:
---
> >> fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match
> if_not_empty;
> >> fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since
> if_not_empty;
> >
> > У вас в конфиге написано: установить заголовки If-N
Судя по конфигу, у вас проблема с куками, если браузер присылает куки
сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша.
Убери из конфига
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE $http_if_modified_since if_not_em
Здравствуйте.
Мы все больше используем микросервисы, они имеют уникальные uri, выполняют
атомарные операции и отдают JSON ответы, их проксирует и кеширует Nginx.
В этих бекенд микросервисах, часто появляются задачи для решения которых
нужны ответы от других бекенд микросервисов, приходится внутри
Maxim Dounin Wrote:
---
> Hello!
>
> On Tue, Apr 19, 2016 at 03:24:37AM -0400, S.A.N wrote:
>
> > > По умолчанию range-запросы из кеша работают только в том случае,
> > > если в ответе бекенда был заголов
> По умолчанию range-запросы из кеша работают только в том случае,
> если в ответе бекенда был заголовок Accept-Ranges и должна быть
> явно указана длина ответа.
Супер, спасибо, отдали Accept-Ranges все работает.
Кстати есть ли смысл бекенду сжимать (gzip) свой ответ, если клиенты
запрашивают к
Здравствуйте.
Я хотел бы узнать, Nginx умеет отдавать клиентам из своего кеша, ответы
частями?
Корректный заголовок Range: bytes... клиент отправляет, но Nginx из кеша
отдает весь ответ статус - 200, вместо частичного ответа со статусом 206.
По сути нужен функционал обратный модулю Slice.
Наш us
> И более правильным, потому что независимо от чей-то любви к
> systemd.socket
> в данном случае он поставленную задачу НЕ решает. Всяко лучше
> устранить
> проблему полностью, чем уменьшить её вероятность на несколько
> процентов.
systemd.socket задачу решает, тесты показали что он заметно ран
Валентин Бартенев Wrote:
---
> Это довольно странное желание - чтобы машина, которая по сути ещё не
> готова
> к работе, частично делала вид, что она готова принимать трафик. Что
> вы будете
> делать если nginx так и не заработает через 700 мс, а
Evgeniy Berdnikov Wrote:
---
> On Tue, Mar 15, 2016 at 11:39:12AM -0400, S.A.N wrote:
> > Evgeniy Berdnikov Wrote:
> > ---
> > > On Tue, Mar 15, 2016 at 10:33
Evgeniy Berdnikov Wrote:
---
> On Tue, Mar 15, 2016 at 10:33:10AM -0400, S.A.N wrote:
> > Наш use case простой, нужно чтобы на ранней стадии загрузки OS,
> нужные порты
> > могли принимать конекты, systemd.socket идеальн
Maxim Dounin Wrote:
---
> Hello!
>
> On Tue, Mar 15, 2016 at 01:32:04AM -0400, S.A.N wrote:
>
> > Есть в планах на ближайшие будущие, реализация принятия сокета от
> unit
> > systemd.socket?
>
> Скорее нет,
Здравствуйте.
Есть в планах на ближайшие будущие, реализация принятия сокета от unit
systemd.socket?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,265330,265330#msg-265330
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.
Maxim Dounin Wrote:
---
> С nginx'ом - нет.
Ok, спасибо.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,265230,265251#msg-265251
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailma
В HTTP спецификации, имена заголовков должны быть регистро независимы.
Нам на бекенде удобней отдавать все в нижнем регистре, проблем с Nginx или
другими прокси не будет?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,265230,265230#msg-265230
_
> > Как понимать "не атомарны"? Может отдаться часть слайса?
>
> Модуль slice разбивает запрос к бекенду на много range-запросов, а
> при отдаче клиенту полученные ответы склеиваются. Соответственно
> если в процессе файл на бекенде поменяют - часть ответов будет от
> одного файла, часть - от
> А от его необработки - теряется корректность возвращаемых ответов,
> и, e.g., клиенту, который не понимает gzip, может быть возвращён
> сжатый ответ из кеша. Т.е., фактически, клиент не получит ответ.
> И, более того, администратор сможет узнать об этом только в том
> случае, если пользоват
> Поддерживаю Антона: поведение совершенно неожиданное, и к тому же
> никак не описанное в документации. Прежде всего нужно эту засаду
> задокументировать, чтобы прилежные читатели не налетали на грабли.
Это не засада, это описано в спеке HTTP/1.1 :)
Если разработчики бекенда не знают специфика
> Но проблема несколько шире. Уже много фреймфорков написанных чисто на
> http 2.0 (gRPC - и это только начало), которые не содержат большого
> количества ненужного кода для поддержки http 1.1 просто потому что он
> не нужен и смысла в нем минимум.
Я думаю, это вопрос денег, если проспонсируете ра
Да, такая проблема была, помогло выключения sendfile:
sendfile off;
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,261118,261120#msg-261120
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
> Теперь законный вопрос, что же не так я делаю с ним:
> zend_extension="/usr/local/lib/php/20100525/eaccelerator.so"
Если есть возможность, обновите версию РНР до 5.6, там из коробки отличный
OPCache, eAccelerator ненужен.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,260893,260933#
Если бекенд, выдаст заголовок:
Link: ; rel=preload; as=script
Nginx, отдаст браузеру содержимое файла my.js или только заголовок от
бекенда?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,260805,260836#msg-260836
___
nginx-ru mailing list
n
После очередной настройки проксирования websocket сервера, меня все больше
удивляет, почему в Nginx нет модуля websocket, c директивами websocket_*?
Модуль нужен не только для красоты конфига, он может хранить под капотом
оптимальные дефолт настройки и кучу проверок на отсеивания заведомо
инвалидн
> Есть стандартное решение, которое работает с любым кэшем: nginx-а,
> memcached-а и т.д.
>
> В значение ключа кэширования добавьте счётчик. Отдельный для каждого
> куска кэша, который хотите вычищать. Когда надо будет вычистить кэш,
> увеличьте на 1 значение нужного счётчика в тексте к
Amanda Sproule Wrote:
---
> >>И возьмём упомянутые 400 location.
>
> поправлю - не локейшенов а server контекстов.
Да, для такого хозяйства нужен менеджер конфигов.
Советую ещё вспомнить что Nginx это реверс прокси, он может общаться с
бекендом
> А я думал, что конфиг _декларативный_, а из _императивного_ там
> только
> if-is-evil. Кто из нас ошибается(?), мне интересно... O_o
Если бы конфиг Nginx, был декларативным, вместо директив были бы декларации
:), наличия директив делает его императивным.
Вы наверно воспринимаете конфиг как скрип
> Согласен, приведите аргументы к выше указанному вопросу и на этом
> закончим
> разговор.
Лучший аргументом может быть два примера решения вашей задачи, один с
использованием наследования директив, второй вариант -копипаст который
предлагают разработчики Nginx.
Ваш вариант с наследованием мне и
> Начать тут нужно с того, что php не thread safe и может безопасно
> исполняться
> только в отдельных процессах. Пулы потоков ему ни чем не помогут.
В РНР есть модификация - ZTS (Zend Thread Safety), но там тоже конечно не
все так хорошо.
> Проще забыть про php, как про страшный сон. ;)
Мы не
Почитал статью про thread pools в Nginx, появилась надежда что когда-то
появится Nginx модуль РНР, который будет обрабатывать запросы к РНР скриптам
внутри процеса Nginx (без блокировки, каждый скрипт использует свободный
thread из пула), тогда про отличия FastCGI и http_proxy можно будет забыть.
> как решить проблему добавления слеша в конец?
Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их можно
использовать на бекенде в алгоритмах роутинга.
Например в наших роутингах слеш в конце означает что uri адресуется к
множеству сущностней (аля папка), отсутствия слеша в конц
> Это разные запросы. Кроме php есть же и другие языки. Например в java
> и RoR
> массивы передаются в GET именно так как вы написали.
В java и RoR, чтобы передать масив id, нужно писать id=1&id=100?
Жаль конечно, в РНР масивы передаются в другом формате id[]=1&id[]=100
Posted at Nginx Forum:
ht
Есть нормализованная переменная $uri, но нет нормализованной $args, но она
реально нужна, попробую объяснить.
Наш ключ к кешу и REQUEST_URI к бекенду = $uri$is_args$args, нормализованный
$uri очень удобен, но не нормализованный $args создает проблемы - дубликаты
в кеше и флуд на бекенд.
Например
> Однако в целом мне такой подход кажется куда более правильным, чем
> неочевидные проверки параметра HTTPS (который тоже ни разу не
> стандартный), и наверное добавить в fastcgi_params по умолчанию
> стоит.
Ок, спасибо.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,259351,259359#
РНР скрипты которые работали под Apache, получали перемененную окружения
REQUEST_SCHEME, в fastcgi_params этот параметр не назначается, я прописал
fastcgi_param REQUEST_SCHEME $scheme.
Вопрос, не нарушил ли я спецификацию FastCGI, если нет, тогда почему этот
параметр не указан в fastcgi_params из
> Поверх этого кода есть ещё прослойка в виде php_fpm. Возможно что он
> смотрит на метод.
Да, php_fpm не отдает тело ответа, если REQUEST_METHOD = HEAD.
Эти нюансы могут стать проблемой, для РНР скриптов которые работали под
Апачем, Nginx проксировал HTTP запросы к Апачу и кешировал, если эти Р
>fastcgi_param REQUEST_METHOD $request_method;
> Cтрого говоря в случае протокола FastCGI такого понятия, как запрос
> "HEAD методом" не существует
Спасибо, теперь все понятно.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,259148,259178#msg-259178
__
> В новых версиях ничего не менялось в этом отношении.
В Nginx/1.9.1, с включенным кэшированием, на бекенд отправляется запрос HEAD
методом.
Вот простой скрипт РНР.
curl -i -X HEAD http://host.dev/
HTTP/1.1 200 OK
Server: nginx/1.9.1
Date: Wed, 27 May 2015 11:36:15 GMT
Content-Type: text/html
При запросе методом HEAD, в кеше сохраняются только заголовки ответа.
При следующем запросе методом GET, Nginx отдает из кеша ответ в котором нет
тела, только заголовки.
Раньше Nginx при запросе методом HEAD, на бекенд отправлял запрос методом
GET, в кеш сохранял ответ бекенда, клиенту отдавал тол
>более штатных способов нет?
Возможно, $upstream_response_length, но я не проверял.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,259066,259090#msg-259090
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listin
> хм...интересная идея..у меня Касперский...попробую вечером его
> выключить...но как тогда объяснить что он не разжимает на лету css и
> js
Вы можете проверить на других сайтах, например http://habrahabr.ru/ если в
ответе не будет Content-Encoding: gzip, значит проблема на вашей стороне
(антивиру
> Хотя если выполнить wget с аналогичными броузерными заголовками, то
> все в порядке - приходит такой ответ
Возможно ваш антивирус или фаирвол, делает декомпресию на лету, тогда ваш
браузер будет приходить незжатые страницы.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,258883,25889
> Он отдает Transfer-Encoding: chunked когда размер ответа заранее
> неизвестен.
Я это понимаю, но думал что где-то на уровне буферизации ответа, Nginx может
узнать что тело пустое, то того как начал передавать клиенту заголовки
ответа.
Но на нет и суда нет.
Posted at Nginx Forum:
http://forum.
По умолчанию, Nginx отдает ответ Transfer-Encoding: chunked, даже когда
длина тела ответа равна нулю.
Это мелочь, но будет лучше, если в этой ситуации Nginx будет отдавать
Content-Length: 0.
Такой ответ короче и более удобный для HTTP клиентов.
Posted at Nginx Forum:
http://forum.nginx.org/read
mainline version будет 1.9, или будет только одна ветка stable а mainline
удалите?
Я спрашиваю, чтобы правильно отредактировать путь для repo в CentOS, сейчас
так:
http://nginx.org/packages/mainline/centos/7/$basearch/
Этот baseurl останется актуальным?
Posted at Nginx Forum:
http://forum.nginx.
> а вот лог backend, видно что при ревалидации отдает не только 304, но
> и полную сущность, а не только заголовок
Бекенд, не должен отдавать тело ответа со статусом 304, вам достаточно
отдать только заголовки и статус 304.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,257971,257978
> в чем тут проблема? как не загружать с бекенда полностью весь ответ
> (1048769 bytes), а только обновить данные что кеш валидный затратив на
> это всего 4096 bytes
Если if-Modified-Since/If-None-Match валидные, отдавайте 304 статус, без
тела ответа.
Posted at Nginx Forum:
http://forum.nginx.or
> Extension", http://tools.ietf.org/html/rfc5861#section-4. Т.е.
> возможность задать в заголовках ответа - можно ли этот ответ в
> дальнейшем использовать при ошибках
Chrome, реализовал директиву stale-while-revalidate, опция пока что
экспериментальная её нужно активировать:
chrome://flags/#enabl
> На фронте имеется n-ое количество nginx которые выступают в качестве
> балансировщиков.
> Нужно наладить единый кэш для всех фронтенд nginxов. Какие есть
> возможности
> в nginx для реализации этой задачи?
Если я правильно понял вашу задачу, проблем нет, просто укажите всем Nginx
одинаковый prox
> Изменения в nginx 1.7.8,
> 02.12.2014:
>
> *) Изменение: теперь строки "If-Modified-Since", "If-Range" и им
>подобные в заголовке запроса клиента передаются бэкенду при
>включённом кэшировании, если nginx заранее знает, что не будет
>кэшировать ответ (например, при ис
Здравствуйте.
Если счетчик cache_min_uses, будет срабатывать только на ответы бекенда в
которых нет запрета на публичное кеширования, тогда ответ с заголовков
Cache-Control: private, не должен изменить счетчик cache_min_uses, Nginx
должен передать бекенду, все условные заголовки клиента.
Тогда бе
Валентин Бартенев Wrote:
---
> Конечно, у задачи сжатия перед кэшированиям тоже есть свои юзкейсы, но
> её реализация не так проста, как может показаться. Скорее всего для
> этого
> придется переписать весь механизм кэширования или добавлять еще
Валентин Бартенев Wrote:
---
> nginx - это такой веб-сервер, с помощью которого можно измерить
> производительность ab, но не наоборот.
:)
Вот по этому, компрессию лучше производить в Nginx, в кеше сохранять сжатый
ответ.
Posted at Nginx Forum:
Gena Makhomed Wrote:
---
> Каким образом скорость соединения с клиентом
> влияет на время *блокировки* воркера nginx ?
>
> nginx работает с сетью в неблокирующем режиме.
Да, вы правы, медленный клиент не блокирует воркер, но компрессия ответа в
Gena Makhomed Wrote:
---
> Совершенно не понятно, почему лучше будеть сжимать ответы бекенда
> на стороне nginx, а не на самом бекенде, особенно если учесть, что:
>
> 1) любая "долгоиграющая" операция (например, компрессия ответа
> бекенда)
> над
При кешировании ответов бекенда, нужно научить Nginx предварительно сжимать
ответ бекенда, если данный ответ соответствует указанному gzip_types.
Раньше это было сложно по многим причинам, не было модуля gunzip и не было
weak ETag, но сейчас есть все необходимое чтобы использовать gzip до
сохранен
Михаил Монашёв Wrote:
---
> Здравствуйте, Maxim.
>
> > *) Изменение: теперь строки "If-Modified-Since", "If-Range" и им
> >подобные в заголовке запроса клиента передаются бэкенду при
> >включённом кэшировании, если nginx заран
> Изменения в nginx 1.7.7
> 28.10.2014
>
> *) Изменение: теперь nginx учитывает при кэшировании строку "Vary"
> в
>заголовке ответа бэкенда.
Где можно почитать подробности влияния Vary, на кеширования в Nginx?
Posted at Nginx Forum:
http://f
Евгений Удовихин Wrote:
---
> В общем разобрался, просто в header функция time в принципе
> некорректно
> себя ведет, если вывести time()+1 в отдельную переменную и
> подставлять, то
> тогда все работает. Спасибо всем.
Сори, я не ставил скобки в
Вы указываете временную дельту равной 1 секунде, относительно от последнего
запроса к РНР бекенду.
Возможно вам больше подойдет вариант указывать абсолютный unix time.
Как-то так
header('X-Accel-Expires: @'.time() + 1);
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,253754,253756#msg-
> В nginx 1.7.3+ при включении ssi_last_modified не удаляются weak
> entity tags (а strong преобразуются в weak), что позволяет
> ревалидировать SSI-ответы по ETag в том числе.
Ok, спасибо
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,253455,253464#msg-253464
_
В документации не нашел, описания как включить ревалидацию по ETag, для
модуля SSI, аналог SSIETag в Apache .
В Nginx, ssi_etag уже есть, или пока что в разработке?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,253455,253455#msg-253455
___
> Надо только - чтобы Epoch у пакетов из репозиториев nginx.org был выше
> чем у пакета nginx из репозитория EPEL и других сторонних
> репозиториев.
>
> Потому что EPEL содержит много полезных пакетов и его очень часто
> подключают к CentOS - в том числе и вместе с репозиторием от nginx.org
Согла
> > Да, думаю будет правильным если Nginx из ветке mainline, будет иметь
> Epoch
> > выше чем у ветки stable.
>
> Нет. Epoch не надо применять там, где достаточно будет версии пакета.
> Если значение Epoch одинаково - rpm тогда смотрит на версию пакета.
> Делать разный Epoch для nginx mainline и n
> 2. с помощью плагина yum-plugin-priorities настроить приоритеты
> репозиториев таким образом, чтобы у EPEL был более низкий приоритет.
> это в любом случае полезно настроить для всех используемых
> репозиториев
Спасибо, так и сделали.
> 3. попросить мантейреров пакета из nginx.org чтобы они
> Пакеты для 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 - постоянно пытается обновить ус
> Всегда их включать? Они так постоянно будут уходить к клиенту.
> Или только, когда нужно, добавлять в конфиг.
Включать всегда их не нужно.
Включать нужно только на стадии разработки, для удобства дебага.
Так удобней и не придется заглядывать в логи Nginx и в логи приложения,
чтобы определить от
> Эти заголовки будут содержаться в закэшированном ответе, но как они
> могут мне помочь?
Нет, эти заголовки не попадают в файл кеша Nginx.
Заголовки пойдут в браузер, вы сможете их посмотреть в браузере и точно
знать, состояния файла кеша.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?
> Всеравно nginx отдаст 304 ответ из своего кеша еще быстрее,
> чем веб-приложение на которое он проксирует запросы клиентов.
Да, конечно.
Но вы не сможете постоянно хранить ответы в кеше, их придется когда-то
ревалидировать.
Я долгое время не понимал, необходимости в ревалидации, считал это лишн
> Я собираюсь иногда чистить его самостоятельно, никаких проблем не
> должно возникнуть?
Скорей всего всё будет без проблем.
Проблемы будут если вы начнете редактировать файлы кеша, особенно в новых
версиях Nginx.
Например если в кеше отредактировать значения ETag, сделать запрос, Nginx
уходит в а
> Причина в бекенде, да. Но переписать весь софт "правильно"
> - не хватит времени и сил. Например, вот та же MediaWiki.
Кстати MediaWiki, использует переменую $_SERVER['HTTP_HOST'] без всякой
проверки.
Если вы используете MediaWiki, советую поискать в коде $_SERVER['HTTP_HOST']
и изучить степень
> В результате: минимальный overhead, максимальная производительность.
В целом я с вами согласен.
С удалением валидаторов, можно мирится, ради производительности.
Так же можно настроить в конфиге все нужные location в которых нужно
выключать кеширования, я тоже знаю как это делать.
Просто мне инт
> Это у вас тоже layering violation, только уже в другую сторону.
Возможно, но в моей практике, нередко были моменты когда что-то описывается
в конфиге Nginx, потом что-то меняется в логике бекенда, все уже забыли что
там в конфигах Nginx, и получаем диссонанс логики бекенда и Nginx.
Если вы посм
> Есть один способ:
> http://www.lexa.ru/nginx-ru/msg30320.html
>
> И второй способ: просто не включать кеширование
> на стороне nginx в тех location`ах, где оно не нужно.
Есть и третий способ
if ($upstream_status = 304) {
set no_cache = 1;
}
fastcgi_no_cache $no_cache;
Ещё как вариант, Nginx
> Пакеты для CentOS 7 доступны.
>
> http://nginx.org/en/linux_packages.html#mainline
Да, спасибо!
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251548,251862#msg-251862
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org
Наверно стоит объяснить почему логику кеширования мы вынесли на бекенд и
минимально используем конфиг Nginx.
Нашим бекендом, пользуются не только браузеры но и мобил приложения, у них
логика кеширования очень продвинутая, там учитывается временное пропадания
online, в этом случаи клиентское прилож
> Если я правильно понял этот поток текста, то на выходе вы хотите
> получить что-то вроде "The stale-if-error Cache-Control
> Extension", http://tools.ietf.org/html/rfc5861#section-4. Т.е.
> возможность задать в заголовках ответа - можно ли этот ответ в
> дальнейшем использовать при ошибках.
> >Но все эти детали лучше не говорить тем кто только начинает изучать
> механизмы кеширования в Nginx )
> Почему?
Чтобы не пугать, раньше времени )
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251763,251837#msg-251837
___
nginx-ru mailin
> "логика кеширования в Nginx такая же как в браузерах", - есть и
> отличия:
>
> http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cac
> he_bypass
>
> если выполняется условие fastcgi_cache_bypass и не выполняется
> условие fastcgi_no_cache - то это и будет out-of-order обновлени
> >С этого и надо было начинать, они нужны обязательно если вы хотите
> клиенту отдавать 304 без контента.
> А можно ли создавать ETag и Last-Modified на стороне nginx и для
> статики и для динамики?
>
> есть директива etag on; но написано что она только для статики
> автоматом вычисляет его.
>
> >Я имел виду, ревалидация В приложении это - RESTful стиль.
>
> Не знал, насколько я знаю, обычно REST преподносят, как набор
> методов(действий), которые можно выполнить с объектом и путь к этому
> объекту.
Да, но не только, основная идея в том, что клиент и сервер могут полностью
описать своё
Budulianin Wrote:
---
> >Это понятно, ревалидировать кеш на в приложении - это стиль RestFull
> приложений,
> НЕ в приложении?
Я имел виду, ревалидация В приложении это - RESTful стиль.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,
> >те кто обновляет страницу в ручную будут получать 304 статус без
> контента,
> Только если в запросе, который должен закэшироваться, был
> заголовок-валидатор(ETag, Last-Modified) иначе нечего будет
> сравнивать.
> У меня сейчас нет их и nginx отдаёт 200.
С этого и надо было начинать, они нужн
> Значит моя схема вполне жизнеспособна и не выглядит нормально? Кладём
> основную нагрузку на nginx и немного на браузер.
Я думаю да, но лучше проконсультироватся у разработчиков Nginx, как
реагирует Nginx если кеш файлы исчезают, без его ведома, я думаю он
нормально реагирует, но мало ли какие т
> Я нажимал не F5, а кнопку браузера, что видимо эквивалентно. Но я
> тогда не понимаю, когда вообще юзеру поможет браузерный кэш?
> Когда он будет по ссылкам ходить, только тогда из кэша браузера будет
> доставаться?
Да, обычные посетители сайта, обычно переходят на страницы по ссылкам, те
кто об
> >Эта схема защитит ваше приложения от нагрузки, но она никак не сможет
> актуализировать кеш быстрей чем это указанно в max-age.
> Я же сказал, что мы можем чистить кэш nginx когда нам это нужно.
Если у вас есть сторонний процесс который чистит кеш, тогда конечно можно
использовать эту схему.
Budulianin Wrote:
---
> >Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к
> серверу вообще, потому что вы ему сказали, что кеш можно использовать
> без ревалидации на протяжении 600 секунд.
>
> А у меня запросы идут к nginx, те бра
Budulianin Wrote:
---
> >В этом случаи приложения должно уметь очень быстро проверять
> If-Modified-Since с текущим Last-Modified, если они равны отдавать
> 304, если нет отдавать новый контент и статус 200.
>
> Под это нужно специально готовить
Budulianin Wrote:
---
> Большое спасибо за ответ, теперь понял.
>
> А если браузер присылает в запросе Cache-Control: no-cache(или
> max-age=0), что часто бывает, а я хочу отдавать кэш, мне как-то
> игнорировать этот заголовок или если из приложе
Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к серверу
вообще, потому что вы ему сказали, что кеш можно использовать без
ревалидации на протяжении 600 секунд.
После истечения 600 секунд, браузер сделает запрос к серверу, передаст ему
If-Modified-Since, Nginx сравнит значения If-Mod
Budulianin Wrote:
---
> >Зачем вы выбрали такое значения Cache-Control: max-age=600 no-cache?
>
> Этой строчкой я хотел сказать браузеру: держи у себя кэш 600 секунд,
> но при каждом запросе отправляй заголовки(видимо If-modified-since)
> Потому
Лучше управлять кешированием из приложения, это более правильное решения и
более гибкое, таким образом приложения самостоятельно решает какой контент
на какой период кешировать и эти же заголовки отправятся в браузер и тогда
не надо будут костыли в виде ignore_headers и hide_header, потому что
прил
Да, директивы uwsgi_cache_valid для этого и придумали, чтобы управлять
кешированием, если бекенд приложения не может самостоятельно отправить
правильные заголовки.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251763,251788#msg-251788
___
n
Если так
uwsgi_ignore_headers X-Accel-Expires Expires Cache-Control Set-Cookie;
uwsgi_hide_header Set-Cookie;
uwsgi_cache_valid 200 10m;
Тогда не важно какие заголовки отправил проксируемый сервер (бекенд), ответ
будет закеширован на 10 минут, этим занимается директива
http://nginx.org/ru/docs/h
>Я хочу принять ответ от uwsgi,
> добавить в него пару заголовков и отдать клиенту.
> Фактически добавить заголовки в ответ nginx.
> Я таким образом хочу управлять кэшем.
Вы таким образом сможете управлять только кешем браузера, если хотите
управлять кешем Nginx, нужно чтобы ваше приложения отдава
Nginx 1.7.3, отличная версия, в ней полностью решен вопрос с ETag.
Но есть мелочи которых очень не хватает, их всего две )
1. Нельзя получить от клиента валидаторы (“If-Modified-Since” и
“If-None-Match”) если файла кеша нет, эта ситуация возникает когда бекенд
отдавал заголовки Cache-Control: pri
Budulianin Wrote:
---
> >Pragma - это костыльный заголовок который вообще не стоит
> использовать для кеширования
> Он для HTTP 1.0
Костыльность Pragma, заключается в том что это заголовок запроса а не
ответа, потом его начали использовать как за
Результаты 101 - 200 из 288 matches
Mail list logo
