From vovansystems на gmail.com Wed May 4 11:58:19 2016 From: vovansystems на gmail.com (VovansystemS) Date: Wed, 4 May 2016 14:58:19 +0300 Subject: =?UTF-8?B?0YDQtdCy0LDQu9C40LTQsNGG0LjRjyDQutC10YjQsCBmYXN0Y2dp?= Message-ID: Добрый день, пытаюсь настроить ревалидацию страниц сайта в кеше директивой fastcgi_cache_revalidate on; ожидаю, что если элемент кеша устарел, то nginx сам сделает запрос к бекэнду с заголовком If-Modified-Since (как это описано тут http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/ ), но этого не происходит. при устаревании элемента кеша $upstream_cache_status == EXPIRED и на бэкэнд уходит стандартный GET без заголовков на ревалидацию при включённом fastcgi_cache_revalidate on. я попробовал задавать fastcgi_cache_revalidate на разных уровнях, на случай если есть особенности наследования, но всё равно безуспешно. если же я делаю curl -i --header 'If-Modified-Since: Tue, 11 Dec 2015 10:10:24 GMT' https://site.com то получаю X-My-Cache: REVALIDATED - потому что клиентский заголовок был корректно передан на бэкэнд, который ответил header('HTTP/1.0 304 Not Modified'); вопрос: я не понимаю как должна работать директива и хочу странного или всё же задачу можно как-то решить? подскажите, пожалуйста. конфиг: fastcgi_cache_path /tmp/MAIN levels=1:2 keys_zone=MAIN:64m max_size=768m inactive=24h; server { listen ***:443 ssl; server_name site.com; ssl on; ssl_certificate /etc/nginx/ssl/certs-mcg/site_co_uk.pem; ssl_certificate_key /etc/nginx/ssl/certs-mcg/site_co_uk.key; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; error_log /home/site/logs/site-ssl.error.log error; access_log /home/site/logs/site-ssl.access.log wtimes; root /www/site/domains/site.com/public_html/; set $sock 127.0.0.1:9001; include fastcgi_params; fastcgi_index index.php; fastcgi_intercept_errors on; fastcgi_param DOCUMENT_ROOT /public_html; fastcgi_param SCRIPT_FILENAME /public_html$fastcgi_script_name; fastcgi_no_cache $cookie_login $cookie_authautologin $cookie_PHPSESSID; fastcgi_cache_bypass $cookie_login $cookie_authautologin $cookie_PHPSESSID; fastcgi_cache_revalidate on; fastcgi_temp_path /tmp/fcgi 1 2; fastcgi_cache MAIN; fastcgi_cache_key "$scheme|$request_method|$host|$request_uri"; fastcgi_cache_lock on; fastcgi_cache_methods GET HEAD; fastcgi_ignore_headers "Cache-Control" "Expires"; fastcgi_cache_valid 10s; add_header X-My-Cache $upstream_cache_status; 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; index index.html index.php; location / { fastcgi_cache_revalidate on; try_files $uri $uri/ /index.php$is_args$args; } location ~* "^/wp-admin(/.*$|/$|$)" { fastcgi_cache off; try_files $fastcgi_script_name =404; fastcgi_pass $sock; add_header X-My-Cache-admin $upstream_cache_status; } location ~* "^/cart(/.*$|/$|$)" { fastcgi_cache off; try_files $fastcgi_script_name =404; fastcgi_pass $sock; add_header X-My-Cache-cart $upstream_cache_status; } location ~* \.php$ { fastcgi_cache_revalidate on; try_files $fastcgi_script_name =404; fastcgi_pass $sock; } # Static files location location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|docx)$ { expires 60d; access_log off; } } версии софта: nginx version: nginx/1.9.15 (из официального репозитория) PHP 5.4.45-1~dotdeb+7.1 Debian GNU/Linux 7 From nginx-forum на forum.nginx.org Wed May 4 12:13:47 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 04 May 2016 08:13:47 -0400 Subject: =?UTF-8?B?UmU6INGA0LXQstCw0LvQuNC00LDRhtC40Y8g0LrQtdGI0LAgZmFzdGNnaQ==?= In-Reply-To: References: Message-ID: Судя по конфигу, у вас проблема с куками, если браузер присылает куки сессии, кеш не работает, 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_empty; Они не нужны На бекенде в РНР, отвечайте http_response_code(304); вместо header('HTTP/1.0 304 Not Modified'); так быстрей и правильней. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266607,266608#msg-266608 From mdounin на mdounin.ru Wed May 4 12:13:44 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 4 May 2016 15:13:44 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQstCw0LvQuNC00LDRhtC40Y8g0LrQtdGI0LAgZmFzdGNnaQ==?= In-Reply-To: References: Message-ID: <20160504121344.GS36620@mdounin.ru> Hello! On Wed, May 04, 2016 at 02:58:19PM +0300, VovansystemS wrote: > Добрый день, > > пытаюсь настроить ревалидацию страниц сайта в кеше директивой > fastcgi_cache_revalidate on; > ожидаю, что если элемент кеша устарел, то nginx сам сделает запрос к > бекэнду с заголовком If-Modified-Since (как это описано тут > http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/ ), но > этого не происходит. > > при устаревании элемента кеша $upstream_cache_status == EXPIRED и на > бэкэнд уходит стандартный GET без заголовков на ревалидацию при > включённом fastcgi_cache_revalidate on. > > я попробовал задавать fastcgi_cache_revalidate на разных уровнях, на > случай если есть особенности наследования, но всё равно безуспешно. > > если же я делаю > curl -i --header 'If-Modified-Since: Tue, 11 Dec 2015 10:10:24 GMT' > https://site.com > > то получаю X-My-Cache: REVALIDATED - потому что клиентский заголовок > был корректно передан на бэкэнд, который ответил header('HTTP/1.0 304 > Not Modified'); > > вопрос: я не понимаю как должна работать директива и хочу странного > или всё же задачу можно как-то решить? подскажите, пожалуйста. [...] > 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-None-Match и If-Modified-Since в запросах к бекенду в полученные от клиента значения. Ревалидация кеша в таких условиях работать не может по очевидным причинам. -- Maxim Dounin http://nginx.org/ From vovansystems на gmail.com Wed May 4 12:33:39 2016 From: vovansystems на gmail.com (VovansystemS) Date: Wed, 4 May 2016 15:33:39 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQstCw0LvQuNC00LDRhtC40Y8g0LrQtdGI0LAgZmFzdGNnaQ==?= In-Reply-To: <20160504121344.GS36620@mdounin.ru> References: <20160504121344.GS36620@mdounin.ru> Message-ID: >> 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-None-Match и > If-Modified-Since в запросах к бекенду в полученные от клиента > значения. Ревалидация кеша в таких условиях работать не может по > очевидным причинам. убрал эти строки. удалил кеш. ристартанул nginx первая загрузка X-My-Cache: MISS (страницы нет в кеше) вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную версию) жду 10 секунд третья загрузка X-My-Cache: EXPIRED (а я ожидаю X-My-Cache: REVALIDATED ) заголовки запроса браузера: GET /product/name HTTP/1.1 Host: site.com Connection: keep-alive Pragma: no-cache Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 на всякий случай сделал то же самое через curl: curl -i "https://site.com/product/name" и получил точно такой же результат: первая загрузка X-My-Cache: MISS (страницы нет в кеше) вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную версию) жду 10 секунд третья загрузка X-My-Cache: EXPIRED > На бекенде в РНР, отвечайте http_response_code(304); вместо header('HTTP/1.0 304 Not Modified'); так быстрей и правильней. поправил > Судя по конфигу, у вас проблема с куками, если браузер присылает куки сессии, кеш не работает, curl куки не присылает, ответ отдается из кеша. вроде нет, см выше описание поведения curl при стандартном GET бэкэнд сейчас, к слову, выглядит примерно так: References: Message-ID: <47e290d7a9c40a8056622788f06a3da7.NginxMailingListRussian@forum.nginx.org> 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-None-Match и > > If-Modified-Since в запросах к бекенду в полученные от клиента > > значения. Ревалидация кеша в таких условиях работать не может по > > очевидным причинам. > > убрал эти строки. удалил кеш. ристартанул nginx > первая загрузка X-My-Cache: MISS (страницы нет в кеше) > вторая загрузка X-My-Cache: HIT (есть в кеше, получаю закешированную > версию) > жду 10 секунд > третья загрузка X-My-Cache: EXPIRED > > (а я ожидаю X-My-Cache: REVALIDATED ) > Вы изначально в ответе отдавали заголовки валидаторы (ETag и/ил Last-Modified)? Посмотрите на содержимое в папке кеша Nginx, есть ли там заголовки ETag и/ил Last-Modified, без них ревалидация кеша невозможно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266607,266612#msg-266612 From vovansystems на gmail.com Wed May 4 14:24:51 2016 From: vovansystems на gmail.com (VovansystemS) Date: Wed, 4 May 2016 17:24:51 +0300 Subject: =?UTF-8?B?UmU6INGA0LXQstCw0LvQuNC00LDRhtC40Y8g0LrQtdGI0LAgZmFzdGNnaQ==?= In-Reply-To: <47e290d7a9c40a8056622788f06a3da7.NginxMailingListRussian@forum.nginx.org> References: <47e290d7a9c40a8056622788f06a3da7.NginxMailingListRussian@forum.nginx.org> Message-ID: > Вы изначально в ответе отдавали заголовки валидаторы (ETag и/ил > Last-Modified)? > Посмотрите на содержимое в папке кеша Nginx, есть ли там заголовки ETag и/ил > Last-Modified, без них ревалидация кеша невозможно. да, спасибо огромное дело оказалось именно в этом! заголовки-то мы отдавали, и у разработчика на машине nginx 1.8.0 и php 5.6 они ставятся нормально, а вот на конфигурации, которая дублирует продакшн nginx 1.9.15 и php 5.4 (fpm, chroot) что-то в приложении эти заголовки упорно снимало. приложение на основе wordpress и там какой-то ад и израиль. пока нашли воркэраунд - заголовки начали ставится и ревалидация заработала. Максим, S.A.N спасибо большое за помощь From nginx-forum на forum.nginx.org Wed May 4 15:58:17 2016 From: nginx-forum на forum.nginx.org (malaf) Date: Wed, 04 May 2016 11:58:17 -0400 Subject: =?UTF-8?B?0KfQsNGB0YLRjCDQt9Cw0L/RgNC+0YHQvtCyINGBINCw0L3QsNC80L7Qu9GM0L0=?= =?UTF-8?B?0L4g0LHQvtC70YzRiNC40LwgJHJlcXVlc3QgdGltZQ==?= Message-ID: <76c6bce55fea788cb08390209e1ade0a.NginxMailingListRussian@forum.nginx.org> Добрый день. Есть такая конфигурация: - фронтенд c nginx - бэкенды с php - для динамических запросов настроено php fastcgi между nginx и php-fpm через tcp порт с кешированием ответов - log_format выглядит примерно так- '$remote_addr # $upstream_addr # $request # $status # $uri # $upstream_response_time # $upstream_cache_status # $request_time - проект высоконагруженный Столкнулся с такой проблемой, судя по логам, то часть запросов имеет существенно большее значение $request_time чем $upstream_response_time, может быть больше как на 1 секунду так и 2, 5 и даже более 30. Особенно это заметно на страницах из кеша, у которых upstream_cache_status = HIT, upstream_response_time = 0 и c большим request_time, хотя для подавляющего большинства этот параметр имеет значение 0-0.01s Влияние "медленных клиентов" на значение $request_time вроде отсёк, проверив лог после обращения к странице в кеше с помощью curl --limit-rate 20K example.com > /dev/null, время ответа было 4 секунды, в лог request_time записался со значение 0. Проблема тоже не fastcgi или кеш-менеджере, так как такое же наблюдается и для запросов, которые обрабатываются с помощью nginx+redis через redis_pass. Подскажите, в чём может быть проблема, на что ещё обратить внимание, что проверить? nginx -V nginx version: nginx/1.8.1 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --without-http_memcached_module --without-http_uwsgi_module --without-http_scgi_module --with-http_stub_status_module --add-module=/root/rpmbuild/SOURCES/nginx_modules/ngx_cache_purge --add-module=/root/rpmbuild/SOURCES/nginx_modules/ngx_http_redis --add-module=/root/rpmbuild/SOURCES/nginx_modules/redis2-nginx-module --add-module=/root/rpmbuild/SOURCES/nginx_modules/lua-nginx-module --add-module=/root/rpmbuild/SOURCES/nginx_modules/ngx_devel_kit --add-module=/root/rpmbuild/SOURCES/nginx_modules/set-misc-nginx-module --with-file-aio --with-http_spdy_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266619,266619#msg-266619 From mdounin на mdounin.ru Wed May 4 17:21:36 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 4 May 2016 20:21:36 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0Ywg0LfQsNC/0YDQvtGB0L7QsiDRgSDQsNC90LDQvNC+0Ls=?= =?UTF-8?B?0YzQvdC+INCx0L7Qu9GM0YjQuNC8ICRyZXF1ZXN0IHRpbWU=?= In-Reply-To: <76c6bce55fea788cb08390209e1ade0a.NginxMailingListRussian@forum.nginx.org> References: <76c6bce55fea788cb08390209e1ade0a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160504172136.GA36620@mdounin.ru> Hello! On Wed, May 04, 2016 at 11:58:17AM -0400, malaf wrote: > Добрый день. > > Есть такая конфигурация: > - фронтенд c nginx > - бэкенды с php > - для динамических запросов настроено php fastcgi между nginx и php-fpm > через tcp порт с кешированием ответов > - log_format выглядит примерно так- '$remote_addr # $upstream_addr # > $request # $status # $uri # $upstream_response_time # $upstream_cache_status > # $request_time > - проект высоконагруженный > > Столкнулся с такой проблемой, судя по логам, то часть запросов имеет > существенно большее значение $request_time чем $upstream_response_time, > может быть больше как на 1 секунду так и 2, 5 и даже более 30. Особенно это > заметно на страницах из кеша, у которых upstream_cache_status = HIT, > upstream_response_time = 0 и c большим request_time, хотя для подавляющего > большинства этот параметр имеет значение 0-0.01s > > Влияние "медленных клиентов" на значение $request_time вроде отсёк, проверив > лог после обращения к странице в кеше с помощью curl --limit-rate 20K > example.com > /dev/null, время ответа было 4 секунды, в лог request_time > записался со значение 0. Использование "curl --limit-rate" для эмуляции медленных клиентов - более или менее работает только в том случае, если размер ответа превышает суммарный размер всех буферов в цепочке. Если в $request_time записалось значение 0 - это хороший признак, что ответ полностью влез в буфера, и с точки зрения nginx'а клиент - быстрее не бывает. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Thu May 5 12:19:17 2016 From: nginx-forum на forum.nginx.org (malaf) Date: Thu, 05 May 2016 08:19:17 -0400 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0Ywg0LfQsNC/0YDQvtGB0L7QsiDRgSDQsNC90LDQvNC+0Ls=?= =?UTF-8?B?0YzQvdC+INCx0L7Qu9GM0YjQuNC8ICRyZXF1ZXN0IHRpbWU=?= In-Reply-To: <20160504172136.GA36620@mdounin.ru> References: <20160504172136.GA36620@mdounin.ru> Message-ID: > > Влияние "медленных клиентов" на значение $request_time вроде отсёк, > проверив > > лог после обращения к странице в кеше с помощью curl --limit-rate > 20K > > example.com > /dev/null, время ответа было 4 секунды, в лог > request_time > > записался со значение 0. > > Использование "curl --limit-rate" для эмуляции медленных клиентов - > более или менее работает только в том случае, если размер ответа > превышает суммарный размер всех буферов в цепочке. Если в > $request_time записалось значение 0 - это хороший признак, что > ответ полностью влез в буфера, и с точки зрения nginx'а клиент - > быстрее не бывает. А с каких точно буферов может состоять цепочка? Пробовал ещё играться с настройками отключая совсем fastcgi_buffering off или уменьшая fastcgi_buffers 2 1k при размере ответа в 100КБ, чтобы было нехватка выделяемого буфера, но всё равно даже близко эмулировать проблемную ситуацию не удается. Хочется понять какие настройки ещё попробовать донастроить, чтобы избежать таких задержек. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266620,266642#msg-266642 From mdounin на mdounin.ru Thu May 5 13:28:54 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 5 May 2016 16:28:54 +0300 Subject: =?UTF-8?B?UmU6INCn0LDRgdGC0Ywg0LfQsNC/0YDQvtGB0L7QsiDRgSDQsNC90LDQvNC+0Ls=?= =?UTF-8?B?0YzQvdC+INCx0L7Qu9GM0YjQuNC8ICRyZXF1ZXN0IHRpbWU=?= In-Reply-To: References: <20160504172136.GA36620@mdounin.ru> Message-ID: <20160505132854.GD36620@mdounin.ru> Hello! On Thu, May 05, 2016 at 08:19:17AM -0400, malaf wrote: > > > Влияние "медленных клиентов" на значение $request_time вроде отсёк, > > проверив > > > лог после обращения к странице в кеше с помощью curl --limit-rate > > 20K > > > example.com > /dev/null, время ответа было 4 секунды, в лог > > request_time > > > записался со значение 0. > > > > Использование "curl --limit-rate" для эмуляции медленных клиентов - > > более или менее работает только в том случае, если размер ответа > > превышает суммарный размер всех буферов в цепочке. Если в > > $request_time записалось значение 0 - это хороший признак, что > > ответ полностью влез в буфера, и с точки зрения nginx'а клиент - > > быстрее не бывает. > А с каких точно буферов может состоять цепочка? Как минимум - из буфера на отправку в сокете со стороны сервера, буфера на приём сокета со стороны клиента. В зависимости от реализации "curl --limit-rate" - может быть ещё что-то внутри curl'а. Ну и если используются туннели или прокси-сервера - к этому всему добавляются буфера в них. > Пробовал ещё играться с настройками отключая совсем fastcgi_buffering off > или уменьшая fastcgi_buffers 2 1k при размере ответа в 100КБ, чтобы было > нехватка выделяемого буфера, но всё равно даже близко эмулировать проблемную > ситуацию не удается. Всё это не имеет отношения к вопросу. > Хочется понять какие настройки ещё попробовать донастроить, чтобы избежать > таких задержек. Если задержки действительно связаны с медленными клиентами - то донастроить вряд ли получится. А если и получится (например, подняв буфера сокета на отправку) - то большей частью это отразится на цифрах в логах, но не на реальном времени получения ответов клиентами. -- Maxim Dounin http://nginx.org/ From exelib на gmail.com Thu May 5 15:55:01 2016 From: exelib на gmail.com (Anton Bessonov) Date: Thu, 05 May 2016 17:55:01 +0200 Subject: =?UTF-8?B?UmU6INCf0L7QtNC80LXQvdCwINCx0LjQvdCw0YDQvdC40LrQsCDQsiDQtNC+0Lo=?= =?UTF-8?B?0LXRgNC1?= In-Reply-To: <1EEBFC39-AF04-4F65-A0B0-4A6B50A56FB9@sysoev.ru> References: <571E54CC.4080302@gmail.com> <5039C10B-D8D7-4657-981A-F82F958BDAD6@sysoev.ru> <571E762F.4080103@gmail.com> <650C696D-02F7-44BB-A08A-7D6D0C9AB5A4@sysoev.ru> <571F96E2.2050006@gmail.com> <1EEBFC39-AF04-4F65-A0B0-4A6B50A56FB9@sysoev.ru> Message-ID: <572B6CD5.2040404@gmail.com> On 26.04.2016 22:19, Igor Sysoev wrote: > On 26 Apr 2016, at 19:27, Anton Bessonov wrote: > >> Спасибо большое, работает. И с демонизацией тоже. >> >> Но наблюдаю эффект, что если убить мастера, то воркер остаётся один. И только после убивания воркера ломается контейнер. Можно сделать как-то (trap?), что бы контейнер или воркер с мастером ломались? А то состояние странное. > Убить как - kill -9 или просто kill ? Во втором случае воркеры должны выходить. > > Как kill -9. С просто kill воркер выходит. From igor на sysoev.ru Thu May 5 16:43:59 2016 From: igor на sysoev.ru (Igor Sysoev) Date: Thu, 5 May 2016 19:43:59 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNC80LXQvdCwINCx0LjQvdCw0YDQvdC40LrQsCDQsiDQtNC+0Lo=?= =?UTF-8?B?0LXRgNC1?= In-Reply-To: <572B6CD5.2040404@gmail.com> References: <571E54CC.4080302@gmail.com> <5039C10B-D8D7-4657-981A-F82F958BDAD6@sysoev.ru> <571E762F.4080103@gmail.com> <650C696D-02F7-44BB-A08A-7D6D0C9AB5A4@sysoev.ru> <571F96E2.2050006@gmail.com> <1EEBFC39-AF04-4F65-A0B0-4A6B50A56FB9@sysoev.ru> <572B6CD5.2040404@gmail.com> Message-ID: On 05 May 2016, at 18:55, Anton Bessonov wrote: > On 26.04.2016 22:19, Igor Sysoev wrote: >> On 26 Apr 2016, at 19:27, Anton Bessonov wrote: >> >>> Спасибо большое, работает. И с демонизацией тоже. >>> >>> Но наблюдаю эффект, что если убить мастера, то воркер остаётся один. И только после убивания воркера ломается контейнер. Можно сделать как-то (trap?), что бы контейнер или воркер с мастером ломались? А то состояние странное. >> Убить как - kill -9 или просто kill ? Во втором случае воркеры должны выходить. >> > Как kill -9. С просто kill воркер выходит. По kill -9 мастер уже ничего не может сделать. -- Igor Sysoev http://nginx.com From dmitry на zhigulinet.ru Fri May 6 05:22:35 2016 From: dmitry на zhigulinet.ru (Dmitry) Date: Fri, 6 May 2016 08:22:35 +0300 Subject: =?UTF-8?B?bmdpbmcg0L/RgNC+0LrRgdC4?= Message-ID: <572C2A1B.2000300@zhigulinet.ru> Добрый день! Возникла аздача проксировать https на два сервера, но со следующими условиями, если один севрвер ответит определенными запросом (не абонента в биллинге), то проксировать на второй сервер, пример так вот: https://1.1.1.1:1443/osmp-s.php?command=check&account=1104492&txn_id=201604290950&sum=20.00 This XML file does not appear to have any style information associated with it. The document tree is shown below. 201604290950 5 User not found То есть если User not found или result 5, отправлять на другой сервер. Подскажите в каком направление двигаться, спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From undying-m на yandex.ru Fri May 6 07:48:16 2016 From: undying-m на yandex.ru (Den Bozhok) Date: Fri, 06 May 2016 10:48:16 +0300 Subject: =?UTF-8?B?UmU6IG5naW5nINC/0YDQvtC60YHQuA==?= In-Reply-To: 158751886864860705 References: <572C2A1B.2000300@zhigulinet.ru> Message-ID: <16473861462520896@web7m.yandex.ru> А код ответа при этом 200 или 404? 06.05.2016, 08:22, "Dmitry" : > Добрый день! > Возникла аздача проксировать https на два сервера, но со следующими условиями, если один севрвер ответит определенными запросом (не абонента в биллинге), то проксировать на второй сервер, пример так вот: > > https://1.1.1.1:1443/osmp-s.php?command=check&account=1104492&txn_id=201604290950&sum=20.00 > > This XML file does not appear to have any style information associated with it. The document tree is shown below. > > 201604290950 > 5 > User not found > > > > То есть если User not found или result 5, отправлять на другой сервер. > Подскажите в каком направление двигаться, спасибо! > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From simplebox66 на gmail.com Fri May 6 10:13:54 2016 From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=) Date: Fri, 6 May 2016 13:13:54 +0300 Subject: =?UTF-8?B?bmdpbngg0L/QtdGA0LXRgdGC0LDQuyDQv9C10YDQtdGB0YLQsNC7INCz0YDRg9C3?= =?UTF-8?B?0LjRgtGMINGE0LDQudC70Ysg0L/QviB3ZWJkYXYg0LIg0L7RgtGB0YPRgtGB?= =?UTF-8?B?0YLQstC40Lgg0LzQtdGB0YLQsCDQsiDQutC+0YDQvdC10LLQvtC8INGA0LA=?= =?UTF-8?B?0LfQtNC10LvQtQ==?= Message-ID: Добрый день! Подскажите, есть nginx( расположен в корне, как и его cache - /var/cache/nginx/), на nginx организован вебдав который складывает файлы куда-то в mnt. В какой-то момент волей случая место в корне было израсходовано на 100% (но израсходовал его не nginx), после чего nginx перестал принимать файлы. Хотелось бы уточнить описанная выше ситуация это норма? Кто виноват в том что файлы перестали грузится, client_body_temp_path ? Как избежать повторения ситуации? Если бы место забила не другая программа, а сам nginx (например путем наполнения client_body_temp_path ), загрузка файлов то же бы застопорилась? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dmitry на zhigulinet.ru Fri May 6 13:41:51 2016 From: dmitry на zhigulinet.ru (Dmitry) Date: Fri, 6 May 2016 16:41:51 +0300 Subject: =?UTF-8?B?UmU6IG5naW5nINC/0YDQvtC60YHQuA==?= In-Reply-To: <16473861462520896@web7m.yandex.ru> References: <572C2A1B.2000300@zhigulinet.ru> <16473861462520896@web7m.yandex.ru> Message-ID: <572C9F1F.60300@zhigulinet.ru> Код ответа всегда 200, именно разбирать ответ, возможно ли это? On 06.05.2016 10:48, Den Bozhok wrote: > А код ответа при этом 200 или 404? > > 06.05.2016, 08:22, "Dmitry" : >> Добрый день! >> Возникла аздача проксировать https на два сервера, но со следующими условиями, если один севрвер ответит определенными запросом (не абонента в биллинге), то проксировать на второй сервер, пример так вот: >> >> https://1.1.1.1:1443/osmp-s.php?command=check&account=1104492&txn_id=201604290950&sum=20.00 >> >> This XML file does not appear to have any style information associated with it. The document tree is shown below. >> >> 201604290950 >> 5 >> User not found >> >> >> >> То есть если User not found или result 5, отправлять на другой сервер. >> Подскажите в каком направление двигаться, спасибо! >> >> _______________________________________________ >> 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 From undying-m на yandex.ru Fri May 6 22:05:53 2016 From: undying-m на yandex.ru (Den Bozhok) Date: Sat, 07 May 2016 01:05:53 +0300 Subject: =?UTF-8?B?UmU6IG5naW5nINC/0YDQvtC60YHQuA==?= In-Reply-To: <572C9F1F.60300@zhigulinet.ru> References: <572C2A1B.2000300@zhigulinet.ru> <16473861462520896@web7m.yandex.ru> <572C9F1F.60300@zhigulinet.ru> Message-ID: <9456011462572353@web14g.yandex.ru> Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat May 7 14:31:15 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 07 May 2016 10:31:15 -0400 Subject: =?UTF-8?B?cHJveHkgaHR0cCB2ZXJzaW9uIDI7INCx0LXQtyBTU0wsINC00LvRjyDQvNGD0Ls=?= =?UTF-8?B?0YzRgtC40L/Qu9C10LrRgdC40YDQvtCy0LDQvdC40LUg0LfQsNC/0YDQvtGB?= =?UTF-8?B?0L7QsiDQuiDQsdC10LrQtdC90LTRgw==?= Message-ID: Наш бекенд работает на HTTP/1.1 в режиме Keep-Alive, но в пикоквые нагрузки, нам приходится держать много открытых конектов. Демон асинхронный, но если один запрос выполняется дольше обычного конект параллельно использовать для других запросов уже не выйдет он просто ждет, хотелось бы попробовать H2 мультиплексирования, но без SSL он не нужен внутри датацентра. Имплементация H2 без SSL, для проксирования бекендов, есть в планах Nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,266693#msg-266693 From dmitry на zhigulinet.ru Sat May 7 17:19:38 2016 From: dmitry на zhigulinet.ru (Dmitry) Date: Sat, 7 May 2016 20:19:38 +0300 Subject: =?UTF-8?B?UmU6IG5naW5nINC/0YDQvtC60YHQuA==?= In-Reply-To: <9456011462572353@web14g.yandex.ru> References: <572C2A1B.2000300@zhigulinet.ru> <16473861462520896@web7m.yandex.ru> <572C9F1F.60300@zhigulinet.ru> <9456011462572353@web14g.yandex.ru> Message-ID: <572E23AA.2010801@zhigulinet.ru> а не подскажите на пример, а то пока не понял, как второй запрос послать, как составить условие чтобы на основе ответа послать на другой сервер. Изначально была идея отдать через proxy_pass в питон скрипт и на него всю работу возложить On 07.05.2016 01:05, Den Bozhok wrote: > Для разбора, нужно писать код, например на lua: > https://github.com/openresty/lua-nginx-module#body_filter_by_lua > 06.05.2016, 16:42, "Dmitry" : >> >> Код ответа всегда 200, именно разбирать ответ, возможно ли это? >> >> On 06.05.2016 10:48, Den Bozhok wrote: >> >> А код ответа при этом 200 или 404? >> >> 06.05.2016, 08:22, "Dmitry" > >: >> >> Добрый день! >> Возникла аздача проксировать https на два сервера, но со >> следующими условиями, если один севрвер ответит определенными >> запросом (не абонента в биллинге), то проксировать на второй >> сервер, пример так вот: >> >> https://1.1.1.1:1443/osmp-s.php?command=check&account=1104492&txn_id=201604290950&sum=20.00 >> >> This XML file does not appear to have any style information >> associated with it. The document tree is shown below. >> >> 201604290950 >> 5 >> User not found >> >> >> >> То есть если User not found или result 5, отправлять на >> другой сервер. >> Подскажите в каком направление двигаться, спасибо! >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sat May 7 23:20:12 2016 From: nginx-forum на forum.nginx.org (Babaev) Date: Sat, 07 May 2016 19:20:12 -0400 Subject: =?UTF-8?B?0JrQsNC6INC90LDRgdGC0YDQvtC40YLRjCBOZ2lueCDQvdCwINCy0LjRgNGC0YM=?= =?UTF-8?B?0LDQu9GM0L3QvtC5INC80LDRiNC40L3QtSBBenVyZT8=?= Message-ID: <43c0cde06dc1c905f6a0161a10d896be.NginxMailingListRussian@forum.nginx.org> Развернул на виртуальной машине (Ubunte Server) Nginx. Все работает с дефолтным конфигом: worker_processes 1; error_log logs/error.log; events { worker_connections 1024; } http { server { listen 8080; location / { default_type text/html; } } } Тест делаю так: curl http://localhost:8080/ Вопрсо в том, что виртуальная машина имеет выделенный(статический) IP адрес. Я хочу достучаться по нему: IP:8080, но это не срабатывает. Получаю сетевую ошибку: This site can’t be reached Какие настройки еще необходимо сделать? Спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266696,266696#msg-266696 From alex.hha на gmail.com Sun May 8 10:36:34 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Sun, 8 May 2016 13:36:34 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0YwgTmdpbngg0L3QsCDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90L7QuSDQvNCw0YjQuNC90LUgQXp1cmU/?= In-Reply-To: <43c0cde06dc1c905f6a0161a10d896be.NginxMailingListRussian@forum.nginx.org> References: <43c0cde06dc1c905f6a0161a10d896be.NginxMailingListRussian@forum.nginx.org> Message-ID: Настроить фаервол? Я не сталкивался с Azure, но в AWS по дефолту надо открывать порт(ы) 2016-05-08 2:20 GMT+03:00 Babaev : > Развернул на виртуальной машине (Ubunte Server) Nginx. > > Все работает с дефолтным конфигом: > > worker_processes 1; > error_log logs/error.log; > events { > worker_connections 1024; > } > http { > server { > listen 8080; > location / { > default_type text/html; > } > } > } > > Тест делаю так: curl http://localhost:8080/ > > Вопрсо в том, что виртуальная машина имеет выделенный(статический) IP > адрес. > Я хочу достучаться по нему: IP:8080, но это не срабатывает. Получаю сетевую > ошибку: This site can’t be reached > > Какие настройки еще необходимо сделать? > Спасибо! > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266696,266696#msg-266696 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 9 14:33:26 2016 From: nginx-forum на forum.nginx.org (Babaev) Date: Mon, 09 May 2016 10:33:26 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LjQstCw0LXRgiDQu9C4IE5naW54INC/0YDQvtC3?= =?UTF-8?B?0YDQsNGH0L3Ri9C5INC/0YDQvtC60YHQuD8=?= In-Reply-To: References: Message-ID: <494dadc96604d026fa7c5c89d8353d05.NginxMailingListRussian@forum.nginx.org> Так ведь reverse proxy и transparent proxy - это разные вещи? Или я что-то не понимаю? Пример может привести, пожалуйста? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266706,266717#msg-266717 From nginx-ru на sadok.spb.ru Mon May 9 20:29:07 2016 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Mon, 9 May 2016 23:29:07 +0300 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LjQstCw0LXRgiDQu9C4IE5naW54INC/0YDQvtC3?= =?UTF-8?B?0YDQsNGH0L3Ri9C5INC/0YDQvtC60YHQuD8=?= In-Reply-To: <494dadc96604d026fa7c5c89d8353d05.NginxMailingListRussian@forum.nginx.org> References: <494dadc96604d026fa7c5c89d8353d05.NginxMailingListRussian@forum.nginx.org> Message-ID: <2910372526.20160509232907@sadok.spb.ru> Здравствуйте, Babaev. Вы писали 9 мая 2016 г., 17:33:26: > Так ведь reverse proxy и transparent proxy - это разные вещи? Или я что-то > не понимаю? > Пример может привести, пожалуйста? Nginx и squid соответственно. -- С уважением, Dmitry nginx-ru на sadok.spb.ru From nginx-forum на forum.nginx.org Mon May 9 23:55:23 2016 From: nginx-forum на forum.nginx.org (Babaev) Date: Mon, 09 May 2016 19:55:23 -0400 Subject: =?UTF-8?B?0JrQsNC6INC90LAg0LvQvtC60LDQu9GM0L3QvtC5INC80LDRiNC40L3QtSDQv9GA?= =?UTF-8?B?0L7QutGB0LjRgNC+0LLQsNGC0Ywg0LfQsNC/0YDQvtGB0Ys/?= Message-ID: <5e5cd6c310b41edd181215d647670a2d.NginxMailingListRussian@forum.nginx.org> Как на локальной машине проксировать запросы в браузере? Сейчас nginx проксирует только localhost Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266721,266721#msg-266721 From chipitsine на gmail.com Tue May 10 08:19:08 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 10 May 2016 13:19:08 +0500 Subject: =?UTF-8?B?UmU6IG5naW5nINC/0YDQvtC60YHQuA==?= In-Reply-To: <9456011462572353@web14g.yandex.ru> References: <572C2A1B.2000300@zhigulinet.ru> <16473861462520896@web7m.yandex.ru> <572C9F1F.60300@zhigulinet.ru> <9456011462572353@web14g.yandex.ru> Message-ID: если бы, к примеру, у вас статус был 404, можно было бы попробовать выкрутиться на error_page 404 @fallback; и в локейшене @fallback еще раз спроксировать. если 200, то , вероятно, проще свой скрипт на питоне 7 мая 2016 г., 3:05 пользователь Den Bozhok написал: > Для разбора, нужно писать код, например на lua: > https://github.com/openresty/lua-nginx-module#body_filter_by_lua > > 06.05.2016, 16:42, "Dmitry" : > > Код ответа всегда 200, именно разбирать ответ, возможно ли это? > > On 06.05.2016 10:48, Den Bozhok wrote: > > А код ответа при этом 200 или 404? > > 06.05.2016, 08:22, "Dmitry" : > > Добрый день! > Возникла аздача проксировать https на два сервера, но со следующими > условиями, если один севрвер ответит определенными запросом (не абонента в > биллинге), то проксировать на второй сервер, пример так вот: > > > https://1.1.1.1:1443/osmp-s.php?command=check&account=1104492&txn_id=201604290950&sum=20.00 > > This XML file does not appear to have any style information associated > with it. The document tree is shown below. > > 201604290950 > 5 > User not found > > > > То есть если User not found или result 5, отправлять на другой сервер. > Подскажите в каком направление двигаться, спасибо! > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue May 10 08:21:53 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 10 May 2016 13:21:53 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0YwgTmdpbngg0L3QsCDQstC40YA=?= =?UTF-8?B?0YLRg9Cw0LvRjNC90L7QuSDQvNCw0YjQuNC90LUgQXp1cmU/?= In-Reply-To: <43c0cde06dc1c905f6a0161a10d896be.NginxMailingListRussian@forum.nginx.org> References: <43c0cde06dc1c905f6a0161a10d896be.NginxMailingListRussian@forum.nginx.org> Message-ID: чтобы можно было обращаться к виртуалке, вам надо добавить "endpoint", и в нем указать, что трафик с порта 8080 надо отправлять на порт 8080 вашей виртуалки 8 мая 2016 г., 4:20 пользователь Babaev написал: > Развернул на виртуальной машине (Ubunte Server) Nginx. > > Все работает с дефолтным конфигом: > > worker_processes 1; > error_log logs/error.log; > events { > worker_connections 1024; > } > http { > server { > listen 8080; > location / { > default_type text/html; > } > } > } > > Тест делаю так: curl http://localhost:8080/ > > Вопрсо в том, что виртуальная машина имеет выделенный(статический) IP > адрес. > Я хочу достучаться по нему: IP:8080, но это не срабатывает. Получаю сетевую > ошибку: This site can’t be reached > > Какие настройки еще необходимо сделать? > Спасибо! > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266696,266696#msg-266696 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 10 10:10:55 2016 From: nginx-forum на forum.nginx.org (ex) Date: Tue, 10 May 2016 06:10:55 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: <151b89b2563c3f904dcbbb072ac26b7b.NginxMailingListRussian@forum.nginx.org> Из документации: Модуль ngx_http_v2_module поддерживает следующие встроенные переменные: $http2 - согласованный идентификатор протокола: “h2” для HTTP/2 через TLS, “h2c” для HTTP/2 через незашифрованный TCP, либо пустая строка. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,266726#msg-266726 From nginx-forum на forum.nginx.org Tue May 10 11:43:08 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 10 May 2016 07:43:08 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <151b89b2563c3f904dcbbb072ac26b7b.NginxMailingListRussian@forum.nginx.org> References: <151b89b2563c3f904dcbbb072ac26b7b.NginxMailingListRussian@forum.nginx.org> Message-ID: Меня интересует H2 в модуле ngx_http_proxy_module (исходящие запросы к бекенду), вы написали про модуль ngx_http_v2_module (входящие запросы от клиентов) Возможно вы хотели сказать что должно работать так: proxy_http_version h2c; но это к сожалению не работает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,266729#msg-266729 From kpoxa на kpoxa.net Tue May 10 12:49:24 2016 From: kpoxa на kpoxa.net (kpoxa) Date: Tue, 10 May 2016 12:49:24 +0000 Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LjQstCw0LXRgiDQu9C4IE5naW54INC/0YDQvtC3?= =?UTF-8?B?0YDQsNGH0L3Ri9C5INC/0YDQvtC60YHQuD8=?= In-Reply-To: <2910372526.20160509232907@sadok.spb.ru> References: <494dadc96604d026fa7c5c89d8353d05.NginxMailingListRussian@forum.nginx.org> <2910372526.20160509232907@sadok.spb.ru> Message-ID: squid точно работает и так и так.. скорее всего и nginx умеет умеет работать в режиме reverse proxy, примерно вот так мне видится конфиг: resolver 127.0.0.1 ; //надо на локалхосте поднять резолвер location { proxy_pass http://$http_host; } пн, 9 мая 2016 г. в 23:29, Dmitry Ivanov : > Здравствуйте, Babaev. > > Вы писали 9 мая 2016 г., 17:33:26: > > > Так ведь reverse proxy и transparent proxy - это разные вещи? Или я > что-то > > не понимаю? > > > Пример может привести, пожалуйста? > > Nginx и squid соответственно. > > -- > С уважением, > Dmitry nginx-ru на sadok.spb.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey на kopeyko.ru Tue May 10 13:05:06 2016 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 10 May 2016 16:05:06 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LjQstCw0LXRgiDQu9C4IE5naW54INC/0YDQvtC3?= =?UTF-8?B?0YDQsNGH0L3Ri9C5INC/0YDQvtC60YHQuD8=?= In-Reply-To: References: <494dadc96604d026fa7c5c89d8353d05.NginxMailingListRussian@forum.nginx.org> <2910372526.20160509232907@sadok.spb.ru> Message-ID: On Tue, 10 May 2016, kpoxa wrote: > squid точно работает и так и так.. скорее всего и nginx умеет умеет > работать в режиме reverse proxy, кроха, Вы напрасно вводите топикстартера в заблуждение - reverse proxy это единственный режим проксирования, в котором nginx умеет работать. Через костыли - таки можно построить "прямой" прокси для пары-тройки фиксированных наперёд сайтов, но в общем случае, для произвольного имени сайта, получаемого от клиента, "прямого прокси" построить нельзя. Потому что nginx не обращает внимания на hostname:port из заголовка GET/HEAD, а смотрит лишь на значение заголовка "Host: ". И напрочь не умеет метод CONNECT. Если вам нужен прямой прокси, да ещё и в прозрачном режиме, вам надо смотреть на - squid - tinyproxy - oops - Apache Traffic Server плюс iptables\pf\ipfw\cisco для заворачивания трафика клиентов на этот прокси. > примерно вот так мне видится конфиг: > resolver 127.0.0.1 ; //надо на локалхосте поднять резолвер > location { > proxy_pass http://$http_host; > } > > пн, 9 мая 2016 г. в 23:29, Dmitry Ivanov : > >> Здравствуйте, Babaev. >> >> Вы писали 9 мая 2016 г., 17:33:26: >> >>> Так ведь reverse proxy и transparent proxy - это разные вещи? Или я >> что-то >>> не понимаю? >> >>> Пример может привести, пожалуйста? >> >> Nginx и squid соответственно. >> >> -- >> С уважением, >> Dmitry nginx-ru на sadok.spb.ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Andrey Kopeyko From vbart на nginx.com Tue May 10 13:23:59 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 10 May 2016 16:23:59 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: <1972203.iF6g4sJg28@vbart-workstation> On Saturday 07 May 2016 10:31:15 S.A.N wrote: > Наш бекенд работает на HTTP/1.1 в режиме Keep-Alive, но в пикоквые нагрузки, > нам приходится держать много открытых конектов. > > Демон асинхронный, но если один запрос выполняется дольше обычного конект > параллельно использовать для других запросов уже не выйдет он просто ждет, > хотелось бы попробовать H2 мультиплексирования, но без SSL он не нужен > внутри датацентра. [..] Также как и h2 внутри датацентра не нужен. Это протокол заточенный под общение браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с относительно высокой задержкой и в условиях крайне ограниченного количества параллельных соединений. Не стоит забивать микроскопы гвоздями. -- Валентин Бартенев From chipitsine на gmail.com Tue May 10 13:57:00 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 10 May 2016 18:57:00 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <1972203.iF6g4sJg28@vbart-workstation> References: <1972203.iF6g4sJg28@vbart-workstation> Message-ID: теоретически, http/2 поддерживает "server push", если вы с nginx проксируете по http/1.1, то никаких push-ей, конечно, не будет. это к тому, что внутри датацентра без http/2 не сделать server push 10 мая 2016 г., 18:23 пользователь Валентин Бартенев написал: > On Saturday 07 May 2016 10:31:15 S.A.N wrote: > > Наш бекенд работает на HTTP/1.1 в режиме Keep-Alive, но в пикоквые > нагрузки, > > нам приходится держать много открытых конектов. > > > > Демон асинхронный, но если один запрос выполняется дольше обычного конект > > параллельно использовать для других запросов уже не выйдет он просто > ждет, > > хотелось бы попробовать H2 мультиплексирования, но без SSL он не нужен > > внутри датацентра. > [..] > > Также как и h2 внутри датацентра не нужен. Это протокол заточенный под > общение > браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с > относительно > высокой задержкой и в условиях крайне ограниченного количества параллельных > соединений. > > Не стоит забивать микроскопы гвоздями. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue May 10 13:59:50 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 10 May 2016 16:59:50 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <1972203.iF6g4sJg28@vbart-workstation> Message-ID: <54184378.4k5y4mAcAY@vbart-workstation> On Tuesday 10 May 2016 18:57:00 Илья Шипицин wrote: > теоретически, http/2 поддерживает "server push", если вы с nginx > проксируете по http/1.1, то никаких push-ей, конечно, не будет. > > это к тому, что внутри датацентра без http/2 не сделать server push > [..] "server push" прекрасно делается, кое-кто уже сделал в nginx: https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ -- Валентин Бартенев From chipitsine на gmail.com Tue May 10 14:03:21 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 10 May 2016 19:03:21 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <54184378.4k5y4mAcAY@vbart-workstation> References: <1972203.iF6g4sJg28@vbart-workstation> <54184378.4k5y4mAcAY@vbart-workstation> Message-ID: прикольно, но это для статики. по инициативе приложения (например, чат или изменение статуса чего-нибудь на странице) так не получится 10 мая 2016 г., 18:59 пользователь Валентин Бартенев написал: > On Tuesday 10 May 2016 18:57:00 Илья Шипицин wrote: > > теоретически, http/2 поддерживает "server push", если вы с nginx > > проксируете по http/1.1, то никаких push-ей, конечно, не будет. > > > > это к тому, что внутри датацентра без http/2 не сделать server push > > > [..] > > "server push" прекрасно делается, кое-кто уже сделал в nginx: > https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue May 10 14:16:34 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 10 May 2016 17:16:34 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <54184378.4k5y4mAcAY@vbart-workstation> Message-ID: <6936438.A9iR6x6Lqn@vbart-workstation> On Tuesday 10 May 2016 19:03:21 Илья Шипицин wrote: > прикольно, но это для статики. > по инициативе приложения (например, чат или изменение статуса чего-нибудь > на странице) так не получится > Так прежде всего server push в h2 вам этого не позволяет. Согласно протоколу, контент который пушится - это всегда добавок к уже полученному запросу от клиента, а не просто некое событие, которое может происходить в случайное время случайным образом. Не нужно путать server push в h2 с web notifications: https://www.w3.org/TR/notifications/ -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue May 10 14:21:49 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 10 May 2016 10:21:49 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <1972203.iF6g4sJg28@vbart-workstation> References: <1972203.iF6g4sJg28@vbart-workstation> Message-ID: > Также как и h2 внутри датацентра не нужен. Это протокол заточенный > под общение > браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с > относительно > высокой задержкой и в условиях крайне ограниченного количества > параллельных > соединений. > > Не стоит забивать микроскопы гвоздями. Если я правильно вас понял, вы считаете что H2 мультиплексирование запросов даст меньший прирост скорсти, из-за суммарного оверхеда самого протокола H2? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266737,266746#msg-266746 From vbart на nginx.com Tue May 10 14:41:04 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 10 May 2016 17:41:04 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <1972203.iF6g4sJg28@vbart-workstation> Message-ID: <5100494.BnvMZ0spko@vbart-workstation> On Tuesday 10 May 2016 10:21:49 S.A.N wrote: > > Также как и h2 внутри датацентра не нужен. Это протокол заточенный > > под общение > > браузера с веб-сервером ради экономии на TLS-хэндшейках по сетям с > > относительно > > высокой задержкой и в условиях крайне ограниченного количества > > параллельных > > соединений. > > > > Не стоит забивать микроскопы гвоздями. > > Если я правильно вас понял, вы считаете что H2 мультиплексирование запросов > даст меньший прирост скорсти, из-за суммарного оверхеда самого протокола H2? > А откуда в вашем случае приросту вообще взяться? Он у вас скорее даст не прирост, а наоборот медленнее станет. Само по себе мультиплексирование не заставляет сигналы быстрее по проводам передаваться, а вот накладных расходов добавляет. -- Валентин Бартенев From chipitsine на gmail.com Tue May 10 15:16:50 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 10 May 2016 20:16:50 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <6936438.A9iR6x6Lqn@vbart-workstation> References: <54184378.4k5y4mAcAY@vbart-workstation> <6936438.A9iR6x6Lqn@vbart-workstation> Message-ID: почитал мат. часть. похоже я зря переживал, действительно это не призвольный контент, который сервер может по своей инициативе отдать клиенту 10 мая 2016 г., 19:16 пользователь Валентин Бартенев написал: > On Tuesday 10 May 2016 19:03:21 Илья Шипицин wrote: > > прикольно, но это для статики. > > по инициативе приложения (например, чат или изменение статуса чего-нибудь > > на странице) так не получится > > > > Так прежде всего server push в h2 вам этого не позволяет. > > Согласно протоколу, контент который пушится - это всегда добавок > к уже полученному запросу от клиента, а не просто некое событие, > которое может происходить в случайное время случайным образом. > > Не нужно путать server push в h2 с web notifications: > https://www.w3.org/TR/notifications/ > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 10 16:03:52 2016 From: nginx-forum на forum.nginx.org (Babaev) Date: Tue, 10 May 2016 12:03:52 -0400 Subject: =?UTF-8?B?0JrQsNC6INC/0LXRgNC10YXQstCw0YLQuNGC0Ywg0L7RgtCy0LXRgiBBcGFjaGUg?= =?UTF-8?B?0LLQvdGD0YLRgNC4IE5naW54Pw==?= Message-ID: Сейчас Nginx перенаправляет все запросы на backend(Apache), как в конфигурации Nginx можно перехватить ответ от Apache? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266762,266762#msg-266762 From annulen на yandex.ru Tue May 10 16:16:12 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Tue, 10 May 2016 19:16:12 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <6936438.A9iR6x6Lqn@vbart-workstation> References: <54184378.4k5y4mAcAY@vbart-workstation> <6936438.A9iR6x6Lqn@vbart-workstation> Message-ID: <667081462896972@web8j.yandex.ru> 10.05.2016, 17:16, "Валентин Бартенев" : > On Tuesday 10 May 2016 19:03:21 Илья Шипицин wrote: >>  прикольно, но это для статики. >>  по инициативе приложения (например, чат или изменение статуса чего-нибудь >>  на странице) так не получится > > Так прежде всего server push в h2 вам этого не позволяет. > > Согласно протоколу, контент который пушится - это всегда добавок > к уже полученному запросу от клиента, а не просто некое событие, > которое может происходить в случайное время случайным образом. > > Не нужно путать server push в h2 с web notifications: > https://www.w3.org/TR/notifications/ Вы имели в виду https://www.w3.org/TR/2011/WD-eventsource-20111020/ и т.п.? Notifications это клиентская сущность, которая вообще никак не относится к HTTP. -- Regards, Konstantin From nginx-forum на forum.nginx.org Tue May 10 16:28:01 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 10 May 2016 12:28:01 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <5100494.BnvMZ0spko@vbart-workstation> References: <5100494.BnvMZ0spko@vbart-workstation> Message-ID: <1c49e4d7514d2a3c8a50ecf71ddf29a5.NginxMailingListRussian@forum.nginx.org> > А откуда в вашем случае приросту вообще взяться? Он у вас скорее даст > не > прирост, а наоборот медленнее станет. > > Само по себе мультиплексирование не заставляет сигналы быстрее по > проводам > передаваться, а вот накладных расходов добавляет. Ну это смотря как считать, если в HTTP 1.1 один конект обрабатывает 100 запросов в 1 сек, то в HTTP 2.0 один конект может обрабатывать 200 запросов в 1 сек, но если вы говорите что там много накладных расходов даже без SSL, тогда наверно быстрей будет 300 запросов в секунду обработать в трех конектах на HTTP 1.1 :) Бекенд из сокета читает и отправляет быстро, сокет чаще ждет чем занимается получением и отправлением данных, по этому я подумал что мультиплексирование будет полезным и не только в скорости, но и в экономии открытых дескрипторов. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266737,266765#msg-266765 From vbart на nginx.com Tue May 10 17:08:57 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 10 May 2016 20:08:57 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <667081462896972@web8j.yandex.ru> References: <6936438.A9iR6x6Lqn@vbart-workstation> <667081462896972@web8j.yandex.ru> Message-ID: <3763980.NfbENg2qt8@vbart-workstation> On Tuesday 10 May 2016 19:16:12 Konstantin Tokarev wrote: > > 10.05.2016, 17:16, "Валентин Бартенев" : > > On Tuesday 10 May 2016 19:03:21 Илья Шипицин wrote: > >> прикольно, но это для статики. > >> по инициативе приложения (например, чат или изменение статуса чего-нибудь > >> на странице) так не получится > > > > Так прежде всего server push в h2 вам этого не позволяет. > > > > Согласно протоколу, контент который пушится - это всегда добавок > > к уже полученному запросу от клиента, а не просто некое событие, > > которое может происходить в случайное время случайным образом. > > > > Не нужно путать server push в h2 с web notifications: > > https://www.w3.org/TR/notifications/ > > Вы имели в виду https://www.w3.org/TR/2011/WD-eventsource-20111020/ и т.п.? > > Notifications это клиентская сущность, которая вообще никак не относится к HTTP. > Ага, промахнулся. -- Валентин Бартенев From vbart на nginx.com Tue May 10 17:21:45 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 10 May 2016 20:21:45 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <1c49e4d7514d2a3c8a50ecf71ddf29a5.NginxMailingListRussian@forum.nginx.org> References: <5100494.BnvMZ0spko@vbart-workstation> <1c49e4d7514d2a3c8a50ecf71ddf29a5.NginxMailingListRussian@forum.nginx.org> Message-ID: <4677116.ZlDiD43GLd@vbart-workstation> On Tuesday 10 May 2016 12:28:01 S.A.N wrote: > > А откуда в вашем случае приросту вообще взяться? Он у вас скорее даст > > не > > прирост, а наоборот медленнее станет. > > > > Само по себе мультиплексирование не заставляет сигналы быстрее по > > проводам > > передаваться, а вот накладных расходов добавляет. > > Ну это смотря как считать, если в HTTP 1.1 один конект обрабатывает 100 > запросов в 1 сек, то в HTTP 2.0 один конект может обрабатывать 200 запросов > в 1 сек, Откуда такая арифметика? > но если вы говорите что там много накладных расходов даже без SSL, > тогда наверно быстрей будет 300 запросов в секунду обработать в трех > конектах на HTTP 1.1 :) > > Бекенд из сокета читает и отправляет быстро, сокет чаще ждет чем занимается > получением и отправлением данных, по этому я подумал что мультиплексирование > будет полезным и не только в скорости, но и в экономии открытых > дескрипторов. > Вы просто перенесете то, что реализовано в ядре операционной системы внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный запрос свой внутренний идентификатор со своими накладными расходами, который точно также будет "простаивать" пока запрос обрабатывается. У вас уже есть мультиплексирование на уровне TCP/IP. HTTP/2 - это коробочка в коробочке. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue May 10 17:32:52 2016 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 10 May 2016 13:32:52 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdGF0LLQsNGC0LjRgtGMINC+0YLQstC10YIgQXBh?= =?UTF-8?B?Y2hlINCy0L3Rg9GC0YDQuCBOZ2lueD8=?= In-Reply-To: References: Message-ID: в смысле как? указать локейшн и завернуть куда надо location ~ ^/pic/ { proxy_pass http://127.0.0.1:9000; proxy_cache pic; # proxy_cache_min_uses 2; proxy_cache_valid 30d; rewrite ^/pic/(.*) /imager.php?params=$1 break; expires 30d; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266762,266768#msg-266768 From nginx-forum на forum.nginx.org Tue May 10 17:40:51 2016 From: nginx-forum на forum.nginx.org (kycedbi) Date: Tue, 10 May 2016 13:40:51 -0400 Subject: =?UTF-8?B?cHJveHkgY2FjaGUg0YEg0LfQsNCz0L7Qu9C+0LLQutC+0LwgUmFuZ2Uu?= Message-ID: Коллеги, здравствуйте. Использую nginx для проксирования и кэширования на диск видео-файлов (mp4) из социальной сети ВКонтакте. Приложение на php узнаёт ссылку на файл на удалённом сервере, определяет где будет хранится файл на диске и отдаёт эту информацию в заголовком Для воспроизведения видео на сайте используется html5-плеер, который, для определения возможности перемотки на ещё не загрузившийся момент, к заголовку запроса добавляет "Range: bytes=0-" и если сервер ответил кодом 206, то даёт возможность делать такую перемотку, если код 200, то такой возможности не предоставляется. Но nginx кэширует ответы только с кодом 200, а 206 с "Range: bytes=0-" нет. В принципе, это хорошо, т.к. неполные файлы в кэше не нужны, но в данном ситуации кэшировать файлы с помощью nginx не представляется возможным (т.к. плеер всегда делает запрос с заголовком Range). Демонстрационный-код + конфиг: https://gist.github.com/anonymous/07a89471f2d2c7a18bda8f0464c3091e Подскажите, пожалуйста, как можно сделать, чтобы nginx таки кэшировал файлы? Мне видятся 2 варианта решения данного вопроса: - из php возвращать код 206 и сделать 2 location, один из которых будет поддерживать заголовок Range, но не будет сохранять файл на диск, а второй будет слать запрос к удалённому серверу без Range и nginx будет сохранять на диск файл; - написать что-то в конфиге nginx, чтобы он заменял код 200 на 206, при наличии заголовка "Range: bytes=0-"; Но как реализовать любой из них - не представляю. P.S. Flash-плеер, который не умеет слать заголовок Range, использовать нет возможности. Благодарю. С уважением. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266769,266769#msg-266769 From nginx-forum на forum.nginx.org Tue May 10 18:17:55 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 10 May 2016 14:17:55 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <4677116.ZlDiD43GLd@vbart-workstation> References: <4677116.ZlDiD43GLd@vbart-workstation> Message-ID: <4a9cef586a9cd610625206501d66a4ef.NginxMailingListRussian@forum.nginx.org> > Откуда такая арифметика? Цифры условные - допустим многопоточный бекенд, имеет 10 потоков, каждый поток может работать со скоростью 1к RPS. Задача получить от одного бекенда 10к RPS На НТТР1.1 нужно как минимум открыть 10 конектов, тогда бекенду очень просто привязать каждый конект к своему отдельному потоку. На НТТР2.0 нужно как минимум открыть 1 конект, но бекенду придется самостоятельно распределять каждый запрос между внутренним пулом потоков. Да, вы меня переубедили, мне уже больше нравится НТТР1.1, без мультиплексирования :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266737,266770#msg-266770 From nginx-forum на forum.nginx.org Tue May 10 20:09:33 2016 From: nginx-forum на forum.nginx.org (Babaev) Date: Tue, 10 May 2016 16:09:33 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdGF0LLQsNGC0LjRgtGMINC+0YLQstC10YIgQXBh?= =?UTF-8?B?Y2hlINCy0L3Rg9GC0YDQuCBOZ2lueD8=?= In-Reply-To: References: Message-ID: <8a268811cb615b875a50d233c9aae11d.NginxMailingListRussian@forum.nginx.org> я имею ввиду как получить контент возвращаемый внутри nginx от apache? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266762,266772#msg-266772 From nginx-forum на forum.nginx.org Wed May 11 00:09:07 2016 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Tue, 10 May 2016 20:09:07 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdGF0LLQsNGC0LjRgtGMINC+0YLQstC10YIgQXBh?= =?UTF-8?B?Y2hlINCy0L3Rg9GC0YDQuCBOZ2lueD8=?= In-Reply-To: <8a268811cb615b875a50d233c9aae11d.NginxMailingListRussian@forum.nginx.org> References: <8a268811cb615b875a50d233c9aae11d.NginxMailingListRussian@forum.nginx.org> Message-ID: <76c2ecda600d8d9a2945ff9a0c8ef861.NginxMailingListRussian@forum.nginx.org> не понял вопроса - лучше описать ситуацию Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266762,266792#msg-266792 From myc на cname.me Wed May 11 09:16:20 2016 From: myc на cname.me (Eugene Mychlo) Date: Wed, 11 May 2016 12:16:20 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINGBINC30LDQs9C+0LvQvtCy0LrQvtC8IFJhbmdlLg==?= In-Reply-To: References: Message-ID: <38E40C12-40EF-4679-ABE0-B4B4353605AA@cname.me> Используете slice модуль. Он для этого и писан. > 10 мая 2016 г., в 20:40, kycedbi написал(а): > > Коллеги, здравствуйте. > Использую nginx для проксирования и кэширования на диск видео-файлов (mp4) > из социальной сети ВКонтакте. > Приложение на php узнаёт ссылку на файл на удалённом сервере, определяет где > будет хранится файл на диске и отдаёт эту информацию в заголовком > Для воспроизведения видео на сайте используется html5-плеер, который, для > определения возможности перемотки на ещё не загрузившийся момент, к > заголовку запроса добавляет "Range: bytes=0-" и если сервер ответил кодом > 206, то даёт возможность делать такую перемотку, если код 200, то такой > возможности не предоставляется. > Но nginx кэширует ответы только с кодом 200, а 206 с "Range: bytes=0-" нет. > В принципе, это хорошо, т.к. неполные файлы в кэше не нужны, но в данном > ситуации кэшировать файлы с помощью nginx не представляется возможным (т.к. > плеер всегда делает запрос с заголовком Range). > > Демонстрационный-код + конфиг: > https://gist.github.com/anonymous/07a89471f2d2c7a18bda8f0464c3091e > > Подскажите, пожалуйста, как можно сделать, чтобы nginx таки кэшировал > файлы? > Мне видятся 2 варианта решения данного вопроса: > - из php возвращать код 206 и сделать 2 location, один из которых будет > поддерживать заголовок Range, но не будет сохранять файл на диск, а второй > будет слать запрос к удалённому серверу без Range и nginx будет сохранять на > диск файл; > - написать что-то в конфиге nginx, чтобы он заменял код 200 на 206, при > наличии заголовка "Range: bytes=0-"; > Но как реализовать любой из них - не представляю. > > P.S. Flash-плеер, который не умеет слать заголовок Range, использовать нет > возможности. > > Благодарю. > С уважением. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266769,266769#msg-266769 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From nginx-forum на forum.nginx.org Wed May 11 10:39:59 2016 From: nginx-forum на forum.nginx.org (milex) Date: Wed, 11 May 2016 06:39:59 -0400 Subject: TLS client certificate caching Message-ID: Добрый день, коллеги! Провожу нагрузочное тестирование абстрактного сервера на базе Nginx+OpenSSL с помощью JMeter. На сервере выполняется проверка клиентского сертификата (двусторонняя аутентификация). Со стороны JMeter создан контейнер с сертификатом клиента. Во время теста генерируются сотни запросов в секунду. Каждый запрос осуществляется в рамках новой TLS сессии, но с одним и тем же сертификатом клиента. Собственно вопрос. Есть ли у Nginx какой либо механизм кеширования одинаковых клиентских сертификатов (например, по SN и не измененному CRL, etc.)? Или в рамках каждой сессии (даже очень часто устанавливаемых) один и тот же сертификат клиента проходит полноценную проверку по сертификату CA и CRL? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266798,266798#msg-266798 From mdounin на mdounin.ru Wed May 11 10:51:22 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 11 May 2016 13:51:22 +0300 Subject: TLS client certificate caching In-Reply-To: References: Message-ID: <20160511105122.GN36620@mdounin.ru> Hello! On Wed, May 11, 2016 at 06:39:59AM -0400, milex wrote: > Добрый день, коллеги! > > Провожу нагрузочное тестирование абстрактного сервера на базе Nginx+OpenSSL > с помощью JMeter. На сервере выполняется проверка клиентского сертификата > (двусторонняя аутентификация). Со стороны JMeter создан контейнер с > сертификатом клиента. Во время теста генерируются сотни запросов в секунду. > Каждый запрос осуществляется в рамках новой TLS сессии, но с одним и тем же > сертификатом клиента. > Собственно вопрос. Есть ли у Nginx какой либо механизм кеширования > одинаковых клиентских сертификатов (например, по SN и не измененному CRL, > etc.)? Или в рамках каждой сессии (даже очень часто устанавливаемых) один и > тот же сертификат клиента проходит полноценную проверку по сертификату CA и > CRL? Стандартный механизм кеширования - SSL сессии (которые, в свою очередь, могут хранится как на сервере в рамках ssl_session_cache, так и на клиенте в рамках session tickets). Других механизмов нет, соответственно каждый раз при создании новой сессии клиентский сертификат будет проверяться. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Wed May 11 11:10:45 2016 From: nginx-forum на forum.nginx.org (milex) Date: Wed, 11 May 2016 07:10:45 -0400 Subject: TLS client certificate caching In-Reply-To: <20160511105122.GN36620@mdounin.ru> References: <20160511105122.GN36620@mdounin.ru> Message-ID: Благодарю, исчерпывающе. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266798,266801#msg-266801 From nginx-forum на forum.nginx.org Wed May 11 11:29:16 2016 From: nginx-forum на forum.nginx.org (AterCattus) Date: Wed, 11 May 2016 07:29:16 -0400 Subject: =?UTF-8?B?0JTQu9GPIEhUVFAvMiBuZ2lueCDQvdC1INC/0YDQuNGB0YvQu9Cw0LXRgiBVUERB?= =?UTF-8?B?VEUgV0lORE9X?= Message-ID: Доброго времени суток. Пробую на nginx 1.9.15 использовать http/2, но выходит, что nginx не присылает обновления окна для flow control. При установке соединения приходит обновление на 2147418112 октетов (плюс исходные 65535, что дает максимум) и все, больше ничего. И после отправки 2ГБ payload в DATA фреймах клиент уже не особо может использовать соединение. Использовать его можно (уходя в минус), но как-то это не правильно. Что с этим можно сделать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266804,266804#msg-266804 From vbart на nginx.com Wed May 11 13:45:28 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 11 May 2016 16:45:28 +0300 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: References: Message-ID: <1908222.7pp6qJ6Zq9@vbart-workstation> On Wednesday 11 May 2016 07:29:16 AterCattus wrote: > Доброго времени суток. > > Пробую на nginx 1.9.15 использовать http/2, но выходит, что nginx не > присылает обновления окна для flow control. > При установке соединения приходит обновление на 2147418112 октетов (плюс > исходные 65535, что дает максимум) и все, больше ничего. > И после отправки 2ГБ payload в DATA фреймах клиент уже не особо может > использовать соединение. Использовать его можно (уходя в минус), но как-то > это не правильно. > > Что с этим можно сделать? > Ответ от nginx уже получен? -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 11 13:55:40 2016 From: nginx-forum на forum.nginx.org (AterCattus) Date: Wed, 11 May 2016 09:55:40 -0400 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <1908222.7pp6qJ6Zq9@vbart-workstation> References: <1908222.7pp6qJ6Zq9@vbart-workstation> Message-ID: <1e274d31eff8087489a43d6ae9243fd6.NginxMailingListRussian@forum.nginx.org> Да, конечно. За эти 2ГБ полезной нагрузки успевает выполнится пачка последовательных запросов (т.е. nginx присылает все соответствующие HEADERS и DATA фреймы). Не говоря уже про обмен SETTINGS. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266812,266814#msg-266814 From vbart на nginx.com Wed May 11 14:02:52 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 11 May 2016 17:02:52 +0300 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <1e274d31eff8087489a43d6ae9243fd6.NginxMailingListRussian@forum.nginx.org> References: <1908222.7pp6qJ6Zq9@vbart-workstation> <1e274d31eff8087489a43d6ae9243fd6.NginxMailingListRussian@forum.nginx.org> Message-ID: <1625231.V8P5qz1QJn@vbart-workstation> On Wednesday 11 May 2016 09:55:40 AterCattus wrote: > Да, конечно. За эти 2ГБ полезной нагрузки успевает выполнится пачка > последовательных запросов (т.е. nginx присылает все соответствующие HEADERS > и DATA фреймы). Не говоря уже про обмен SETTINGS. > [..] Так пришлось сделать из-за славного браузера Chrome, подробности: http://hg.nginx.org/nginx/rev/8df664ebe037 На самом деле не только Chrome этим грешит, но и MS IE/Edge, Safari. У вас какой-то свой клиент? -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 11 14:06:58 2016 From: nginx-forum на forum.nginx.org (AterCattus) Date: Wed, 11 May 2016 10:06:58 -0400 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <1625231.V8P5qz1QJn@vbart-workstation> References: <1625231.V8P5qz1QJn@vbart-workstation> Message-ID: <802e10feab41d63607d9d6b09f75d1c8.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Wednesday 11 May 2016 09:55:40 AterCattus wrote: > > Да, конечно. За эти 2ГБ полезной нагрузки успевает выполнится пачка > > последовательных запросов (т.е. nginx присылает все соответствующие > HEADERS > > и DATA фреймы). Не говоря уже про обмен SETTINGS. > > > [..] > > Так пришлось сделать из-за славного браузера Chrome, подробности: > http://hg.nginx.org/nginx/rev/8df664ebe037 > > На самом деле не только Chrome этим грешит, но и MS IE/Edge, Safari. > > У вас какой-то свой клиент? > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Да, я видел фикс для (RST_STREAM, NO_ERROR). Надеялся, что хоть по превышению 2Г nginx отдаст еще 2Г в window_update, но нет. Выходит, единственное решение - это по истечению окна переподключаться? Клиент свой самописный, да. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266812,266818#msg-266818 From vbart на nginx.com Wed May 11 14:12:06 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 11 May 2016 17:12:06 +0300 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <802e10feab41d63607d9d6b09f75d1c8.NginxMailingListRussian@forum.nginx.org> References: <1625231.V8P5qz1QJn@vbart-workstation> <802e10feab41d63607d9d6b09f75d1c8.NginxMailingListRussian@forum.nginx.org> Message-ID: <2816723.bSlP1TpoNk@vbart-workstation> On Wednesday 11 May 2016 10:06:58 AterCattus wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Wednesday 11 May 2016 09:55:40 AterCattus wrote: > > > Да, конечно. За эти 2ГБ полезной нагрузки успевает выполнится пачка > > > последовательных запросов (т.е. nginx присылает все соответствующие > > HEADERS > > > и DATA фреймы). Не говоря уже про обмен SETTINGS. > > > > > [..] > > > > Так пришлось сделать из-за славного браузера Chrome, подробности: > > http://hg.nginx.org/nginx/rev/8df664ebe037 > > > > На самом деле не только Chrome этим грешит, но и MS IE/Edge, Safari. > > > > У вас какой-то свой клиент? > > > > -- > > Валентин Бартенев > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Да, я видел фикс для (RST_STREAM, NO_ERROR). Надеялся, что хоть по > превышению 2Г nginx отдаст еще 2Г в window_update, но нет. > Выходит, единственное решение - это по истечению окна переподключаться? > > Клиент свой самописный, да. > Уточню, речь идет ведь об окне на stream? Или на соединение? Окно на соединение сейчас всегда поддерживается максимальным и window_update на него должны ходить по условию: if (h2c->recv_window < NGX_HTTP_V2_MAX_WINDOW / 4) { if (ngx_http_v2_send_window_update(h2c, 0, NGX_HTTP_V2_MAX_WINDOW - h2c->recv_window) == NGX_ERROR) { return ngx_http_v2_connection_error(h2c, NGX_HTTP_V2_INTERNAL_ERROR); } h2c->recv_window = NGX_HTTP_V2_MAX_WINDOW; } -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 11 14:13:01 2016 From: nginx-forum на forum.nginx.org (AterCattus) Date: Wed, 11 May 2016 10:13:01 -0400 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <802e10feab41d63607d9d6b09f75d1c8.NginxMailingListRussian@forum.nginx.org> References: <1625231.V8P5qz1QJn@vbart-workstation> <802e10feab41d63607d9d6b09f75d1c8.NginxMailingListRussian@forum.nginx.org> Message-ID: <19a3dd53e3754d1d8311b97ea540e543.NginxMailingListRussian@forum.nginx.org> AterCattus Wrote: ------------------------------------------------------- > Валентин Бартенев Wrote: > ------------------------------------------------------- > > On Wednesday 11 May 2016 09:55:40 AterCattus wrote: > > > Да, конечно. За эти 2ГБ полезной нагрузки успевает выполнится > пачка > > > последовательных запросов (т.е. nginx присылает все > соответствующие > > HEADERS > > > и DATA фреймы). Не говоря уже про обмен SETTINGS. > > > > > [..] > > > > Так пришлось сделать из-за славного браузера Chrome, подробности: > > http://hg.nginx.org/nginx/rev/8df664ebe037 > > > > На самом деле не только Chrome этим грешит, но и MS IE/Edge, > Safari. > > > > У вас какой-то свой клиент? > > > > -- > > Валентин Бартенев > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Да, я видел фикс для (RST_STREAM, NO_ERROR). Надеялся, что хоть по > превышению 2Г nginx отдаст еще 2Г в window_update, но нет. > Выходит, единственное решение - это по истечению окна > переподключаться? > > Клиент свой самописный, да. Да и, честно говоря, не понятно как RST_STREAM, отсылаемый для прерывания отправки запроса, влияет на отправку WINDOW_UPDATE после получения DATA? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266812,266820#msg-266820 From vbart на nginx.com Wed May 11 14:32:26 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 11 May 2016 17:32:26 +0300 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <19a3dd53e3754d1d8311b97ea540e543.NginxMailingListRussian@forum.nginx.org> References: <1625231.V8P5qz1QJn@vbart-workstation> <802e10feab41d63607d9d6b09f75d1c8.NginxMailingListRussian@forum.nginx.org> <19a3dd53e3754d1d8311b97ea540e543.NginxMailingListRussian@forum.nginx.org> Message-ID: <4011464.97gT5o9epL@vbart-workstation> On Wednesday 11 May 2016 10:13:01 AterCattus wrote: > AterCattus Wrote: > > > > Да, я видел фикс для (RST_STREAM, NO_ERROR). Надеялся, что хоть по > > превышению 2Г nginx отдаст еще 2Г в window_update, но нет. > > Выходит, единственное решение - это по истечению окна > > переподключаться? > > > > Клиент свой самописный, да. > > Да и, честно говоря, не понятно как RST_STREAM, отсылаемый для прерывания > отправки запроса, влияет на отправку WINDOW_UPDATE после получения DATA? > [..] Если речь идет все же об окне конкретного запроса, на который nginx уже ответил и забыл, то поддерживать окно для таких запросов не представляется возможным. Если речь про окно на соединение, то оно поддерживается на уровне максимума, путем отправки window_update при исчерпании его на 3/4. В случае, если последнего не наблюдается, то присылайте дебаг-лог, будем разбираться. -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 11 14:32:41 2016 From: nginx-forum на forum.nginx.org (AterCattus) Date: Wed, 11 May 2016 10:32:41 -0400 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <2816723.bSlP1TpoNk@vbart-workstation> References: <2816723.bSlP1TpoNk@vbart-workstation> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > On Wednesday 11 May 2016 10:06:58 AterCattus wrote: > > Валентин Бартенев Wrote: > > ------------------------------------------------------- > > > On Wednesday 11 May 2016 09:55:40 AterCattus wrote: > > > > Да, конечно. За эти 2ГБ полезной нагрузки успевает выполнится > пачка > > > > последовательных запросов (т.е. nginx присылает все > соответствующие > > > HEADERS > > > > и DATA фреймы). Не говоря уже про обмен SETTINGS. > > > > > > > [..] > > > > > > Так пришлось сделать из-за славного браузера Chrome, подробности: > > > http://hg.nginx.org/nginx/rev/8df664ebe037 > > > > > > На самом деле не только Chrome этим грешит, но и MS IE/Edge, > Safari. > > > > > > У вас какой-то свой клиент? > > > > > > -- > > > Валентин Бартенев > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Да, я видел фикс для (RST_STREAM, NO_ERROR). Надеялся, что хоть по > > превышению 2Г nginx отдаст еще 2Г в window_update, но нет. > > Выходит, единственное решение - это по истечению окна > переподключаться? > > > > Клиент свой самописный, да. > > > > Уточню, речь идет ведь об окне на stream? Или на соединение? > > Окно на соединение сейчас всегда поддерживается максимальным > и window_update на него должны ходить по условию: > > if (h2c->recv_window < NGX_HTTP_V2_MAX_WINDOW / 4) { > > if (ngx_http_v2_send_window_update(h2c, 0, > NGX_HTTP_V2_MAX_WINDOW > - h2c->recv_window) > == NGX_ERROR) > { > return ngx_http_v2_connection_error(h2c, > > NGX_HTTP_V2_INTERNAL_ERROR); > } > > h2c->recv_window = NGX_HTTP_V2_MAX_WINDOW; > } > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Речь про окно на соединение. Я не тестил на стримах в 2ГБ (только стримы на несколько мегабайт с суммарным трафиком на соединение в 2-3ГБ), хотя сделаю сейчас для полноты картины. Проблема в том, что UPDATE_WINDOW вообще больше никакой не присылается после первоначального обмена фреймами. Тест на 2ГБ занимает десятки секунд, flow window соединения за это время уходит в минус, но nginx не присылает обновления окна. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266812,266824#msg-266824 From vbart на nginx.com Wed May 11 14:37:55 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 11 May 2016 17:37:55 +0300 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: References: <2816723.bSlP1TpoNk@vbart-workstation> Message-ID: <2035221.TyggoKQai3@vbart-workstation> On Wednesday 11 May 2016 10:32:41 AterCattus wrote: [..] > > Речь про окно на соединение. Я не тестил на стримах в 2ГБ (только стримы на > несколько мегабайт с суммарным трафиком на соединение в 2-3ГБ), хотя сделаю > сейчас для полноты картины. > > Проблема в том, что UPDATE_WINDOW вообще больше никакой не присылается после > первоначального обмена фреймами. Тест на 2ГБ занимает десятки секунд, flow > window соединения за это время уходит в минус, но nginx не присылает > обновления окна. > Так не должно быть. В таком случае хотелось бы увидеть дебаг-лог: http://nginx.org/ru/docs/debugging_log.html Отдельно замечу, что nginx не допустит превышения окна соединения и в этом случае вернет GO_AWAY и закроет соединение. Если этого не происходит, то значит с его точки зрения окно не было превышено (в том числе потому, что window_update таки был отправлен). -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 11 14:50:37 2016 From: nginx-forum на forum.nginx.org (AterCattus) Date: Wed, 11 May 2016 10:50:37 -0400 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: <2035221.TyggoKQai3@vbart-workstation> References: <2035221.TyggoKQai3@vbart-workstation> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > On Wednesday 11 May 2016 10:32:41 AterCattus wrote: > [..] > > > > Речь про окно на соединение. Я не тестил на стримах в 2ГБ (только > стримы на > > несколько мегабайт с суммарным трафиком на соединение в 2-3ГБ), хотя > сделаю > > сейчас для полноты картины. > > > > Проблема в том, что UPDATE_WINDOW вообще больше никакой не > присылается после > > первоначального обмена фреймами. Тест на 2ГБ занимает десятки > секунд, flow > > window соединения за это время уходит в минус, но nginx не присылает > > обновления окна. > > > > Так не должно быть. > > В таком случае хотелось бы увидеть дебаг-лог: > http://nginx.org/ru/docs/debugging_log.html > > Отдельно замечу, что nginx не допустит превышения окна соединения и в > этом > случае вернет GO_AWAY и закроет соединение. Если этого не происходит, > то > значит с его точки зрения окно не было превышено (в том числе потому, > что > window_update таки был отправлен). > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Клиентская сторона свои WINDOW_UPDATE присылает: http2 WINDOW_UPDATE frame sid:0 window:16383 http2 WINDOW_UPDATE frame sid:137 window:16383 Со стороны сервера нет в логах про "http2 send WINDOW_UPDATE frame sid:%ui, window:%uz" кроме первоначального: http2 send WINDOW_UPDATE frame sid:0, window:2147418112 Есть debug лог до момента получения flow window на соединение в -121032660 октетов. Могу выложить куда-нибудь. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266812,266830#msg-266830 From vbart на nginx.com Wed May 11 15:04:11 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 11 May 2016 18:04:11 +0300 Subject: =?UTF-8?B?UmU6INCU0LvRjyBIVFRQLzIgbmdpbngg0L3QtSDQv9GA0LjRgdGL0LvQsNC10YIg?= =?UTF-8?B?VVBEQVRFIFdJTkRPVw==?= In-Reply-To: References: <2035221.TyggoKQai3@vbart-workstation> Message-ID: <3218646.eZ9gdCxTkq@vbart-workstation> On Wednesday 11 May 2016 10:50:37 AterCattus wrote: > Валентин Бартенев Wrote: > > Так не должно быть. > > > > В таком случае хотелось бы увидеть дебаг-лог: > > http://nginx.org/ru/docs/debugging_log.html > > > > Отдельно замечу, что nginx не допустит превышения окна соединения и в > > этом > > случае вернет GO_AWAY и закроет соединение. Если этого не происходит, > > то > > значит с его точки зрения окно не было превышено (в том числе потому, > > что > > window_update таки был отправлен). > > > > > Клиентская сторона свои WINDOW_UPDATE присылает: > http2 WINDOW_UPDATE frame sid:0 window:16383 > http2 WINDOW_UPDATE frame sid:137 window:16383 > > Со стороны сервера нет в логах про "http2 send WINDOW_UPDATE frame sid:%ui, > window:%uz" кроме первоначального: > http2 send WINDOW_UPDATE frame sid:0, window:2147418112 > > Есть debug лог до момента получения flow window на соединение в -121032660 > октетов. Могу выложить куда-нибудь. > Да, покажите. Можно выложить на тот же яндекс.диск например. -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 11 15:17:05 2016 From: nginx-forum на forum.nginx.org (Babaev) Date: Wed, 11 May 2016 11:17:05 -0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdGF0LLQsNGC0LjRgtGMINC+0YLQstC10YIgQXBh?= =?UTF-8?B?Y2hlINCy0L3Rg9GC0YDQuCBOZ2lueD8=?= In-Reply-To: <76c2ecda600d8d9a2945ff9a0c8ef861.NginxMailingListRussian@forum.nginx.org> References: <8a268811cb615b875a50d233c9aae11d.NginxMailingListRussian@forum.nginx.org> <76c2ecda600d8d9a2945ff9a0c8ef861.NginxMailingListRussian@forum.nginx.org> Message-ID: <8f8f4a61d09ef10495a150946e2ca0f7.NginxMailingListRussian@forum.nginx.org> Если взять конфигурацию nginx, то в разделе location есть директива proxy_pass с адресом IP, по которому сидит Apache. После этой строчки как я понимаю - я могу получить тело ответа от Apache. Здесь и нужно перехватить ответ и его модифицировать. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266762,266834#msg-266834 From chipitsine на gmail.com Wed May 11 17:48:58 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 11 May 2016 22:48:58 +0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdGF0LLQsNGC0LjRgtGMINC+0YLQstC10YIgQXBh?= =?UTF-8?B?Y2hlINCy0L3Rg9GC0YDQuCBOZ2lueD8=?= In-Reply-To: <8f8f4a61d09ef10495a150946e2ca0f7.NginxMailingListRussian@forum.nginx.org> References: <8a268811cb615b875a50d233c9aae11d.NginxMailingListRussian@forum.nginx.org> <76c2ecda600d8d9a2945ff9a0c8ef861.NginxMailingListRussian@forum.nginx.org> <8f8f4a61d09ef10495a150946e2ca0f7.NginxMailingListRussian@forum.nginx.org> Message-ID: каким образом вы хотите модифицировать ответ ? статус ? тело ? хедеры? есть пример? 11 мая 2016 г., 20:17 пользователь Babaev написал: > Если взять конфигурацию nginx, то в разделе location есть директива > proxy_pass с адресом IP, по которому сидит Apache. > После этой строчки как я понимаю - я могу получить тело ответа от Apache. > Здесь и нужно перехватить ответ и его модифицировать. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266762,266834#msg-266834 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu May 12 07:11:27 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 12 May 2016 12:11:27 +0500 Subject: =?UTF-8?B?0L7RgtC70LDQtNC+0YfQvdCw0Y8g0LjQvdGE0L7RgNC80LDRhtC40Y8g0L3QsCBI?= =?UTF-8?B?VFRQLzI=?= Message-ID: Добрый день! nginx-1.9.15, включил отладку, в лог посыпалось вот такое 2016/05/12 10:09:09 [info] 4887#0: *83822012 client sent stream with data before settings were acknowledged while processing HTTP/2 connection, client: X.X.X.X, server: X.X.X.X:443 это какая-то известная штука ? Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu May 12 10:02:50 2016 From: nginx-forum на forum.nginx.org (kycedbi) Date: Thu, 12 May 2016 06:02:50 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINGBINC30LDQs9C+0LvQvtCy0LrQvtC8IFJhbmdlLg==?= In-Reply-To: References: Message-ID: <1a58339fab3a5865ab1822fcd40e7a51.NginxMailingListRussian@forum.nginx.org> Ребята, вопрос не очень понятен, или решения нету? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266769,266860#msg-266860 From nginx-forum на forum.nginx.org Thu May 12 10:19:08 2016 From: nginx-forum на forum.nginx.org (Eugene Mychlo) Date: Thu, 12 May 2016 06:19:08 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGNhY2hlINGBINC30LDQs9C+0LvQvtCy0LrQvtC8IFJhbmdlLg==?= In-Reply-To: References: Message-ID: см. https://forum.nginx.org/read.php?21,266797,266797 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266769,266863#msg-266863 From mdounin на mdounin.ru Thu May 12 11:56:08 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 12 May 2016 14:56:08 +0300 Subject: =?UTF-8?B?UmU6INC+0YLQu9Cw0LTQvtGH0L3QsNGPINC40L3RhNC+0YDQvNCw0YbQuNGPINC9?= =?UTF-8?B?0LAgSFRUUC8y?= In-Reply-To: References: Message-ID: <20160512115608.GS36620@mdounin.ru> Hello! On Thu, May 12, 2016 at 12:11:27PM +0500, Илья Шипицин wrote: > Добрый день! > > nginx-1.9.15, включил отладку, в лог посыпалось вот такое > > 2016/05/12 10:09:09 [info] 4887#0: *83822012 client sent stream with data > before settings were acknowledged while processing HTTP/2 connection, > client: X.X.X.X, server: X.X.X.X:443 > > > это какая-то известная штука ? Такое сообщение логгируется, если клиент попытался прислать POST в первом запросе по HTTP/2, до того, как подтвердил получение SETTINGS. В этом случае nginx отклоняет stream, предлагая его прислать позже. Поскольку событие не совсем low-level, и у некоторых HTTP/2-клиентов проблемы с его обработкой - этот факт логгируется. Подробнее можно почитать тут и по ссылкам: https://trac.nginx.org/nginx/ticket/959 -- Maxim Dounin http://nginx.org/ From morozov.g.o на gmail.com Thu May 12 12:58:13 2016 From: morozov.g.o на gmail.com (=?UTF-8?B?0JPQu9C10LEg0JzQvtGA0L7Qt9C+0LI=?=) Date: Thu, 12 May 2016 15:58:13 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9C10YDQtdGF0LLQsNGC0LjRgtGMINC+0YLQstC10YIgQXBh?= =?UTF-8?B?Y2hlINCy0L3Rg9GC0YDQuCBOZ2lueD8=?= In-Reply-To: References: <8a268811cb615b875a50d233c9aae11d.NginxMailingListRussian@forum.nginx.org> <76c2ecda600d8d9a2945ff9a0c8ef861.NginxMailingListRussian@forum.nginx.org> <8f8f4a61d09ef10495a150946e2ca0f7.NginxMailingListRussian@forum.nginx.org> Message-ID: Возможно вам поможет ngx_http_sub_module для модификации ответа - http://nginx.org/en/docs/http/ngx_http_sub_module.html 2016-05-11 20:48 GMT+03:00 Илья Шипицин : > каким образом вы хотите модифицировать ответ ? > > статус ? тело ? хедеры? > > есть пример? > > 11 мая 2016 г., 20:17 пользователь Babaev > написал: > > Если взять конфигурацию nginx, то в разделе location есть директива >> proxy_pass с адресом IP, по которому сидит Apache. >> После этой строчки как я понимаю - я могу получить тело ответа от Apache. >> Здесь и нужно перехватить ответ и его модифицировать. >> >> Posted at Nginx Forum: >> https://forum.nginx.org/read.php?21,266762,266834#msg-266834 >> >> _______________________________________________ >> 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 > -- -------- C уважением, Глеб Морозов ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri May 13 13:33:28 2016 From: nginx-forum на forum.nginx.org (grey) Date: Fri, 13 May 2016 09:33:28 -0400 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgdC60L7QvNC/0LjQu9C40YDQvtCy0LDRgtGMIG5n?= =?UTF-8?B?aW54INC/0L7QtCBXaW5kb3dz?= Message-ID: Здравствуйте! Возникла необходимость работы nginx'a с модулем geoip под Windows. Нашел инструкцию "Building nginx on the Win32 platform with Visual C", скачал и установил все программы, но ничего толком не получается, да и наверно не может получиться, т.к. никогда этого не делал. Может кто-то может собрать поделиться готовым exe'шником с модулем geoip? Заранее спасибо! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266886,266886#msg-266886 From sokol на zavolga.net Sun May 15 22:47:12 2016 From: sokol на zavolga.net (Sergey V. Sokolov) Date: Mon, 16 May 2016 01:47:12 +0300 Subject: =?UTF-8?B?0KHQvtC/0L7RgdGC0LDQstC70LXQvdC40LUgJHF1ZXJ5X3N0cmluZyDRgdC+INGB?= =?UTF-8?B?0YLRgNC+0LrQvtC5INGB0L7QtNC10YDQttCw0YnQtdC5ICIkIg==?= Message-ID: <3468051463352432@web26g.yandex.ru> Есть такой кусочек в конфигурации: if ($query_string = 'p=anyquery$') { return 403; } nginx естественно и вполне законно ругается при старте так: invalid variable name in /path/to/config:1413 Вопрос. Как правильно выполнить данную операцию? Возможно символ "$" может как то экранироваться, чтобы nginx не воспринимал это как переменную? -- С уважением, Сергей Соколов From cnst++ на FreeBSD.org Sun May 15 23:42:55 2016 From: cnst++ на FreeBSD.org (Constantine A. Murenin) Date: Sun, 15 May 2016 16:42:55 -0700 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <3468051463352432@web26g.yandex.ru> References: <3468051463352432@web26g.yandex.ru> Message-ID: 2016-05-15 15:47 GMT-07:00 Sergey V. Sokolov : > Есть такой кусочек в конфигурации: > if ($query_string = 'p=anyquery$') { return 403; } > > nginx естественно и вполне законно ругается при старте так: > invalid variable name in /path/to/config:1413 > > Вопрос. Как правильно выполнить данную операцию? > Возможно символ "$" может как то экранироваться, чтобы nginx не воспринимал это как переменную? Вроде для этого http://nginx.org/r/geo рекомендуют. geo $eosdollar { default "$"; } ... if ($query_string = 'p=anyquery$eosdollar') { return 403; } :-) -- Константин http://Constantine.SU/ From nginx на kinetiksoft.com Sun May 15 23:56:59 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Mon, 16 May 2016 02:56:59 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <3468051463352432@web26g.yandex.ru> References: <3468051463352432@web26g.yandex.ru> Message-ID: <4002647.2lfeSIBV1g@cybernote> В письме от 16 мая 2016 01:47:12 пользователь Sergey V. Sokolov написал: > $query_string Здравствуйте! Наиболее правильно map $arg_p $block { 'anyqwery$' 1; } if ($block) { return 403; } С уважением, Иван. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sokol на zavolga.net Mon May 16 11:02:57 2016 From: sokol на zavolga.net (Sergey V. Sokolov) Date: Mon, 16 May 2016 14:02:57 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: References: <3468051463352432@web26g.yandex.ru> Message-ID: <10216771463396577@web10o.yandex.ru> А как быть, если символ "$" не в конце строки. Переменные в строках можно как-то выделить? Например как в PHP "text{$variable}text"? 16.05.2016, 02:43, "Constantine A. Murenin" : > 2016-05-15 15:47 GMT-07:00 Sergey V. Sokolov : >>  Есть такой кусочек в конфигурации: >>  if ($query_string = 'p=anyquery$') { return 403; } >> >>  nginx естественно и вполне законно ругается при старте так: >>  invalid variable name in /path/to/config:1413 >> >>  Вопрос. Как правильно выполнить данную операцию? >>  Возможно символ "$" может как то экранироваться, чтобы nginx не воспринимал это как переменную? > > Вроде для этого http://nginx.org/r/geo рекомендуют. > > geo $eosdollar { >     default "$"; > } > > ... > >     if ($query_string = 'p=anyquery$eosdollar') { return 403; } > > :-) > > -- >   Константин >   http://Constantine.SU/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Сергей Соколов Заместитель директора Zavolga.Net (ООО "Горизонт"), г. Ярославль Тел.: +7 4852 333-402 Сайт: http://zavolga.net Руководитель проекта Региональный Интернет Дневник Сайт: http://dnevnik76.ru  Руководитель проекта Ярославский Internet Exchange (YAR-IX) Сайт: http://yar-ix.net nic-hdl: SVS141-RIPE X-NCC-RegID: ru.gorizont From sokol на zavolga.net Mon May 16 11:05:52 2016 From: sokol на zavolga.net (Sergey V. Sokolov) Date: Mon, 16 May 2016 14:05:52 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <4002647.2lfeSIBV1g@cybernote> References: <3468051463352432@web26g.yandex.ru> <4002647.2lfeSIBV1g@cybernote> Message-ID: <15051463396752@web10o.yandex.ru> Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Mon May 16 11:07:25 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Mon, 16 May 2016 14:07:25 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <15051463396752@web10o.yandex.ru> References: <3468051463352432@web26g.yandex.ru> <4002647.2lfeSIBV1g@cybernote> <15051463396752@web10o.yandex.ru> Message-ID: <1579652.XXvDYMCNEz@cybernote> Мне кажется, что нет, не правильно понимаете. Опишите конкретнее, что хотите получить, пожалуйста. В письме от 16 мая 2016 14:05:52 пользователь Sergey V. Sokolov написал: > Я правильно понимаю, что на каждую такую операцию сравнения, будет две > директивы в конфиге map и if? Получается в две операции. Короче можно? > 16.05.2016, 02:57, "Иван" : > > В письме от 16 мая 2016 01:47:12 пользователь Sergey V. Sokolov написал: > > $query_string > > > Здравствуйте! > > Наиболее правильно > map $arg_p $block { > 'anyqwery$' 1; > } > > if ($block) { > return 403; > } > > С уважением, Иван. > , > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > С уважением, Сергей Соколов > Заместитель директора > Zavolga.Net (ООО "Горизонт"), г. Ярославль > Тел.: +7 4852 333-402 > Сайт: http://zavolga.net > > Руководитель проекта > Региональный Интернет Дневник > Сайт: http://dnevnik76.ru > > Руководитель проекта > Ярославский Internet Exchange (YAR-IX) > Сайт: http://yar-ix.net > > nic-hdl: SVS141-RIPE > X-NCC-RegID: ru.gorizont > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sokol на zavolga.net Mon May 16 11:46:12 2016 From: sokol на zavolga.net (Sergey V. Sokolov) Date: Mon, 16 May 2016 14:46:12 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <1579652.XXvDYMCNEz@cybernote> References: <3468051463352432@web26g.yandex.ru> <4002647.2lfeSIBV1g@cybernote> <15051463396752@web10o.yandex.ru> <1579652.XXvDYMCNEz@cybernote> Message-ID: <321951463399172@web14h.yandex.ru> Вложение в формате HTML было извлечено… URL: From nginx на kinetiksoft.com Mon May 16 12:20:27 2016 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Mon, 16 May 2016 15:20:27 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <321951463399172@web14h.yandex.ru> References: <3468051463352432@web26g.yandex.ru> <1579652.XXvDYMCNEz@cybernote> <321951463399172@web14h.yandex.ru> Message-ID: <5905225.MMWHYz8ha5@cybernote> Вы хотите анализировать именно $query_string или конкретные переменные из нее? Для приведенного Вами примера с p= работает моя конструкция. Если надо сравнивать p с несколькими подстроками, то будет map $arg_p $block { 'anyqwery$' 1; 'otherqwery' 1; 'some$otherqwery' 1; } if ($block) { return 403; } Если таких p не одна, а, например, есть еще q, то будет как-то так map $arg_p $pblock { default 0; 'anyqwery$' 1; 'otherqwery' 1; 'some$otherqwery' 1; } map $arg_q $qblock { default 0; '2qwery$' 1; 'newotherqwery' 1; '3some$otherqwery$' 1; } map $pblock$qblock $block { default 1; 00 0; } if ($block) { return 403; } Если же переменных p,q много, то можно сделать регэкспом по всей $query_string: map $query_string $block { default 0; ~'p=anyqwery$' 1; #если $query_string содержит "p=anyqwery$" или "zap=anyqwery$otherqwery", будет отлуп ~'otherqwery' 1; ~'$$$' 1; } if ($block) { return 403; } Прочитайте документацию на map: http://nginx.org/r/map/ru. В письме от 16 мая 2016 14:46:12 пользователь Sergey V. Sokolov написал: > Мне нужно для одного из location заблокировать порядка 10-20 query_string, а > остальные пропустить. Так вот, query_string может содержать символ $ и > нужно это учесть. > 16.05.2016, 14:07, "Иван" : > Мне кажется, что нет, не правильно понимаете. Опишите конкретнее, что хотите > получить, пожалуйста. > > В письме от 16 мая 2016 14:05:52 пользователь Sergey V. Sokolov написал: > > Я правильно понимаю, что на каждую такую операцию сравнения, будет две > > директивы в конфиге map и if? Получается в две операции. Короче можно? > > 16.05.2016, 02:57, "Иван" : > > > > В письме от 16 мая 2016 01:47:12 пользователь Sergey V. Sokolov написал: > > > $query_string > > > > > > Здравствуйте! > > > > Наиболее правильно > > map $arg_p $block { > > 'anyqwery$' 1; > > } > > > > if ($block) { > > return 403; > > } > > > > С уважением, Иван. > > , > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > > > > -- > > С уважением, Сергей Соколов > > Заместитель директора > > Zavolga.Net (ООО "Горизонт"), г. Ярославль > > Тел.: +7 4852 333-402 > > Сайт: http://zavolga.net > > > > Руководитель проекта > > Региональный Интернет Дневник > > Сайт: http://dnevnik76.ru > > > > Руководитель проекта > > Ярославский Internet Exchange (YAR-IX) > > Сайт: http://yar-ix.net > > > > nic-hdl: SVS141-RIPE > > X-NCC-RegID: ru.gorizont > > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sokol на zavolga.net Mon May 16 14:54:48 2016 From: sokol на zavolga.net (Sergey V. Sokolov) Date: Mon, 16 May 2016 17:54:48 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <5905225.MMWHYz8ha5@cybernote> References: <3468051463352432@web26g.yandex.ru> <1579652.XXvDYMCNEz@cybernote> <321951463399172@web14h.yandex.ru> <5905225.MMWHYz8ha5@cybernote> Message-ID: <128681463410488@web3j.yandex.ru> Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 16 19:16:10 2016 From: nginx-forum на forum.nginx.org (itpp2012) Date: Mon, 16 May 2016 15:16:10 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YHQutC+0LzQv9C40LvQuNGA0L7QstCw0YI=?= =?UTF-8?B?0Ywgbmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: References: Message-ID: См http://nginx-win.ecsds.eu/download/ngxLuaDB-1.1.zip из http://nginx-win.ecsds.eu/ и пример "/ngxLuaDB/conf/nginx GEOIP-MYSQL with Cache Non-Blocking.conf" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266886,266928#msg-266928 From sokol на zavolga.net Mon May 16 21:49:03 2016 From: sokol на zavolga.net (Sergey V. Sokolov) Date: Tue, 17 May 2016 00:49:03 +0300 Subject: =?UTF-8?B?UmU6INCh0L7Qv9C+0YHRgtCw0LLQu9C10L3QuNC1ICRxdWVyeV9zdHJpbmcg0YE=?= =?UTF-8?B?0L4g0YHRgtGA0L7QutC+0Lkg0YHQvtC00LXRgNC20LDRidC10LkgIiQi?= In-Reply-To: <128681463410488@web3j.yandex.ru> References: <3468051463352432@web26g.yandex.ru> <1579652.XXvDYMCNEz@cybernote> <321951463399172@web14h.yandex.ru> <5905225.MMWHYz8ha5@cybernote> <128681463410488@web3j.yandex.ru> Message-ID: <1127021463435343@web29m.yandex.ru> Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 16 22:30:02 2016 From: nginx-forum на forum.nginx.org (Dimka) Date: Mon, 16 May 2016 18:30:02 -0400 Subject: =?UTF-8?B?0JzQvtC20L3QviDQt9Cw0LrQvtC00LjRgNC+0LLQsNGC0YwgKEVzY2FwZSkg0L4=?= =?UTF-8?B?0LHRgNCw0YLQvdC+INC/0LXRgNC10LzQtdC90L3Rg9GOINC/0LXRgNC10LQg?= =?UTF-8?B?0L/QtdGA0LXQtNCw0YfQtdC5INCx0LXQutC10L3QtNGDPw==?= Message-ID: <4493bf37ed8e75ed69e7c8f30ee20d2b.NginxMailingListRussian@forum.nginx.org> Всем привет! Хочу передать бекенду $http_user_agent в query string Для этого делаю location ~ ^/cs/s { set $args $args&ip=$remote_addr; set $args $args&ua=$http_user_agent; proxy_pass http://192.168.0.1:8080; ...... } С бекенда возвращается ошибка, причина которой в том что $http_user_agent передается раскодированный. К сожалению, бекенд сервер может в этом кейсе брать только queryString и поэтому, вариант передать в заголовках не подходит. Что посоветуете попробовать? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266931,266931#msg-266931 From nginx-forum на forum.nginx.org Tue May 17 08:08:14 2016 From: nginx-forum на forum.nginx.org (grey) Date: Tue, 17 May 2016 04:08:14 -0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YHQutC+0LzQv9C40LvQuNGA0L7QstCw0YI=?= =?UTF-8?B?0Ywgbmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: References: Message-ID: <880e495b6cd462eab34cb2eadfe0f33b.NginxMailingListRussian@forum.nginx.org> Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266886,266935#msg-266935 From chipitsine на gmail.com Tue May 17 17:12:10 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 17 May 2016 22:12:10 +0500 Subject: =?UTF-8?B?0L3QtdC+0LHRj9C30LDRgtC10LvRjNC90L7RgdGC0Ywg0YXQtdC00LXRgNCwIENv?= =?UTF-8?B?bnRlbnQtVHlwZSDQsiDQvtGC0LLQtdGC0LUgPw==?= Message-ID: Добрый день! есть сервер, отдает ответы _без_ Content-Type. судя по RFC, это допустимо. как сделать так, чтобы при проксировании nginx сохранялось это же поведение ? (т.е. если хедера в ответе нет, то не добавлять его) Илья Шипицин ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue May 17 17:52:59 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 17 May 2016 20:52:59 +0300 Subject: =?UTF-8?B?UmU6INC90LXQvtCx0Y/Qt9Cw0YLQtdC70YzQvdC+0YHRgtGMINGF0LXQtNC10YA=?= =?UTF-8?B?0LAgQ29udGVudC1UeXBlINCyINC+0YLQstC10YLQtSA/?= In-Reply-To: References: Message-ID: <9891890.MJQfd89rEl@vbart-workstation> On Tuesday 17 May 2016 22:12:10 Илья Шипицин wrote: > Добрый день! > > есть сервер, отдает ответы _без_ Content-Type. > судя по RFC, это допустимо. > > как сделать так, чтобы при проксировании nginx сохранялось это же поведение > ? (т.е. если хедера в ответе нет, то не добавлять его) > А nginx при проксировании и не добавляет, если специально не настроить. -- Валентин Бартенев From chipitsine на gmail.com Tue May 17 18:26:02 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 17 May 2016 23:26:02 +0500 Subject: =?UTF-8?B?UmU6INC90LXQvtCx0Y/Qt9Cw0YLQtdC70YzQvdC+0YHRgtGMINGF0LXQtNC10YA=?= =?UTF-8?B?0LAgQ29udGVudC1UeXBlINCyINC+0YLQstC10YLQtSA/?= In-Reply-To: <9891890.MJQfd89rEl@vbart-workstation> References: <9891890.MJQfd89rEl@vbart-workstation> Message-ID: собрал стенд без сторонних модулей, вы правы, не добавляет. 17 мая 2016 г., 22:52 пользователь Валентин Бартенев написал: > On Tuesday 17 May 2016 22:12:10 Илья Шипицин wrote: > > Добрый день! > > > > есть сервер, отдает ответы _без_ Content-Type. > > судя по RFC, это допустимо. > > > > как сделать так, чтобы при проксировании nginx сохранялось это же > поведение > > ? (т.е. если хедера в ответе нет, то не добавлять его) > > > > А nginx при проксировании и не добавляет, если специально не настроить. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu May 19 14:27:43 2016 From: nginx-forum на forum.nginx.org (tonagra) Date: Thu, 19 May 2016 10:27:43 -0400 Subject: ngx_http_proxy_module + ngx_http_sub_module Message-ID: <3a0dad9f7bbeb8d0a99e106c205742fe.NginxMailingListRussian@forum.nginx.org> Добрый день, А правда, что subs_filter работает только для одной строки в HTML? И сделать полноценную замену не получиться. Не получается сделать subs_filter '(.*)' 'Test1$1Test2' gir; только так subs_filter '' 'Test1' gir; subs_filter '' 'Test' gir; https://habrahabr.ru/post/158393/ "Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp." Подскажите есть ли выход.... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267000,267000#msg-267000 From annulen на yandex.ru Thu May 19 14:30:44 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Thu, 19 May 2016 17:30:44 +0300 Subject: ngx_http_proxy_module + ngx_http_sub_module In-Reply-To: <3a0dad9f7bbeb8d0a99e106c205742fe.NginxMailingListRussian@forum.nginx.org> References: <3a0dad9f7bbeb8d0a99e106c205742fe.NginxMailingListRussian@forum.nginx.org> Message-ID: <870201463668244@web18m.yandex.ru> 19.05.2016, 17:28, "tonagra" : > Добрый день, > > А правда, что subs_filter работает только для одной строки в HTML? И сделать > полноценную замену не получиться. > Не получается сделать > > subs_filter '(.*)' > 'Test1$1Test2' gir; > > только так > > subs_filter '' 'Test1' gir; > subs_filter '' 'Test' gir; > > https://habrahabr.ru/post/158393/ > "Единственное, но очень серьезное ограничение модуля замены — он работает > только с одной строкой. Это ограничение заложено архитектурно, поскольку > модуль работает на этапе, когда страница загружена частично (chunked > transfer encoding) и нет никакой возможности выполнить полнотекстовый > regexp." > > Подскажите есть ли выход.... Написать серверный скрипт, который будет выкачивать ответ целиком и возвращать результат обработки -- Regards, Konstantin From nginx-forum на forum.nginx.org Thu May 19 14:37:59 2016 From: nginx-forum на forum.nginx.org (tonagra) Date: Thu, 19 May 2016 10:37:59 -0400 Subject: ngx_http_proxy_module + ngx_http_sub_module In-Reply-To: <870201463668244@web18m.yandex.ru> References: <870201463668244@web18m.yandex.ru> Message-ID: <400406bbf6f6a4802d8cbf5cce4f6e1f.NginxMailingListRussian@forum.nginx.org> А есть другие варианты? :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267000,267002#msg-267002 From kpoxa на kpoxa.net Thu May 19 16:49:09 2016 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 19 May 2016 16:49:09 +0000 Subject: ngx_http_proxy_module + ngx_http_sub_module In-Reply-To: <400406bbf6f6a4802d8cbf5cce4f6e1f.NginxMailingListRussian@forum.nginx.org> References: <870201463668244@web18m.yandex.ru> <400406bbf6f6a4802d8cbf5cce4f6e1f.NginxMailingListRussian@forum.nginx.org> Message-ID: Нет чт, 19 мая 2016 г. в 17:38, tonagra : > А есть другие варианты? :) > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267000,267002#msg-267002 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на forum.nginx.org Thu May 19 16:54:05 2016 From: nginx-forum на forum.nginx.org (bagas) Date: Thu, 19 May 2016 12:54:05 -0400 Subject: =?UTF-8?B?bmdpbngg0YDQtdC00LjRgNC10LrRgtGL?= Message-ID: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> Вечер добрый. Подскажите пожалуйста как мне реализовать такой редирект. Есть сайт на битриксе. Нужно реализовать редирект с http://site.ru/catalog/kos-i-kosmet/maz-tor/index.php на http://site.ru/catalog/kos-i-kosmet/maz-tor/ И такой редирект нужен ко всему контенту на сайте. И второй такой редирект: с http://site.ru/catalog/kos-i-kosmet/maz-tor на http://site.ru/catalog/kos-i-kosmet/maz-tor/ Как такое можно реализовать? Спасибо за понимание. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267006,267006#msg-267006 From nginx-forum на forum.nginx.org Sat May 21 05:40:45 2016 From: nginx-forum на forum.nginx.org (bagas) Date: Sat, 21 May 2016 01:40:45 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INGA0LXQtNC40YDQtdC60YLRiw==?= In-Reply-To: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> References: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> Message-ID: <78059333fd022fe4ef7b705e98cbcf37.NginxMailingListRussian@forum.nginx.org> Вот реидректы движка приготовленные для апача. Options +FollowSymLinks RewriteEngine On RewriteCond %{HTTP_HOST} ^www.site\.ru$ [NC] RewriteRule ^(.*)$ http://site.ru/$1 [R=301,L] RewriteCond %{THE_REQUEST} /(.*)index.php.*$ RewriteCond %{QUERY_STRING} ^\z RewriteRule ^(.*)index\.php$ http://%{HTTP_HOST}/$1 [R=301,L] RewriteCond %{THE_REQUEST} /(.*)index.html.*$ RewriteRule .* /%1 [R=301,L] RewriteCond %{REQUEST_URI} (.*/[^/.]+)($|\?) RewriteRule .* %1/ [R=301,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$ RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L] RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}] Как их перевести на nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267006,267032#msg-267032 From nginx-forum на forum.nginx.org Sun May 22 04:51:57 2016 From: nginx-forum на forum.nginx.org (Vasiliy P. Melnik) Date: Sun, 22 May 2016 00:51:57 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INGA0LXQtNC40YDQtdC60YLRiw==?= In-Reply-To: <78059333fd022fe4ef7b705e98cbcf37.NginxMailingListRussian@forum.nginx.org> References: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> <78059333fd022fe4ef7b705e98cbcf37.NginxMailingListRussian@forum.nginx.org> Message-ID: В гугле забанили , да? :) З.Ы только это не редиректы - это раврайты https://www.google.com.ua/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=convert%20apache%20rewrite%20to%20nginx Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267006,267038#msg-267038 From nginx-forum на forum.nginx.org Sun May 22 13:22:01 2016 From: nginx-forum на forum.nginx.org (bagas) Date: Sun, 22 May 2016 09:22:01 -0400 Subject: =?UTF-8?B?UmU6IG5naW54INGA0LXQtNC40YDQtdC60YLRiw==?= In-Reply-To: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> References: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> Message-ID: <57701908673a609ad9f998e1a27af743.NginxMailingListRussian@forum.nginx.org> Решил щадачу. если кому понадобится, то вот тут выложил информацию. http://www.fryaha.ru/nginx-examples-redirect/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267006,267041#msg-267041 From alex.hha на gmail.com Sun May 22 16:38:59 2016 From: alex.hha на gmail.com (Alex Domoradov) Date: Sun, 22 May 2016 19:38:59 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INGA0LXQtNC40YDQtdC60YLRiw==?= In-Reply-To: <57701908673a609ad9f998e1a27af743.NginxMailingListRussian@forum.nginx.org> References: <658e07fe82009375af3e55c13ed80f09.NginxMailingListRussian@forum.nginx.org> <57701908673a609ad9f998e1a27af743.NginxMailingListRussian@forum.nginx.org> Message-ID: > rewrite ^([^.\?]*[^/])$ $1/ permanent; вроде можно проще try_files $uri $uri/ 2016-05-22 16:22 GMT+03:00 bagas : > Решил щадачу. > если кому понадобится, то вот тут выложил информацию. > http://www.fryaha.ru/nginx-examples-redirect/ > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267006,267041#msg-267041 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 23 07:19:18 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Mon, 23 May 2016 03:19:18 -0400 Subject: =?UTF-8?B?0JfQsNCy0LjRgdCw0L3QuNC1IG5naW54INC40Lct0LfQsCBtZW1jYWNoZWQ=?= Message-ID: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> Здравствуйте У нас 5 nginx, которые соединены с 2мя memcached. После того как на memcached случился segfault at 24 ip 000000000040dda0 sp 00007ff13d03cc10 error 4 in memcached[400000+16000]; каждый nginx worker (по настройке их 8 на каждом nginx) начинает утилизировать 100% ядра CPU, вызывая "зависание" процессов nginx на всех серверах. Когда подняли сбойнувший memcached с помощью monit, то ситуация не изменилась. Пришлось убить все nginx и снова поднять. После этого, все заработало как до segfault. Версия nginx: 1.4.2 Версия memcached: 1.4.10 ОС: CentOS 6.5 Настройки memcached в nginx: upstream memcached_screenshots { server 127.0.0.1:11211; hash $uri; keepalive 512; } memcached_connect_timeout 60s; memcached_read_timeout 60s; memcached_send_timeout 60s; Запуск memcached: memcached -d -p 11211 -u memcached -m 16384 -c 1024 -P /var/run/memcached/memcached.pid -t 2 Настройки nginx workers: worker_processes 8; timer_resolution 100ms; worker_rlimit_nofile 50000; worker_priority -5; events { worker_connections 100000; use epoll; } Как я понимаю, segfault является следствием количества evictions в memcached (200-2000) перед моментом остановки процесса (возможно баг в процессе дефрагментации у memcached), и т.к. задан timeout, видимо, относительно большой в 60 секунд, то те запросы, которые приходили на nginx, скапливались в некоторой очереди в ожидании получения соединения, а каждый worker ходил по этой очереди и проверял для каждого запроса, имеется ли возможность соединиться с memcached или нет. Ну + к этому, возможно, когда случился segfault сокет не отдался ОС (достоверно неизвестно на данный момент, после segfault убился процесс memcached или нет). Видимо, уменьшение connect|read|write timeout должно решить проблему. Но так ли это ? Подскажите, пожалуйста, как если не устранить проблему, то уменьшить возможность ее появления в ближайшем будущем. И является ли это проблемой nginx (возможно, у клиента старая версия nginx и стоит обновиться до 1.10) или все-таки проблема в конфигурации (что то нужно убрать, что то добавить) ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267049#msg-267049 From postmaster на softsearch.ru Mon May 23 10:48:35 2016 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Mon, 23 May 2016 13:48:35 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> References: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <957348519.20160523134835@softsearch.ru> Здравствуйте, Vadim. > Версия nginx: 1.4.2 Обновлять nginx не пробовали? -- С уважением, Михаил mailto:postmaster на softsearch.ru From nginx-forum на forum.nginx.org Mon May 23 11:40:37 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Mon, 23 May 2016 07:40:37 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <957348519.20160523134835@softsearch.ru> References: <957348519.20160523134835@softsearch.ru> Message-ID: <670b86767e3c94dde669753d85202ae0.NginxMailingListRussian@forum.nginx.org> нет, т.к. это довольно рискованный и трудоемкий процесс в сравнении с возможным изменением конфиг. файла nginx.conf, настроек memcached. Чтобы обновить до 1.10 потребуется заново собирать nginx, проверять правильность работы сторонних модулей, делать обычное и нагрузочное тестирование. Поэтому, хотелось бы обойтись меньшими затратами Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267055#msg-267055 From postmaster на softsearch.ru Mon May 23 12:04:19 2016 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Mon, 23 May 2016 15:04:19 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <670b86767e3c94dde669753d85202ae0.NginxMailingListRussian@forum.nginx.org> References: <957348519.20160523134835@softsearch.ru> <670b86767e3c94dde669753d85202ae0.NginxMailingListRussian@forum.nginx.org> Message-ID: <1444831498.20160523150419@softsearch.ru> Здравствуйте, Vadim. Эксперимент можно было бы провести без сторонних модулей. Тогда появился бы хотя бы один вариант решения Вашей проблемы. > нет, т.к. это довольно рискованный и трудоемкий процесс в сравнении с > возможным изменением конфиг. файла nginx.conf, настроек memcached. > Чтобы обновить до 1.10 потребуется заново собирать nginx, проверять > правильность работы сторонних модулей, делать обычное и нагрузочное > тестирование. > Поэтому, хотелось бы обойтись меньшими затратами > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267055#msg-267055 > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Михаил mailto:postmaster на softsearch.ru From nginx-forum на forum.nginx.org Mon May 23 13:16:27 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Mon, 23 May 2016 09:16:27 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <1444831498.20160523150419@softsearch.ru> References: <1444831498.20160523150419@softsearch.ru> Message-ID: <67db08c4f3f3a67f56b9beeea11b09b4.NginxMailingListRussian@forum.nginx.org> А как провести без сторонних модулей ? :) Запустить на production, убрав нужные url-ы ? Если имеется в виду проводить эксперимент на тестовом стенде, то выходит, что достаточное кол-во подключений, запросов, машин, стендов, их параметры вряд ли получится достоверно воспроизвести, но возможно не это главное, а то, как воспроизвести segfault на memcached, чтобы он в свою очередь стал причиной для nginx. А на сколько мне известно, у memcached нету, как у redis, такой способности. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267058#msg-267058 From chipitsine на gmail.com Mon May 23 13:33:08 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 23 May 2016 18:33:08 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <670b86767e3c94dde669753d85202ae0.NginxMailingListRussian@forum.nginx.org> References: <957348519.20160523134835@softsearch.ru> <670b86767e3c94dde669753d85202ae0.NginxMailingListRussian@forum.nginx.org> Message-ID: если не является коммерческой тайной, покажите вывод nginx -V ? 23 мая 2016 г., 16:40 пользователь Vadim Osipov написал: > нет, т.к. это довольно рискованный и трудоемкий процесс в сравнении с > возможным изменением конфиг. файла nginx.conf, настроек memcached. > Чтобы обновить до 1.10 потребуется заново собирать nginx, проверять > правильность работы сторонних модулей, делать обычное и нагрузочное > тестирование. > Поэтому, хотелось бы обойтись меньшими затратами > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267055#msg-267055 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Mon May 23 14:34:02 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 23 May 2016 20:34:02 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <67db08c4f3f3a67f56b9beeea11b09b4.NginxMailingListRussian@forum.nginx.org> References: <1444831498.20160523150419@softsearch.ru> <67db08c4f3f3a67f56b9beeea11b09b4.NginxMailingListRussian@forum.nginx.org> Message-ID: <183467062.xZgzkVL9e8@note> > то, как воспроизвести segfault на memcached, чтобы он в свою очередь стал > причиной для nginx. А на сколько мне известно, у memcached нету, как у > redis, такой способности. killall -11 memcached -- wbr, mva From nginx-forum на forum.nginx.org Mon May 23 14:59:04 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Mon, 23 May 2016 10:59:04 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: Message-ID: <536a8dad624a1172cfddcd8c869a15d4.NginxMailingListRussian@forum.nginx.org> nginx version: nginx/1.4.2 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-http_xslt_module --with-debug --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upstream-fair --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upload-progress-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/mod_zip --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_mod_h264_streaming --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-push-stream-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_upstream_hash --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-memcached-hash-pass --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/echo-nginx-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/ngx_http_gunzip_filter_module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/headers-more-nginx-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-rewrite-request-body-module Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267064#msg-267064 From nginx-forum на forum.nginx.org Mon May 23 15:01:32 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Mon, 23 May 2016 11:01:32 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <183467062.xZgzkVL9e8@note> References: <183467062.xZgzkVL9e8@note> Message-ID: <2f68a3fcf0dccc7be59ce32053faa4d5.NginxMailingListRussian@forum.nginx.org> Спасибо, попробую ! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267065#msg-267065 From kpoxa на kpoxa.net Mon May 23 16:01:19 2016 From: kpoxa на kpoxa.net (kpoxa) Date: Mon, 23 May 2016 16:01:19 +0000 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <67db08c4f3f3a67f56b9beeea11b09b4.NginxMailingListRussian@forum.nginx.org> References: <1444831498.20160523150419@softsearch.ru> <67db08c4f3f3a67f56b9beeea11b09b4.NginxMailingListRussian@forum.nginx.org> Message-ID: Нужные урлы пропустите через промежуточный nginx последней версии, который уже будет коннектиться к мемкешу. пн, 23 мая 2016 г. в 16:16, Vadim Osipov : > А как провести без сторонних модулей ? :) > Запустить на production, убрав нужные url-ы ? > > Если имеется в виду проводить эксперимент на тестовом стенде, то выходит, > что достаточное кол-во подключений, запросов, машин, стендов, их параметры > вряд ли получится достоверно воспроизвести, но возможно не это главное, а > то, как воспроизвести segfault на memcached, чтобы он в свою очередь стал > причиной для nginx. А на сколько мне известно, у memcached нету, как у > redis, такой способности. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267058#msg-267058 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From medvedev.yp на gmail.com Mon May 23 16:13:06 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Mon, 23 May 2016 19:13:06 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= References: <1444831498.20160523150419@softsearch.ru> <67db08c4f3f3a67f56b9beeea11b09b4.NginxMailingListRussian@forum.nginx.org> Message-ID: <11dm996h9a6cgcwss3rt33ix.1464019986377@email.android.com> Пакет соберите и будет вам счастье. Отправлено с моего ASUS -------- Исходное сообщение -------- Отправитель:kpoxa Отправленные:Mon, 23 May 2016 19:01:19 +0300 Получатель:nginx-ru на nginx.org Тема:Re: Зависание nginx из-за memcached >_______________________________________________ >nginx-ru mailing list >nginx-ru на nginx.org >http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Mon May 23 17:07:27 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 23 May 2016 22:07:27 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <536a8dad624a1172cfddcd8c869a15d4.NginxMailingListRussian@forum.nginx.org> References: <536a8dad624a1172cfddcd8c869a15d4.NginxMailingListRussian@forum.nginx.org> Message-ID: headers-more-nginx-module - с этим модулем во времена, когда вы компилировали, проблемы были (в свежих версиях исправлено), у нас, например, worker-ы зависали а вы прямо по необходимости модули собирали? у меня с трудом укладывается, зачем одновременно push и h264 может (на стенде) часть модулей убрать? 2016-05-23 19:59 GMT+05:00 Vadim Osipov : > nginx version: nginx/1.4.2 > built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > TLS SNI support enabled > configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx > --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log > --http-client-body-temp-path=/var/lib/nginx/tmp/client_body > --http-proxy-temp-path=/var/lib/nginx/tmp/proxy > --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi > --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx > --with-http_secure_link_module --with-http_random_index_module > --with-http_ssl_module --with-http_realip_module > --with-http_addition_module > --with-http_sub_module --with-http_dav_module --with-http_flv_module > --with-http_gzip_static_module --with-http_stub_status_module > --with-http_perl_module --with-http_xslt_module --with-debug --with-mail > --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upstream-fair > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-upload-progress-module > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/mod_zip > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_mod_h264_streaming > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-push-stream-module > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_upstream_hash > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-memcached-hash-pass > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/echo-nginx-module > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/ngx_http_gunzip_filter_module > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/headers-more-nginx-module > > --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-rewrite-request-body-module > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267064#msg-267064 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 24 07:22:20 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Tue, 24 May 2016 03:22:20 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: Message-ID: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> h264, flv, mp4 - все это можно безболезненно убрать (есть выделенные видеосервера). Использование h264, возможно, - legacy, пытались снизить нагрузку с видеосерверов, точно не знаю. Push модуль точно нужен, используем его для организации comet-соединений. Из советов по проблеме, все-таки решил собрать 1.10 (хотя руководству не очень нравится идея обычного и нагрузочного тестирования), там и убрал часть сторонних модулей (осталось только заменить на эквиваленты, появившееся в самом nginx). Ориентировочно так выглядит часть описания из configure: --without-http_fastcgi_module \ --without-http_uwsgi_module \ --without-http_scgi_module \ --without-http_ssi_module \ --without-http_empty_gif_module \ --with-http_ssl_module \ --with-http_realip_module \ --with-http_sub_module \ --with-http_gunzip_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --with-http_xslt_module=dynamic \ --with-http_image_filter_module=dynamic \ --with-http_geoip_module=dynamic \ --with-http_perl_module=dynamic \ --add-dynamic-module=njs-%{module_njs_shaid}/nginx \ --with-threads \ --with-stream \ --with-stream_ssl_module \ --with-http_slice_module \ --with-file-aio \ --with-ipv6 \ --add-module=nginx-push-stream-module-0.5.1 \ --add-module=headers-more-nginx-module-0.29 \ --add-module=echo-nginx-module-0.58 \ А скажите, как вы обнаружили, что в вашем случае проблема была в headers-more-nginx-module ? Добавили модуль и через какое то короткое время и/или через access & error logs увидели, что после прихода запрос на какой то url возникает зависание ? + вы полностью от headers-more-nginx-module отказались, заменив на связку add_header + убрав возможное дублирование заголовка со стороны application server ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267077#msg-267077 From nginx-forum на forum.nginx.org Tue May 24 07:27:04 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Tue, 24 May 2016 03:27:04 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <11dm996h9a6cgcwss3rt33ix.1464019986377@email.android.com> References: <11dm996h9a6cgcwss3rt33ix.1464019986377@email.android.com> Message-ID: <6afd570f7ef47861f27129200b314f23.NginxMailingListRussian@forum.nginx.org> Извините, в каком смысле собрать пакет ? :) Последней версии nginx ? Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно воспроизвести проблему на старом решении. Просто, возможно, проблема с конфигурацией. P.S. Я тесты с killall -11 еще не проводил, но чувствую, что придется надеяться, что 1.10 решит проблему, хотя просмотрел Release notes от 1.4.2 и выше и какого упоминания о исправлении возможного бага в коде модуля memcached не заметил. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267078#msg-267078 From medvedev.yp на gmail.com Tue May 24 08:21:54 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Tue, 24 May 2016 11:21:54 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <6afd570f7ef47861f27129200b314f23.NginxMailingListRussian@forum.nginx.org> References: <11dm996h9a6cgcwss3rt33ix.1464019986377@email.android.com> <6afd570f7ef47861f27129200b314f23.NginxMailingListRussian@forum.nginx.org> Message-ID: Вы для бинарных дистрибутивов из исходных кодов собираете? 24 мая 2016 г., 10:27 пользователь Vadim Osipov написал: > Извините, в каком смысле собрать пакет ? :) Последней версии nginx ? > Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно > воспроизвести проблему на старом решении. Просто, возможно, проблема с > конфигурацией. > > P.S. > Я тесты с killall -11 еще не проводил, но чувствую, что придется надеяться, > что 1.10 решит проблему, хотя просмотрел Release notes от 1.4.2 и выше и > какого упоминания о исправлении возможного бага в коде модуля memcached не > заметил. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267078#msg-267078 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From medvedev.yp на gmail.com Tue May 24 08:23:31 2016 From: medvedev.yp на gmail.com (Yuriy Medvedev) Date: Tue, 24 May 2016 11:23:31 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: <11dm996h9a6cgcwss3rt33ix.1464019986377@email.android.com> <6afd570f7ef47861f27129200b314f23.NginxMailingListRussian@forum.nginx.org> Message-ID: UP: посмотрел как у вас собран nginx и если не вы rpm билдили, тогда это стандартный пакет для rhel подобных 24 мая 2016 г., 11:21 пользователь Yuriy Medvedev написал: > Вы для бинарных дистрибутивов из исходных кодов собираете? > > 24 мая 2016 г., 10:27 пользователь Vadim Osipov < > nginx-forum на forum.nginx.org> написал: > > Извините, в каком смысле собрать пакет ? :) Последней версии nginx ? >> Ну, чтобы показать, что он решает проблему возможных ошибок в коде, нужно >> воспроизвести проблему на старом решении. Просто, возможно, проблема с >> конфигурацией. >> >> P.S. >> Я тесты с killall -11 еще не проводил, но чувствую, что придется >> надеяться, >> что 1.10 решит проблему, хотя просмотрел Release notes от 1.4.2 и выше и >> какого упоминания о исправлении возможного бага в коде модуля memcached не >> заметил. >> >> Posted at Nginx Forum: >> https://forum.nginx.org/read.php?21,267049,267078#msg-267078 >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue May 24 08:51:28 2016 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Tue, 24 May 2016 11:51:28 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <6afd570f7ef47861f27129200b314f23.NginxMailingListRussian@forum.nginx.org> References: <11dm996h9a6cgcwss3rt33ix.1464019986377@email.android.com> <6afd570f7ef47861f27129200b314f23.NginxMailingListRussian@forum.nginx.org> Message-ID: <1073706389.20160524115128@softsearch.ru> Здравствуйте, Vadim. > просмотрел Release notes от 1.4.2 и выше и какого упоминания о > исправлении возможного бага в коде модуля memcached не заметил. Сторонние модули могут наводить проблемы для других модулей. Чем их меньше, тем лучше. А обновиться стоит потому, что несколько secure-багов исправлено. -- С уважением, Михаил mailto:postmaster на softsearch.ru From chipitsine на gmail.com Tue May 24 11:11:10 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 24 May 2016 16:11:10 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> References: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> Message-ID: экспериментально обнаружили. был модуль - были зависания, не было модуля - не было зависаний. это давно было, модуль выпилили, глубже копать не стали. на add_header не получалось, оно на 500-е коды в то время не умело добавлять. насчет вашей текущей ситуации, если добавлять модули в том порядке, в котором у вас (сначала headers-more, потом echo), то тесты разваливаются https://travis-ci.org/chipitsine/headers-more-nginx-module/jobs/122438099 утверждается, что порядок имеет значение, если добавлять в обратном ( https://github.com/openresty/headers-more-nginx-module/blob/master/util/build.sh ), то не разваливаются https://travis-ci.org/openresty/headers-more-nginx-module почему порядок имеет значение - не дошли руки разобраться еще. почему начальство против тестирования - непонятно. хорошая же вещь. как без тестирования то. 24 мая 2016 г., 12:22 пользователь Vadim Osipov написал: > h264, flv, mp4 - все это можно безболезненно убрать (есть выделенные > видеосервера). Использование h264, возможно, - legacy, пытались снизить > нагрузку с видеосерверов, точно не знаю. > > Push модуль точно нужен, используем его для организации comet-соединений. > > Из советов по проблеме, все-таки решил собрать 1.10 (хотя руководству не > очень нравится идея обычного и нагрузочного тестирования), там и убрал > часть > сторонних модулей (осталось только заменить на эквиваленты, появившееся в > самом nginx). Ориентировочно так выглядит часть описания из configure: > --without-http_fastcgi_module \ > --without-http_uwsgi_module \ > --without-http_scgi_module \ > --without-http_ssi_module \ > --without-http_empty_gif_module \ > --with-http_ssl_module \ > --with-http_realip_module \ > --with-http_sub_module \ > --with-http_gunzip_module \ > --with-http_gzip_static_module \ > --with-http_stub_status_module \ > --with-http_xslt_module=dynamic \ > --with-http_image_filter_module=dynamic \ > --with-http_geoip_module=dynamic \ > --with-http_perl_module=dynamic \ > --add-dynamic-module=njs-%{module_njs_shaid}/nginx \ > --with-threads \ > --with-stream \ > --with-stream_ssl_module \ > --with-http_slice_module \ > --with-file-aio \ > --with-ipv6 \ > --add-module=nginx-push-stream-module-0.5.1 \ > --add-module=headers-more-nginx-module-0.29 \ > --add-module=echo-nginx-module-0.58 \ > > А скажите, как вы обнаружили, что в вашем случае проблема была в > headers-more-nginx-module ? Добавили модуль и через какое то короткое время > и/или через access & error logs увидели, что после прихода запрос на какой > то url возникает зависание ? > > + вы полностью от headers-more-nginx-module отказались, заменив на связку > add_header + убрав возможное дублирование заголовка со стороны application > server ? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267077#msg-267077 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue May 24 12:34:57 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 24 May 2016 08:34:57 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <4677116.ZlDiD43GLd@vbart-workstation> References: <4677116.ZlDiD43GLd@vbart-workstation> Message-ID: > Вы просто перенесете то, что реализовано в ядре операционной системы > внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный > запрос свой внутренний идентификатор со своими накладными расходами, > который точно также будет "простаивать" пока запрос обрабатывается. > > У вас уже есть мультиплексирование на уровне TCP/IP. > > HTTP/2 - это коробочка в коробочке. Провел простые тесты, получил интересные результаты. Браузер делает три аякс запроса GET /one HTTP/1.1 GET /two HTTP/1.1 GET /three HTTP/1.1 Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном конекте. Nginx отправляет все эти три запроса в одном конекте на бекенд. Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит очередь HTTP запросов, допустим время ответа у нас такое: GET /one HTTP/1.1 -- 500ms GET /two HTTP/1.1 -- 20ms GET /three HTTP/1.1 -- 10ms Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос, не дожидаясь обработки первого медленного запроса. Есть три варианта как это сделать: 1. Бекенд читает все запросы из сокета и обрабатывает асинхроно, ответы буферизирует чтобы отправить в том же порядки как пришли запросы. 2. Перейти на НТТР/2 для работы бекенда с Nginx, но этого нет в планах Nginx 3. Если сделать свой велосипед, использовать $request_id для связи ответов и запросов, тогда бекенд сможет отвечать асинхроно, будет в зоголовке указывать $request_id запроса на который он отвечает, Nginx клиенту отправит ответы в той же последовательности как клиент прислал запросы. Я не люблю велосипеды ($request_id) но если Nginx не планирует мультиплескирования (НТТР/2 или FastCGI) в апстримах, возможно это неплохой компромис, как вы считаете? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267088#msg-267088 From nginx на mva.name Tue May 24 12:35:06 2016 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Tue, 24 May 2016 18:35:06 +0600 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <16915793.1C9r62upqc@note> > почему порядок имеет значение - не дошли руки разобраться еще. Для модулей NginX (особенно связанных с filter-инфраструктурой) это довольно обычное явление. Например, для модулей, использующих модуль ndk как "базу" такое очень свойственно. Для naxsi. Ну и т.п. Особенности архитектуры NginX, в общем :) // а учитывая декларативный характер конфига — с динамическими модулями проблема тоже сохраняется. Только прееносится из "какой первым добавить в сборку" на "какой первым объявить в конфиге" :) -- wbr, mva From vbart на nginx.com Tue May 24 12:43:54 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 May 2016 15:43:54 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <4677116.ZlDiD43GLd@vbart-workstation> Message-ID: <3424137.ZrRMcCNMxq@vbart-workstation> On Tuesday 24 May 2016 08:34:57 S.A.N wrote: > > Вы просто перенесете то, что реализовано в ядре операционной системы > > внутрь приложения. В случае HTTP/2 у вас будет на каждый отдельный > > запрос свой внутренний идентификатор со своими накладными расходами, > > который точно также будет "простаивать" пока запрос обрабатывается. > > > > У вас уже есть мультиплексирование на уровне TCP/IP. > > > > HTTP/2 - это коробочка в коробочке. > > > Провел простые тесты, получил интересные результаты. > > Браузер делает три аякс запроса > > GET /one HTTP/1.1 > GET /two HTTP/1.1 > GET /three HTTP/1.1 > > Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном > конекте. > Nginx отправляет все эти три запроса в одном конекте на бекенд. > > Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит > очередь HTTP запросов, допустим время ответа у нас такое: > > GET /one HTTP/1.1 -- 500ms > GET /two HTTP/1.1 -- 20ms > GET /three HTTP/1.1 -- 10ms > > Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос, > не дожидаясь обработки первого медленного запроса. > > Есть три варианта как это сделать: > > 1. Бекенд читает все запросы из сокета и обрабатывает асинхроно, ответы > буферизирует чтобы отправить в том же порядки как пришли запросы. > Nginx никогда не посылает запрос в то же соединение, пока не получит ответ и соединение освободиться. Т.н. pipelining он не умеет и не использует. Если бы следующий запрос пришел до того, как на первый был получен ответ, то он бы был отправлен на бекенд в другом соединении. Т.е. никакой проблемы между nginx и бекендом нет. > 2. Перейти на НТТР/2 для работы бекенда с Nginx, но этого нет в планах > Nginx > > 3. Если сделать свой велосипед, использовать $request_id для связи ответов и > запросов, тогда бекенд сможет отвечать асинхроно, будет в зоголовке > указывать $request_id запроса на который он отвечает, Nginx клиенту отправит > ответы в той же последовательности как клиент прислал запросы. > > > Я не люблю велосипеды ($request_id) но если Nginx не планирует > мультиплескирования (НТТР/2 или FastCGI) в апстримах, возможно это неплохой > компромис, как вы считаете? > [..] Вы пытаетесь решить несуществующую проблему, см. выше. Проблема в общении браузера и сервера, которую решает мультиплексирование, заключается исключительно в том, что браузер жестко ограничен в количестве TCP соединений. Между nginx и бекендом - такого ограничения нет, следовательно и проблемы тоже. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue May 24 12:57:46 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 24 May 2016 08:57:46 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <3424137.ZrRMcCNMxq@vbart-workstation> References: <3424137.ZrRMcCNMxq@vbart-workstation> Message-ID: <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> > Nginx никогда не посылает запрос в то же соединение, пока не получит > ответ > и соединение освободиться. Т.н. pipelining он не умеет и не > использует. > > Если бы следующий запрос пришел до того, как на первый был получен > ответ, > то он бы был отправлен на бекенд в другом соединении. > > Т.е. никакой проблемы между nginx и бекендом нет. Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока первый не ответит, в этом и проблема, потому что он ждет ответа на первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый запрос и отправил второй и третий запрос в другом свободном конекте или открыл новый конект, но Nginx эти запросы будет держать в очереди и это очень плохо. Могу выслать код теста. > Проблема в общении браузера и сервера, которую решает > мультиплексирование, > заключается исключительно в том, что браузер жестко ограничен в > количестве TCP > соединений. > Между nginx и бекендом - такого ограничения нет, следовательно и > проблемы тоже. В линуксе кол-во открытых fd тоже ограничено. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267091#msg-267091 From chipitsine на gmail.com Tue May 24 13:12:53 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 24 May 2016 18:12:53 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <16915793.1C9r62upqc@note> References: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> <16915793.1C9r62upqc@note> Message-ID: у меня не очень укладывается в голове, что он втихую это обрабатывает. сругался бы чтоли. не должно это быть обычным явлением дойдут руки, посмотрю 24 мая 2016 г., 17:35 пользователь Vadim A. Misbakh-Soloviov написал: > > почему порядок имеет значение - не дошли руки разобраться еще. > Для модулей NginX (особенно связанных с filter-инфраструктурой) это > довольно > обычное явление. Например, для модулей, использующих модуль ndk как "базу" > такое очень свойственно. Для naxsi. Ну и т.п. > > Особенности архитектуры NginX, в общем :) > > // а учитывая декларативный характер конфига — с динамическими модулями > проблема тоже сохраняется. Только прееносится из "какой первым добавить в > сборку" на "какой первым объявить в конфиге" :) > > -- > wbr, > mva > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Tue May 24 13:38:48 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 May 2016 16:38:48 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> References: <3424137.ZrRMcCNMxq@vbart-workstation> <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> Message-ID: <4259454.oMAsMZAoJN@vbart-workstation> On Tuesday 24 May 2016 08:57:46 S.A.N wrote: > > Nginx никогда не посылает запрос в то же соединение, пока не получит > > ответ и соединение освободиться. Т.н. pipelining он не умеет и не > > использует. > > > > Если бы следующий запрос пришел до того, как на первый был получен > > ответ, то он бы был отправлен на бекенд в другом соединении. > > > > Т.е. никакой проблемы между nginx и бекендом нет. > > Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока первый не > ответит, в этом и проблема, потому что он ждет ответа на первый запрос, я бы > ещё понял если бы Nginx не ждал ответа на первый запрос и отправил второй и > третий запрос в другом свободном конекте или открыл новый конект, но Nginx > эти запросы будет держать в очереди и это очень плохо. > Могу выслать код теста. > Вышлите. Текущая версия nginx без сторонних модулей ждать не умеет, и чтобы научить его ждать в Plus даже специальную очередь программировать пришлось. > > > Проблема в общении браузера и сервера, которую решает > > мультиплексирование, > > заключается исключительно в том, что браузер жестко ограничен в > > количестве TCP > > соединений. > > > Между nginx и бекендом - такого ограничения нет, следовательно и > > проблемы тоже. > > В линуксе кол-во открытых fd тоже ограничено. > Равно как и память в системе, которую HTTP/2 будет кушать. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue May 24 14:38:46 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 24 May 2016 10:38:46 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> References: <3424137.ZrRMcCNMxq@vbart-workstation> <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> Message-ID: <5d5c464c9c624f867001e09f83005939.NginxMailingListRussian@forum.nginx.org> > > Nginx никогда не посылает запрос в то же соединение, пока не > получит > > ответ > > и соединение освободиться. Т.н. pipelining он не умеет и не > > использует. > > > > Если бы следующий запрос пришел до того, как на первый был получен > > ответ, > > то он бы был отправлен на бекенд в другом соединении. > > > > Т.е. никакой проблемы между nginx и бекендом нет. > > Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока > первый не ответит, в этом и проблема, потому что он ждет ответа на > первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый > запрос и отправил второй и третий запрос в другом свободном конекте > или открыл новый конект, но Nginx эти запросы будет держать в очереди > и это очень плохо. > Могу выслать код теста. > Я ещё раз проверил, Nginx разносит три запроса из одного клиенского соеденения, по разным соединениям бекенда только если клиент сделал запросы по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского соединения по разным соединениям бекенда. Проверил на Nginx/1.9.15 без стороних модулей. Я здесь выложу исходники тест скриптов, они не большие и результат, я тестировал в nc чтобы убедится что все три запроса отправляются в одном соединение. В роли бекенда может быть все что угодно, главное чтобы бекенд умел принимать и паралейно выполнять новые соеденения, даже FPM с тремя воркерами подойдет. Три РНР скрипта: -------------------------------------------------- 1.php -------------------------------------------------- References: <3424137.ZrRMcCNMxq@vbart-workstation> <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> <5d5c464c9c624f867001e09f83005939.NginxMailingListRussian@forum.nginx.org> Message-ID: <4116002.lrf6KTFWkW@vbart-workstation> On Tuesday 24 May 2016 10:38:46 S.A.N wrote: > > > Nginx никогда не посылает запрос в то же соединение, пока не > > получит > > > ответ > > > и соединение освободиться. Т.н. pipelining он не умеет и не > > > использует. > > > > > > Если бы следующий запрос пришел до того, как на первый был получен > > > ответ, > > > то он бы был отправлен на бекенд в другом соединении. > > > > > > Т.е. никакой проблемы между nginx и бекендом нет. > > > > Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока > > первый не ответит, в этом и проблема, потому что он ждет ответа на > > первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый > > запрос и отправил второй и третий запрос в другом свободном конекте > > или открыл новый конект, но Nginx эти запросы будет держать в очереди > > и это очень плохо. > > Могу выслать код теста. > > > > Я ещё раз проверил, Nginx разносит три запроса из одного клиенского > соеденения, по разным соединениям бекенда только если клиент сделал запросы > по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу > HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского > соединения по разным соединениям бекенда. > [..] Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1 обрабатываются последовательно. Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для этого нужно отрыть 3 соединения и в каждом делать по запросу. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue May 24 14:52:47 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Tue, 24 May 2016 10:52:47 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: Message-ID: <538ecb5f397a1c71c842d3f9a2c171e0.NginxMailingListRussian@forum.nginx.org> Yuriy Medvedev Wrote: ------------------------------------------------------- > UP: посмотрел как у вас собран nginx и если не вы rpm билдили, тогда > это > стандартный пакет для rhel подобных Ну, если бы я не собирал rpm с помощью rpmbuild, не включал бы сторонние модули, то да это был бы стандартным пакет rhel, который можно скачать из http://nginx.org/packages/centos/6/x86_64/RPMS/ и да, вы были бы правы. А к чему мы об этом ? Вы намекаете на то, чтобы протестировать только те locations, которые не используют директивы сторонних модулей, удалив заодно сами директивы и попытаться дать нагрузку на стандартный пакет версии 1.4.2 ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267101#msg-267101 From vbart на nginx.com Tue May 24 14:56:12 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 May 2016 17:56:12 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> References: <02076b8f4c2d910cf1d1af99fb4f2b9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <2198413.BHS8FxjBSF@vbart-workstation> On Tuesday 24 May 2016 03:22:20 Vadim Osipov wrote: > h264, flv, mp4 - все это можно безболезненно убрать (есть выделенные > видеосервера). Использование h264, возможно, - legacy, пытались снизить > нагрузку с видеосерверов, точно не знаю. > > Push модуль точно нужен, используем его для организации comet-соединений. > > Из советов по проблеме, все-таки решил собрать 1.10 (хотя руководству не > очень нравится идея обычного и нагрузочного тестирования), там и убрал часть > сторонних модулей (осталось только заменить на эквиваленты, появившееся в > самом nginx). Ориентировочно так выглядит часть описания из configure: > --without-http_fastcgi_module \ > --without-http_uwsgi_module \ > --without-http_scgi_module \ > --without-http_ssi_module \ > --without-http_empty_gif_module \ > --with-http_ssl_module \ > --with-http_realip_module \ > --with-http_sub_module \ > --with-http_gunzip_module \ > --with-http_gzip_static_module \ > --with-http_stub_status_module \ > --with-http_xslt_module=dynamic \ > --with-http_image_filter_module=dynamic \ > --with-http_geoip_module=dynamic \ > --with-http_perl_module=dynamic \ > --add-dynamic-module=njs-%{module_njs_shaid}/nginx \ > --with-threads \ > --with-stream \ > --with-stream_ssl_module \ > --with-http_slice_module \ > --with-file-aio \ > --with-ipv6 \ > --add-module=nginx-push-stream-module-0.5.1 \ > --add-module=headers-more-nginx-module-0.29 \ > --add-module=echo-nginx-module-0.58 \ > А зачем echo нужен, если не секрет? -- Валентин Бартенев From basil на vpm.net.ua Tue May 24 15:13:14 2016 From: basil на vpm.net.ua (Vasiliy P. Melnik) Date: Tue, 24 May 2016 18:13:14 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <4116002.lrf6KTFWkW@vbart-workstation> References: <3424137.ZrRMcCNMxq@vbart-workstation> <4d02be503f3d96246bbf76a4a9332520.NginxMailingListRussian@forum.nginx.org> <5d5c464c9c624f867001e09f83005939.NginxMailingListRussian@forum.nginx.org> <4116002.lrf6KTFWkW@vbart-workstation> Message-ID: reuseport не поможет? 24 мая 2016 г., 17:49 пользователь Валентин Бартенев написал: > On Tuesday 24 May 2016 10:38:46 S.A.N wrote: > > > > Nginx никогда не посылает запрос в то же соединение, пока не > > > получит > > > > ответ > > > > и соединение освободиться. Т.н. pipelining он не умеет и не > > > > использует. > > > > > > > > Если бы следующий запрос пришел до того, как на первый был получен > > > > ответ, > > > > то он бы был отправлен на бекенд в другом соединении. > > > > > > > > Т.е. никакой проблемы между nginx и бекендом нет. > > > > > > Да, конечно Nginx не пошлет второй и третий запрос на бекенд, пока > > > первый не ответит, в этом и проблема, потому что он ждет ответа на > > > первый запрос, я бы ещё понял если бы Nginx не ждал ответа на первый > > > запрос и отправил второй и третий запрос в другом свободном конекте > > > или открыл новый конект, но Nginx эти запросы будет держать в очереди > > > и это очень плохо. > > > Могу выслать код теста. > > > > > > > Я ещё раз проверил, Nginx разносит три запроса из одного клиенского > > соеденения, по разным соединениям бекенда только если клиент сделал > запросы > > по протоколу HTTP/2, если клиент сделает эти три запроса по протоколу > > HTTP/1.1, тогда Nginx никогда не разносит запросы из одного клиентского > > соединения по разным соединениям бекенда. > > > [..] > > Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1 > обрабатываются последовательно. > > Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для этого > нужно отрыть 3 соединения и в каждом делать по запросу. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Tue May 24 15:18:45 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 24 May 2016 18:18:45 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <4677116.ZlDiD43GLd@vbart-workstation> Message-ID: <20160524151845.GO3184@sie.protva.ru> On Tue, May 24, 2016 at 08:34:57AM -0400, S.A.N wrote: > Протокол клиента HTTP/1.1 все три запроса браузер отправляет в одном > конекте. > Nginx отправляет все эти три запроса в одном конекте на бекенд. > > Теперь смотрим как все плохо в HTTP/1.1 когда в одном конекте приходит > очередь HTTP запросов, допустим время ответа у нас такое: > > GET /one HTTP/1.1 -- 500ms > GET /two HTTP/1.1 -- 20ms > GET /three HTTP/1.1 -- 10ms > > Бекенд многопоточный, он бы мог принять и обработать второй и третий запрос, > не дожидаясь обработки первого медленного запроса. В принципе да, Nginx мог бы обрабатывать эти запросы параллельно. Не знаю, делает он так или нет, но ответы всё равно придётся отдавать в сеть последовательно: в HTTP/1.1 есть лишь pipelining, который подразумевает сериализацию ответов, но нет мультиплексирования, которое позволило бы переставлять ответы местами и/или выдавать по частям. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Tue May 24 15:20:58 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 24 May 2016 11:20:58 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <4116002.lrf6KTFWkW@vbart-workstation> References: <4116002.lrf6KTFWkW@vbart-workstation> Message-ID: <1d9e5781f0d09d03812085ae59361ae2.NginxMailingListRussian@forum.nginx.org> > Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1 > обрабатываются последовательно. > > Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для > этого > нужно отрыть 3 соединения и в каждом делать по запросу. В этом то и проблема, браузеры на НТТР/1.1 часто экономят на новых соединениях и отправляют запросы в одном соединение. В наше время проще выделить серверу +1GB памяти на HTTP/2 для бекенда, чем выделить в линуксе +1 млн fd. Мультиплексированее запросов к бекенду, имеет технико экономическое обоснования. Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про Node.js, Go, etc.. Возможно уже пришло время, переосмыслить и переписать логику работы upstream в Nginx? Тогда асинхронные бекенды смогут эффективней работать. Спасибо. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267105#msg-267105 From vbart на nginx.com Tue May 24 15:34:06 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 May 2016 18:34:06 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <3424137.ZrRMcCNMxq@vbart-workstation> <4116002.lrf6KTFWkW@vbart-workstation> Message-ID: <8770448.r77inmPeje@vbart-workstation> On Tuesday 24 May 2016 18:13:14 Vasiliy P. Melnik wrote: > reuseport не поможет? > [..] SO_REUSEPORT к этому не имеет вообще никакого отношения. Проблема тут искусственно создана с помощью теста, который отправляет три запроса в одном соединении. Подробнее про reuseport тут: https://habrahabr.ru/post/259403/ -- Валентин Бартенев From vbart на nginx.com Tue May 24 15:41:24 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 May 2016 18:41:24 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <1d9e5781f0d09d03812085ae59361ae2.NginxMailingListRussian@forum.nginx.org> References: <4116002.lrf6KTFWkW@vbart-workstation> <1d9e5781f0d09d03812085ae59361ae2.NginxMailingListRussian@forum.nginx.org> Message-ID: <3186193.IdG2PfyTXa@vbart-workstation> On Tuesday 24 May 2016 11:20:58 S.A.N wrote: > > Всё верно, потому что запросы в одном соединении по протоколу HTTP/1.1 > > обрабатываются последовательно. > > > > Если вы хотите сделать три параллельных запроса в HTTP/1.1, то для > > этого > > нужно отрыть 3 соединения и в каждом делать по запросу. > > В этом то и проблема, браузеры на НТТР/1.1 часто экономят на новых > соединениях и отправляют запросы в одном соединение. > О чем речь. HTTP/2 - это протокол для общения браузеров с сервером, не более. Уберите из уравнения "браузер" и HTTP/2 вам не нужен. > В наше время проще выделить серверу +1GB памяти на HTTP/2 для бекенда, чем > выделить в линуксе +1 млн fd. > Мультиплексированее запросов к бекенду, имеет технико экономическое > обоснования. Какое? Вообще обоснование для HTTP/2 неплохо раписано у phk: http://queue.acm.org/detail.cfm?id=2716278 > > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про > Node.js, Go, etc.. > Возможно уже пришло время, переосмыслить и переписать логику работы upstream > в Nginx? > Тогда асинхронные бекенды смогут эффективней работать. > Асинхронный nginx прекрасно работает по HTTP/1.x сам с собой, так какие проблемы возникают у перечисленных фреймворков? -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue May 24 16:03:05 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Tue, 24 May 2016 12:03:05 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <1073706389.20160524115128@softsearch.ru> References: <1073706389.20160524115128@softsearch.ru> Message-ID: Михаил Монашёв Wrote: ------------------------------------------------------- > Здравствуйте, Vadim. > > > просмотрел Release notes от 1.4.2 и выше и какого упоминания о > > исправлении возможного бага в коде модуля memcached не заметил. > > Сторонние модули могут наводить проблемы для других модулей. Чем их > меньше, тем лучше. > > А обновиться стоит потому, что несколько secure-багов исправлено. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Ну да, нужно стремиться к меньшему количеству зависимостей от сторонних модулей, чтобы потом не приходилось вспоминать как работает push-stream модуль, что значит та или иная директива при выходе новой версии, писать разработчику этого же модуля, когда начинает течь память ну и нечто подобное с другими модулями (где то что то устарело, появилось в самом nginx и прочее). Ну и регулярно обновлять версию nginx, т.к. проект регулярно улучшается. Но дело в том, что нереально воспроизвести те условия, которые происходят у клиента на проде. И каждое обновление требует обычного, а затем нагрузочного тестирования, причем последнее делается со всевозможными погрешностями (и порой странной работой самих утилит нагрузочного тестирования; привет jMeter, tsung). А рисковать никто не хочет. Если работает, то зачем трогать. Поэтому, порой к сожалению прагматичнее с точки зрения стоимости нервов, времени и честности оставить все как есть. (Но кажется, мы отвлеклись от темы) P.S. сборку для 1.10 собрал, конфигурационные файлы поправил. Буду тестить Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267106#msg-267106 From nginx-forum на forum.nginx.org Tue May 24 16:26:22 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Tue, 24 May 2016 12:26:22 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <3186193.IdG2PfyTXa@vbart-workstation> References: <3186193.IdG2PfyTXa@vbart-workstation> Message-ID: <2786115ab124eec5a21a6cdd5003cd4c.NginxMailingListRussian@forum.nginx.org> > > > > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про > > Node.js, Go, etc.. > > Возможно уже пришло время, переосмыслить и переписать логику работы > upstream > > в Nginx? > > Тогда асинхронные бекенды смогут эффективней работать. > > > > Асинхронный nginx прекрасно работает по HTTP/1.x сам с собой, так > какие проблемы > возникают у перечисленных фреймворков? > Мы уже ходим по кругу :), я уже писал, что браузеры в реальной жизни часто отправляют множество запросов в одном соединении, в результате все эти запросы становятся в очередь к бекенду, вместо параллельного выполнения, вообще браузеры одновременно более 4-8 соединений не открывают, давайте говорить честно, Nginx выполняет запросы HTTP/1.x в одном соединении последовательно, а не асинхронно. Кстати nodejs/http-parser уже планируют реализовать HTTP/2, так что спрос на мультиплексирования запросов к бекенду, будет только расти. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267111#msg-267111 From mdounin на mdounin.ru Tue May 24 16:26:57 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 May 2016 19:26:57 +0300 Subject: nginx-1.11.0 Message-ID: <20160524162657.GC36620@mdounin.ru> Изменения в nginx 1.11.0 24.05.2016 *) Добавление: параметр transparent директив proxy_bind, fastcgi_bind, memcached_bind, scgi_bind и uwsgi_bind. *) Добавление: переменная $request_id. *) Добавление: директива map поддерживает комбинации нескольких переменных в качестве результирующих значений. *) Добавление: теперь при использовании метода epoll nginx проверяет, поддерживает ли ядро события EPOLLRDHUP, и соответственно оптимизирует обработку соединений. *) Добавление: директивы ssl_certificate и ssl_certificate_key теперь можно указывать несколько раз для загрузки сертификатов разных типов (например, RSA и ECDSA). *) Добавление: при использовании OpenSSL 1.0.2 и новее с помощью директивы ssl_ecdh_curve теперь можно задать список кривых; по умолчанию используется встроенный в OpenSSL список кривых. *) Изменение: для использования DHE-шифров теперь надо явно задавать файл параметров с помощью директивы ssl_dhparam. *) Добавление: переменная $proxy_protocol_port. *) Добавление: переменная $realip_remote_port в модуле ngx_http_realip_module. *) Добавление: модуль ngx_http_realip_module теперь позволяет устанавливать не только адрес, но и порт клиента. *) Изменение: при попытке запросить виртуальный сервер, отличающийся от согласованного в процессе SSL handshake, теперь возвращается ответ "421 Misdirected Request"; это улучшает совместимость с некоторыми HTTP/2-клиентами в случае использования клиентских сертификатов. *) Изменение: HTTP/2-клиенты теперь могут сразу присылать тело запроса; директива http2_body_preread_size позволяет указать размер буфера, который будет использоваться до того, как nginx начнёт читать тело. *) Исправление: при использовании директивы proxy_cache_bypass не обновлялись закэшированные ошибочные ответы. -- Maxim Dounin http://nginx.org/ From vbart на nginx.com Tue May 24 17:16:27 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 24 May 2016 20:16:27 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <2786115ab124eec5a21a6cdd5003cd4c.NginxMailingListRussian@forum.nginx.org> References: <3186193.IdG2PfyTXa@vbart-workstation> <2786115ab124eec5a21a6cdd5003cd4c.NginxMailingListRussian@forum.nginx.org> Message-ID: <1594782.SD342TD0Ol@vbart-workstation> On Tuesday 24 May 2016 12:26:22 S.A.N wrote: > > > > > > Даже в РНР появляются новые асинхронные фрейворки, не говоря уже про > > > Node.js, Go, etc.. > > > Возможно уже пришло время, переосмыслить и переписать логику работы > > > upstream > > > в Nginx? > > > Тогда асинхронные бекенды смогут эффективней работать. > > > > > > > Асинхронный nginx прекрасно работает по HTTP/1.x сам с собой, так > > какие проблемы > > возникают у перечисленных фреймворков? > > > > Мы уже ходим по кругу :), я уже писал, что браузеры в реальной жизни часто > отправляют множество запросов в одном соединении, в результате все эти > запросы становятся в очередь к бекенду, вместо параллельного выполнения, > вообще браузеры одновременно более 4-8 соединений не открывают, давайте > говорить честно, Nginx выполняет запросы HTTP/1.x в одном соединении > последовательно, а не асинхронно. Какой браузер отправляет в одном HTTP/1.1 соединении следующий запрос не дожидаясь ответа на предыдущий? Ещё раз, если речь идет об общении между бэкендом и nginx, то nginx так не делает, он использует столько соединений, сколько необходимо обработать запросов и ни один запрос не ждет в очереди. Ситуация браузер <-> сервер, и сервер <-> бэкенд - они разные, не нужно их мешать в одну кучу. Проблема, которую решает HTTP/2 возникает только между браузером и сервером, и только потому, что браузер по RFC ограничен в количестве TCP соединений. Когда такого ограничения нет, то HTTP/1 с одним запросом на соединение работает лучше и эффективнее. > > Кстати nodejs/http-parser уже планируют реализовать HTTP/2, так что спрос на > мультиплексирования запросов к бекенду, будет только расти. > Что совершенно не делает HTTP/2 лучшим выбором при общении с бэкендом. Мультиплексирование запросов к бекенду есть и без HTTP/2, на уровне TCP, и HTTP/2 тут только лишний оверхэд создает. Подозреваю, что уже для 1000 запросов оверхэд может стать весьма заметным. -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 25 08:39:27 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Wed, 25 May 2016 04:39:27 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <2198413.BHS8FxjBSF@vbart-workstation> References: <2198413.BHS8FxjBSF@vbart-workstation> Message-ID: <325c8b83b6963a21b70ff973a705971e.NginxMailingListRussian@forum.nginx.org> Это не секрет. Сейчас пробежался по конф. файлу - 1) для отладки (как альтернатива dummy location с return xxx "text" и log_format) 2) некоторые location содержат location /some_url/jsonpp/ { echo_before_body "core.RequestManager.response("; proxy_pass http://localhost/some_url2/; echo_after_body ");"; } Насчет 2го - ничего не могу сказать, писалось не мною и не при мне. Возможно, стоит вынести на app server. Видимо, делалось как ad-hoc решение. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267133#msg-267133 From vbart на nginx.com Wed May 25 09:08:42 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 25 May 2016 12:08:42 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <325c8b83b6963a21b70ff973a705971e.NginxMailingListRussian@forum.nginx.org> References: <2198413.BHS8FxjBSF@vbart-workstation> <325c8b83b6963a21b70ff973a705971e.NginxMailingListRussian@forum.nginx.org> Message-ID: <9648764.Nbkp3NL1GN@vbart-laptop> On Wednesday 25 May 2016 04:39:27 Vadim Osipov wrote: > Это не секрет. > Сейчас пробежался по конф. файлу - > 1) для отладки (как альтернатива dummy location с return xxx "text" и > log_format) > 2) некоторые location содержат > location /some_url/jsonpp/ { > echo_before_body "core.RequestManager.response("; > proxy_pass http://localhost/some_url2/; > echo_after_body ");"; > } > Насчет 2го - ничего не могу сказать, писалось не мною и не при мне. > Возможно, стоит вынести на app server. Видимо, делалось как ad-hoc решение. > Т.е. модуль в действительности не нужен, поскольку и то, и другое делается штатными средствами. http://nginx.org/ru/docs/http/ngx_http_addition_module.html -- Валентин Бартенев From nginx-forum на forum.nginx.org Wed May 25 10:28:28 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Wed, 25 May 2016 06:28:28 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: Message-ID: <580ae64b625dde4899db65fdf28efd3a.NginxMailingListRussian@forum.nginx.org> 1) Проверил у себя, да, в те 3 location, в которые поступали запросы с дальнейшим перенаправлением в memcached, имеются директивы из headers-more-nginx-module. Попробую выполнить запросы на эти location с отрубанием memcached по kill -11 2) Спасибо за ссылки, тоже обратил внимание FAILED ./configure --with-debug --with-pcre --with-pcre-jit --with-http_dav_module --add-module=.. --add-module=../echo-nginx-module --add-module=../lua-nginx-module --add-module=../nginx-eval-module PASSED ./configure --with-debug --with-pcre --with-pcre-jit --with-http_dav_module --add-module=../nginx-eval-module --add-module=../lua-nginx-module --add-module=../echo-nginx-module --add-module=.. > build.log 2>&1 || (cat build.log && exit 1) not ok 73 - TEST 12: set multi-value header to a single value - response_body - response is expected (req 0) интересно, какой случай этот тест проверяет ? Когда в результате указанных директив nginx должен вернуть больше 1 header с идентичным ключом, но разным значением ? Например: Content-Type: application/javascript Content-Type: application/json ? 3) тестирование - вещь добрая и нужная, только есть 2 основные версии и куча минорных для наших клиентов, клиентов по обе стороны немало, в каждой версии есть разного объема правки в файлах конфигурации nginx. Чтобы по феншую провести, нужно создать окружение как у клиента, желательно такую же машину, но нагрузку нереально достоверно точно сымулировать, в лучшем случае jMeter-ом записать что есть, что стало. И если делать максимально правильно, то может занять немало времени, а т.к., видимо, у клиентов есть проблемы, но продолжают есть кактусы, то начальство не очень заинтересовано в трате времени на разворачивание стенда (-ов если логику с comet проверять) для проверки старых версий. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267138#msg-267138 From nginx-forum на forum.nginx.org Wed May 25 10:42:44 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Wed, 25 May 2016 06:42:44 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <9648764.Nbkp3NL1GN@vbart-laptop> References: <9648764.Nbkp3NL1GN@vbart-laptop> Message-ID: <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > > Т.е. модуль в действительности не нужен, поскольку и то, > и другое делается штатными средствами. > > http://nginx.org/ru/docs/http/ngx_http_addition_module.html > тогда получается, чтобы сделать то же самое с помощью ngx_http_addition_module, но без echo И правки кода на app server, теоретически нужно только изменить текущий и добавить 2 location вида location /some_url/jsonpp/ { add_before_body /before; proxy_pass http://localhost/some_url2/; add_after_body /after; } location /before { return 200 "core.RequestManager.response("; } location /after { return 200 ");"; } ? (ну и подключить сам модуль) P.S. извините, за изврат :) Вы наверное и не такого насмотрелись, что люди вытворяют Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267139#msg-267139 From nginx-forum на forum.nginx.org Wed May 25 11:19:04 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Wed, 25 May 2016 07:19:04 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <1594782.SD342TD0Ol@vbart-workstation> References: <1594782.SD342TD0Ol@vbart-workstation> Message-ID: <6f20985bcb1adba2d6aa04f5664c8822.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: > Какой браузер отправляет в одном HTTP/1.1 соединении следующий запрос > не > дожидаясь ответа на предыдущий? Вы правы, я наконец то понял, браузеры отправляют в одном соединении запросы последовательно, всегда дожидаясь ответа на предыдущий, т.е. очередь запросов в соединении нет, по этому сделать какое-то мультиплексирования не выйдет, потому что сервер не сможет прочитать из сокета новые запросы пока не ответит на предыдущий запрос. > и HTTP/2 тут только лишний оверхэд создает. Подозреваю, что уже для > 1000 запросов оверхэд может стать весьма заметным. В спеке протокола FastCGI есть мультиплексирование, правда его ещё никто не реализовал, но если HTTP/2 дает большой оверхед, возможно FastCGI будет лучше, для мультиплексирования запросов Nginx к бекендам? Нам это особенно нужно вот для чего: Наши бекенды (микросервисы) делают запросы друг к другу внутри дата центра, запросы ходят через Nginx, он нужен для кеширования и балансировки, ~70% ответов Nginx отдает из своего кеша, причем этот кеш публичный, клиенты могут его загружать из вне аяксом. Вот здесь я уже про это спрашивал https://forum.nginx.org/read.php?21,266537 Раньше мы для этого использовали мемкеш, это было очень просто и удобно бекенд делает gets (мультигет) получает кучу ответов, теперь когда перешли на НТТР, сделать такой мультигет запрос к Nginx оказывается нельзя, я знаю что бекенд может каждый запрос послать в отдельном соединении, но в результате очень много одновременно открытых дескрипторов, и там тоже свои оверхеды. Кстати если Nginx, будет уметь слушать протокол мемкеша, он бы мог стать для многих отличной его заменой, схема простая Nginx принимает запросы по протоколу мемкеш, интерпритирует их как НТТР, проверяет наличия ответа в своем кеше, если нет, отправляет запрос на бекенд, получает ответ от бекенда, сохраняет его в кеше, схема очень удобная. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267140#msg-267140 From vbart на nginx.com Wed May 25 11:27:40 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 25 May 2016 14:27:40 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> References: <9648764.Nbkp3NL1GN@vbart-laptop> <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> Message-ID: <13436138.CKIggCj38S@vbart-workstation> On Wednesday 25 May 2016 06:42:44 Vadim Osipov wrote: > Валентин Бартенев Wrote: > ------------------------------------------------------- > > > > Т.е. модуль в действительности не нужен, поскольку и то, > > и другое делается штатными средствами. > > > > http://nginx.org/ru/docs/http/ngx_http_addition_module.html > > > > тогда получается, чтобы сделать то же самое с помощью > ngx_http_addition_module, но без echo И правки кода на app server, > теоретически нужно только изменить текущий и добавить 2 location вида > > location /some_url/jsonpp/ { > add_before_body /before; > proxy_pass http://localhost/some_url2/; > add_after_body /after; > } > > location /before { > return 200 "core.RequestManager.response("; > } > > location /after { > return 200 ");"; > } > > ? > (ну и подключить сам модуль) > [..] Да, как-то так. И не забыть addition_types настроить. Можно ещё добавить internal и использовать точное совпадение: location =/before { internal; return 200 "core.RequestManager.response("; } location =/after { internal; return 200 ");"; } И вместо стороннего модуля на 4000+ строк кода вы будете использовать стандартный из 200 строк. -- Валентин Бартенев From denis на webmaster.spb.ru Wed May 25 12:27:41 2016 From: denis на webmaster.spb.ru (denis) Date: Wed, 25 May 2016 15:27:41 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> References: <9648764.Nbkp3NL1GN@vbart-laptop> <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> Message-ID: <57459A3D.1070005@webmaster.spb.ru> 25.05.2016 13:42, Vadim Osipov пишет: > > P.S. извините, за изврат :) Вы наверное и не такого насмотрелись, что люди > вытворяют "Изврат" люди вытворяют, когда надо например получить параметр из POST без lua, а здесь так, цветочки. From chipitsine на gmail.com Wed May 25 14:26:24 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 25 May 2016 19:26:24 +0500 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <580ae64b625dde4899db65fdf28efd3a.NginxMailingListRussian@forum.nginx.org> References: <580ae64b625dde4899db65fdf28efd3a.NginxMailingListRussian@forum.nginx.org> Message-ID: если не секрет, как именно используется headers-more-nginx-module ? 25 мая 2016 г., 15:28 пользователь Vadim Osipov написал: > 1) Проверил у себя, да, в те 3 location, в которые поступали запросы с > дальнейшим перенаправлением в memcached, имеются директивы из > headers-more-nginx-module. > Попробую выполнить запросы на эти location с отрубанием memcached по kill > -11 > > 2) Спасибо за ссылки, тоже обратил внимание > FAILED > ./configure --with-debug --with-pcre --with-pcre-jit --with-http_dav_module > > --add-module=.. > --add-module=../echo-nginx-module > --add-module=../lua-nginx-module > --add-module=../nginx-eval-module > > PASSED > ./configure --with-debug --with-pcre --with-pcre-jit --with-http_dav_module > > --add-module=../nginx-eval-module > --add-module=../lua-nginx-module > --add-module=../echo-nginx-module > --add-module=.. > > build.log 2>&1 || (cat build.log && exit 1) > > not ok 73 - TEST 12: set multi-value header to a single value - > response_body - response is expected (req 0) > > интересно, какой случай этот тест проверяет ? > Когда в результате указанных директив nginx должен вернуть больше 1 header > с > идентичным ключом, но разным значением ? > Например: > Content-Type: application/javascript > Content-Type: application/json > ? > 3) тестирование - вещь добрая и нужная, только есть 2 основные версии и > куча > минорных для наших клиентов, клиентов по обе стороны немало, в каждой > версии > есть разного объема правки в файлах конфигурации nginx. Чтобы по феншую > провести, нужно создать окружение как у клиента, желательно такую же > машину, > но нагрузку нереально достоверно точно сымулировать, в лучшем случае > jMeter-ом записать что есть, что стало. И если делать максимально > правильно, > то может занять немало времени, а т.к., видимо, у клиентов есть проблемы, > но > продолжают есть кактусы, то начальство не очень заинтересовано в трате > времени на разворачивание стенда (-ов если логику с comet проверять) для > проверки старых версий. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,267049,267138#msg-267138 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From kpoxa на kpoxa.net Wed May 25 14:35:33 2016 From: kpoxa на kpoxa.net (kpoxa) Date: Wed, 25 May 2016 14:35:33 +0000 Subject: =?UTF-8?B?0J3QtdGB0LrQvtC70YzQutC+INC00L7QvNC10L3QvtCyINGBIFNTTA==?= In-Reply-To: <57459A3D.1070005@webmaster.spb.ru> References: <9648764.Nbkp3NL1GN@vbart-laptop> <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> <57459A3D.1070005@webmaster.spb.ru> Message-ID: Добрый день. А как лучше описать несколько доменов с SSL для одного сервера? -- Рустам -------------- next part -------------- An HTML attachment was scrubbed... URL: From russjura на gmail.com Wed May 25 15:00:15 2016 From: russjura на gmail.com (=?UTF-8?B?0K7RgNC40Lk=?=) Date: Wed, 25 May 2016 17:00:15 +0200 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQtNC+0LzQtdC90L7QsiDRgSBTU0w=?= In-Reply-To: References: <9648764.Nbkp3NL1GN@vbart-laptop> <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> <57459A3D.1070005@webmaster.spb.ru> Message-ID: каждый сайт - свой конфиг. Проверенная и рабочая годами схема - достаточно производительно. 25 мая 2016 г., 16:35 пользователь kpoxa написал: > Добрый день. > > А как лучше описать несколько доменов с SSL для одного сервера? > > -- > Рустам > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Wed May 25 15:59:09 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 25 May 2016 18:59:09 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <6f20985bcb1adba2d6aa04f5664c8822.NginxMailingListRussian@forum.nginx.org> References: <1594782.SD342TD0Ol@vbart-workstation> <6f20985bcb1adba2d6aa04f5664c8822.NginxMailingListRussian@forum.nginx.org> Message-ID: <1713838.kUFZltc2o1@vbart-workstation> On Wednesday 25 May 2016 07:19:04 S.A.N wrote: [..] > Раньше мы для этого использовали мемкеш, это было очень просто и удобно > бекенд делает gets (мультигет) получает кучу ответов, теперь когда перешли > на НТТР, сделать такой мультигет запрос к Nginx оказывается нельзя, я знаю > что бекенд может каждый запрос послать в отдельном соединении, но в > результате очень много одновременно открытых дескрипторов, и там тоже свои > оверхеды. > > Кстати если Nginx, будет уметь слушать протокол мемкеша, он бы мог стать для > многих отличной его заменой, схема простая Nginx принимает запросы по > протоколу мемкеш, интерпритирует их как НТТР, проверяет наличия ответа в > своем кеше, если нет, отправляет запрос на бекенд, получает ответ от > бекенда, сохраняет его в кеше, схема очень удобная. > [..] Если необходимо вытащить множество разных данных одним запросом, то для этого есть SSI. Причем разные части будут доставаться параллельно и складываться в один большой ответ достаточно эффективно. -- Валентин Бартенев From bgx на protva.ru Wed May 25 16:01:36 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 25 May 2016 19:01:36 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <6f20985bcb1adba2d6aa04f5664c8822.NginxMailingListRussian@forum.nginx.org> References: <1594782.SD342TD0Ol@vbart-workstation> <6f20985bcb1adba2d6aa04f5664c8822.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160525160136.GQ3184@sie.protva.ru> On Wed, May 25, 2016 at 07:19:04AM -0400, S.A.N wrote: > Вы правы, я наконец то понял, браузеры отправляют в одном соединении запросы > последовательно, всегда дожидаясь ответа на предыдущий, т.е. очередь > запросов в соединении нет, по этому сделать какое-то мультиплексирования не > выйдет, потому что сервер не сможет прочитать из сокета новые запросы пока > не ответит на предыдущий запрос. Напишу ещё раз: браузеры могут посылать пачки запросов по http/1.1, это называется pipelining, но ответы в http/1.1 должны идти строго в том же порядке, что и запросы. > > и HTTP/2 тут только лишний оверхэд создает. Подозреваю, что уже для > > 1000 запросов оверхэд может стать весьма заметным. > > В спеке протокола FastCGI есть мультиплексирование, правда его ещё никто не > реализовал, но если HTTP/2 дает большой оверхед, возможно FastCGI будет > лучше, для мультиплексирования запросов Nginx к бекендам? Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2. Но само по себе мультиплексирование не является самоцелью, оно может быть уместно в каких-то вычурных ситуациях (вроде исчерпания сокетов), которые на самом деле разруливаются другими методами. Нужно понимать, что мультиплексирование связано с дополнительным оверхедом (на буферы, разбор потока и т.п.), который при отсутствии мультиплексирования переносится на уровень ядра ОС. А ядро обычно решает свои проблемы очень эффективно, и было бы наивно надеяться на то, что управление потоком в прикладной программе будет лучше, чем в сетевом стэке. -- Eugene Berdnikov From vbart на nginx.com Wed May 25 16:07:48 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 25 May 2016 19:07:48 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <20160525160136.GQ3184@sie.protva.ru> References: <1594782.SD342TD0Ol@vbart-workstation> <6f20985bcb1adba2d6aa04f5664c8822.NginxMailingListRussian@forum.nginx.org> <20160525160136.GQ3184@sie.protva.ru> Message-ID: <5813621.x5iEfDb9m0@vbart-workstation> On Wednesday 25 May 2016 19:01:36 Evgeniy Berdnikov wrote: > On Wed, May 25, 2016 at 07:19:04AM -0400, S.A.N wrote: > > Вы правы, я наконец то понял, браузеры отправляют в одном соединении запросы > > последовательно, всегда дожидаясь ответа на предыдущий, т.е. очередь > > запросов в соединении нет, по этому сделать какое-то мультиплексирования не > > выйдет, потому что сервер не сможет прочитать из сокета новые запросы пока > > не ответит на предыдущий запрос. > > Напишу ещё раз: браузеры могут посылать пачки запросов по http/1.1, > это называется pipelining, но ответы в http/1.1 должны идти строго > в том же порядке, что и запросы. > По факту ни один популярный браузер pipelining не использует, если только специально глубоко в настройках это не включить. Могут но не делают. > > > и HTTP/2 тут только лишний оверхэд создает. Подозреваю, что уже для > > > 1000 запросов оверхэд может стать весьма заметным. > > > > В спеке протокола FastCGI есть мультиплексирование, правда его ещё никто не > > реализовал, но если HTTP/2 дает большой оверхед, возможно FastCGI будет > > лучше, для мультиплексирования запросов Nginx к бекендам? > > Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2. > > Но само по себе мультиплексирование не является самоцелью, оно может > быть уместно в каких-то вычурных ситуациях (вроде исчерпания сокетов), > которые на самом деле разруливаются другими методами. Нужно понимать, > что мультиплексирование связано с дополнительным оверхедом (на буферы, > разбор потока и т.п.), который при отсутствии мультиплексирования > переносится на уровень ядра ОС. А ядро обычно решает свои проблемы > очень эффективно, и было бы наивно надеяться на то, что управление > потоком в прикладной программе будет лучше, чем в сетевом стэке. > Всё так. -- Валентин Бартенев From kpoxa на kpoxa.net Wed May 25 16:22:41 2016 From: kpoxa на kpoxa.net (kpoxa) Date: Wed, 25 May 2016 16:22:41 +0000 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQtNC+0LzQtdC90L7QsiDRgSBTU0w=?= In-Reply-To: References: <9648764.Nbkp3NL1GN@vbart-laptop> <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> <57459A3D.1070005@webmaster.spb.ru> Message-ID: Часто это неудобно, хочется единым конфигом и без инклюдов. ср, 25 мая 2016 г. в 18:00, Юрий : > каждый сайт - свой конфиг. Проверенная и рабочая годами схема - достаточно > производительно. > > 25 мая 2016 г., 16:35 пользователь kpoxa написал: > >> Добрый день. >> >> А как лучше описать несколько доменов с SSL для одного сервера? >> >> -- >> Рустам >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine на gmail.com Wed May 25 16:56:56 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 25 May 2016 21:56:56 +0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDQtNC+0LzQtdC90L7QsiDRgSBTU0w=?= In-Reply-To: References: <9648764.Nbkp3NL1GN@vbart-laptop> <4c3695620700d8a0c79f2d97acb8b8a9.NginxMailingListRussian@forum.nginx.org> <57459A3D.1070005@webmaster.spb.ru> Message-ID: пардон, а что мешает сделать как вам удобно? 25 мая 2016 г., 21:22 пользователь kpoxa написал: > Часто это неудобно, хочется единым конфигом и без инклюдов. > > ср, 25 мая 2016 г. в 18:00, Юрий : > >> каждый сайт - свой конфиг. Проверенная и рабочая годами схема - >> достаточно производительно. >> >> 25 мая 2016 г., 16:35 пользователь kpoxa написал: >> >>> Добрый день. >>> >>> А как лучше описать несколько доменов с SSL для одного сервера? >>> >>> -- >>> Рустам >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu May 26 10:17:00 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Thu, 26 May 2016 06:17:00 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> References: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> Message-ID: <00db80b234f9060383023f6114a4b30d.NginxMailingListRussian@forum.nginx.org> Новые подробности. Благодаря советам, решил попытаться дать такую нагрузку на nginx, чтобы потом заsegfault-ив memcached, попытаться смоделировать у проблему у клиента. Однако, заинтересовала ситуация, возможно, подобная тому, что есть у клиента, по меньшей мере, по загрузке CPU и косвенным признакам, что memcached является причиной. В общем. upstream memcached_cluster { server 10.197.162.35:11211; # <------ такого memcached нету либо он не запущен (или упал, завис как в случае как у клиента) hash $uri/3.6; hash_again 1000; keepalive 512; } Запускаю nginx с описанным выше upstream. Если запросов нету, которые приводят к обращению к memcached_cluster, то все нормально, но когда приходит несколько запросов (может быть даже 1, точно не скажу, но 5-10 точно хватит), начинается загрузка CPU примерно 96-99.5% при server, который не работает (или был, но упал/завис). Естественно, если server работает, то все нормально и такой загрузки нету. После такой загрузки, service nginx stop/restart пытается остановить, перезапустить сервис, но ... я не дождался. Более подробно - ниже. ------------------------------------------------------------------------------------------------------------ ps uax | grep nginx USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND nginx 5072 0.0 0.2 428488 16500 ? S 11:03 0:00 nginx: worker process nginx 5073 0.0 0.2 428488 16500 ? S 11:03 0:00 nginx: worker process nginx 5074 0.0 0.2 428488 16500 ? S 11:03 0:00 nginx: worker process nginx 5075 0.0 0.0 416764 4724 ? S 11:03 0:00 nginx: cache manager process root 15711 0.0 0.1 416764 6532 ? Ss May25 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 15715 3.8 0.2 426956 15468 ? R< May25 40:17 nginx: worker process root 5130 0.0 0.0 103268 896 pts/2 S+ 11:03 0:00 grep nginx ------------------------------------------------------------------------------------------------------------ top top - 11:08:11 up 2 days, 2 min, 3 users, load average: 1.03, 1.03, 0.92 Tasks: 96 total, 2 running, 94 sleeping, 0 stopped, 0 zombie Cpu(s): 98.0%us, 0.0%sy, 2.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 5993264k total, 2813292k used, 3179972k free, 221772k buffers Swap: 3145724k total, 0k used, 3145724k free, 1060512k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15715 nginx 15 -5 416m 15m 1256 R 97.2 0.3 44:23.91 nginx ------------------------------------------------------------------------------------------------------------ # service nginx restart nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Stopping nginx:..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C Пришлось, как видно, сделать Ctrl + C, а затем kill -9 ------------------------------------------------------------------------------------------------------------ error_log в режим error: 2016/05/26 11:21:29 [alert] 15711#0: worker process 15715 exited on signal 9 2016/05/26 11:24:42 [error] 7159#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 172.16.11.46, server: 10.197.162.35, request: "GET /url1?rnd=0.7008626744856947 HTTP/1.1", upstream: "memcached://10.197.164.22:11211", host: "172.20.1.240", referrer: "http://172.20.1.240/url2" 2016/05/26 11:24:47 [error] 7159#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 172.16.11.46, server: 10.197.162.35, request: "GET /url1?rnd=0.7008626744856947 HTTP/1.1", upstream: "memcached://10.197.162.35:11211", host: "172.20.1.240", referrer: "http://172.20.1.240/url2" ------------------------------------------------------------------------------------------------------------ Установил error_log в режим info: 2016/05/26 12:15:51 [notice] 11221#0: using the "epoll" event method 2016/05/26 12:15:51 [notice] 11221#0: nginx/1.4.2 2016/05/26 12:15:51 [notice] 11221#0: built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) 2016/05/26 12:15:51 [notice] 11221#0: OS: Linux 2.6.32-504.12.2.el6.x86_64 2016/05/26 12:15:51 [notice] 11221#0: getrlimit(RLIMIT_NOFILE): 2048:4096 2016/05/26 12:15:51 [notice] 11222#0: start worker processes 2016/05/26 12:15:51 [notice] 11222#0: start worker process 11224 2016/05/26 12:15:51 [notice] 11222#0: start worker process 11225 2016/05/26 12:15:51 [notice] 11222#0: start worker process 11226 2016/05/26 12:15:51 [notice] 11222#0: start cache manager process 11227 2016/05/26 12:15:51 [notice] 11222#0: start cache loader process 11228 2016/05/26 12:16:51 [notice] 11228#0: http file cache: /var/cache/nginx/ftl 0.055M, bsize: 4096 2016/05/26 12:16:51 [notice] 11228#0: http file cache: /var/cache/nginx/systemConfig 0.008M, bsize: 4096 2016/05/26 12:16:51 [notice] 11228#0: http file cache: /var/cache/nginx/banners 0.000M, bsize: 4096 2016/05/26 12:16:51 [notice] 11228#0: http file cache: /dev/shm/screenshots 0.000M, bsize: 4096 2016/05/26 12:16:51 [notice] 11222#0: signal 17 (SIGCHLD) received 2016/05/26 12:16:51 [notice] 11222#0: cache loader process 11228 exited with code 0 2016/05/26 12:16:51 [notice] 11222#0: signal 29 (SIGIO) received 2016/05/26 12:20:35 [error] 11224#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: 172.16.11.46, server: 10.197.162.35, request: "GET /url1?rnd=0.9631175188545227 HTTP/1.1", upstream: "memcached://10.197.162.35:11211", host: "172.20.1.240", referrer: "http://172.20.1.240/url2" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267159#msg-267159 From nginx-forum на forum.nginx.org Thu May 26 10:18:55 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Thu, 26 May 2016 06:18:55 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <13436138.CKIggCj38S@vbart-workstation> References: <13436138.CKIggCj38S@vbart-workstation> Message-ID: Спасибо. Появились некоторые новые детали, которые, возможно, будут интересны вам. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267160#msg-267160 From nginx-forum на forum.nginx.org Thu May 26 10:24:47 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Thu, 26 May 2016 06:24:47 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <00db80b234f9060383023f6114a4b30d.NginxMailingListRussian@forum.nginx.org> References: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> <00db80b234f9060383023f6114a4b30d.NginxMailingListRussian@forum.nginx.org> Message-ID: Vadim Osipov Wrote: ------------------------------------------------------- > Новые подробности. Благодаря советам, решил попытаться дать такую > upstream memcached_cluster { > server 10.197.162.35:11211; # <------ такого memcached нету > либо он не запущен (или упал, завис как в случае как у клиента) > hash $uri/3.6; > hash_again 1000; > keepalive 512; > } > > # service nginx restart > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok > nginx: configuration file /etc/nginx/nginx.conf test is successful > Stopping > nginx:................................................................ > ...................................................................... > ...................................................................... > ...................................................................... > ...................................................................... > ...................................................................... > ............................................................^C Забыл добавить, что пытался как лечить Установка memcached_connect_time с 60s на 5s; Убирание директивы worker_priority -5; Добавление fail_timeout=15s max_fails=3; к server 10.197.162.35:11211; - не помогло Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267161#msg-267161 From vbart на nginx.com Thu May 26 10:29:07 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 26 May 2016 13:29:07 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <00db80b234f9060383023f6114a4b30d.NginxMailingListRussian@forum.nginx.org> References: <4f64517c82d6c6a68aaa560614787c9f.NginxMailingListRussian@forum.nginx.org> <00db80b234f9060383023f6114a4b30d.NginxMailingListRussian@forum.nginx.org> Message-ID: <1750202.phguYkLvNH@vbart-laptop> On Thursday 26 May 2016 06:17:00 Vadim Osipov wrote: > Новые подробности. Благодаря советам, решил попытаться дать такую нагрузку > на nginx, чтобы потом заsegfault-ив memcached, попытаться смоделировать у > проблему у клиента. Однако, заинтересовала ситуация, возможно, подобная > тому, что есть у клиента, по меньшей мере, по загрузке CPU и косвенным > признакам, что memcached является причиной. > > В общем. > > upstream memcached_cluster { > server 10.197.162.35:11211; # <------ такого memcached нету либо он > не запущен (или упал, завис как в случае как у клиента) > hash $uri/3.6; > hash_again 1000; Такой директивы как hash_again в стандартном nginx нет. Это видимо какой-то сторонний модуль для балансировки, и логично предположить, что именно он и есть причина ваших бед. -- Валентин Бартенев From nginx-forum на forum.nginx.org Thu May 26 11:16:46 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 26 May 2016 07:16:46 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <1713838.kUFZltc2o1@vbart-workstation> References: <1713838.kUFZltc2o1@vbart-workstation> Message-ID: <53b4763e8b925427b46afba16b94543e.NginxMailingListRussian@forum.nginx.org> > Если необходимо вытащить множество разных данных одним запросом, то > для > этого есть SSI. Причем разные части будут доставаться параллельно и > складываться в один большой ответ достаточно эффективно. SSI здесь не поможет, нам надо чтобы бекенд получил данные из другого бекенда, обработал их и отдал клиенту. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267165#msg-267165 From nginx-forum на forum.nginx.org Thu May 26 11:28:59 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 26 May 2016 07:28:59 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <20160525160136.GQ3184@sie.protva.ru> References: <20160525160136.GQ3184@sie.protva.ru> Message-ID: > Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2. > > Но само по себе мультиплексирование не является самоцелью, оно может > быть уместно в каких-то вычурных ситуациях (вроде исчерпания > сокетов), > которые на самом деле разруливаются другими методами. Подскажите где почитать про другие эффективные методы решения дефицита свободных fd в линуксе? Сейчас fd улетают как горячие пирожки, реал юзкейс Nginx, получает соединения от клиента, открывает соединения к бекенду, а бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от других бекендов, нам же приходится каждый запрос делать в отдельном соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для этой пустяковой задачи мы уже потратили 93 fd. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267166#msg-267166 From nginx-forum на forum.nginx.org Thu May 26 12:04:59 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Thu, 26 May 2016 08:04:59 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: Message-ID: <077552d74f5dbd3795a28e80726e20dc.NginxMailingListRussian@forum.nginx.org> location /screenshot/ { if ($request_method != GET) { proxy_pass http://127.0.0.1:8080; break; } more_clear_headers 'Content-Type'; more_clear_headers 'Cache-Control'; more_set_headers 'Content-Type: image/jpeg'; more_set_headers 'Cache-Control: no-cache'; add_header Cache-Control no-cache; add_header Content-Type image/jpeg; default_type image/jpeg; recursive_error_pages on; proxy_pass http://screenshots; proxy_cache_key $scheme$proxy_host$uri; proxy_cache screenshots-cache; proxy_cache_valid 200 302 1m; proxy_cache_valid 404 1m; proxy_ignore_headers X-Accel-Redirect; proxy_ignore_headers X-Accel-Expires Expires Cache-Control; proxy_hide_header "Set-Cookie"; proxy_cache_lock on; proxy_cache_lock_timeout 15s; proxy_intercept_errors on; proxy_connect_timeout 3s; proxy_send_timeout 3s; proxy_read_timeout 3s; error_page 404 502 504 = @logo; } location @logo { set $memcached_key "$uri/$tve_version"; memcached_pass memcached_cluster; error_page 404 502 504 = @fallback; } location @fallback { proxy_pass http://127.0.0.1:8080; root /usr/share/nginx/html; index index.html index.htm; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267167#msg-267167 From nginx-forum на forum.nginx.org Thu May 26 12:11:05 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Thu, 26 May 2016 08:11:05 -0400 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <1750202.phguYkLvNH@vbart-laptop> References: <1750202.phguYkLvNH@vbart-laptop> Message-ID: <8c16f8f20d27bb7f7349b57008f22c17.NginxMailingListRussian@forum.nginx.org> Да, это из модуля nginx_upstream_hash. Я когда 1.10 собирал ее удалил и для версии что у клиента 1.4.2 забыл, что она есть. И даже забыл, что она не из nginx. Убрал, проверил, нагрузки не возникает, спасибо большое вам и всем остальным (bow) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267049,267168#msg-267168 From vbart на nginx.com Thu May 26 12:20:03 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 26 May 2016 15:20:03 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <077552d74f5dbd3795a28e80726e20dc.NginxMailingListRussian@forum.nginx.org> References: <077552d74f5dbd3795a28e80726e20dc.NginxMailingListRussian@forum.nginx.org> Message-ID: <1804402.6SdrBpJsbq@vbart-workstation> On Thursday 26 May 2016 08:04:59 Vadim Osipov wrote: > location /screenshot/ { > if ($request_method != GET) { > proxy_pass http://127.0.0.1:8080; > break; > } > > more_clear_headers 'Content-Type'; > more_clear_headers 'Cache-Control'; Это делается с помощью proxy_hide_header. > more_set_headers 'Content-Type: image/jpeg'; > more_set_headers 'Cache-Control: no-cache'; > > add_header Cache-Control no-cache; > add_header Content-Type image/jpeg; Это какой-то перебор. Модуль headers-more-nginx-module вам тоже не нужен, всё это реализуется штатными средствами. -- Валентин Бартенев From bgx на protva.ru Thu May 26 12:39:00 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 26 May 2016 15:39:00 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <20160525160136.GQ3184@sie.protva.ru> Message-ID: <20160526123900.GT3184@sie.protva.ru> On Thu, May 26, 2016 at 07:28:59AM -0400, S.A.N wrote: > > Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2. > > > > Но само по себе мультиплексирование не является самоцелью, оно может > > быть уместно в каких-то вычурных ситуациях (вроде исчерпания > > сокетов), > > которые на самом деле разруливаются другими методами. > > Подскажите где почитать про другие эффективные методы решения дефицита > свободных fd в линуксе? > > Сейчас fd улетают как горячие пирожки, реал юзкейс Интересно, сколько нужно открыть fd чтобы ощутить их дефицит в системе? > Nginx, получает соединения от клиента, открывает соединения к бекенду, а > бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от > других бекендов, нам же приходится каждый запрос делать в отдельном > соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для > этой пустяковой задачи мы уже потратили 93 fd. Если у клиента такая логика, что он делает 30 запросов json одновременно, может быть, стоит подумать о пересмотре модели работы клиента? Так ли уж там нужна параллельная обработка этих 30 запросов? -- Eugene Berdnikov From postmaster на softsearch.ru Thu May 26 13:17:24 2016 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Thu, 26 May 2016 16:17:24 +0300 Subject: nginx-1.11.0 In-Reply-To: <20160524162657.GC36620@mdounin.ru> References: <20160524162657.GC36620@mdounin.ru> Message-ID: <1086476033.20160526161724@softsearch.ru> Здравствуйте, Maxim. > *) Добавление: переменная $request_id. Это таймстамп+счётчик? -- С уважением, Михаил mailto:postmaster на softsearch.ru From v.tolstov на selfip.ru Thu May 26 13:57:00 2016 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Thu, 26 May 2016 16:57:00 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <1804402.6SdrBpJsbq@vbart-workstation> References: <077552d74f5dbd3795a28e80726e20dc.NginxMailingListRussian@forum.nginx.org> <1804402.6SdrBpJsbq@vbart-workstation> Message-ID: 26 мая 2016 г., 15:20 пользователь Валентин Бартенев написал: > Это какой-то перебор. > > Модуль headers-more-nginx-module вам тоже не нужен, > всё это реализуется штатными средствами. Может на сайте nginx где-то в доках указать хауту для таких целей, например - есть модуль такой-то - можно использовать стандартный nginx для этого так-то...? -- Vasiliy Tolstov, e-mail: v.tolstov на yoctocloud.net From mdounin на mdounin.ru Thu May 26 14:01:54 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 26 May 2016 17:01:54 +0300 Subject: nginx-1.11.0 In-Reply-To: <1086476033.20160526161724@softsearch.ru> References: <20160524162657.GC36620@mdounin.ru> <1086476033.20160526161724@softsearch.ru> Message-ID: <20160526140154.GJ36620@mdounin.ru> Hello! On Thu, May 26, 2016 at 04:17:24PM +0300, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Добавление: переменная $request_id. > > Это таймстамп+счётчик? Нет, это 128-bit random. Счётчики не работают, когда нужно обеспечить уникальность на более чем одной машине, а распространение виртуализации и контейнеризации приводит к тому, что это значит "чуть менее, чем всегда". -- Maxim Dounin http://nginx.org/ From me на kemko.ru Thu May 26 15:11:06 2016 From: me на kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Thu, 26 May 2016 15:11:06 +0000 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: <1804402.6SdrBpJsbq@vbart-workstation> References: <077552d74f5dbd3795a28e80726e20dc.NginxMailingListRussian@forum.nginx.org> <1804402.6SdrBpJsbq@vbart-workstation> Message-ID: чт, 26 мая 2016 г. в 15:20, Валентин Бартенев : > On Thursday 26 May 2016 08:04:59 Vadim Osipov wrote: > > location /screenshot/ { > > if ($request_method != GET) { > > proxy_pass http://127.0.0.1:8080; > > break; > > } > > > > more_clear_headers 'Content-Type'; > > more_clear_headers 'Cache-Control'; > > Это делается с помощью proxy_hide_header. > И для случаев, когда нужно удалить header из ответа клиенту, но залогировать в access_log-е тоже? Ну вдруг счастье уже наступило, а я не в курсе. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Thu May 26 15:24:44 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 26 May 2016 20:24:44 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <20160525160136.GQ3184@sie.protva.ru> Message-ID: а вы настройте keepalive между nginx и бекендами. 26 мая 2016 г., 16:28 пользователь S.A.N написал: > > Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2. > > > > Но само по себе мультиплексирование не является самоцелью, оно может > > быть уместно в каких-то вычурных ситуациях (вроде исчерпания > > сокетов), > > которые на самом деле разруливаются другими методами. > > Подскажите где почитать про другие эффективные методы решения дефицита > свободных fd в линуксе? > > Сейчас fd улетают как горячие пирожки, реал юзкейс > > Nginx, получает соединения от клиента, открывает соединения к бекенду, а > бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от > других бекендов, нам же приходится каждый запрос делать в отдельном > соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для > этой пустяковой задачи мы уже потратили 93 fd. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266693,267166#msg-267166 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Thu May 26 15:30:10 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 26 May 2016 18:30:10 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQstC40YHQsNC90LjQtSBuZ2lueCDQuNC3LdC30LAgbWVtY2FjaGVk?= In-Reply-To: References: <1804402.6SdrBpJsbq@vbart-workstation> Message-ID: <10537702.ofcDSjCmir@vbart-workstation> On Thursday 26 May 2016 15:11:06 Дмитрий Андреев wrote: > чт, 26 мая 2016 г. в 15:20, Валентин Бартенев : > > > On Thursday 26 May 2016 08:04:59 Vadim Osipov wrote: > > > location /screenshot/ { > > > if ($request_method != GET) { > > > proxy_pass http://127.0.0.1:8080; > > > break; > > > } > > > > > > more_clear_headers 'Content-Type'; > > > more_clear_headers 'Cache-Control'; > > > > Это делается с помощью proxy_hide_header. > > > И для случаев, когда нужно удалить header из ответа клиенту, но > залогировать в access_log-е тоже? Ну вдруг счастье уже наступило, а я не в > курсе. Всегда было можно: $ cat test.conf events {} http { log_format header '"$request_uri" "$upstream_http_x_header"'; server { listen 8080; location / { proxy_pass http://127.0.0.1:8080/header; proxy_hide_header X-Header; access_log logs/headers.log header; } location /header { add_header X-Header $arg_v; return 204; } } } $ build/sbin/nginx -c ../test.conf $ curl -i 127.0.0.1:8080/?v=hello HTTP/1.1 204 No Content Server: nginx/1.11.1 Date: Thu, 26 May 2016 15:26:11 GMT Connection: keep-alive $ curl -i 127.0.0.1:8080/?v=world HTTP/1.1 204 No Content Server: nginx/1.11.1 Date: Thu, 26 May 2016 15:26:15 GMT Connection: keep-alive $ cat build/logs/headers.log "/?v=hello" "hello" "/?v=world" "world" -- Валентин Бартенев From nginx-forum на forum.nginx.org Thu May 26 16:12:02 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Thu, 26 May 2016 12:12:02 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: <11321a532ba5f7f681e5537034018a9f.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > а вы настройте keepalive между nginx и бекендами. Да, этим и спасаемся, у нас огромные значения keepalive в upstream :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267180#msg-267180 From nginx-forum на forum.nginx.org Thu May 26 16:35:00 2016 From: nginx-forum на forum.nginx.org (wavedocs) Date: Thu, 26 May 2016 12:35:00 -0400 Subject: =?UTF-8?B?0JrQvtGA0L7RgtC60L7QtSDQuNC80Y8gaG9zdG5hbWU=?= Message-ID: <5fa228334573be8f5ab62854721121ae.NginxMailingListRussian@forum.nginx.org> Есть нужда передавать в хидере типа X-Aloha передавать хостней сервера, но без site.ru. Какие есть варианты кроме regex, map и lua? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267181,267181#msg-267181 From vovansystems на gmail.com Thu May 26 18:48:11 2016 From: vovansystems на gmail.com (VovansystemS) Date: Thu, 26 May 2016 21:48:11 +0300 Subject: =?UTF-8?B?0LrQvtCz0LTQsCDQu9GD0YfRiNC1INC40YHQv9C+0LvRjNC30L7QstCw0YLRjCBt?= =?UTF-8?B?dWx0aV9hY2NlcHQgb24=?= Message-ID: Добрый вечер, подскажите пожалуйста, в каких случаях нужно включать multi_accept on и как именно он работает? документацию читал http://nginx.org/r/multi_accept/ru из того, что мне удалось нагуглить, ничто не проясняет ситуацию для меня: http://mailman.nginx.org/pipermail/nginx-ru/2009-October/028973.html : При "multi_accept on" nginx пытается accept()нуть все соединения при получении сообщения о новых соединениях http://mailman.nginx.org/pipermail/nginx-ru/2015-May/056041.html : С multi_accept не пересекается никак - в зависимости от workload'а и желаемых результатов может иметь или не иметь смысл включать multi_accept. Проблема всё та же: multi_accept позволяет принять сразу несколько соединений за одну итерацию event loop'а, но ценой одного лишнего вызова accept(). Есть небольшой положительный эффект - при использовании reuseport из-за multi_accept'а не будут возникать перекосы в распределении соединений между рабочими процессами при microbenchmark'ах. http://mailman.nginx.org/pipermail/nginx-ru/2014-June/054012.html : По умолчанию nginx старается работать так, чтобы "пробуждалось" минимальное количество рабочих процессов - это позволяет экономить затраты на переключение контекстов и "лишние" пробуждения процессов. При реальной работе - в результате используется столько процессов, сколько на самом деле нужно для обработки той нагрузки, которая есть. Если хочется получить более ровное распределение в тестах - то имеет смысл: - accept_mutex выключить; - multi_accept, если вдруг включён, выключить; - убедиться, что тесты не используют постоянные соединения и/или количество устанавливаемых соединений так или иначе велико. Я не понимаю что мы выигрываем от принятия сразу нескольких соединений за одну итерацию event loop'а. Валентин, может быть Вы сможете проиллюстрировать ситуацию со включенным и отключенным multi_accept на примере с бомжами и мусорными баками? https://habrahabr.ru/post/188114/#comment_6549442 From voron на amhost.net Thu May 26 19:28:36 2016 From: voron на amhost.net (Alex Vorona) Date: Thu, 26 May 2016 22:28:36 +0300 Subject: =?UTF-8?B?UmU6INCa0L7RgNC+0YLQutC+0LUg0LjQvNGPIGhvc3RuYW1l?= In-Reply-To: <5fa228334573be8f5ab62854721121ae.NginxMailingListRussian@forum.nginx.org> References: <5fa228334573be8f5ab62854721121ae.NginxMailingListRussian@forum.nginx.org> Message-ID: 26.05.16 19:35, wavedocs пишет: > Есть нужда передавать в хидере типа X-Aloha передавать хостней сервера, но > без site.ru. > Какие есть варианты кроме regex, map и lua? А чем вариант с map named capture не устраивает? map $hostname $hname { "~*(?[0-9A-Za-z\-]+)\.[0-9A-Za-z\-]+.[0-9A-Za-z\-]+" $h2name; } ... proxy_set_header X-Aloha $hname; From chipitsine на gmail.com Fri May 27 05:20:09 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 27 May 2016 10:20:09 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <11321a532ba5f7f681e5537034018a9f.NginxMailingListRussian@forum.nginx.org> References: <11321a532ba5f7f681e5537034018a9f.NginxMailingListRussian@forum.nginx.org> Message-ID: зачем огромные ? значение keepalive - это "запас", соединения, которые держатся подгретыми на всякий случай. если у вас нагрузка носит однородный характер, то они будут простаивать 26 мая 2016 г., 21:12 пользователь S.A.N написал: > Илья Шипицин Wrote: > ------------------------------------------------------- > > а вы настройте keepalive между nginx и бекендами. > > Да, этим и спасаемся, у нас огромные значения keepalive в upstream :) > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266693,267180#msg-267180 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri May 27 10:04:08 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 27 May 2016 06:04:08 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: > зачем огромные ? > > значение keepalive - это "запас", соединения, которые держатся > подгретыми > на всякий случай. > если у вас нагрузка носит однородный характер, то они будут > простаивать У нас 250 keepalive на upstream, начинали с 8, потом имперически увеличивали, обычно они не простаивают. Кстати почему по дефолту keepalive_requests имеет такое маленькое значения - 100? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267191#msg-267191 From oleg на mamontov.net Fri May 27 10:08:55 2016 From: oleg на mamontov.net (Oleg A. Mamontov) Date: Fri, 27 May 2016 13:08:55 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: <20160527100855.GD69347@xenon.mamontov.net> On Fri, May 27, 2016 at 06:04:08AM -0400, S.A.N wrote: > > зачем огромные ? > > > > значение keepalive - это "запас", соединения, которые держатся > > подгретыми > > на всякий случай. > > если у вас нагрузка носит однородный характер, то они будут > > простаивать > > У нас 250 keepalive на upstream, начинали с 8, потом имперически > увеличивали, обычно они не простаивают. > > Кстати почему по дефолту keepalive_requests имеет такое маленькое значения - > 100? Это опция относится только к клиентскому соединению. -- Cheers, Oleg A. Mamontov mailto: oleg на mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 From nginx-forum на forum.nginx.org Fri May 27 10:39:06 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 27 May 2016 06:39:06 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <20160527100855.GD69347@xenon.mamontov.net> References: <20160527100855.GD69347@xenon.mamontov.net> Message-ID: > > Кстати почему по дефолту keepalive_requests имеет такое маленькое > значения - > > 100? > > Это опция относится только к клиентскому соединению. Наши бекенды открывают клиентские соединения к другим нашим бекендам, по этому пришлось значительно увеличить keepalive_requests. Я хотел узнать, если по умолчанию 100, возможно на это есть какие-то низкоуровневые причины и наше увеличения до 10 000, может негативно сказаться, на практике проблем не заметил. Или keepalive_requests это просто историческая дань проблемам Apache? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267194#msg-267194 From chipitsine на gmail.com Fri May 27 10:56:38 2016 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 27 May 2016 15:56:38 +0500 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: а как вы понимаете, простаивают они или нет ? 27 мая 2016 г., 15:04 пользователь S.A.N написал: > > зачем огромные ? > > > > значение keepalive - это "запас", соединения, которые держатся > > подгретыми > > на всякий случай. > > если у вас нагрузка носит однородный характер, то они будут > > простаивать > > У нас 250 keepalive на upstream, начинали с 8, потом имперически > увеличивали, обычно они не простаивают. > > Кстати почему по дефолту keepalive_requests имеет такое маленькое значения > - > 100? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,266693,267191#msg-267191 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri May 27 11:13:23 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 27 May 2016 07:13:23 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: Message-ID: <6f44156887badcbc83091beb33d99aff.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > а как вы понимаете, простаивают они или нет ? Очень просто, мы на бекенде замеряли сколько соединений открывает Nginx, днем 200-300, ночью намного меньше, мы установили 250, по таймауту закрываются лишние. Кстати когда замеряли, заметили Nginx часто открывал кратковременные соединения, потом их закрывал и сразу открывал новые, не понятно зачем он закрывает соединения чтобы потом сразу открыть новые в том же кол-ве которые сам закрыл (в логах ошибок небыло), лучше бы Nginx повторно их использовал, в общем установили keepalive 250 и Nginx перестал постоянно открывать и закрывать соединения. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267196#msg-267196 From mdounin на mdounin.ru Fri May 27 15:31:09 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 27 May 2016 18:31:09 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: References: <20160527100855.GD69347@xenon.mamontov.net> Message-ID: <20160527153109.GV36620@mdounin.ru> Hello! On Fri, May 27, 2016 at 06:39:06AM -0400, S.A.N wrote: > > > Кстати почему по дефолту keepalive_requests имеет такое маленькое > > значения - > > > 100? > > > > Это опция относится только к клиентскому соединению. > > Наши бекенды открывают клиентские соединения к другим нашим бекендам, по > этому пришлось значительно увеличить keepalive_requests. > > Я хотел узнать, если по умолчанию 100, возможно на это есть какие-то > низкоуровневые причины и наше увеличения до 10 000, может негативно > сказаться, на практике проблем не заметил. > > Или keepalive_requests это просто историческая дань проблемам Apache? Некоторые аллокации делаются из пула соединения, и соответственно освобождаются - вместе с соединением. Т.е. если соединение вообще не закрывать - в некоторых случаях будет расти занятая память. Поэтому соединения периодически принудительно закрываются. Количество запросов по умолчанию, после которого соединения закрывается - рассчитано на то, чтобы минимально влиять на работу обычных браузеров. Поднять ограничение выше - можно, максимум, чем вы рискуете - это лишним расходом памяти. Принципиальной разницы между 100 и 10 000, в общем-то, нет. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Fri May 27 19:09:37 2016 From: nginx-forum на forum.nginx.org (dim1) Date: Fri, 27 May 2016 15:09:37 -0400 Subject: =?UTF-8?B?bWFwINC00LvRjyDQstGL0LLQvtC0INC30LDQv9C40YHQtdC5INCyIGVycm9yLmxv?= =?UTF-8?B?ZyDQv9C+INGD0YHQu9C+0LLQuNGO?= Message-ID: Проблема: В логе есть множество не нужных 404 ошибок. Например, c перебором всего URL. Пример с юзерагентом WhatsApp: http://domen.com/category/subcategory/subsubcategory/page http://domen.com/category/subcategory/subsubcategory/pag http://domen.com/category/subcategory/subsubcategory/pa ... http://domen.com/c Кстати, зачем он так делает?! ЗАДАЧА: Писать в отдельный error.log только записи с реферером, исключая некоторые UA. РЕАЛИЗАЦИЯ: map "$http_user_agent" $iswa { default 1; ~WhatsApp 0; } map "$http_referer:$iswa:$status" $log404 { default 0; ~^http.+:1:4[0-9][0-9] 1; ~^http.+:1:50[0-9] 1; } ... sever { access_log /path/domen.error.log combined if=$log404; ... } Записываем в отдельный лог все UA кроме WhatsApp, и только 4хх и 50х ошибки (4[0-9][0-9] и 50[0-9]), при НЕ пустом реферере (^http.+). Если вместо ^http.+ поставить .+ заметно увеличивается нагрузка. ~.+ - заметно грузит nginx (вместо 2% на процесс - получается 7%) ~^http.+ - не так сильно грузит процессор. ВОПРОСЫ: 1. Верна ли реализация, в общем? 2. Какой регуляркой лучше указывать - НЕ пустая строка? Странно, что так сильно грузит ~.+. 3. Имеет ли значение порядок переменных в map? Возможно простые условия (без регулярок) лучше ставить первыми? 4. Есть ли возможность указать ! (NOT) для условия в map? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267206,267206#msg-267206 From nginx-forum на forum.nginx.org Mon May 30 05:10:05 2016 From: nginx-forum на forum.nginx.org (rba) Date: Mon, 30 May 2016 01:10:05 -0400 Subject: =?UTF-8?B?dXBzdHJlYW0gcmVpbml0IChBUEksINCh0Lgp?= Message-ID: Здравствуйте, помогите пожалуйста разобраться... Написал модуль, но т.к. не до конца понимаю некоторые механизмы nginx, после смены версии nginx, зависимостей и системы всё разумеется перестало работать. Просьба в ngx_postgres не указывать, смотрел, там вроде несколько по другому. Подозреваю кусок кода которые был переписан со следующего блокирующего образца: do { status = PQconnectPoll(conn); } while(status != PGRES_POLLING_FAILED && status != PGRES_POLLING_OK); О том как было переписано: Комментарий об порядке вызовов https://github.com/AntonRiab/ngx_pgcopy/blob/master/ngx_http_pgcopy_module.c#L482 Лог вызовов функций https://github.com/AntonRiab/ngx_pgcopy/blob/master/reinit.log.xml Правильно ли я понимаю: upstream_init из reinit уходит в глубокую рекурсию, переполняет стек и поэтому вываливается в segfault? Куда корректно переместить повторные вызовы чтоб не уходить в рекурсию? Или есть способ по другому вызвать reinit? При том что таймер(pgcopy_PQconnectPoll_delay) почему то повторно не вызывается(даже после повторной установки). Есть подозрение, что будет работать если вынести повторые вызовы в r->upstream->read_event_handler/write_event_handle, но тогда роль access_handler выпадает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267216,267216#msg-267216 From sytar.alex на gmail.com Mon May 30 06:10:54 2016 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Mon, 30 May 2016 09:10:54 +0300 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIHJlaW5pdCAoQVBJLCDQodC4KQ==?= In-Reply-To: References: Message-ID: 30 мая 2016 г., 8:10 пользователь rba написал: > Здравствуйте, помогите пожалуйста разобраться... > > > Правильно ли я понимаю: upstream_init из reinit уходит в глубокую рекурсию, > переполняет стек и поэтому вываливается в segfault? > > Безотносительно nginx - если есть сегфолт, значит есть корка. Если есть корка - то gdb в руки, там будет и стек, и трейс и прочие полезные в отладке вещи ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon May 30 06:18:25 2016 From: nginx-forum на forum.nginx.org (rba) Date: Mon, 30 May 2016 02:18:25 -0400 Subject: =?UTF-8?B?UmU6IHVwc3RyZWFtIHJlaW5pdCAoQVBJLCDQodC4KQ==?= In-Reply-To: References: Message-ID: <79c25e522e491eccbbf364c901166bc1.NginxMailingListRussian@forum.nginx.org> Вопрос не в отладке а в api nginx... Куда корректно переместить повторные вызовы чтоб не уходить в рекурсию? Есть ли способ по другому вызвать reinit? (...чтобы вызывалось из main loop nginx) Таймер установленный внутри upstream->peer.get почему то повторно не вызывается(даже после повторной установки). Есть подозрение, что будет работать если вынести повторые вызовы в r->upstream->read_event_handler/write_event_handle, но тогда роль access_handler выпадает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267216,267219#msg-267219 From nginx-forum на forum.nginx.org Mon May 30 11:11:09 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Mon, 30 May 2016 07:11:09 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <20160526123900.GT3184@sie.protva.ru> References: <20160526123900.GT3184@sie.protva.ru> Message-ID: <24d089dac107b2351e408ec7c3bf3b97.NginxMailingListRussian@forum.nginx.org> > Интересно, сколько нужно открыть fd чтобы ощутить их дефицит в > системе? Это зависит от установленого лимита в ОС, по умолчанию 1024, я кстати всегда хотел узнать, зачем линукс по умолчанию ставит такой низкий лимит? > Если у клиента такая логика, что он делает 30 запросов json > одновременно, > может быть, стоит подумать о пересмотре модели работы клиента? Так ли > уж > там нужна параллельная обработка этих 30 запросов? Я всегда стремлюсь максимально эффективно использовать свободные ресурсы сервера. Если запросы обрабатывать последовательно в одном соединение, сокет будет простаивать без трафика, процес будет простаивать в ожидании получения новых задач, в общем железо будет простаивать, в результате конечный клиент будет ждать дольше. Если все запросы отправлять в новых соединениях, тогда придется за это платить, для бекендов которые написана на высокоуровневых технологиях, новые соединения это совсем не zero cost. Я не против новых соединений, я пытался найти возможности повысить КПД этих соединений, мультиплексирования в H2 и FastCGI для этого и созданы. Это важно не только между браузером и серверов, например тот же GRPC использует HTTP/2 для мультиплексирования. У нас REST API с HTTP кешированием, но к сожалению мультиплексирования запросов в upstream соединениях Nginx не поддерживает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267223#msg-267223 From annulen на yandex.ru Mon May 30 11:17:18 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Mon, 30 May 2016 14:17:18 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <24d089dac107b2351e408ec7c3bf3b97.NginxMailingListRussian@forum.nginx.org> References: <20160526123900.GT3184@sie.protva.ru> <24d089dac107b2351e408ec7c3bf3b97.NginxMailingListRussian@forum.nginx.org> Message-ID: <379111464607038@web8o.yandex.ru> 30.05.2016, 14:11, "S.A.N" : >>   Интересно, сколько нужно открыть fd чтобы ощутить их дефицит в >>  системе? > > Это зависит от установленого лимита в ОС, по умолчанию 1024, я кстати всегда > хотел узнать, зачем линукс по умолчанию ставит такой низкий лимит? > >>   Если у клиента такая логика, что он делает 30 запросов json >>  одновременно, >>   может быть, стоит подумать о пересмотре модели работы клиента? Так ли >>  уж >>   там нужна параллельная обработка этих 30 запросов? > > Я всегда стремлюсь максимально эффективно использовать свободные ресурсы > сервера. > Если запросы обрабатывать последовательно в одном соединение, сокет будет > простаивать без трафика, процес будет простаивать в ожидании получения новых > задач, в общем железо будет простаивать, в результате конечный клиент будет > ждать дольше. Если сокет "простаивает без трафика", то железо отнюдь не простаивает, а выполняет работу по тем сокетам, которые не простаивают. К тому же при однородной нагрузке количество требуемых содинений с бэкэндами должно быть стабильно во времени > > Если все запросы отправлять в новых соединениях, тогда придется за это > платить, для бекендов которые написана на высокоуровневых технологиях, новые > соединения это совсем не zero cost. > > Я не против новых соединений, я пытался найти возможности повысить КПД этих > соединений, мультиплексирования в H2 и FastCGI для этого и созданы. > > Это важно не только между браузером и серверов, например тот же GRPC > использует HTTP/2 для мультиплексирования. > У нас REST API с HTTP кешированием, но к сожалению мультиплексирования > запросов в upstream соединениях Nginx не поддерживает. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267223#msg-267223 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Mon May 30 12:17:41 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Mon, 30 May 2016 08:17:41 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <379111464607038@web8o.yandex.ru> References: <379111464607038@web8o.yandex.ru> Message-ID: <09d806546ae6789ebc3dbfd64c086a3b.NginxMailingListRussian@forum.nginx.org> > Если сокет "простаивает без трафика", то железо отнюдь не простаивает, > а выполняет работу по тем сокетам, которые не простаивают. > > К тому же при однородной нагрузке количество требуемых содинений с > бэкэндами должно быть стабильно во времени Если 30 запросов отправить в 30 разных соединениях, тогда конечно EventLoop будет все 30 обрабатывать, но тратить на один запрос целое соединения это слишком расточительно, попробую объяснить на цифрах. 1 запрос выполняется за 100ms Если послать 30 последовательных запросов в 1 соединение мы получим 30 ответов за 3000ms Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за 100ms Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за 100ms В первом варианте, 1 сокет находится в режиме busy ~3000ms В втором варианте, 30 сокетов находится в режиме busy ~100ms В третьем варианте, 1 сокет находится в режиме busy ~100ms Вопрос какой из трех вариантов более эффективно использует ресурсы? Если HTPP/2 создает оверхед, ок, есть мультиплексирование в FastCGI, но я так понял что проблема не в протоколах, проблема в том что логика upstrem в Nginx ничего не знает про мультиплексирование запросов и заточена на новые соединения. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267225#msg-267225 From annulen на yandex.ru Mon May 30 12:22:13 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Mon, 30 May 2016 15:22:13 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <09d806546ae6789ebc3dbfd64c086a3b.NginxMailingListRussian@forum.nginx.org> References: <379111464607038@web8o.yandex.ru> <09d806546ae6789ebc3dbfd64c086a3b.NginxMailingListRussian@forum.nginx.org> Message-ID: <846481464610933@web6m.yandex.ru> 30.05.2016, 15:17, "S.A.N" : >>  Если сокет "простаивает без трафика", то железо отнюдь не простаивает, >>  а выполняет работу по тем сокетам, которые не простаивают. >> >>  К тому же при однородной нагрузке количество требуемых содинений с >>  бэкэндами должно быть стабильно во времени > > Если 30 запросов отправить в 30 разных соединениях, тогда конечно EventLoop > будет все 30 обрабатывать, но тратить на один запрос целое соединения это > слишком расточительно, попробую объяснить на цифрах. > > 1 запрос выполняется за 100ms > > Если послать 30 последовательных запросов в 1 соединение мы получим 30 > ответов за 3000ms > Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за > 100ms > Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за > 100ms > > В первом варианте, 1 сокет находится в режиме busy ~3000ms > В втором варианте, 30 сокетов находится в режиме busy ~100ms > В третьем варианте, 1 сокет находится в режиме busy ~100ms > > Вопрос какой из трех вариантов более эффективно использует ресурсы? > > Если HTPP/2 создает оверхед, ок, есть мультиплексирование в FastCGI Любое мультиплексирование в принципе создает оверхед, так как данные из разных ответов приходится разгребать из одного соединения Возможно, эффективным решением для соединения бэкэндов было бы фиксированное количество соединений, бесконечный keepalive и pipelining >, но я > так понял что проблема не в протоколах, проблема в том что логика upstrem в > Nginx ничего не знает про мультиплексирование запросов и заточена на новые > соединения. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267225#msg-267225 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From annulen на yandex.ru Mon May 30 12:23:31 2016 From: annulen на yandex.ru (Konstantin Tokarev) Date: Mon, 30 May 2016 15:23:31 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <846481464610933@web6m.yandex.ru> References: <379111464607038@web8o.yandex.ru> <09d806546ae6789ebc3dbfd64c086a3b.NginxMailingListRussian@forum.nginx.org> <846481464610933@web6m.yandex.ru> Message-ID: <855191464611011@web6m.yandex.ru> 30.05.2016, 15:22, "Konstantin Tokarev" : > 30.05.2016, 15:17, "S.A.N" : >>>   Если сокет "простаивает без трафика", то железо отнюдь не простаивает, >>>   а выполняет работу по тем сокетам, которые не простаивают. >>> >>>   К тому же при однородной нагрузке количество требуемых содинений с >>>   бэкэндами должно быть стабильно во времени >> >>  Если 30 запросов отправить в 30 разных соединениях, тогда конечно EventLoop >>  будет все 30 обрабатывать, но тратить на один запрос целое соединения это >>  слишком расточительно, попробую объяснить на цифрах. >> >>  1 запрос выполняется за 100ms >> >>  Если послать 30 последовательных запросов в 1 соединение мы получим 30 >>  ответов за 3000ms >>  Если послать 30 запросов в 30 разных соединениях мы получим 30 ответов за >>  100ms >>  Если послать 30 асинхронных запросов в 1 соединение мы получим 30 ответов за >>  100ms >> >>  В первом варианте, 1 сокет находится в режиме busy ~3000ms >>  В втором варианте, 30 сокетов находится в режиме busy ~100ms >>  В третьем варианте, 1 сокет находится в режиме busy ~100ms >> >>  Вопрос какой из трех вариантов более эффективно использует ресурсы? >> >>  Если HTPP/2 создает оверхед, ок, есть мультиплексирование в FastCGI > > Любое мультиплексирование в принципе создает оверхед, так как данные из разных ответов приходится разгребать из одного соединения > > Возможно, эффективным решением для соединения бэкэндов было бы фиксированное количество соединений, бесконечный keepalive и pipelining Фиксированное в смысле 30 (или 100, или сколько тербуется в среднем), а не как в браузере > >> , но я >>  так понял что проблема не в протоколах, проблема в том что логика upstrem в >>  Nginx ничего не знает про мультиплексирование запросов и заточена на новые >>  соединения. >> >>  Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267225#msg-267225 >> >>  _______________________________________________ >>  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 -- Regards, Konstantin From nginx-forum на forum.nginx.org Mon May 30 13:15:06 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Mon, 30 May 2016 09:15:06 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <846481464610933@web6m.yandex.ru> References: <846481464610933@web6m.yandex.ru> Message-ID: <71e952afe21b6afcef7e266b3d5300a3.NginxMailingListRussian@forum.nginx.org> > Возможно, эффективным решением для соединения бэкэндов было бы > фиксированное количество соединений, бесконечный keepalive и > pipelining Да, мы сделали свой pool keepalive сокетов, это действительно помогает. pipelining мы хотели сделать, но Nginx его не поддерживает, мы гоняем запросы между бекендами через Nginx, потому что нужен кеш Nginx и балансировка запросов между бекендами. Для наших задач (возможно и не только для наших) подходит memcache протокол, он очень простой, ответы имеют id - это uri запроса, мультиплицировать его очень просто. Я поискал сторонние модули, но они не умеет принимать входящие memcache запросы. Было бы очень круто, если бы в Nginx была возможность что-то вроде этого location / { proxy_cache_pass localhost:11211; # address memcached server socket } Тогда клиентcий код станет гениально простым :) memcached->connect("localhost:11211") создания соединения с Nginx для общения по протоколу memcached memcached->get($uri) запрос принимает Nginx, ищет ответ в своем кеше, ключ запроса равен ключу кеша, если в кеше ответа нет, этот запрос отправляется на бекенд, проксирования на бекенд такое же если бы этот запрос пришел от браузера по НТТР, т.е GET uri HTTP/1.1 Я понимаю, что это похоже на извращения, но поверьте разработчики бекендов оценят это и очень быстро и появится много статей как использовать Nginx вместо Memcache. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267228#msg-267228 From mdounin на mdounin.ru Mon May 30 14:28:59 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 30 May 2016 17:28:59 +0300 Subject: =?UTF-8?B?UmU6IG1hcCDQtNC70Y8g0LLRi9Cy0L7QtCDQt9Cw0L/QuNGB0LXQuSDQsiBlcnJv?= =?UTF-8?B?ci5sb2cg0L/QviDRg9GB0LvQvtCy0LjRjg==?= In-Reply-To: References: Message-ID: <20160530142858.GC36620@mdounin.ru> Hello! On Fri, May 27, 2016 at 03:09:37PM -0400, dim1 wrote: > Проблема: > В логе есть множество не нужных 404 ошибок. Например, c перебором всего URL. > > Пример с юзерагентом WhatsApp: > http://domen.com/category/subcategory/subsubcategory/page > http://domen.com/category/subcategory/subsubcategory/pag > http://domen.com/category/subcategory/subsubcategory/pa > ... > http://domen.com/c > > Кстати, зачем он так делает?! > > > ЗАДАЧА: > Писать в отдельный error.log только записи с реферером, исключая некоторые > UA. > > > РЕАЛИЗАЦИЯ: > map "$http_user_agent" $iswa { > default 1; > ~WhatsApp 0; > } > map "$http_referer:$iswa:$status" $log404 { > default 0; > ~^http.+:1:4[0-9][0-9] 1; > ~^http.+:1:50[0-9] 1; > } > ... > sever { > access_log /path/domen.error.log combined if=$log404; > ... > } > > Записываем в отдельный лог все UA кроме WhatsApp, и только 4хх и 50х ошибки > (4[0-9][0-9] и 50[0-9]), при НЕ пустом реферере (^http.+). > > Если вместо ^http.+ поставить .+ заметно увеличивается нагрузка. > ~.+ - заметно грузит nginx (вместо 2% на процесс - получается 7%) > ~^http.+ - не так сильно грузит процессор. > > > ВОПРОСЫ: > 1. Верна ли реализация, в общем? Реализация - в целом да. Тут, скорее, неверна задача, но это отдельный вопрос. Ну и регулярное выражение - неправильное. > 2. Какой регуляркой лучше указывать - НЕ пустая строка? Странно, что так > сильно грузит ~.+. В мире регулярный выражений есть такое понятие, как backtracking (aka "поиск с возвратом"): когда встречается символ, не удовлетворяющий выбранному выражению, сопоставление выражения откатывается на предыдущую точку, где было возможно более одного варианта совпадения, и поиск возможных совпадений продолжается. Так, для регулярного выражения "^a.+b" и строки "a0b0" поиск будет происходить так: 1. в первой позиции будет найден символ "a" 2. следом под шаблон ".+" попадут символы "0b0" 3. дальше встречен конец строки, в то время как нам нужен символ "b", так что случится backtracking и мы вернёмся на этап сопоставления с шаблоном ".+" 4. на этот раз шаблону ".+" сопоставят только символы "0b" 5. следующий символ "0" опять не совпадает с тем, что нужно ("b"), так что снова возврат к шаблону ".+" 6. в этот раз шаблону ".+" сопоставят только символ "0" 7. следующий символ "b", и совпадение найдено Очевидно, что такой метод поиска совпадений - приводит к множеству лишней работы в случае, если совпадения нет. В особо запущенных случаях росто сложности получается экспоненциальный, и это называется "catastrophic backtracking", подробнее где-то тут: http://www.regular-expressions.info/catastrophic.html В вашем случае выражение "http.+:1:..." приводит к просто backtracking'у на всю длину Referer'а, что не так плохо, как могло бы быть, но всё равно - плохо. Кроме того, волшебная строка ":1:404:" в Referer'е просто отключит логгирование запроса с таким конфигом. Проще всего для решения всех этих проблем проверяемую строку перевернуть, поставив известные фиксированные переменные в начало: map $iswa:$status:$http_referer $log404 { default 0; ~^1:4[0-9][0-9]:http.+ 1; ~^1:50[0-9]:http.+ 1; } > 3. Имеет ли значение порядок переменных в map? Возможно простые условия (без > регулярок) лучше ставить первыми? См. выше. > 4. Есть ли возможность указать ! (NOT) для условия в map? В случае точного сопоставления строк - нет, используйте вместо этого значение по умолчанию. В случае регулярных выражений - man pcresyntax в руки. Если нужно построить отрицание, то обычно это проще всего сделать с помощью negative lookahead assertion, "(?!...)". Ну или опять же использовать значение по умолчанию. -- Maxim Dounin http://nginx.org/ From bgx на protva.ru Mon May 30 15:18:46 2016 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 30 May 2016 18:18:46 +0300 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <71e952afe21b6afcef7e266b3d5300a3.NginxMailingListRussian@forum.nginx.org> References: <846481464610933@web6m.yandex.ru> <71e952afe21b6afcef7e266b3d5300a3.NginxMailingListRussian@forum.nginx.org> Message-ID: <20160530151845.GB2573@sie.protva.ru> On Mon, May 30, 2016 at 09:15:06AM -0400, S.A.N wrote: > Было бы очень круто, если бы в Nginx была возможность что-то вроде этого > > location / > { > proxy_cache_pass localhost:11211; # address memcached server socket > } > > > Тогда клиентcий код станет гениально простым :) > > memcached->connect("localhost:11211") > создания соединения с Nginx для общения по протоколу memcached > > memcached->get($uri) > запрос принимает Nginx, ищет ответ в своем кеше, ключ запроса равен ключу > кеша, если в кеше ответа нет, этот запрос отправляется на бекенд, > проксирования на бекенд такое же если бы этот запрос пришел от браузера по > НТТР, т.е GET uri HTTP/1.1 Если я правильно понял этот набор слов, предлагается вместо кэша nginx использовать кэш memcached'а, почему эта связка должна быть эффективнее чем один кэш nginx'a? -- Eugene Berdnikov From nginx-forum на forum.nginx.org Mon May 30 17:19:03 2016 From: nginx-forum на forum.nginx.org (S.A.N) Date: Mon, 30 May 2016 13:19:03 -0400 Subject: =?UTF-8?B?UmU6IHByb3h5IGh0dHAgdmVyc2lvbiAyOyDQsdC10LcgU1NMLCDQtNC70Y8g0Lw=?= =?UTF-8?B?0YPQu9GM0YLQuNC/0LvQtdC60YHQuNGA0L7QstCw0L3QuNC1INC30LDQv9GA?= =?UTF-8?B?0L7RgdC+0LIg0Log0LHQtdC60LXQvdC00YM=?= In-Reply-To: <20160530151845.GB2573@sie.protva.ru> References: <20160530151845.GB2573@sie.protva.ru> Message-ID: <7a8068bc61ca0261528b6e4c5e3e9cf9.NginxMailingListRussian@forum.nginx.org> > Если я правильно понял этот набор слов, предлагается вместо кэша > nginx > использовать кэш memcached'а, почему эта связка должна быть > эффективнее > чем один кэш nginx'a? Нет, будет использоваться только кеш Nginx, но бекенды получат возможность получать по ключу, тело (body) кеша Nginx, по протоколу Memcached, если в Nginx, нет закешированого ответа или кеш требует ревалидации, тогда Nginx переводит этот GET запрос из протокола Memcached в GET запрос протокола HTTP, и отправляет его на бекенд, для получения нового ответа или статуса 304. По сути Nginx сервер будет эмулировать работу Memcached сервера, тогда бекенды будут работать с Nginx как с Memcached. Протокол HTTP не очень подходит для быстрого общения бекендов между собой внутри датацентра, HTTP слишком многословен, часто тело JSON ответа короче HTTP заголовков. Когда бекенд делает запрос к другому бекенду через Nginx, его интересует код ответа, длина ответа и само тело ответа, все остальное это мусор который нужен только браузеру, по этому протокол Memcached подходит лучше, плюс этот протокол мультиплецируется :) Такая связка во многом лучше чем работать с реальным сервером Memcached. 1. Nginx асинхроный и многопоточный, Memcached однопоточный и запросы обрабатывает последовательно. 2. Nginx имеет опции кеша cache_lock, use_stale, min_uses. 3. Nginx умеет ревалидировать кеш 4. Нет холодного старта и размер кеша не ограничен оперативной памятью. 5. Нет лишнего звена и зависимости от Memcached сервера Ну как вам? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,266693,267235#msg-267235 From nginx-forum на forum.nginx.org Tue May 31 06:28:17 2016 From: nginx-forum на forum.nginx.org (Vadim Osipov) Date: Tue, 31 May 2016 02:28:17 -0400 Subject: =?UTF-8?B?0J3QtdC/0L7QvdC40LzQsNC90LjQtSDQutCw0Log0YDQsNCx0L7RgtCw0LXRgiBm?= =?UTF-8?B?YWlsIHRpbWVvdXQg0L3QsCDRgdCw0LzQvtC8INC00LXQu9C1?= Message-ID: <37b6f77f94b8ae86834bcda2e4a9e850.NginxMailingListRussian@forum.nginx.org> Здравствуйте Столкнулся с такой ситуацией, что, видимо, не понимаю в каком случае срабатывает fail_timeout, max_fails. Как я это понимаю при моей конфигурации: например, я делаю 1 запрос http://localhost:80/mem/key10, вычисляется хэш, ему ставится в соответствие сервер из upstream - это 172.16.11.46:11211 (в моем случае), и если сервер завис, не отвечает или произошла ошибка соединения с сервером (машина выключена/не существует), то в течение 30 секунд запросы на эту машину/сервер не идут. Однако, что получается в действительности - после того, как не удалось соединиться, начинает ретрансмит через 1 секунду, затем 2, потом (т.к. тут уже вступает в игру memcached_connect_timeout и ретрансмита между последней попыткой и новой не будет, т.к. тогда будет разница в 4 сек.) nginx рехэширует запрос/ключ, и он попадает на работающий сервер, делает запрос и отдает то, что есть в другом сервере (в моем случае, это 127.0.0.1:11211). Так какой же вопрос ? Почему последующий запрос http://localhost:80/mem/key10 не идет сразу на 127.0.0.1:11211, а продолжает те же самые попытки - достучаться до 172.16.11.46:11211 ? Как проверяли ? С помощью tcpdump. tcpdump -i any -s 0 -vvv -w /tmp/dump_240_46.pcup Конфигурация: upstream memcached_cluster { server 127.0.0.1:11211 fail_timeout=30s max_fails=1; server 172.16.11.46:11211 fail_timeout=30s max_fails=1; # <---- is not working now hash $uri/3.6; # nginx_upstream_hash hash_again 1000; # nginx_upstream_hash keepalive 512; } memcached_connect_timeout 5s; location /mem { set $memcached_key "$uri/3.6"; memcached_pass memcached_cluster; } Окружение: nginx version: nginx/1.4.2 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-http_xslt_module --with-debug --with-mail --with-mail_ssl_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ipv6 --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-push-stream-module --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx_upstream_hash --add-module=/root/rpmbuild/BUILD/nginx-1.4.2/nginx-memcached-hash-pass OS: CentOS release 6.6 (Final) Kernel: Linux tve-lab-240 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Документация по стороннему модулю: https://github.com/evanmiller/nginx_upstream_hash http://hb.321key.org/hb/nginx-1.3.8/03A6EA3ED31C437BB3DF5902E32F2E68/4B83DA8DC7.htm Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267237,267237#msg-267237 From vbart на nginx.com Tue May 31 10:32:40 2016 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 31 May 2016 13:32:40 +0300 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3QuNC80LDQvdC40LUg0LrQsNC6INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YIgZmFpbCB0aW1lb3V0INC90LAg0YHQsNC80L7QvCDQtNC10LvQtQ==?= In-Reply-To: <37b6f77f94b8ae86834bcda2e4a9e850.NginxMailingListRussian@forum.nginx.org> References: <37b6f77f94b8ae86834bcda2e4a9e850.NginxMailingListRussian@forum.nginx.org> Message-ID: <1748660.c7j2Yax1dJ@vbart-laptop> On Tuesday 31 May 2016 02:28:17 Vadim Osipov wrote: > Здравствуйте > Столкнулся с такой ситуацией, что, видимо, не понимаю в каком случае > срабатывает fail_timeout, max_fails. > Как я это понимаю при моей конфигурации: > например, я делаю 1 запрос http://localhost:80/mem/key10, вычисляется хэш, > ему ставится в соответствие сервер из upstream - это 172.16.11.46:11211 (в > моем случае), и если сервер завис, не отвечает или произошла ошибка > соединения с сервером (машина выключена/не существует), то в течение 30 > секунд запросы на эту машину/сервер не идут. > Однако, что получается в действительности - после того, как не удалось > соединиться, начинает ретрансмит через 1 секунду, затем 2, потом (т.к. тут > уже вступает в игру memcached_connect_timeout и ретрансмита между последней > попыткой и новой не будет, т.к. тогда будет разница в 4 сек.) nginx > рехэширует запрос/ключ, и он попадает на работающий сервер, делает запрос и > отдает то, что есть в другом сервере (в моем случае, это 127.0.0.1:11211). > > Так какой же вопрос ? > Почему последующий запрос http://localhost:80/mem/key10 не идет сразу на > 127.0.0.1:11211, а продолжает те же самые попытки - достучаться до > 172.16.11.46:11211 ? [..] Если у вас настроено несколько рабочих процессов, то следующий запрос, если он сделан не в том же соединении, мог попасть в другой рабочий процесс, который ещё ничего не знает о том, что 172.16.11.46:11211 недоступен. -- Валентин Бартенев From mdounin на mdounin.ru Tue May 31 16:41:40 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 31 May 2016 19:41:40 +0300 Subject: nginx-1.11.1 Message-ID: <20160531164140.GT36620@mdounin.ru> Изменения в nginx 1.11.1 31.05.2016 *) Безопасность: при записи тела специально созданного запроса во временный файл в рабочем процессе мог происходить segmentation fault (CVE-2016-4450); ошибка появилась в 1.3.9. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue May 31 16:42:16 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 31 May 2016 19:42:16 +0300 Subject: nginx-1.10.1 Message-ID: <20160531164216.GX36620@mdounin.ru> Изменения в nginx 1.10.1 31.05.2016 *) Безопасность: при записи тела специально созданного запроса во временный файл в рабочем процессе мог происходить segmentation fault (CVE-2016-4450); ошибка появилась в 1.3.9. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue May 31 16:42:55 2016 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 31 May 2016 19:42:55 +0300 Subject: nginx security advisory (CVE-2016-4450) Message-ID: <20160531164255.GB36620@mdounin.ru> Hello! В коде nginx, отвечающем за сохранение тела клиентских запросов во временные файлы, была обнаружена проблема. Специально созданный запрос мог вызывать крах рабочего процесса из-за разыменования нулевого указателя в процессе записи тела запроса во временный файл (CVE-2016-4450). Проблеме подвержен nginx 1.3.9 - 1.11.0. Проблема исправлена в nginx 1.11.1, 1.10.1. Патч для nginx 1.9.13 - 1.11.0 доступен тут: http://nginx.org/download/patch.2016.write.txt Патч для более старых версий nginx (1.3.9 - 1.9.12): http://nginx.org/download/patch.2016.write2.txt -- Maxim Dounin http://nginx.org/