анализ кода nginx-1.11.1 статическим анализатором clang
Привет! сделал вот так ./configure scan-build make нашлось несколько потенциальных "Dereference of null pointer" отчет тут http://chipitsine.github.io/nginx-1.11.1-clang/ насколько они могут стать реальными, пока не смотрел. Илья Шипицин ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
reuseport и тормоза
Здравствуйте. Ситуация такая: по специфике моего проекта, у каждого сайта выделенный IP адрес. Если я указываю всем (135) сайтам reuseport - обновление конфигурации nginx service reload и nginx -t длится очень долго, если этой опции нету, вышеприведенные команды выполняются моментально. Вопрос: Для каждого из 135 IP явно указано reuseport. Может есть способ указать reuseport не для каждого ip, а для подсети или всего nginx в целом? Как при использовании reuseport вернуть быстрое обновление конфигурации на лету? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267388,267388#msg-267388 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?
> > 1 запрос выполняется за 100ms > > > > Если послать 30 последовательных запросов в 1 соединение мы получим > 30 > > ответов за 3000ms > > Если послать 30 запросов в 30 разных соединениях мы получим 30 > ответов за > > 100ms > > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 > ответов за > > 100ms > > > > В первом варианте, 1 сокет находится в режиме busy 3000ms > > В втором варианте, 30 сокетов находится в режиме busy 100ms > > В третьем варианте, 1 сокет находится в режиме busy ~0ms > > Интересная математика, т.е. в третьем варианте у вас 30 запросов > приложение отработало за 0ms, при том, что по вашему же условию 1 > запрос выполняется 100ms? Нет, в третьем варианте, 30 запросов отработают за 100ms, это же указанно чуть выше. Но сокет в третьем варианте, будет занят 0ms, это означает что на протяжении этих 100ms, вы можете продолжать отправлять новые запросы в этот же сокет, не дожидаясь ответов на предыдущие 30 запросов, т.е. сокет всегда готов принимать новые запросы. Это очень упрощает алгоритм отправки новых запросов, вы постоянно говорите про сложности которые создает мультиплексирования, но я вижу, что он дает только плюсы и упрощения алгоритмов. > Вы забываете, что у вас в третьем варианте будет 1 TCP сокет и 30 > виртуальных > сокетов внутри этого самого мультиплексированного соединения. 30 виртуальных сокетов - это 30 объектов Request/Respons в которых есть свой id и указатель на свой сокет. Сейчас без мультиплексирования эти 30 объектов тоже создаются, но без id. Так что ничего особо сложного в коде бекенд приложений делать не придется. Возможно для низкоуровневых бекенд приложений это большие сложности, но для приложений на Go, Python, Node.js, PHP демоны, это не добавит особых сложностей. > Протоколу FastCGI, который умеет мультиплекирование, уже много-много > лет. > Как вы думаете, почему за все это время никто это самое > мультиплексирование > в нем не использует? Ответ прост - потому что это сложно и > неэффективно. Нет, ответ ещё проще, 80% сайтов работает на РНР, который "умирает" после выполнения запроса и в процессе работы весь его I/O с блокировкой. Использовать мультиплексирования в PHP-FPM это так же бессмысленно как использовать антикрыло в грузовиках, по этому его там никто не использует, но это совсем не значит что мультиплексирование не эффективная технология, люди которые создавали FastCGI просто опережали свое время. Я понимаю что мой юзкейс (запросы между бекендами через Nginx) редкость для других пользователей Nginx, но только там я увидел как быстро улетает 1024 fd на простых задачах без особых нагрузок. Жить конечно можно, мы увеличили лимиты fd, создали пулы keep-alive, но есть ощущения что нет смысла тратить столько fd. Реализовать мультиплексирование на бекенде не сложно, но жаль нельзя проверить на тестах, чтобы убедится так ли это или нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267387#msg-267387 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?
On Friday 03 June 2016 19:26:38 S.A.N wrote: > > Можете расшифровать выражение "сокет не простаивал в пустую"? Чем > > грозит > > сокет, который простаивает впустую? Что по вашему такой сокет > > потребляет: > > ресурсы процессора, электричество, солярку, деньги? > > Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память > приложения, мы используем libev. > Один сокет требует, создания одного WatcherObject и одного HandlerMethod, > это не много, но они 70% времени ничего не делают, потому что время > выполнения запроса в десятки раз превышает время передачи данных по > локальному сокету. Т.е. вся проблем состоит в том, что вы это так неэффективно запрограммировали ваше приложение, а мультиплексирование служит лишь поводом изменить его логику работы на более эффективную? Почему бы просто не изменить её? > > Это не важно когда запросов не много, но когда частота запросов высокая, > открывать новые соединения, на каждый запрос это расточительно и глупо. > Расточительно конкретно в вашем приложении? > Зачем открывать новое соединения, если в бекенд приложении уже и так есть > 100 busy сокетов, которые ничего не делают, потому что ждут ответа на > предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне > HTTP/1.х, хотя сокет non-blocking mode. Ничего не делать и ждать ответа - это несколько разные вещи, не нужно их приравнивать. > > Мультиплексирование убирает понятие socket busy, бекенд приложению будет > достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше > WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю > его снова: Почему бы не решить проблему с "WatcherObject и HandlerMethod", а не пытаться выдавать проблему конкретного неудачного подхода за проблему протокола? В использовании нескольких сокетов, по одному на запрос, нет ровным счетом ничего плохого. Вы пытаетесь доказать, что сокеты плохи, описывая, как работает ваше приложение. Но может быть дело не в сокетах, а в том, что ваше приложение использует ресурсы неэффективно? Любое мультиплексирование нескольких соединений внутри другого соединения является усложнением, а усложнение приводит к трате большего числа ресурсов. От того, что вы замените TCP сокеты на виртуальные сокеты внутри одного мультиплексированного соединения, вы просто замените одни идентификаторы на другие. И у вас точно также будут "простаивать" те самые виртуальные идентификаторы и все ресурсы, что с ними связаны, и расходовать память. Каким образом замена одних id на другие id что-то меняет? > > 1 запрос выполняется за 100ms > > Если послать 30 последовательных запросов в 1 соединение мы получим 30 > ответов за 3000ms > Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за > 100ms > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за > 100ms > > В первом варианте, 1 сокет находится в режиме busy 3000ms > В втором варианте, 30 сокетов находится в режиме busy 100ms > В третьем варианте, 1 сокет находится в режиме busy ~0ms Интересная математика, т.е. в третьем варианте у вас 30 запросов приложение отработало за 0ms, при том, что по вашему же условию 1 запрос выполняется 100ms? > Вопрос какой из трех вариантов более эффективно использует ресурсы? Вариант номер 1 и 2. Поскольку третий вариант требует более сложного протокола и логики работы, что требует большего числа ресурсов. Вы забываете, что у вас в третьем варианте будет 1 TCP сокет и 30 виртуальных сокетов внутри этого самого мультиплексированного соединения. Протоколу FastCGI, который умеет мультиплекирование, уже много-много лет. Как вы думаете, почему за все это время никто это самое мультиплексирование в нем не использует? Ответ прост - потому что это сложно и неэффективно. С HTTP/2 в upstream та же история, это сложно и неэффективно. > > Мультиплексирование - нужно всем бекенд приложениям, у которых есть > временное окно между запросом и ответом, чем больше это временное окно, тем > больше позитив эффекта от мультиплексирование. > > Сокеты - это как нефть, её много, но ресурс ограничен > Мультиплексирование - это как сланцевая нефть, она дает возможность > использовать ту нефть, которая ранее считались не пригодная к использованию. > Сокеты - это котятки, каждый раз когда рождается новый, ну вы понимаете... -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
On Sat, Jun 04, 2016 at 01:54:41PM -0400, Steven3009 wrote: > Вопрос как раз в том, что при загрузке страницы/повторной загрузки страницы > - измененные статические элементы не обновляются. Обновление происходит > только по F5/обновить. > > Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если у > меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не > почистит кэш, не получит обновлений, пока не закончится срок действия кэша? > 2016 год... Вы какой алгоритм обновления кэша держите у себя в голове? Изложите его. Хотя бы для себя, чтобы понимать о чём спрашиваете. Слова "Ф5" и "обновить" ничего не говорят о том, какой запрос (с какими заголовками и какими значениями) посылает браузер и что отвечает сервер. Поэтому это всё рассуждения о чёрном ящике. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?
> Хэндлер должен быть один для всех однотипных операций Да, это детали конкретной реализации, там нужно контекст передать, по этому создается новый интсанст хендлера. Если перечислять все кроме WatcherObject и HandlerMethod, тогда нужно начинать с того что accept socket создает новый fd в процессе, а дальше ещё много аллокаций с сокетом найдется в коде бекенд приложения :) > ... зато придется выполнять работу, которую более эфеективно делает > ядро (разбирать, какому логическому соединению принадлжеат пакеты) Никакой особой работы выполнять не придется, просто в ответе (Response) нужно будет передавать id запроса (Request), это все делается на уровне фрейморка бекенд приложения. Уверен request->id будет меньше потреблять памяти, чем отдельное соединения, которое требует, +1 fd в процессе, +1 WatcherObject, -1 fd лимита OS... > Тогда уж лучше на UDP переходить :) Я только за! Что вы думаете про ещё один експерементал протокол гугла - QUICK? Он на udp, и возможно он лучше подходит для общения Nginx с бекендами... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267382#msg-267382 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
04.06.2016, 20:55, "Steven3009" : > Илья Шипицин Wrote: > Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если у > меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не > почистит кэш, не получит обновлений, пока не закончится срок действия кэша? Именно так, в этом и заключается смысл срока действия кэша. Для часто изменямых ресурсов или ресурсов, для которых важна оперативность изменений, он должен быть маленьким или вообще нулевым. -- Regards, Konstantin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
посмотрите в сторону asset management, это способ объединения нескольких однотипных статических ресурсов в общий файл с уникальным именем, который можно кешировать вечно, примеры подобных инструментов https://webpack.github.io/ https://github.com/jetheredge/SquishIt (список можно продолжать и продолжать) 4 июня 2016 г., 22:54 пользователь Steven3009 написал: > Илья Шипицин Wrote: > --- > > ETag и Last-Modified - для так называемого "ленивого" кеширования. > > > > это ситуация, когда вы не знаете, насколько долго можно кешировать > > ваши > > ответы, и не сообщаете браузеру Cache-Control: max-age=NNN > > > > в этом случае браузер кеширует ответ, и при повторном запросе браузер > > валидирует при помощи If-Modified-Since/If-None-Match, можно ли > > использовать то, что он закешировал > > > > количество запросов не уменьшается, уменьшается трафик ответа сервера > > (за > > счет того, что у 304 нет тела) > > > > но браузеру все равно придется делать запросы, он не сможет начать > > рендерить страницу, пока не убедится, что закешированные стили можно > > использовать > > > > при более грамотной настройке кеша вы выставляете заголовки ответа > > Cache-Control: max-age=NNN и браузер не будет валидировать, можно ли > > использовать то, что в кеше, а будет рендерить страницу сразу же > > Гугл рекомендует использовать ETag или Last-Modified как раз для > определения, можно ил использовать кэш или нет > "Эти заголовки позволяют браузеру эффективно обновлять кешированные > ресурсы, > отправляя запросы GET каждый раз, когда пользователь явным образом > перезагружает страницу. Условные запросы GET не возвращают полный ответ, > если ресурс не изменился на сервере, и таким образом обеспечивают меньшую > задержку, чем полные запросы. " > > Вопрос как раз в том, что при загрузке страницы/повторной загрузки страницы > - измененные статические элементы не обновляются. Обновление происходит > только по F5/обновить. > > Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если > у > меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не > почистит кэш, не получит обновлений, пока не закончится срок действия кэша? > 2016 год... > > > > > 2016-06-04 22:01 GMT+05:00 Steven3009 : > > > > > Я так не думаю. Зачем тогда Etag и Last-Modified? > > > Думаю, я что-то упускаю. > > > > > > Posted at Nginx Forum: > > > https://forum.nginx.org/read.php?21,267368,267376#msg-267376 > > > > > > ___ > > > nginx-ru mailing list > > > nginx-ru@nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267368,267378#msg-267378 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
Илья Шипицин Wrote: --- > ETag и Last-Modified - для так называемого "ленивого" кеширования. > > это ситуация, когда вы не знаете, насколько долго можно кешировать > ваши > ответы, и не сообщаете браузеру Cache-Control: max-age=NNN > > в этом случае браузер кеширует ответ, и при повторном запросе браузер > валидирует при помощи If-Modified-Since/If-None-Match, можно ли > использовать то, что он закешировал > > количество запросов не уменьшается, уменьшается трафик ответа сервера > (за > счет того, что у 304 нет тела) > > но браузеру все равно придется делать запросы, он не сможет начать > рендерить страницу, пока не убедится, что закешированные стили можно > использовать > > при более грамотной настройке кеша вы выставляете заголовки ответа > Cache-Control: max-age=NNN и браузер не будет валидировать, можно ли > использовать то, что в кеше, а будет рендерить страницу сразу же Гугл рекомендует использовать ETag или Last-Modified как раз для определения, можно ил использовать кэш или нет "Эти заголовки позволяют браузеру эффективно обновлять кешированные ресурсы, отправляя запросы GET каждый раз, когда пользователь явным образом перезагружает страницу. Условные запросы GET не возвращают полный ответ, если ресурс не изменился на сервере, и таким образом обеспечивают меньшую задержку, чем полные запросы. " Вопрос как раз в том, что при загрузке страницы/повторной загрузки страницы - измененные статические элементы не обновляются. Обновление происходит только по F5/обновить. Вы хотите сказать, что я ничего не упускаю и так и должно работать? И если у меня изменится стиль или картинка, то пользователь если не нажмет Ф5 или не почистит кэш, не получит обновлений, пока не закончится срок действия кэша? 2016 год... > 2016-06-04 22:01 GMT+05:00 Steven3009 : > > > Я так не думаю. Зачем тогда Etag и Last-Modified? > > Думаю, я что-то упускаю. > > > > Posted at Nginx Forum: > > https://forum.nginx.org/read.php?21,267368,267376#msg-267376 > > > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267378#msg-267378 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
ETag и Last-Modified - для так называемого "ленивого" кеширования. это ситуация, когда вы не знаете, насколько долго можно кешировать ваши ответы, и не сообщаете браузеру Cache-Control: max-age=NNN в этом случае браузер кеширует ответ, и при повторном запросе браузер валидирует при помощи If-Modified-Since/If-None-Match, можно ли использовать то, что он закешировал количество запросов не уменьшается, уменьшается трафик ответа сервера (за счет того, что у 304 нет тела) но браузеру все равно придется делать запросы, он не сможет начать рендерить страницу, пока не убедится, что закешированные стили можно использовать при более грамотной настройке кеша вы выставляете заголовки ответа Cache-Control: max-age=NNN и браузер не будет валидировать, можно ли использовать то, что в кеше, а будет рендерить страницу сразу же 2016-06-04 22:01 GMT+05:00 Steven3009 : > Я так не думаю. Зачем тогда Etag и Last-Modified? > Думаю, я что-то упускаю. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267368,267376#msg-267376 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
Я так не думаю. Зачем тогда Etag и Last-Modified? Думаю, я что-то упускаю. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267376#msg-267376 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
On Sat, 4 Jun 2016, Steven3009 wrote: Добрый день, Steven! Но проблема с тем, что статика не обновляется в браузере при загрузке страниц - остается. Пример: я изменил СSS, залил на сервер. Естественно, у файла другой Last_modified и Etag, но сколько я бы не перемещался по сайте, браузер не хочет обновлять стиль. Чудес не бывает. Выкладывайте новый стиль под новым именем, и обновляйте ссылки на него - и настанет вам счастье. -- Best regards, Andrey Kopeyko ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?
04.06.2016, 17:30, "S.A.N" : >> Можете расшифровать выражение "сокет не простаивал в пустую"? Чем >> грозит >> сокет, который простаивает впустую? Что по вашему такой сокет >> потребляет: >> ресурсы процессора, электричество, солярку, деньги? > > Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память > приложения, мы используем libev. > Один сокет требует, создания одного WatcherObject и одного HandlerMethod, Хэндлер должен быть один для всех однотипных операций > это не много, но они 70% времени ничего не делают, потому что время > выполнения запроса в десятки раз превышает время передачи данных по > локальному сокету. > > Это не важно когда запросов не много, но когда частота запросов высокая, > открывать новые соединения, на каждый запрос это расточительно и глупо. > > Зачем открывать новое соединения, если в бекенд приложении уже и так есть > 100 busy сокетов, которые ничего не делают, потому что ждут ответа на > предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне > HTTP/1.х, хотя сокет non-blocking mode. > > Мультиплексирование убирает понятие socket busy, бекенд приложению будет > достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше > WatcherObject и HandlerMethod) ... зато придется выполнять работу, которую более эфеективно делает ядро (разбирать, какому логическому соединению принадлжеат пакеты) Тогда уж лучше на UDP переходить :) >, я уже приводил пример в другой теме, повторю > его снова: > > 1 запрос выполняется за 100ms > > Если послать 30 последовательных запросов в 1 соединение мы получим 30 > ответов за 3000ms > Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за > 100ms > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за > 100ms > > В первом варианте, 1 сокет находится в режиме busy 3000ms > В втором варианте, 30 сокетов находится в режиме busy 100ms > В третьем варианте, 1 сокет находится в режиме busy ~0ms > > Вопрос какой из трех вариантов более эффективно использует ресурсы? > > Мультиплексирование - нужно всем бекенд приложениям, у которых есть > временное окно между запросом и ответом, чем больше это временное окно, тем > больше позитив эффекта от мультиплексирование. > > Сокеты - это как нефть, её много, но ресурс ограничен > Мультиплексирование - это как сланцевая нефть, она дает возможность > использовать ту нефть, которая ранее считались не пригодная к использованию. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267298,267369#msg-267369 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Валидация кэша на Nginx
Одну часть проблемы я решил, насчет ответа 304. "expires 7d; if_modified_since before;" Но проблема с тем, что статика не обновляется в браузере при загрузке страниц - остается. Пример: я изменил СSS, залил на сервер. Естественно, у файла другой Last_modified и Etag, но сколько я бы не перемещался по сайте, браузер не хочет обновлять стиль. Стиль или другая статика обновляется лишь по нажатию F5. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267368,267373#msg-267373 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx + X-Accel-Redirect
Спасибо, такой вариант сработал.
Максим, хотел бы в догонку задать вопрос не совсем связанный с предыдущим
вопросом, но связанный с X-Accel-Redirect. На каком-то из форумов (возможно
что здесь же, не помню точно) вы кому-то ответили, что только при
переадресации на named location, запрос сохраняется неизменным (POST запрос
остается POST запросом вместе с телом). А вот при переадресации на обычную
location POST запросы становятся GET. С чем связано такое поведение? А
именно, хочу понять, не является ли штука с named location каким-то "хаком",
не очень желательным и который может исчезнуть в новых версиях.
Вообще, X-Accel-Redirect придумана для раздачи статики. Я использую ее для
того чтобы разгрузить основной бекенд от запросов, в которых совершаются
длительные HTTP-запросы к внешним ресурсам (длительных - это примерно секунд
по 30). Поэтому возникла такая задача. Не является ли вообще такой подход
bad design, или все-таки неверный инструмент для решения такой задачи?
Maxim Dounin Wrote:
---
> Hello!
>
> On Fri, Jun 03, 2016 at 03:51:00AM -0400, materkov wrote:
>
> > Здравствуйте!
> >
> > Пытаюсь настроить X-Accel-Redirect.
> > Вот такой конфиг:
> >
> > location /api {
> > proxy_pass http://127.0.0.1:8000;
> > }
> >
> > location @tornado {
> > internal;
>
> Just a side note: директива "internal" в именованных location'ах
> не нужна, иначе как в результате перенаправления в такой location
> в любом случае не попасть.
>
> > proxy_set_header X-foo1 $upstream_http_myheader;
> > proxy_set_header X-foo2 $upstream_status;
> > proxy_pass http://127.0.0.1:;
> > }
> >
> > Вот такой код в первом апстриме (Django):
> >
> > def app_hyper_report(request):
> > r = api.Response()
> > r['myheader'] = 10
> > r['X-Accel-Redirect'] = '@tornado'
> > return r
> >
> > То есть здесь идет переадресация через X-Accel-Redirect на второй
> апстрим.
> > При этом, нужно передать во второй апстрим некоторые параметры.
> Пытаюсь это
> > сделать через headers. Столкнулся с проблемой: почему-то не работает
> > передача headers через $upstream_http_myheader (в то время как
> > $upstream_status срабатывает нормально).
> >
> > В чем здесь может быть проблема?
>
> Проблема в том, что в момент выполнения proxy_set_header уже
> началась работа новым upstream'ом, и значения переменных
> $upstream_http_* и $upstream_status - пустые.
>
> Решается сохранением нужных значений в промежуточные переменные с
> помощью set, как-то так:
>
> location @tornado {
> set $saved_myheader $upstream_http_myheader;
> set $saved_status $upstream_status;
> proxy_set_header X-foo1 $saved_myheader;
> proxy_set_header X-foo2 $saved_status;
> proxy_pass http://127.0.0.1:;
> }
>
> --
> Maxim Dounin
> http://nginx.org/
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,267345,267372#msg-267372
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Валидация кэша на Nginx
Всем привет,
Сделал кэширование ресурсов на Nginx.
Кэширование есть, а валидации, если к примеру поменялся стиль без нажатия на
F5 нет.
ЧАСТЬ КОНФИГА
server {
listen 80;
server_name 111.111.111.111 sitename.ru;
etag on;
if_modified_since exact;
location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico|pdf)$
{
root /storage/www;
expires 30d;
add_header Cache-Control 'public';
}
fastcgi_pass unix://var/run/php-fpm/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /storage/www$fastcgi_script_name;
fastcgi_pass_header Last-Modified;
include fastcgi_params;
fastcgi_read_timeout 240s;
fastcgi_send_timeout 240s;
fastcgi_intercept_errors on;
}
Проверка http://last-modified.com/ru/if-modified-since.html заголовка
показывает
Сайт css/stylesheet.css отдал время последней модификации, но не
отреагировал на If-Modified-Since
Посоветуйте, пожалуйста, что делать?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,267368,267368#msg-267368
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Есть ли смысл использовать что-то кроме http/1.1, при соединении с бэкэндом?
> Можете расшифровать выражение "сокет не простаивал в пустую"? Чем > грозит > сокет, который простаивает впустую? Что по вашему такой сокет > потребляет: > ресурсы процессора, электричество, солярку, деньги? Сокет который простаивает в пустую (ждет ответа на запрос) потребляет память приложения, мы используем libev. Один сокет требует, создания одного WatcherObject и одного HandlerMethod, это не много, но они 70% времени ничего не делают, потому что время выполнения запроса в десятки раз превышает время передачи данных по локальному сокету. Это не важно когда запросов не много, но когда частота запросов высокая, открывать новые соединения, на каждый запрос это расточительно и глупо. Зачем открывать новое соединения, если в бекенд приложении уже и так есть 100 busy сокетов, которые ничего не делают, потому что ждут ответа на предыдущий запрос, это по сути blocking mode сокета, но созданный на уровне HTTP/1.х, хотя сокет non-blocking mode. Мультиплексирование убирает понятие socket busy, бекенд приложению будет достаточно иметь в десятки раз меньше открытых сокетов (в десятки раз меньше WatcherObject и HandlerMethod), я уже приводил пример в другой теме, повторю его снова: 1 запрос выполняется за 100ms Если послать 30 последовательных запросов в 1 соединение мы получим 30 ответов за 3000ms Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за 100ms Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за 100ms В первом варианте, 1 сокет находится в режиме busy 3000ms В втором варианте, 30 сокетов находится в режиме busy 100ms В третьем варианте, 1 сокет находится в режиме busy ~0ms Вопрос какой из трех вариантов более эффективно использует ресурсы? Мультиплексирование - нужно всем бекенд приложениям, у которых есть временное окно между запросом и ответом, чем больше это временное окно, тем больше позитив эффекта от мультиплексирование. Сокеты - это как нефть, её много, но ресурс ограничен Мультиплексирование - это как сланцевая нефть, она дает возможность использовать ту нефть, которая ранее считались не пригодная к использованию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267298,267369#msg-267369 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx + X-Accel-Redirect
Hello!
On Fri, Jun 03, 2016 at 03:51:00AM -0400, materkov wrote:
> Здравствуйте!
>
> Пытаюсь настроить X-Accel-Redirect.
> Вот такой конфиг:
>
> location /api {
> proxy_pass http://127.0.0.1:8000;
> }
>
> location @tornado {
> internal;
Just a side note: директива "internal" в именованных location'ах
не нужна, иначе как в результате перенаправления в такой location
в любом случае не попасть.
> proxy_set_header X-foo1 $upstream_http_myheader;
> proxy_set_header X-foo2 $upstream_status;
> proxy_pass http://127.0.0.1:;
> }
>
> Вот такой код в первом апстриме (Django):
>
> def app_hyper_report(request):
> r = api.Response()
> r['myheader'] = 10
> r['X-Accel-Redirect'] = '@tornado'
> return r
>
> То есть здесь идет переадресация через X-Accel-Redirect на второй апстрим.
> При этом, нужно передать во второй апстрим некоторые параметры. Пытаюсь это
> сделать через headers. Столкнулся с проблемой: почему-то не работает
> передача headers через $upstream_http_myheader (в то время как
> $upstream_status срабатывает нормально).
>
> В чем здесь может быть проблема?
Проблема в том, что в момент выполнения proxy_set_header уже
началась работа новым upstream'ом, и значения переменных
$upstream_http_* и $upstream_status - пустые.
Решается сохранением нужных значений в промежуточные переменные с
помощью set, как-то так:
location @tornado {
set $saved_myheader $upstream_http_myheader;
set $saved_status $upstream_status;
proxy_set_header X-foo1 $saved_myheader;
proxy_set_header X-foo2 $saved_status;
proxy_pass http://127.0.0.1:;
}
--
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
