From gmm на csdoc.com Thu Dec 1 00:38:49 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 01 Dec 2011 02:38:49 +0200 Subject: alias issue again In-Reply-To: <201111302336.08564.ne@vbart.ru> References: <69f7fb1eab58c64bb8a74774a7ae91b2.NginxMailingListRussian@forum.nginx.org> <201111302228.57843.ne@vbart.ru> <4ED67E63.1000408@csdoc.com> <201111302336.08564.ne@vbart.ru> Message-ID: <4ED6CC99.2040803@csdoc.com> On 30.11.2011 21:36, Валентин Бартенев wrote: >> в исходном конфиге >> >> location / {} >> location ~ \.php$ {} >> location /pma/ {} >> location ~ ^/pma/(.*\.php)$ {} >> >> я не смог визуально найти причину, почему появляется ошибка >> 'directory index of "/usr/local/www/phpMyAdmin" is forbidden' >> >> и он не просил вместо него написать конфиг, он просил ответить >> на вопрос о причине этой ошибки - "Я не так использую alias-ы?" > > Причина данной конкретной ошибки, как я сразу и написал: > неправильный alias, без нужного в данном случае '/' на конце. > > И как следствие, не срабатывал index index.php; поэтому запрос > обрабатывался как попытка обратиться к /usr/local/www/phpMyAdmin > в текущем локэйшене. > > А листинг директорий у автора был запрещен, на что и указывала ошибка. судя по отладочному логу: 2011/12/01 01:58:40 [debug] 30615#0: *1590545 test location: "/" 2011/12/01 01:58:40 [debug] 30615#0: *1590545 test location: "pma/" 2011/12/01 01:58:40 [debug] 30615#0: *1590545 test location: ~ "\.php$" 2011/12/01 01:58:40 [debug] 30615#0: *1590545 test location: ~ "^/pma/(.*\.php)$" 2011/12/01 01:58:40 [debug] 30615#0: *1590545 using configuration "/pma/" 2011/12/01 01:58:40 [debug] 30615#0: *1590545 open index "/usr/local/www/phpMyAdminindex.php" 2011/12/01 01:58:40 [debug] 30615#0: *1590545 stat() "/usr/local/www/phpMyAdminindex.php" failed (2: No such file or directory) 2011/12/01 01:58:40 [debug] 30615#0: *1590545 http index check dir: "/usr/local/www/phpMyAdmin" 2011/12/01 01:58:40 [error] 30615#0: *1590545 directory index of "/usr/local/www/phpMyAdmin" is forbidden, client: 10.17.1.237, server: q, request: "GET /pma/ HTTP/1.1", host: "q" текущий локейшин - это "/pma/", за его пределы nginx не выходил. nginx пытался открыть индексный файл /usr/local/www/phpMyAdminindex.php и поскольку такого файла не было - выдавал ошибку что directory index is forbidden. >> мои вопросы касались уже исключительно того варианта конфига, >> который получился в результате, и который имхо будет гораздо хуже >> для поддержки, чем его исходный конфиг с 4-мя разными locations. > Ни я, ни вы - не знаем задач автора. И конечный вариант должен все же > писаться ориентируясь на конкретные цели и самим автором, с пониманием > что происходит и как работает. ИМХО мы не знаем задач автора, это правда. но кроме /pma/ у него рано или поздно появятся там и другие locations, поэтому лучше изначально делать конфигурацию удобной для поддержки, т.е. чтобы все locations были максимально независимы друг от друга и от порядка следованиях их в конфиге, т.е. чтобы все locations с регулярными выражениями были бы вложены внутрь небольших по размеру locations с префиксами. > Моя цель была помочь человеку, коли сам он с проблемой справиться не > может и никто ему больше не написал рабочего варианта. Мой вариант конфига > плох ровно настолько, насколько у меня было больное уставшее сознание > после 9 часов работы и попыток понять из авторского конфига, чего же он хотел > и почему же у него не работает. понял, sorry. но писать конфиги для элементарных задач за всех пользователей nginx - это наверное не выход из положения. тем более, что судя по вопросу - было видно что документацию по директиве alias он читал, но из документации и обычного (не отладочного ) error_log`а он не смог понять почему у него директива alias не работает так как ожидалось. следовательно - проблемы с документацией к директиве alias - она не полная и нюанс с '/' там не отражен. -- Best regards, Gena From nginx-forum на nginx.us Thu Dec 1 03:47:51 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Wed, 30 Nov 2011 22:47:51 -0500 Subject: =?UTF-8?B?RmVhdHVyZSByZXF1ZXN0OiBsaW1pdCBjb25uINC90LUg0YXQstCw0YLQsNC10YIg?= =?UTF-8?B?0L7Qv9GG0LjQuCDRgdCx0YDQvtGB0LAg0YHQvtC10LTQuNC90LXQvdC40Y8=?= Message-ID: <6a9553f03d6376ec2ab17bbb7ebb350d.NginxMailingListRussian@forum.nginx.org> Суть проблемы. При срабатывании limit_conn в nginx клиенту отдается 503 ошибка, но соединения продолжают висеть в conntrack табице ОС. Таким образом даже при настроенных параметрах limit_conn единственный клиент с помощью например ab может исчерпать всю таблицу conntrack соединений. Предлагаю сделать параметр limit_conn_action с двумя возможными значениями: Действие error (по умолчанию) - выдает стандартную 503 (Service Temporarily Unavailable) Действие drop - сбрасывает TCP сессию с клиентом на которой произошло срабатывание limit_conn. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219404,219404#msg-219404 From ne на vbart.ru Thu Dec 1 06:58:15 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 1 Dec 2011 10:58:15 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiAg0L3QtSDRhdCy0LDRgtCw?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <6a9553f03d6376ec2ab17bbb7ebb350d.NginxMailingListRussian@forum.nginx.org> References: <6a9553f03d6376ec2ab17bbb7ebb350d.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112011058.15404.ne@vbart.ru> On Thursday 01 December 2011 07:47:51 INF[SZ] wrote: > Суть проблемы. > > При срабатывании limit_conn в nginx клиенту > отдается 503 ошибка, но соединения > продолжают висеть в conntrack табице ОС. > > Таким образом даже при настроенных > параметрах limit_conn единственный клиент с > помощью например ab может исчерпать всю > таблицу conntrack соединений. Более того в limit_conn не учитываются висящие keep-alive соединения. Модуль нужен для ограничения числа одновременно обрабатываемых запросов к конкретному ресурсу. Пассивно висящие соединения он не учитывал и не может учитывать. > Предлагаю сделать параметр limit_conn_action с > двумя возможными значениями: > > Действие error (по умолчанию) - выдает > стандартную 503 (Service Temporarily Unavailable) > > Действие drop - сбрасывает TCP сессию с > клиентом на которой произошло > срабатывание limit_conn. Если я не ошибаюсь, вы и так можете это сделать с помощью директивы error_page 503 =444; , но как я уже написал выше, это вас не защитит. -- Валентин Бартенев From nginx-forum на nginx.us Thu Dec 1 07:25:29 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 02:25:29 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <201112011058.15404.ne@vbart.ru> References: <201112011058.15404.ne@vbart.ru> Message-ID: >Более того в limit_conn не учитываются висящие keep-alive соединения. Проверил, Вы правы. Есть ли какой-нибудь способ обойти проблему ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219407#msg-219407 From stalker на altlinux.ru Thu Dec 1 07:58:07 2011 From: stalker на altlinux.ru (Anton Gorlov) Date: Thu, 01 Dec 2011 11:58:07 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: <201112011058.15404.ne@vbart.ru> Message-ID: <4ED7338F.40209@altlinux.ru> 01.12.2011 11:25, INF[SZ] пишет: >> Более того в limit_conn не учитываются > висящие keep-alive соединения. > Проверил, Вы правы. Есть ли какой-нибудь > способ обойти проблему ? разве что файрволлом попытаться ограничивать кол-во подключений From nefer05 на gmail.com Thu Dec 1 08:06:35 2011 From: nefer05 на gmail.com (Nefer) Date: Thu, 01 Dec 2011 12:06:35 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <4ED7338F.40209@altlinux.ru> References: <201112011058.15404.ne@vbart.ru> <4ED7338F.40209@altlinux.ru> Message-ID: <4ED7358B.1050709@gmail.com> On 12/01/11 11:58, Anton Gorlov wrote: > 01.12.2011 11:25, INF[SZ] пишет: > >>> Более того в limit_conn не учитываются >> висящие keep-alive соединения. >> Проверил, Вы правы. Есть ли какой-нибудь >> способ обойти проблему ? > разве что файрволлом попытаться ограничивать кол-во подключений На кипаливы это не подействует. Они живут в рамках одной TCP сессии. ИМХО единственное решение на сейчас - отключить кипаливы. From citrin на citrin.ru Thu Dec 1 08:13:04 2011 From: citrin на citrin.ru (Anton Yuzhaninov) Date: Thu, 01 Dec 2011 12:13:04 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: <201112011058.15404.ne@vbart.ru> Message-ID: <4ED73710.10202@citrin.ru> 01.12.2011 11:25, INF[SZ] пишет: >> Более того в limit_conn не учитываются > висящие keep-alive соединения. > > Проверил, Вы правы. Есть ли какой-нибудь > способ обойти проблему ? А почему это проблема? На поддержание висящих в ожидании keep alive коннекциий требуется очень мало ресурсов. From scukonick на gmail.com Thu Dec 1 08:21:47 2011 From: scukonick на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQsNC70L7Qsg==?=) Date: Thu, 1 Dec 2011 12:21:47 +0400 Subject: =?UTF-8?B?UmU6IHJld3JpdGUg0LIg0YLQvtGH0L3QvtGB0YLQuCDQutCw0Log0YMg0LDQv9Cw?= =?UTF-8?B?0YfQsA==?= In-Reply-To: <336411322644274@web33.yandex.ru> References: <7cb95bb663d8876a3a6c83dea2330816.NginxMailingListRussian@forum.nginx.org> <1322623029.11485.5.camel@N900> <336411322644274@web33.yandex.ru> Message-ID: Приветствую! 30 ноября 2011 г. 13:11 пользователь Denis F. Latypoff написал: > 30.11.2011, 10:17, "Мисбах-Соловь?в Вадим" : >> Ну, или менее любимый Игорем стиль реврайтов: >> location ~ ^/some/img/banners/ { >> try_files $uri $uri/ @banner; >> } >> > > зачем лишний stat(2)? > >> location @banner { >>    rewrite ^/([0-9]{1,4})-([0-5]).png$ /file.php?id=$1&type=$2; >> } >> >> Ну и вообще... Я бы посоветовал автору для начала убрать "permanent" из своего изначального варианта, потом пойти почитать доку по реврайтам, чтобы увидель в чем отличие last от permanent, например. Потом быть счастливым благодаря заработавшему реврайту. ;)) > > А я бы посоветовал автору с переходом на nginx забыть про рерайты вообще. > А вам бы посоветовал советовать новичкам то, что я посоветовал )) > В 99% случаях они не нужны вообще. Для статики есть alias, для редиректов > есть return, для всего остального *_pass. return для редиректов - это как? "It is possible to use the following values: 200, 204, 400, 402-406, 408, 410, 411, 413, 416 and 500-504" -- Alexey Malov From latypoff на yandex.ru Thu Dec 1 09:00:26 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Thu, 01 Dec 2011 16:00:26 +0700 Subject: =?UTF-8?B?UmU6IHJld3JpdGUg0LIg0YLQvtGH0L3QvtGB0YLQuCDQutCw0Log0YMg0LDQv9Cw?= =?UTF-8?B?0YfQsA==?= In-Reply-To: References: <7cb95bb663d8876a3a6c83dea2330816.NginxMailingListRussian@forum.nginx.org> <1322623029.11485.5.camel@N900> <336411322644274@web33.yandex.ru> Message-ID: <567161322730026@web68.yandex.ru> 01.12.2011, 15:21, "Алексей Малов" : > Приветствую! > > 30 ноября 2011 г. 13:11 пользователь Denis F. Latypoff > написал: > >>  30.11.2011, 10:17, "Мисбах-Соловь?в Вадим" : >>>  Ну, или менее любимый Игорем стиль реврайтов: >>>  location ~ ^/some/img/banners/ { >>>  try_files $uri $uri/ @banner; >>>  } >>  зачем лишний stat(2)? >>>  location @banner { >>>     rewrite ^/([0-9]{1,4})-([0-5]).png$ /file.php?id=$1&type=$2; >>>  } >>> >>>  Ну и вообще... Я бы посоветовал автору для начала убрать "permanent" из своего изначального варианта, потом пойти почитать доку по реврайтам, чтобы увидель в чем отличие last от permanent, например. Потом быть счастливым благодаря заработавшему реврайту. ;)) >>  А я бы посоветовал автору с переходом на nginx забыть про рерайты вообще. >>  А вам бы посоветовал советовать новичкам то, что я посоветовал )) >>  В 99% случаях они не нужны вообще. Для статики есть alias, для редиректов >>  есть return, для всего остального *_pass. > > return для редиректов - это как? > "It is possible to use the following values: 200, 204, 400, 402-406, > 408, 410, 411, 413, 416 and 500-504" > location = /redirect.html { return [301|302] /redirected.html; } -- br, Denis F. Latypoff. From ne на vbart.ru Thu Dec 1 09:07:25 2011 From: ne на vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 1 Dec 2011 13:07:25 +0400 Subject: =?UTF-8?B?UmU6IHJld3JpdGUgINCyINGC0L7Rh9C90L7RgdGC0Lgg0LrQsNC6INGDINCw0L8=?= =?UTF-8?B?0LDRh9Cw?= In-Reply-To: References: <7cb95bb663d8876a3a6c83dea2330816.NginxMailingListRussian@forum.nginx.org> <336411322644274@web33.yandex.ru> Message-ID: <201112011307.25469.ne@vbart.ru> On Thursday 01 December 2011 12:21:47 Алексей Малов wrote: > > return для редиректов - это как? > "It is possible to use the following values: 200, 204, 400, 402-406, > 408, 410, 411, 413, 416 and 500-504" return http://example.com/en/; Можно даже с переменными: return http://$var.example.com/; Можно еще и код указать: return 301 http://nginx.org/; -- Валентин Бартенев From nginx-forum на nginx.us Thu Dec 1 09:09:14 2011 From: nginx-forum на nginx.us (yokodzun) Date: Thu, 01 Dec 2011 04:09:14 -0500 Subject: alias issue again In-Reply-To: <4ED66A93.7090802@csdoc.com> References: <4ED66A93.7090802@csdoc.com> Message-ID: <6bf515421916157a069078901a08ff64.NginxMailingListRussian@forum.nginx.org> Gena Makhomed Wrote: > скорее всего ему не только > /pma/ нужно будет на сервере, > но и другие locations тоже. > поэтому наверное - лучше > изначально > писать легко > масштабируемую > конфигурацию, используя > вложенные > locations, т.е. примерно так: > > server { > ... > location /pma/ { > ... > location ~ \.php$ { > ... > } > } > } > Если я правильно понял Вашу идею, то конфиг получился такой: location ~ \.php$ { fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /usr/local/www; fastcgi_param SCRIPT_FILENAME /usr/local/www$fastcgi_script_name; include fastcgi_params; } location /pma/ { alias /usr/local/www/phpMyAdmin/; #root /usr/local/www/phpMyAdmin; index index.php; location ~ \.php$ { fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin; fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin$fastcgi_script_name; include fastcgi_params; } } но в логе получаею что-то для меня совсем непонятное: errlog 2011/12/01 16:05:14 [info] 83996#0: *45 client closed prematurely connection while reading client request line, client: 213.133.166.70, server: localhost 2011/12/01 16:05:14 [info] 83996#0: *44 client closed prematurely connection while reading client request line, client: 213.133.166.70, server: localhost access 213.133.166.70 - - [01/Dec/2011:16:05:01 +0700] "GET /pma/ HTTP/1.1" 404 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2" 213.133.166.70 - - [01/Dec/2011:16:05:14 +0700] "-" 400 0 "-" "-" 213.133.166.70 - - [01/Dec/2011:16:05:14 +0700] "-" 400 0 "-" "-" > > вместо rewrite ^/pma/(.+)$ /phpMyAdmin/$1 > break; > в конфиге наверное лучше > использовать alias все-таки. > судя по документации > именно для этого директива > alias и придумана. > Да, хотелось бы таки добить через алиасы. Хотя, может быть для моего сулчая это неправильный инструмент? Задачу правильней решать иначе? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219415#msg-219415 From nginx-forum на nginx.us Thu Dec 1 09:42:34 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 04:42:34 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <201112011058.15404.ne@vbart.ru> References: <201112011058.15404.ne@vbart.ru> Message-ID: >А почему это проблема? Это проблема потому, что один клиент может исчерпать conntrack таблицу сервера. В Linux это по умолчанию всего 65535. Можно увеличить этот параметр раз в 10-20, но это лишний расход оперативной памяти, и рост времени поиска по conntrack таблице. Можно также отключить conntrack в iptables, но после этого многие модули iptables работающие с состоянием соединений не будут функционировать. Хотелось бы иметь решение проблемы на уровне web сервера четко осознавая, что если в конфигурации web сервера всего один локэйшн с параметрами limit_conn addr 10, то больше 10 tcp сессий от каждого из клиентов в conntrack таблице не будет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219416#msg-219416 From nginx-forum на nginx.us Thu Dec 1 09:44:12 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 04:44:12 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <4ED7338F.40209@altlinux.ru> References: <4ED7338F.40209@altlinux.ru> Message-ID: Anton Gorlov Wrote: ------------------------------------------------------- > разве что файрволлом > попытаться ограничивать > кол-во подключений Покажите каким образом Вы хотите файрволлом ограничить доступ к выбранному location. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219417#msg-219417 From nefer05 на gmail.com Thu Dec 1 09:46:55 2011 From: nefer05 на gmail.com (Nefer) Date: Thu, 01 Dec 2011 13:46:55 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: <201112011058.15404.ne@vbart.ru> Message-ID: <4ED74D0F.4020709@gmail.com> On 12/01/11 13:42, INF[SZ] wrote: >> А почему это проблема? > Это проблема потому, что один клиент > может исчерпать conntrack таблицу сервера. > В Linux это по умолчанию всего 65535. Я, возможно, что то упустил, но каким образом кипаливы способны отожрать conntrack? Они все сидят в рамках одного TCP соединения! From mdounin на mdounin.ru Thu Dec 1 09:54:35 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 1 Dec 2011 13:54:35 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: <4ED7338F.40209@altlinux.ru> Message-ID: <20111201095434.GW67687@mdounin.ru> Hello! On Thu, Dec 01, 2011 at 04:44:12AM -0500, INF[SZ] wrote: > Anton Gorlov Wrote: > ------------------------------------------------------- > > разве что файрволлом > > попытаться ограничивать > > кол-во подключений > > Покажите каким образом Вы хотите > файрволлом ограничить доступ к > выбранному location. А каким образом вы хотите сделать это через nginx? Директива limit_conn позволяет ограничить работающие в данном location запросы. Если запроса нет, а соединение висит в keepalive, то ни к какому location'у это соединение отнести нельзя, ибо какой там будет очередной запрос (и будет ли вообще) - неизвестно. In short: 1. Ограничить количество соединений, делающих что-то в данном location'е - limit_conn. Например, ограничить скачивание больших файлов во много потоков. Или обращения к тяжёлому скрипту, долго отдающему результат. 2. Ограничить все установленные соединения - firewall. Maxim Dounin From mdounin на mdounin.ru Thu Dec 1 10:19:24 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 1 Dec 2011 14:19:24 +0400 Subject: =?UTF-8?B?UmU6IHJld3JpdGUg0LIg0YLQvtGH0L3QvtGB0YLQuCDQutCw0Log0YMg0LDQv9Cw?= =?UTF-8?B?0YfQsA==?= In-Reply-To: References: <7cb95bb663d8876a3a6c83dea2330816.NginxMailingListRussian@forum.nginx.org> <1322623029.11485.5.camel@N900> <336411322644274@web33.yandex.ru> Message-ID: <20111201101923.GY67687@mdounin.ru> Hello! On Thu, Dec 01, 2011 at 12:21:47PM +0400, Алексей Малов wrote: > Приветствую! > > 30 ноября 2011 г. 13:11 пользователь Denis F. Latypoff > написал: > > 30.11.2011, 10:17, "Мисбах-Соловь?в Вадим" : > >> Ну, или менее любимый Игорем стиль реврайтов: > >> location ~ ^/some/img/banners/ { > >> try_files $uri $uri/ @banner; > >> } > >> > > > > зачем лишний stat(2)? > > > >> location @banner { > >>    rewrite ^/([0-9]{1,4})-([0-5]).png$ /file.php?id=$1&type=$2; > >> } > >> > >> Ну и вообще... Я бы посоветовал автору для начала убрать "permanent" из своего изначального варианта, потом пойти почитать доку по реврайтам, чтобы увидель в чем отличие last от permanent, например. Потом быть счастливым благодаря заработавшему реврайту. ;)) > > > > А я бы посоветовал автору с переходом на nginx забыть про рерайты вообще. > > А вам бы посоветовал советовать новичкам то, что я посоветовал )) > > В 99% случаях они не нужны вообще. Для статики есть alias, для редиректов > > есть return, для всего остального *_pass. > > return для редиректов - это как? > "It is possible to use the following values: 200, 204, 400, 402-406, > 408, 410, 411, 413, 416 and 500-504" Changes with nginx 0.8.42: *) Feature: a text answer may be added to a "return" directive. Changes with nginx 0.7.51: *) Feature: now any response code can be used in the "return" directive. Maxim Dounin From gmm на csdoc.com Thu Dec 1 12:55:55 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 01 Dec 2011 14:55:55 +0200 Subject: alias issue again In-Reply-To: <6bf515421916157a069078901a08ff64.NginxMailingListRussian@forum.nginx.org> References: <4ED66A93.7090802@csdoc.com> <6bf515421916157a069078901a08ff64.NginxMailingListRussian@forum.nginx.org> Message-ID: <4ED7795B.2040309@csdoc.com> On 01.12.2011 11:09, yokodzun wrote: >> лучше >> изначально >> писать легко >> масштабируемую >> конфигурацию, используя >> вложенные >> locations, т.е. примерно так: >> >> server { >> ... >> location /pma/ { >> ... >> location ~ \.php$ { >> ... >> } >> } >> } > Если я правильно понял Вашу идею, то > конфиг получился такой: > > location ~ \.php$ { > fastcgi_pass unix:/tmp/php-fpm.sock; > fastcgi_index index.php; > fastcgi_param DOCUMENT_ROOT /usr/local/www; > fastcgi_param SCRIPT_FILENAME > /usr/local/www$fastcgi_script_name; > include fastcgi_params; > } > > location /pma/ { > alias /usr/local/www/phpMyAdmin/; > #root /usr/local/www/phpMyAdmin; > index index.php; > > location ~ \.php$ { > fastcgi_pass unix:/tmp/php-fpm.sock; > fastcgi_index index.php; > fastcgi_param DOCUMENT_ROOT > /usr/local/www/phpMyAdmin; > fastcgi_param SCRIPT_FILENAME > /usr/local/www/phpMyAdmin$fastcgi_script_name; > include fastcgi_params; > } > > } > > но в логе получаею что-то для меня > совсем непонятное: > > errlog > > 2011/12/01 16:05:14 [info] 83996#0: *45 client closed prematurely > connection while reading client request line, client: 213.133.166.70, > server: localhost > 2011/12/01 16:05:14 [info] 83996#0: *44 client closed prematurely > connection while reading client request line, client: 213.133.166.70, > server: localhost > > access > > 213.133.166.70 - - [01/Dec/2011:16:05:01 +0700] "GET /pma/ HTTP/1.1" 404 > 5 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.2 > (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2" > 213.133.166.70 - - [01/Dec/2011:16:05:14 +0700] "-" 400 0 "-" "-" > 213.133.166.70 - - [01/Dec/2011:16:05:14 +0700] "-" 400 0 "-" "-" > а если посмотреть в логи PHP ? это ведь он возвращает 404 ошибку. >> вместо rewrite ^/pma/(.+)$ /phpMyAdmin/$1 >> break; >> в конфиге наверное лучше >> использовать alias все-таки. >> судя по документации >> именно для этого директива >> alias и придумана. > Да, хотелось бы таки добить через > алиасы. > Хотя, может быть для моего сулчая это > неправильный инструмент? насколько я понимаю, alias подходит. почему PHP возвращает 404 ошибку - я не знаю пока что. > Задачу правильней решать иначе? а как задача звучит? -- Best regards, Gena From nginx-forum на nginx.us Thu Dec 1 13:53:06 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 08:53:06 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <4ED74D0F.4020709@gmail.com> References: <4ED74D0F.4020709@gmail.com> Message-ID: <4a300ee3ccfd68ad705812906b4ec518.NginxMailingListRussian@forum.nginx.org> Nefer Wrote: > Я, возможно, что то упустил, > но каким образом кипаливы > способны отожрать > conntrack? Они все сидят в > рамках одного TCP > соединения! > Например так: Вот настройки Nginx касающиеся keepalive keepalive_timeout 45 60; keepalive_requests 10000; на location / стоят ограничения limit_conn addr 10; Смотрим кол-во conntrack sysctl -a|grep net.ipv4.netfilter.ip_conntrack_count net.ipv4.netfilter.ip_conntrack_count = 678 Теперь на клиентской машине запускаем ab -n 1000000 -c 5 http://example.com/ Смотрим кол-во conntrack sysctl -a|grep net.ipv4.netfilter.ip_conntrack_count net.ipv4.netfilter.ip_conntrack_count = 65535 В dmesg kernel: ip_conntrack: table full, dropping packet. Cистема стала не управляема, ни один клиент не может соединиться ни с одним сервисом на машине. До тех пор пока сессии по таймаутам не отвалятся. Хотелось бы избежать данной ситуации средствами приложения задав суммарное максимальное количество одновременных соединений, а также максимальное количество одновременных соединений для выбраных location, без проблем описанных Валентином Бартеневым Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219427#msg-219427 From nginx-forum на nginx.us Thu Dec 1 13:57:31 2011 From: nginx-forum на nginx.us (yokodzun) Date: Thu, 01 Dec 2011 08:57:31 -0500 Subject: alias issue again In-Reply-To: <4ED7795B.2040309@csdoc.com> References: <4ED7795B.2040309@csdoc.com> Message-ID: Gena Makhomed Wrote: > > а если посмотреть в логи PHP ? > это ведь он возвращает 404 > ошибку. Включил дебаг PHP, в errlog [01-Dec-2011 20:49:44.595347] DEBUG: pid 84518, fpm_pctl_perform_idle_server_maintenance(), line 362: [pool www] currently 0 active children, 20 spare children, 20 running children. Spawning rate 1 [01-Dec-2011 20:49:45.597341] DEBUG: pid 84518, fpm_pctl_perform_idle_server_maintenance(), line 362: [pool www] currently 0 active children, 20 spare children, 20 running children. Spawning rate 1 [01-Dec-2011 20:49:46.599338] DEBUG: pid 84518, fpm_pctl_perform_idle_server_maintenance(), line 362: [pool www] currently 0 active children, 20 spare children, 20 running children. Spawning rate 1 в access при запросе /pma/ - - 01/Dec/2011:20:45:50 +0700 "GET /pma/index.php" 404 - - 01/Dec/2011:20:46:26 +0700 "GET /pma/index.php" 404 при запросе полного пути - - 01/Dec/2011:20:49:39 +0700 "GET /phpMyAdmin/index.php" 200 - - 01/Dec/2011:20:49:40 +0700 "GET /phpMyAdmin/phpmyadmin.css.php" 200 - - 01/Dec/2011:20:49:41 +0700 "GET /phpMyAdmin/js/messages.php" 200 Судя по всем, таки не правильно срабатывает alias > > насколько я понимаю, alias > подходит. > > почему PHP возвращает 404 > ошибку - я не знаю пока что. > > > Задачу правильней решать > иначе? > > а как задача звучит? > Собственно типичная, как мне кажется. Стандартный путь, куда устанавливается портовый phpmyadmin - /usr/local/www/phpMyAdmin Те, кто будет его использовать, привыкли к /pma/, что понятно, удобней и короче. Хочется получить это удобство, и не потерять возможность обновлять софт из портов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219428#msg-219428 From nginx-forum на nginx.us Thu Dec 1 14:19:43 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Thu, 01 Dec 2011 09:19:43 -0500 Subject: php-fpm upstream pool In-Reply-To: References: Message-ID: <6107178ded0228eaa8962b2a03596dc7.NginxMailingListRussian@forum.nginx.org> Перенес nginx на физическую машину, теперь "всегда живой" бэкенд перестал отваливаться по таймауту (надо бы инвестигировать поведение фрибсд в виртуальной машине, но это не по теме). Ситуация слегка поменялясь, но все равно плохо - на 10000 соединений 30 отвалились по 504 ошибке, вот таким образом: 10.0.0.1 - - [01/Dec/2011:15:08:40 +0200] "GET /fcgi-proxy/ HTTP/1.1" 504 183 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.70)" "-" "10.0.0.77:9003, 10.0.0.77:9004 504, 504 - 10.002, 10.002" 20.004 SSL:-/- "gzip:-" 10.0.0.1 - - [01/Dec/2011:15:08:40 +0200] "GET /fcgi-proxy/ HTTP/1.1" 504 183 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.70)" "-" "10.0.0.77:9003, 10.0.0.77:9004 504, 504 - 10.002,10.002" 20.004 SSL:-/- "gzip:-" {skip} причем есть и корректные, например: 10.0.0.1 - - [01/Dec/2011:15:06:07 +0200] "GET /fcgi-proxy/ HTTP/1.1" 200 33 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.70)" "-" "10.0.0.77:9001, 10.0.0.77:9002, 10.0.0.73:9000 504, 504, 200 - 10.002, 10.001, 0.006" 20.009 SSL:-/- "gzip:-" ---- Поставил nginx 1.1.9. Намного лучше, в общем то, что хотелось. На 10000 соединений 504-х (и 502) нет вообще, а есть только 18 соединений по 10 секунд: HTTP/1.1 200 10.01 secs: 22 bytes ==> /fcgi-proxy/ HTTP/1.1 200 10.01 secs: 22 bytes ==> /fcgi-proxy/ HTTP/1.1 200 10.01 secs: 22 bytes ==> /fcgi-proxy/ {skip} Это потому что 1.1.X проверяет нерабочий бэкенд только одним запросом. Есть ли планы сделать так же в 1.0.X ветке? --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219032,219429#msg-219429 From nginx-forum на nginx.us Thu Dec 1 14:28:34 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 09:28:34 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <20111201095434.GW67687@mdounin.ru> References: <20111201095434.GW67687@mdounin.ru> Message-ID: <177ab15d5968bc4574bc37fb1b81f838.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: > А каким образом вы хотите > сделать это через nginx? > Директива > limit_conn позволяет ограничить > работающие в данном location > запросы. Если запроса нет, > а соединение висит в keepalive, > то ни > к какому location'у это > соединение отнести нельзя, > ибо какой там > будет очередной запрос (и > будет ли вообще) - > неизвестно. > > In short: > > 1. Ограничить количество > соединений, делающих что-то > в данном > location'е - limit_conn. Например, > ограничить скачивание > больших > файлов во много потоков. > Или обращения к тяжёлому > скрипту, долго > отдающему результат. > > 2. Ограничить все > установленные соединения - > firewall. > > Maxim Dounin > Вынужден согласиться, пожалуй это единственный на данный момент вариант. Тогда можно ли по срабатыванию ограничений limit_conn, limit_req вызывать внешний скрипт с передачей ему в качестве параметров ip, server, location. Решение с парсингом логов по крону кажется несколько топорным. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219430#msg-219430 From ne на vbart.ru Thu Dec 1 15:06:45 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 1 Dec 2011 19:06:45 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiAg0L3QtSDRhdCy0LDRgtCw?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <177ab15d5968bc4574bc37fb1b81f838.NginxMailingListRussian@forum.nginx.org> References: <20111201095434.GW67687@mdounin.ru> <177ab15d5968bc4574bc37fb1b81f838.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112011906.45901.ne@vbart.ru> On Thursday 01 December 2011 18:28:34 INF[SZ] wrote: [...] > > Тогда можно ли по срабатыванию > ограничений limit_conn, limit_req вызывать > внешний скрипт с передачей ему в > качестве параметров ip, server, location. > Решение с парсингом логов по крону > кажется несколько топорным. > При большом желании можно: с использованием директивы error_page, и proxy/fastcgi/uwsgi_pass - будет это в 10 раз топорнее. Но это каким-то образом помешает открыть сколько угодно соединений, не посылая запросов вообще? Вам уже много раз намекнули, вы не на том уровне пытаетесь решить свою проблему. -- Валентин Бартенев From nginx-forum на nginx.us Thu Dec 1 16:18:02 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 11:18:02 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <201112011906.45901.ne@vbart.ru> References: <201112011906.45901.ne@vbart.ru> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > Вам уже много раз > намекнули, вы не на том > уровне пытаетесь решить > свою проблему. Резюмируя: На "подлете" к nginx, например на пограничном маршрутизаторе ограничиваем общее количество TCP сессий на 80 порт web сервера, также ограничиваем количество одновременных TCP сессий от каждого ip адреса. На сервере ставим ограничение в location limit_conn, limit_req ограничивая "тяжелый" либо долго обрабатываемый контент.. Спасибо участникам обсуждения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219435#msg-219435 From gmm на csdoc.com Thu Dec 1 16:29:19 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 01 Dec 2011 18:29:19 +0200 Subject: alias issue again In-Reply-To: References: <4ED7795B.2040309@csdoc.com> Message-ID: <4ED7AB5F.4030305@csdoc.com> On 01.12.2011 15:57, yokodzun wrote: > при запросе /pma/ > > - - 01/Dec/2011:20:45:50 +0700 "GET /pma/index.php" 404 > - - 01/Dec/2011:20:46:26 +0700 "GET /pma/index.php" 404 > > при запросе полного пути > > - - 01/Dec/2011:20:49:39 +0700 "GET /phpMyAdmin/index.php" 200 > - - 01/Dec/2011:20:49:40 +0700 "GET /phpMyAdmin/phpmyadmin.css.php" > 200 > - - 01/Dec/2011:20:49:41 +0700 "GET /phpMyAdmin/js/messages.php" 200 > Судя по всем, таки не правильно > срабатывает alias alias скорее всего срабатывает правильно. похоже что это я раньше не правильно понимал, как эта директива работает. получается, что alias меняет location только для запросов к статике. а поскольку index.php - не статика, то он обрабатывается во вложенном location ~ \.php$ он as-is, без модификации, так что без директивы "rewrite ^/pma/(.+)$ /phpMyAdmin/$1 break;" из модуля mod_rewrite внутри location ~ \.php$ похоже что никак не обойтись: server { ... location / { ... } location /pma/ { alias /usr/local/www/phpMyAdmin/; index index.php; location ~ \.php$ { rewrite ^/pma/(.+)$ /phpMyAdmin/$1 break; ... } } } похоже что в таком варианте - все должно работать нормально, и возможно - это будет самый оптимальный вариант настройки. потому что вся работа с /pma/ будет теперь инкапсусирована внутри одного location`а и этот location /pma/ { ... } можно будет менять/настраивать независимо от всех остальных location`ов, которые могут быть в этом server`е. -- Best regards, Gena From mdounin на mdounin.ru Thu Dec 1 17:12:27 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 1 Dec 2011 21:12:27 +0400 Subject: php-fpm upstream pool In-Reply-To: <6107178ded0228eaa8962b2a03596dc7.NginxMailingListRussian@forum.nginx.org> References: <6107178ded0228eaa8962b2a03596dc7.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111201171227.GZ67687@mdounin.ru> Hello! On Thu, Dec 01, 2011 at 09:19:43AM -0500, igor.goncharenko wrote: > Перенес nginx на физическую машину, > теперь "всегда живой" бэкенд перестал > отваливаться по таймауту (надо бы > инвестигировать поведение фрибсд в > виртуальной машине, но это не по теме). Если это не в рамках одной виртуальной машины, то скорее исследовать надо сетевую подсистему виртуализатора. Обычно она не блещет и/или имеет в себе statefull firewall, со всеми вытекающими прелестями в виде потери соединений при переполнении таблицы состояний и невозможности использования timewait'ов, пока не протухнет соответствующая запись в firewall'е. > Ситуация слегка поменялясь, но все > равно плохо - на 10000 соединений 30 > отвалились по 504 ошибке, вот таким > образом: > > 10.0.0.1 - - [01/Dec/2011:15:08:40 +0200] "GET /fcgi-proxy/ HTTP/1.1" > 504 183 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.70)" "-" > "10.0.0.77:9003, 10.0.0.77:9004 504, 504 - 10.002, 10.002" 20.004 > SSL:-/- "gzip:-" > > 10.0.0.1 - - [01/Dec/2011:15:08:40 +0200] "GET /fcgi-proxy/ HTTP/1.1" > 504 183 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.70)" "-" > "10.0.0.77:9003, 10.0.0.77:9004 504, 504 - 10.002,10.002" 20.004 SSL:-/- > "gzip:-" > > {skip} > причем есть и корректные, например: > > 10.0.0.1 - - [01/Dec/2011:15:06:07 +0200] "GET /fcgi-proxy/ HTTP/1.1" > 200 33 "-" "JoeDog/1.00 [en] (X11; I; Siege 2.70)" "-" "10.0.0.77:9001, > 10.0.0.77:9002, 10.0.0.73:9000 504, 504, 200 - 10.002, 10.001, 0.006" > 20.009 SSL:-/- "gzip:-" Судя по всему, это одно из проявлений вот этого бага: http://trac.nginx.org/nginx/ticket/64 > ---- > Поставил nginx 1.1.9. Намного лучше, в общем > то, что хотелось. На 10000 соединений 504-х > (и 502) нет вообще, а есть только 18 > соединений по 10 секунд: > > HTTP/1.1 200 10.01 secs: 22 bytes ==> /fcgi-proxy/ > HTTP/1.1 200 10.01 secs: 22 bytes ==> /fcgi-proxy/ > HTTP/1.1 200 10.01 secs: 22 bytes ==> /fcgi-proxy/ > {skip} > > Это потому что 1.1.X проверяет нерабочий > бэкенд только одним запросом. Есть ли > планы сделать так же в 1.0.X ветке? Скорее нет, чем да. Изменение в целом хорошее, но потенциально может затронуть работающие конфигурации с долгими запросами и/или 3rd party балансировщиками. А чем 1.1.x не устраивает? Maxim Dounin From voron на amhost.net Thu Dec 1 17:40:12 2011 From: voron на amhost.net (Alex Vorona) Date: Thu, 01 Dec 2011 19:40:12 +0200 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <4a300ee3ccfd68ad705812906b4ec518.NginxMailingListRussian@forum.nginx.org> References: <4ED74D0F.4020709@gmail.com> <4a300ee3ccfd68ad705812906b4ec518.NginxMailingListRussian@forum.nginx.org> Message-ID: <4ED7BBFC.7020209@amhost.net> 01.12.2011 15:53, INF[SZ] wrote: > Смотрим кол-во conntrack > > sysctl -a|grep net.ipv4.netfilter.ip_conntrack_count > > net.ipv4.netfilter.ip_conntrack_count = 65535 > > В dmesg > > kernel: ip_conntrack: table full, dropping packet. А зачем conntrack'ать коннекты к 80-му порту? -j NOTRACK в raw table и все счастливы? From nginx-forum на nginx.us Thu Dec 1 21:21:13 2011 From: nginx-forum на nginx.us (J3FF3) Date: Thu, 01 Dec 2011 16:21:13 -0500 Subject: =?UTF-8?B?UmU6IHJld3JpdGUg0LIg0YLQvtGH0L3QvtGB0YLQuCDQutCw0Log0YMg0LDQv9Cw?= =?UTF-8?B?0YfQsA==?= In-Reply-To: <20111201101923.GY67687@mdounin.ru> References: <20111201101923.GY67687@mdounin.ru> Message-ID: <2993de8ce82df98d3efdfdfd6e912413.NginxMailingListRussian@forum.nginx.org> Доброго времени суток. Спасибо за ответы по теме. Пошаманил, родил следующий кусок: location ~ ^/img([0-9]*).gif$ { rewrite ^/img([0-9]*).gif$ /index.php?r=controller/get_img&id=$1 last; } С try_files что-то не сработало у меня, потому так сделал. Вроде работает. Кстати, у меня стояло даже не permanent, а break. Это я по памяти чтото напутал. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219323,219442#msg-219442 From nginx-forum на nginx.us Thu Dec 1 21:30:20 2011 From: nginx-forum на nginx.us (alex_ru) Date: Thu, 01 Dec 2011 16:30:20 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: Приветствую, Подскажите пожалуйста, чего надо поставить, что бы скомпилировать nginx. Зашел сюда http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express . Чего качать не понял, Visual C++? Если нет, дайте пожалуйста ссылку, с C вообще не знаком, есть некие трудности в понимании задачи. Msys еще не пробовал ставить, почитаю пока что это такое :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219443#msg-219443 From andrew на nginx.com Thu Dec 1 21:34:13 2011 From: andrew на nginx.com (Andrew Alexeev) Date: Thu, 1 Dec 2011 16:34:13 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: Это читали? :) http://nginx.org/en/docs/howto_build_on_win32.html -- On Dec 1, 2011, at 16:30, "alex_ru" wrote: > Приветствую, > > Подскажите пожалуйста, чего надо > поставить, что бы скомпилировать nginx. > Зашел сюда > http://www.microsoft.com/visualstudio/en-us/products/2010-editions/express > . Чего качать не понял, Visual C++? Если нет, > дайте пожалуйста ссылку, с C вообще не > знаком, есть некие трудности в > понимании задачи. > Msys еще не пробовал ставить, почитаю > пока что это такое :) > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219443#msg-219443 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From latypoff на yandex.ru Thu Dec 1 21:35:27 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Fri, 02 Dec 2011 04:35:27 +0700 Subject: =?UTF-8?B?UmU6IHJld3JpdGUg0LIg0YLQvtGH0L3QvtGB0YLQuCDQutCw0Log0YMg0LDQv9Cw?= =?UTF-8?B?0YfQsA==?= In-Reply-To: <2993de8ce82df98d3efdfdfd6e912413.NginxMailingListRussian@forum.nginx.org> References: <20111201101923.GY67687@mdounin.ru> <2993de8ce82df98d3efdfdfd6e912413.NginxMailingListRussian@forum.nginx.org> Message-ID: <163591322775327@web151.yandex.ru> 02.12.2011, 04:21, "J3FF3" : > Доброго времени суток. Спасибо за > ответы по теме. > > Пошаманил, родил следующий кусок: > Можно избежать ненужного шороху в виде поиска /index.php после рерайта. >         location ~ ^/img([0-9]*).gif$ { -                 rewrite ^/img([0-9]*).gif$ - /index.php?r=controller/get_img&id=$1 last; + fastcgi_pass ... + fastcgi_include fastcgi.conf; + fastcgi_param SCRIPT_FILENAME /path/to/index.php; + fastcgi_param QUERY_STRING r=controller/get_img&id=$1; >         } > > С try_files что-то не сработало у меня, > потому так сделал. Вроде работает. try_files и не нужен, не в этом его предназначение. > > Кстати, у меня стояло даже не permanent, а > break. Это я по памяти чтото напутал. > Тогда редиректа не должно было быть. -- br, Denis F. Latypoff. From nginx-forum на nginx.us Thu Dec 1 21:58:16 2011 From: nginx-forum на nginx.us (alex_ru) Date: Thu, 01 Dec 2011 16:58:16 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: References: Message-ID: <442e1527637bfd3f372cb89aeeac7644.NginxMailingListRussian@forum.nginx.org> Andrew Alexeev Wrote: ------------------------------------------------------- > Это читали? :) > http://nginx.org/en/docs/howto_build_on_win32.html Ага, только пункт 1 (Microsoft Visual C compiler. Microsoft Visual Studio? 8 and 10 are known to work.) меня немного выбил, когда я зашел качать эту самую студию :) Нашел только C++ и C#, а вот просто C не нашел. Моих знания в этой области весьма скромны, но как я знаю это все разные языки. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219446#msg-219446 From scukonick на gmail.com Thu Dec 1 22:00:27 2011 From: scukonick на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQsNC70L7Qsg==?=) Date: Fri, 2 Dec 2011 02:00:27 +0400 Subject: =?UTF-8?B?UmU6IHJld3JpdGUg0LIg0YLQvtGH0L3QvtGB0YLQuCDQutCw0Log0YMg0LDQv9Cw?= =?UTF-8?B?0YfQsA==?= In-Reply-To: <20111201101923.GY67687@mdounin.ru> References: <7cb95bb663d8876a3a6c83dea2330816.NginxMailingListRussian@forum.nginx.org> <1322623029.11485.5.camel@N900> <336411322644274@web33.yandex.ru> <20111201101923.GY67687@mdounin.ru> Message-ID: 1 декабря 2011 г. 14:19 пользователь Maxim Dounin написал: > Hello! > > On Thu, Dec 01, 2011 at 12:21:47PM +0400, Алексей Малов wrote: > >> Приветствую! >> >> 30 ноября 2011 г. 13:11 пользователь Denis F. Latypoff >> написал: >> > 30.11.2011, 10:17, "Мисбах-Соловь?в Вадим" : >> >> Ну, или менее любимый Игорем стиль реврайтов: >> >> location ~ ^/some/img/banners/ { >> >> try_files $uri $uri/ @banner; >> >> } >> >> >> > >> > зачем лишний stat(2)? >> > >> >> location @banner { >> >>    rewrite ^/([0-9]{1,4})-([0-5]).png$ /file.php?id=$1&type=$2; >> >> } >> >> >> >> Ну и вообще... Я бы посоветовал автору для начала убрать "permanent" из своего изначального варианта, потом пойти почитать доку по реврайтам, чтобы увидель в чем отличие last от permanent, например. Потом быть счастливым благодаря заработавшему реврайту. ;)) >> > >> > А я бы посоветовал автору с переходом на nginx забыть про рерайты вообще. >> > А вам бы посоветовал советовать новичкам то, что я посоветовал )) >> > В 99% случаях они не нужны вообще. Для статики есть alias, для редиректов >> > есть return, для всего остального *_pass. >> >> return для редиректов - это как? >> "It is possible to use the following values: 200, 204, 400, 402-406, >> 408, 410, 411, 413, 416 and 500-504" > > Changes with nginx 0.8.42: > >    *) Feature: a text answer may be added to a "return" directive. > > Changes with nginx 0.7.51: > >    *) Feature: now any response code can be used in the "return" directive. Ого, вот к чему чтение старой документации приводит, совсем от жизни отстал. Спасибо большое всем ответившим. > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Alexey Malov From nginx-forum на nginx.us Thu Dec 1 22:36:02 2011 From: nginx-forum на nginx.us (Craken) Date: Thu, 01 Dec 2011 17:36:02 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: References: Message-ID: <54e957fbf64a6b8cf02c0c02f989ab68.NginxMailingListRussian@forum.nginx.org> to alex_ru: C можно скомпилировать компилятором C++! А вот C# - это уже действительно другой язык! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219449#msg-219449 From nginx-forum на nginx.us Fri Dec 2 00:03:14 2011 From: nginx-forum на nginx.us (INF[SZ]) Date: Thu, 01 Dec 2011 19:03:14 -0500 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <4ED7BBFC.7020209@amhost.net> References: <4ED7BBFC.7020209@amhost.net> Message-ID: <29a1c02ce0a0ee8643854e8f4a190103.NginxMailingListRussian@forum.nginx.org> Alex Vorona Wrote: ------------------------------------------------------- > А зачем conntrack'ать коннекты к > 80-му порту? -j NOTRACK в raw table и > все счастливы? Это понятно, я пытался понять возможно ли выкрутиться средствами приложения. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219451#msg-219451 From nginx-forum на nginx.us Fri Dec 2 08:47:31 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Fri, 02 Dec 2011 03:47:31 -0500 Subject: php-fpm upstream pool In-Reply-To: <20111201171227.GZ67687@mdounin.ru> References: <20111201171227.GZ67687@mdounin.ru> Message-ID: <96a56f6dfbd266da481cb19b2d2b1991.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > > инвестигировать > поведение фрибсд в > > виртуальной машине, но это > не по теме). > > Если это не в рамках одной > виртуальной машины, то > скорее > исследовать надо сетевую > подсистему виртуализатора. > Обычно она не > блещет и/или имеет в себе > statefull firewall, со всеми > вытекающими > прелестями в виде потери > соединений при > переполнении таблицы > состояний и невозможности > использования timewait'ов, пока > не > протухнет соответствующая > запись в firewall'е. Похоже на то. Это ESXi 4.1 и я замечал некоторое несоответствие в поведении freebsd в виртуальной машине и на физической. Время заняться этим. > > 10.0.0.1 - - [01/Dec/2011:15:08:40 +0200] "GET > /fcgi-proxy/ HTTP/1.1" > > 504 183 "-" "JoeDog/1.00 [en] (X11; I; Siege > 2.70)" "-" > > "10.0.0.77:9003, 10.0.0.77:9004 504, 504 - > 10.002,10.002" 20.004 SSL:-/- > > "gzip:-" > > > > {skip} > > причем есть и корректные, > например: > > > > 10.0.0.1 - - [01/Dec/2011:15:06:07 +0200] "GET > /fcgi-proxy/ HTTP/1.1" > > 200 33 "-" "JoeDog/1.00 [en] (X11; I; Siege > 2.70)" "-" "10.0.0.77:9001, > > 10.0.0.77:9002, 10.0.0.73:9000 504, 504, 200 - > 10.002, 10.001, 0.006" > > 20.009 SSL:-/- "gzip:-" > > Судя по всему, это одно из > проявлений вот этого бага: > http://trac.nginx.org/nginx/ticket/64 Да. Очень похоже это оно. Тогда в продакшин двигать на 1.0.X нельзя пока :( >> > Поставил nginx 1.1.9. Намного > лучше, в общем > > то, что хотелось. На 10000 > соединений 504-х > > (и 502) нет вообще, а есть > только 18 > > соединений по 10 секунд: > > > > Это потому что 1.1.X > проверяет нерабочий > > бэкенд только одним > запросом. Есть ли > > планы сделать так же в 1.0.X > ветке? > > Скорее нет, чем да. > Изменение в целом хорошее, > но потенциально > может затронуть работающие > конфигурации с долгими > запросами и/или > 3rd party балансировщиками. А > чем 1.1.x не устраивает? Ситуация такая - продакшин сейчас до сих пор на 0.8.54 (балансер). В этой версии я тоже замечал присутствие бага http://trac.nginx.org/nginx/ticket/64 хотя я больше грешил на виртуализацию. С появлением ветки 1.0.X была запланирована миграция на эту ветку и сейчас вроде как время пришло, но появилась задача с fcgi пулом. И теперь оказалось, похоже, смысла мигрировать на 1.0.X нет - потому что для задач балансера этот баг - серьезный. Насчет 1.1.X. Ну во-первых, ветка позиционируется как девелопмент, соответственно, использовать на продакшине можно только в крайнем случае. Во-вторых, упомянутый вами вопрос с долгими запросами. У меня могут быть тяжелые запросы к базе, надо подумать как изменение в схеме балансинга может на них повлять - судя по всему тем, что "живые" бэкенды будут нагружены больше чем раньше. 3rd балансировщиками не пользуюсь. Я бы сделал изменение схемы балансировки в 1.0.x опциональным и выключенным по дефолту, если это возможно. Иначе судя по всему, в моем случае, мне придется ждать пока ветка 1.1.X не будет переведена в stable. > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219032,219459#msg-219459 From nginx-forum на nginx.us Fri Dec 2 09:02:48 2011 From: nginx-forum на nginx.us (alex_ru) Date: Fri, 02 Dec 2011 04:02:48 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: Спасибо, дальше думаю разберусь :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219460#msg-219460 From mdounin на mdounin.ru Fri Dec 2 10:07:36 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 2 Dec 2011 14:07:36 +0400 Subject: php-fpm upstream pool In-Reply-To: <96a56f6dfbd266da481cb19b2d2b1991.NginxMailingListRussian@forum.nginx.org> References: <20111201171227.GZ67687@mdounin.ru> <96a56f6dfbd266da481cb19b2d2b1991.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111202100736.GC67687@mdounin.ru> Hello! On Fri, Dec 02, 2011 at 03:47:31AM -0500, igor.goncharenko wrote: [...] > > Судя по всему, это одно из > > проявлений вот этого бага: > > http://trac.nginx.org/nginx/ticket/64 > > Да. Очень похоже это оно. Тогда в > продакшин двигать на 1.0.X нельзя пока :( Баг потенциально может проявится тогда и только тогда, когда более одного бекенда в пуле - мёртвые. И почти не имеет шансов проявится, если при этом более одного живого бекенда. При этом мёртвый бекенд в пуле - это, вообще говоря, чрезвычайная ситуация. [...] > > Скорее нет, чем да. > > Изменение в целом хорошее, > > но потенциально > > может затронуть работающие > > конфигурации с долгими > > запросами и/или > > 3rd party балансировщиками. А > > чем 1.1.x не устраивает? > > Ситуация такая - продакшин сейчас до > сих пор на 0.8.54 (балансер). В этой версии > я тоже замечал присутствие бага > http://trac.nginx.org/nginx/ticket/64 хотя я больше > грешил на виртуализацию. С появлением > ветки 1.0.X была запланирована миграция > на эту ветку и сейчас вроде как время > пришло, но появилась задача с fcgi пулом. > И теперь оказалось, похоже, смысла > мигрировать на 1.0.X нет - потому что для > задач балансера этот баг - серьезный. В 0.8.x в этом месте те же проблемы, и существенно хуже в других местах. > Насчет 1.1.X. Ну во-первых, ветка > позиционируется как девелопмент, > соответственно, использовать на > продакшине можно только в крайнем > случае. Отличие stable состоит в первую очередь в том, что её, по возможности, не ломают, т.е. обновления с версии на версию не должны приносить сюрпризов. В development нужно быть несколько осторожнее с обновлениями (желательно читать changelog). По стабильности - 1.1.10 сейчас лучше, чем 1.0.10. > Во-вторых, упомянутый вами > вопрос с долгими запросами. У меня > могут быть тяжелые запросы к базе, надо > подумать как изменение в схеме > балансинга может на них повлять - судя > по всему тем, что "живые" бэкенды будут > нагружены больше чем раньше. Если вас это пугает - то зачем вы просите сделать merge этого изменения в stable? :) На самом деле там всё не очень страшно. Алгоритм такой: упавший бекенд не будет признан снова работающим, пока не отработает успешно хотя бы один запрос, на него отправленный. Запросы на него будут отправляться 1 раз в fail_timeout. Если запросы долгие (много длиннее fail_timeout, т.е. не просто "тяжёлые запросы к базе", а какой-нибудь streaming или long polling) это, потенциально, может привести к тому, что бекенд (после смерти и оживания обратно) некоторое время будет продолжать считаться мёртвым (пока хотя бы один запрос не завершится, или клиент его не закроет). Нагрузка, соответственно, будет идти большей частью на другие бекенды. Есть, впрочем, мнение, что для streaming/long polling подобное поведение тоже вполне разумно, и максимум что в подобных ситуациях следует сделать - это уменьшить fail_timeout. > 3rd балансировщиками не пользуюсь. > > Я бы сделал изменение схемы > балансировки в 1.0.x опциональным и > выключенным по дефолту, если это > возможно. Нет. > Иначе судя по всему, в моем > случае, мне придется ждать пока ветка > 1.1.X не будет переведена в stable. Up to you. Maxim Dounin From postmaster на softsearch.ru Fri Dec 2 10:21:48 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 2 Dec 2011 14:21:48 +0400 Subject: =?UTF-8?Q?NXWEB_=D0=B8_nginx?= Message-ID: <817357842.20111202142148@softsearch.ru> Здравствуйте. Наткнулся на новый вебсервер: https://bitbucket.org/yarosla/nxweb/wiki/Home Автор, судя по имени, русский: Yaroslav yarosla на gmail.com Там в ссылке есть тест производительности, где приводятся цифры по кроме всего прочего и по nginx-у . Выглядят они почему-то значительно хуже, чем цифры по другим веб-серверам, особенно при работе с keep-alive запросами. А 10000 конкурентных запросов nginx в тестах не смог переварить. Подозреваю, что дело в неправильной настройке nginx-а. Есть автор NXWEB в этой рассылке? Можно увидеть конфиг nginx-а, используемый при тестах производительности? -- С уважением, Михаил mailto:postmaster на softsearch.ru From ne на vbart.ru Fri Dec 2 10:26:41 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 2 Dec 2011 14:26:41 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <817357842.20111202142148@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> Message-ID: <201112021426.42093.ne@vbart.ru> On Friday 02 December 2011 14:21:48 Михаил Монашёв wrote: > Здравствуйте. > > Наткнулся на новый вебсервер: https://bitbucket.org/yarosla/nxweb/wiki/Home > Автор, судя по имени, русский: Yaroslav yarosla на gmail.com > > Там в ссылке есть тест производительности, где приводятся цифры по > кроме всего прочего и по nginx-у . Выглядят они почему-то значительно > хуже, чем цифры по другим веб-серверам, особенно при работе с > keep-alive запросами. А 10000 конкурентных запросов nginx в тестах не > смог переварить. Подозреваю, что дело в неправильной настройке > nginx-а. > > Есть автор NXWEB в этой рассылке? Можно увидеть конфиг nginx-а, > используемый при тестах производительности? Там ниже и написано: nginx: using default setup as installed from ubuntu 11.10 repo (v.1.0.5); in "hello" tests request /.htaccess file, which gives an error [hopefully] without invlving filesystem; no aio/directio/sendfile optimizations turned on Причем, в стандартном конфиге worker_processes 1;, а тестировалось наверняка на многоядерной системе. -- Валентин Бартенев From igor на sysoev.ru Fri Dec 2 10:29:30 2011 From: igor на sysoev.ru (Igor Sysoev) Date: Fri, 2 Dec 2011 14:29:30 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <201112021426.42093.ne@vbart.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> Message-ID: <20111202102930.GB16939@nginx.com> On Fri, Dec 02, 2011 at 02:26:41PM +0400, Валентин Бартенев wrote: > On Friday 02 December 2011 14:21:48 Михаил Монашёв wrote: > > Здравствуйте. > > > > Наткнулся на новый вебсервер: https://bitbucket.org/yarosla/nxweb/wiki/Home > > Автор, судя по имени, русский: Yaroslav yarosla на gmail.com > > > > Там в ссылке есть тест производительности, где приводятся цифры по > > кроме всего прочего и по nginx-у . Выглядят они почему-то значительно > > хуже, чем цифры по другим веб-серверам, особенно при работе с > > keep-alive запросами. А 10000 конкурентных запросов nginx в тестах не > > смог переварить. Подозреваю, что дело в неправильной настройке > > nginx-а. > > > > Есть автор NXWEB в этой рассылке? Можно увидеть конфиг nginx-а, > > используемый при тестах производительности? > > Там ниже и написано: nginx: using default setup as installed from ubuntu 11.10 > repo (v.1.0.5); in "hello" tests request /.htaccess file, which gives an error > [hopefully] without invlving filesystem; no aio/directio/sendfile optimizations > turned on > > Причем, в стандартном конфиге worker_processes 1;, а тестировалось наверняка на > многоядерной системе. "Hello, world!" nginx умеет отдавать без /.htaccess: return 200 "

Hello, world!

"; -- Игорь Сысоев http://sysoev.ru From gmm на csdoc.com Fri Dec 2 10:53:31 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 02 Dec 2011 12:53:31 +0200 Subject: php-fpm upstream pool In-Reply-To: <20111202100736.GC67687@mdounin.ru> References: <20111201171227.GZ67687@mdounin.ru> <96a56f6dfbd266da481cb19b2d2b1991.NginxMailingListRussian@forum.nginx.org> <20111202100736.GC67687@mdounin.ru> Message-ID: <4ED8AE2B.4060203@csdoc.com> On 02.12.2011 12:07, Maxim Dounin wrote: > Алгоритм такой: упавший > бекенд не будет признан снова работающим, пока не отработает > успешно хотя бы один запрос, на него отправленный. Запросы на > него будут отправляться 1 раз в fail_timeout. > > Если запросы долгие (много длиннее fail_timeout, т.е. не просто > "тяжёлые запросы к базе", а какой-нибудь streaming или long > polling) это, потенциально, может привести к тому, что бекенд > (после смерти и оживания обратно) некоторое время будет продолжать > считаться мёртвым (пока хотя бы один запрос не завершится, или > клиент его не закроет). Нагрузка, соответственно, будет идти > большей частью на другие бекенды. > > Есть, впрочем, мнение, что для streaming/long polling подобное > поведение тоже вполне разумно, и максимум что в подобных ситуациях > следует сделать - это уменьшить fail_timeout. а почему нельзя делать health checks не тратя на это запросы клиентов, например, таким способом, как это сделано в haproxy. и если эта light проверка жив ли бекенд завершится не успешно - то и нет смысла туда отправлять запрос пользователя и устраивать ему denial of service ? -- Best regards, Gena From yarosla на gmail.com Fri Dec 2 10:56:42 2011 From: yarosla на gmail.com (Yaroslav) Date: Fri, 2 Dec 2011 14:56:42 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <817357842.20111202142148@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> Message-ID: Здравствуйте, Михаил! Я - автор NXWEB. Вполне допускаю, что конфиг неверный. Я, собственно, так и написал, что настройки не производились. Собственно, nginx приведен в таблице лишь как отправная точка. Сравниваемые сервера находятся совсем в другой весовой категории - это скорее микро-обработчики http-запросов для создания веб-приложений на языке C, в то время как nginx - полноценный сервер с широким функционалом. Микро-сервера оказываются быстрее nginx-а во многих сравнениях. Буду рад скорректировать тесты, если подскажете как. Вот текущий конфиг: worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type text/html; userid on; userid_name uid; log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" "$uri" "$args" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$uid_got" "$uid_set"'; access_log /var/log/nginx/access.log main; sendfile on; keepalive_timeout 65; log_subrequest on; ## Proxy options # тут у меня настройки прокси к томкету server { listen 80; server_name ****; charset utf-8; location / { root /www/****/www; index index.htm; ssi on; try_files $uri $uri/ @tomcat; error_page 404 = @tomcat; } location @tomcat { ... } location ~ /\.ht { deny all; } } # HTTPS server # server { listen 443; ssl on; # тут настройки SSL } } Кстати, я похоже наврал, что sendfile не включен. Он оказывается включен. Ярослав 2011/12/2 Михаил Монашёв > Здравствуйте. > > Наткнулся на новый вебсервер: > https://bitbucket.org/yarosla/nxweb/wiki/Home > Автор, судя по имени, русский: Yaroslav yarosla на gmail.com > > Там в ссылке есть тест производительности, где приводятся цифры по > кроме всего прочего и по nginx-у . Выглядят они почему-то значительно > хуже, чем цифры по другим веб-серверам, особенно при работе с > keep-alive запросами. А 10000 конкурентных запросов nginx в тестах не > смог переварить. Подозреваю, что дело в неправильной настройке > nginx-а. > > Есть автор NXWEB в этой рассылке? Можно увидеть конфиг nginx-а, > используемый при тестах производительности? > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Fri Dec 2 12:23:00 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 2 Dec 2011 16:23:00 +0400 Subject: =?UTF-8?B?UmVbMl06IE5YV0VCINC4IG5naW54?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> Message-ID: <428027705.20111202162300@softsearch.ru> Здравствуйте, Yaroslav. > Я - автор NXWEB. Вполне допускаю, что конфиг неверный. Я, > собственно, так и написал, что настройки не производились. > Собственно, nginx приведен в таблице лишь как отправная точка. > Сравниваемые сервера находятся совсем в другой весовой категории - > это скорее микро-обработчики http-запросов для создания > веб-приложений на языке C, в то время как nginx - полноценный сервер > с широким функционалом. Микро-сервера оказываются быстрее nginx-а во > многих сравнениях. > Буду рад скорректировать тесты, если подскажете как. А какая операционка на сервере, и сколько ядер в нём? У Вас тестах видна значительная деградация при увеличении конкурентности запросов. Почти в 2 раза отличается для 1000 и 10000 запросов. ИМХО, nginx не должен также деградировать. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Fri Dec 2 12:43:13 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 2 Dec 2011 16:43:13 +0400 Subject: =?UTF-8?B?UmVbMl06IE5YV0VCINC4IG5naW54?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> Message-ID: <1953056624.20111202164313@softsearch.ru> Здравствуйте, Yaroslav. Попробуйте вот такой конфиг тестов по отдаче простой строчки. Он без тюнинга под Вашу операционку, но возможно подойдёт: timer_resolution 100ms; worker_processes 4; error_log /opt/log/nginx/error.log; pid /var/run/nginx.pid; events { # use epoll; worker_connections 16384; } http { access_log off; sendfile on; tcp_nopush on; # aio sendfile; # read_ahead 256k; tcp_nodelay on; send_lowat 12000; postpone_output 1460; keepalive_timeout 75 60; reset_timedout_connection on; types { text/html html; } default_type text/html; server { listen 1.2.3.4:80 default accept_filter=httpready rcvbuf=4096 sndbuf=131072 backlog=4096; server_name site.ru; return 200 "

Hello, world!

"; } } Подкорректируйте, если что-то неверно. -- С уважением, Михаил mailto:postmaster на softsearch.ru From hell-for-yahoo на umail.ru Fri Dec 2 13:37:43 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Fri, 2 Dec 2011 17:37:43 +0400 Subject: NXWEB и nginx In-Reply-To: References: <817357842.20111202142148@softsearch.ru> Message-ID: <506326677.20111202173743@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Yaroslav! Y> Я - автор NXWEB. Вполне допускаю, что конфиг неверный. Я, собственно, так и Y> написал, что настройки не производились. Однако вы загрузили сервер объёмом запросов, для которых необходима предварительная настройка. Конфигурация по умолчанию предназначена "для широкого круга пользователей", что, обычно, означает менее-чем-оптимальную настройку в каждом конкретном случае. Y> Собственно, nginx приведен в таблице лишь как отправная точка. Сравниваемые Y> сервера находятся совсем в другой весовой категории - это скорее Y> микро-обработчики http-запросов для создания веб-приложений на языке C, в Y> то время как nginx - полноценный сервер с широким функционалом. Y> Микро-сервера оказываются быстрее nginx-а во многих сравнениях. Я бы не стал так утверждать, не проведя предварительную настройку для приведения програм в относительно равные условия сравнения. P.S. И, пожалуйста, постарайтесь, по возможности, не топ-постить. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) пятница, 02.12.2011, <17:32> From hell-for-yahoo на umail.ru Fri Dec 2 13:40:19 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Fri, 2 Dec 2011 17:40:19 +0400 Subject: php-fpm upstream pool In-Reply-To: <4ED8AE2B.4060203@csdoc.com> References: <20111201171227.GZ67687@mdounin.ru> <96a56f6dfbd266da481cb19b2d2b1991.NginxMailingListRussian@forum.nginx.org> <20111202100736.GC67687@mdounin.ru> <4ED8AE2B.4060203@csdoc.com> Message-ID: <12188499.20111202174019@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Gena Makhomed! GM> отправлять запрос пользователя и устраивать ему denial of service ? На сколько я понимаю алгоритм работы с бэкэндами, DoS для пользователя случится, только если таймаут соединения на фронтэнде выпадет раньше, чем разрешится статус проверяемого бэкэнда. Что, в общем случае, маловероятно. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) пятница, 02.12.2011, <17:38> From gmm на csdoc.com Fri Dec 2 15:53:20 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 02 Dec 2011 17:53:20 +0200 Subject: php-fpm upstream pool In-Reply-To: <12188499.20111202174019@mtu-net.ru> References: <20111201171227.GZ67687@mdounin.ru> <96a56f6dfbd266da481cb19b2d2b1991.NginxMailingListRussian@forum.nginx.org> <20111202100736.GC67687@mdounin.ru> <4ED8AE2B.4060203@csdoc.com> <12188499.20111202174019@mtu-net.ru> Message-ID: <4ED8F470.7000802@csdoc.com> On 02.12.2011 15:40, Andrey Repin wrote: > GM> отправлять запрос пользователя и устраивать ему denial of service ? > На сколько я понимаю алгоритм работы с бэкэндами, DoS для пользователя > случится, только если таймаут соединения на фронтэнде выпадет раньше, чем > разрешится статус проверяемого бэкэнда. > Что, в общем случае, маловероятно. даже если это формально и не будет DoS, то в любом случае это будет ухудшение QoS. чего можно легко избежать, проверяя статус backend`а запросами не от пользователей, а от самого nginx`а. и если health check показал, что backend не работает, тогда нет смысла туда посылать запрос от пользователя. -- Best regards, Gena From ne на vbart.ru Fri Dec 2 16:02:48 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 2 Dec 2011 20:02:48 +0400 Subject: php-fpm upstream pool In-Reply-To: <4ED8F470.7000802@csdoc.com> References: <20111201171227.GZ67687@mdounin.ru> <12188499.20111202174019@mtu-net.ru> <4ED8F470.7000802@csdoc.com> Message-ID: <201112022002.48984.ne@vbart.ru> On Friday 02 December 2011 19:53:20 Gena Makhomed wrote: > даже если это формально и не будет DoS, > то в любом случае это будет ухудшение QoS. > > чего можно легко избежать, проверяя статус backend`а > запросами не от пользователей, а от самого nginx`а. > > и если health check показал, что backend не работает, > тогда нет смысла туда посылать запрос от пользователя. Вот идет у нас на фронтэнд, скажем, 5000 rps. И раскидывается это по 5-ти бэкендам. Получается в среднем 1000 rps на бекэнд. Итого, интервал между запросами ~ 1 миллисекунда. Каким же образом, некий "health check" узнает о том, что бэкенд не работает, раньше, чем это станет известно от одного из запросов? health check-ать с интервалом 0.1 мс? 10 000 раз в секунду? -- Валентин Бартенев From gmm на csdoc.com Fri Dec 2 16:10:58 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 02 Dec 2011 18:10:58 +0200 Subject: php-fpm upstream pool In-Reply-To: <201112022002.48984.ne@vbart.ru> References: <20111201171227.GZ67687@mdounin.ru> <12188499.20111202174019@mtu-net.ru> <4ED8F470.7000802@csdoc.com> <201112022002.48984.ne@vbart.ru> Message-ID: <4ED8F892.6020801@csdoc.com> On 02.12.2011 18:02, Валентин Бартенев wrote: >> даже если это формально и не будет DoS, >> то в любом случае это будет ухудшение QoS. >> >> чего можно легко избежать, проверяя статус backend`а >> запросами не от пользователей, а от самого nginx`а. >> >> и если health check показал, что backend не работает, >> тогда нет смысла туда посылать запрос от пользователя. > Вот идет у нас на фронтэнд, скажем, 5000 rps. И раскидывается > это по 5-ти бэкендам. Получается в среднем 1000 rps на бекэнд. > > Итого, интервал между запросами ~ 1 миллисекунда. > > Каким же образом, некий "health check" узнает о том, что бэкенд > не работает, раньше, чем это станет известно от одного из запросов? > > health check-ать с интервалом 0.1 мс? 10 000 раз в секунду? ок, теперь я понял почему этой feature нет в nginx. спасибо. но почему/зачем тогда такую feature реализовали в haproxy, и в различных других аппаратных и программных балансировщиках? они ведь тоже расчитаны на высокую нагрузку и большое число запросов. -- Best regards, Gena From zzz на zzz.org.ua Fri Dec 2 16:11:27 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Fri, 2 Dec 2011 18:11:27 +0200 Subject: php-fpm upstream pool In-Reply-To: <201112022002.48984.ne@vbart.ru> References: <20111201171227.GZ67687@mdounin.ru> <12188499.20111202174019@mtu-net.ru> <4ED8F470.7000802@csdoc.com> <201112022002.48984.ne@vbart.ru> Message-ID: On Fri, Dec 2, 2011 at 6:02 PM, Валентин Бартенев wrote: > Каким же образом, некий "health check" узнает о том, что бэкенд > не работает, раньше, чем это станет известно от одного из запросов? А зачем? Health-check нужен на подъем, чтобы не слать запросы на неработающий бэкенд вообще. И реализовать достаточно просто. From gmm на csdoc.com Fri Dec 2 16:14:32 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 02 Dec 2011 18:14:32 +0200 Subject: php-fpm upstream pool In-Reply-To: References: <20111201171227.GZ67687@mdounin.ru> <12188499.20111202174019@mtu-net.ru> <4ED8F470.7000802@csdoc.com> <201112022002.48984.ne@vbart.ru> Message-ID: <4ED8F968.9000601@csdoc.com> On 02.12.2011 18:11, Alexandr Gomoliako wrote: >> Каким же образом, некий "health check" узнает о том, что бэкенд >> не работает, раньше, чем это станет известно от одного из запросов? > А зачем? Health-check нужен на подъем, чтобы не слать запросы > на неработающий бэкенд вообще. И реализовать достаточно просто. кстати, да. и узнать о том, что неработающий backend начал работать с помощью Health-check можно будет гораздо быстрее, чем сейчас - после большого таймаута и с помощью попытки отправить туда запрос от клиента. -- Best regards, Gena From ne на vbart.ru Fri Dec 2 16:17:26 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 2 Dec 2011 20:17:26 +0400 Subject: php-fpm upstream pool In-Reply-To: References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> Message-ID: <201112022017.26541.ne@vbart.ru> On Friday 02 December 2011 20:11:27 Alexandr Gomoliako wrote: > On Fri, Dec 2, 2011 at 6:02 PM, Валентин Бартенев wrote: > > Каким же образом, некий "health check" узнает о том, что бэкенд > > не работает, раньше, чем это станет известно от одного из запросов? > > А зачем? Health-check нужен на подъем, чтобы не слать запросы > на неработающий бэкенд вообще. И реализовать достаточно просто. На подъем это другое дело. С этим я не спорю. У Геннадия было: "и если health check показал, что backend не работает, тогда нет смысла туда посылать запрос от пользователя". -- Валентин Бартенев From gmm на csdoc.com Fri Dec 2 16:45:24 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 02 Dec 2011 18:45:24 +0200 Subject: php-fpm upstream pool In-Reply-To: <201112022017.26541.ne@vbart.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> Message-ID: <4ED900A4.2070103@csdoc.com> On 02.12.2011 18:17, Валентин Бартенев wrote: >> А зачем? Health-check нужен на подъем, чтобы не слать запросы >> на неработающий бэкенд вообще. И реализовать достаточно просто. > На подъем это другое дело. С этим я не спорю. так я об этом и спрашивал. именно что на подъем, после того как backend помечался как неработающий. fail_timeout == 10 секунд (что слишком много, если backend лежит можно делать проверку через healtp check хоть раз в секунду) и при этом не будет уходить "налево" запрос от пользователя, если мы не знаем работает сейчас backend или нет, и в прошлый раз - он точно был не рабочим. вероятность того, что он сразу после этого будет уже рабочий - достаточно невысокая. в результате: и повышение QoS для пользователей и более быстрое восстановление сервера после сбоя. если он уже поднялся - не будет простаивать 5-10 секунд, а буквально через секунду включится в работу. > У Геннадия было: "и если health check показал, что backend не работает, > тогда нет смысла туда посылать запрос от пользователя". у Максима было: "Запросы на него будут отправляться 1 раз в fail_timeout." On 02.12.2011 12:07, Maxim Dounin wrote: > Алгоритм такой: упавший > бекенд не будет признан снова работающим, пока не отработает > успешно хотя бы один запрос, на него отправленный. Запросы на > него будут отправляться 1 раз в fail_timeout. > > Если запросы долгие (много длиннее fail_timeout, т.е. не просто > "тяжёлые запросы к базе", а какой-нибудь streaming или long > polling) это, потенциально, может привести к тому, что бекенд > (после смерти и оживания обратно) некоторое время будет продолжать > считаться мёртвым (пока хотя бы один запрос не завершится, или > клиент его не закроет). Нагрузка, соответственно, будет идти > большей частью на другие бекенды. > > Есть, впрочем, мнение, что для streaming/long polling подобное > поведение тоже вполне разумно, и максимум что в подобных ситуациях > следует сделать - это уменьшить fail_timeout. -- Best regards, Gena From mdounin на mdounin.ru Fri Dec 2 17:51:28 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 2 Dec 2011 21:51:28 +0400 Subject: php-fpm upstream pool In-Reply-To: <4ED900A4.2070103@csdoc.com> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> Message-ID: <20111202175128.GI67687@mdounin.ru> Hello! On Fri, Dec 02, 2011 at 06:45:24PM +0200, Gena Makhomed wrote: > On 02.12.2011 18:17, Валентин Бартенев wrote: > > >>А зачем? Health-check нужен на подъем, чтобы не слать запросы > >>на неработающий бэкенд вообще. И реализовать достаточно просто. > > >На подъем это другое дело. С этим я не спорю. > > так я об этом и спрашивал. именно что на подъем, после того > как backend помечался как неработающий. fail_timeout == 10 секунд > (что слишком много, если backend лежит можно делать проверку через > healtp check хоть раз в секунду) и при этом не будет уходить "налево" > запрос от пользователя, если мы не знаем работает сейчас backend > или нет, и в прошлый раз - он точно был не рабочим. вероятность того, > что он сразу после этого будет уже рабочий - достаточно невысокая. Health check'и не отменяют всей той алгоритмики, которая есть сейчас. Ибо health check может быть успешным, а реальный запрос - нет. > в результате: и повышение QoS для пользователей и более быстрое > восстановление сервера после сбоя. если он уже поднялся - не будет > простаивать 5-10 секунд, а буквально через секунду включится в работу. Более быстрого восстановления - не будет, см. выше. Остаётся, соответственно, небольшое повышение QoS в случае очень малого трафика (health check успевает раньше) или при сбое (можно сэкономить единицы реальных запросов, т.к. не нужно посылать на бекенд реальные запросы, пока health check'и продолжают fail'иться). Единственное интересное место, которое мне видится - это делать другие (меньшие) таймауты для health check'ов. Тогда можно будет, теоретически, быстрее определять умершие бекенды по health check'ам, чем по реальным запросам, и сохранять какое-то значимое количество реальных запросов. Maxim Dounin From zzz на zzz.org.ua Fri Dec 2 18:12:33 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Fri, 2 Dec 2011 20:12:33 +0200 Subject: php-fpm upstream pool In-Reply-To: <20111202175128.GI67687@mdounin.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> Message-ID: On Fri, Dec 2, 2011 at 7:51 PM, Maxim Dounin wrote: > или при сбое (можно сэкономить единицы реальных запросов, т.к. > не нужно посылать на бекенд реальные запросы Если это сбой на пол часа, то может и единицы. А если на пару дней, то уже не единицы. А посетителям все равно, они терпеть не будут. From zzz на zzz.org.ua Fri Dec 2 18:14:21 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Fri, 2 Dec 2011 20:14:21 +0200 Subject: php-fpm upstream pool In-Reply-To: References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> Message-ID: On Fri, Dec 2, 2011 at 8:12 PM, Alexandr Gomoliako wrote: > Если это сбой на пол часа, то может и единицы. А если на пару дней, > то уже не единицы. О, еще можно просто увеличивать время fail_timeout по какой-то формуле. Тоже решит проблему и еще проще. From alexander.moskalenko на gmail.com Fri Dec 2 18:15:48 2011 From: alexander.moskalenko на gmail.com (Alexander Moskalenko) Date: Fri, 2 Dec 2011 20:15:48 +0200 Subject: alias issue again In-Reply-To: <4ED7AB5F.4030305@csdoc.com> References: <4ED7795B.2040309@csdoc.com> <4ED7AB5F.4030305@csdoc.com> Message-ID: - location ~ \.php$ { + location ~ "\/pma\/(?P\.php)$ { - rewrite ^/pma/(.+)$ /phpMyAdmin/$1 break; - fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin$ fastcgi_script_name; + fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$script_name; -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.moskalenko на gmail.com Fri Dec 2 18:31:56 2011 From: alexander.moskalenko на gmail.com (Alexander Moskalenko) Date: Fri, 2 Dec 2011 20:31:56 +0200 Subject: alias issue again In-Reply-To: References: <4ED7795B.2040309@csdoc.com> <4ED7AB5F.4030305@csdoc.com> Message-ID: - location ~ "\/pma\/(?P\.php)$ { + location ~ "\/pma\/(?P.+\.php)$ { On Fri, Dec 2, 2011 at 8:15 PM, Alexander Moskalenko < alexander.moskalenko на gmail.com> wrote: > - location ~ \.php$ { > + location ~ "\/pma\/(?P\.php)$ { > - rewrite ^/pma/(.+)$ /phpMyAdmin/$1 break; > - fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin$ > fastcgi_script_name; > + fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$script_name; > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm на csdoc.com Fri Dec 2 18:51:47 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 02 Dec 2011 20:51:47 +0200 Subject: php-fpm upstream pool In-Reply-To: <20111202175128.GI67687@mdounin.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> Message-ID: <4ED91E43.3020907@csdoc.com> On 02.12.2011 19:51, Maxim Dounin wrote: >>>> А зачем? Health-check нужен на подъем, чтобы не слать запросы >>>> на неработающий бэкенд вообще. И реализовать достаточно просто. >>> На подъем это другое дело. С этим я не спорю. >> так я об этом и спрашивал. именно что на подъем, после того >> как backend помечался как неработающий. fail_timeout == 10 секунд >> (что слишком много, если backend лежит можно делать проверку через >> healtp check хоть раз в секунду) и при этом не будет уходить "налево" >> запрос от пользователя, если мы не знаем работает сейчас backend >> или нет, и в прошлый раз - он точно был не рабочим. вероятность того, >> что он сразу после этого будет уже рабочий - достаточно невысокая. > Health check'и не отменяют всей той алгоритмики, которая есть > сейчас. Ибо health check может быть успешным, а реальный запрос - > нет. что у нас есть: 1. если backend не смог ответить на health check, то он с вероятностью 99.999% не сможет ответить на реальный запрос. 2. если backend смог ответить на health check, то скорее всего он сможет ответить и на реальный запрос. (верятность этого 99%) т.е. health check помогает уменьшить количество неопределенности сможет какой-то backend после сбоя обработать реальный запрос или нет. и ответ на вопрос "работает ли этот backend" можно будет получить раньше, чем через fail_timeout секунд ожидания. >> в результате: и повышение QoS для пользователей и более быстрое >> восстановление сервера после сбоя. если он уже поднялся - не будет >> простаивать 5-10 секунд, а буквально через секунду включится в работу. > Более быстрого восстановления - не будет, см. выше. например, если есть несколько backend`ов и все они помечены как не работающие, то лучше посылать запрос клиента на тот backend, который ответил на health check запрос - высока вероятность того, что он сможет ответить и на реальный запрос. а если не ответил на health check, то скорее всего такой backend не сможет ответить и на реальный запрос. а если есть "живые" backend`ы, то да, можно и не спешить особо, и ждать fail_timeout секунд, прежде чем слать туда реальный запрос. > Остаётся, соответственно, небольшое повышение QoS в случае очень > малого трафика (health check успевает раньше) или при сбое (можно > сэкономить единицы реальных запросов, т.к. не нужно посылать на > бекенд реальные запросы, пока health check'и продолжают > fail'иться). так это самое неприятное и есть - посылать реальные запросы клиентов с интервалом в fail_timeout секунд на backend, который не работает. proxy_connect_timeout по умолчанию 60 секунд, если поставить 1-2 секунды, то живые, но нагруженные backend`ы будут считаться не работающими и на остальные живые backend`ы в результате нагрузка еще больше вырастет и их все nginx начнет считать нерабочими на ближайшие fail_timeout секунд. а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15) то пользователь такую большую задержку заметит и может не дождавшись ответа от сервера уйти, посчитав его не работающим или перегруженным, хотя живые backend`ы были в наличии и ответ он мог получить быстрее. > Единственное интересное место, которое мне видится - это делать > другие (меньшие) таймауты для health check'ов. Тогда можно будет, > теоретически, быстрее определять умершие бекенды по health > check'ам, чем по реальным запросам, и сохранять какое-то значимое > количество реальных запросов. это если реальные запросы приходят реже, чем интервалы health check'ов. т.е. ответ backend`а на реальный запрос автоматически можно считать и успешным ответом на health check запрос. таким образом - при средней и высокой нагрузке на backend`ы - health check запросы на них вообще не будут отсылаться. они пойдут только если какой-то backend падал, или если на какой-то backend давно не было реальных запросов. -- Best regards, Gena From latypoff на yandex.ru Fri Dec 2 19:59:51 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Sat, 03 Dec 2011 02:59:51 +0700 Subject: php-fpm upstream pool In-Reply-To: <4ED91E43.3020907@csdoc.com> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> Message-ID: <656771322855991@web115.yandex.ru> 03.12.2011, 01:51, "Gena Makhomed" : > On 02.12.2011 19:51, Maxim Dounin wrote: > >>>>>  А зачем? Health-check нужен на подъем, чтобы не слать запросы >>>>>  на неработающий бэкенд вообще. И реализовать достаточно просто. >>>>  На подъем это другое дело. С этим я не спорю. >>>  так я об этом и спрашивал. именно что на подъем, после того >>>  как backend помечался как неработающий. fail_timeout == 10 секунд >>>  (что слишком много, если backend лежит можно делать проверку через >>>  healtp check хоть раз в секунду) и при этом не будет уходить "налево" >>>  запрос от пользователя, если мы не знаем работает сейчас backend >>>  или нет, и в прошлый раз - он точно был не рабочим. вероятность того, >>>  что он сразу после этого будет уже рабочий - достаточно невысокая. >>  Health check'и не отменяют всей той алгоритмики, которая есть >>  сейчас.  Ибо health check может быть успешным, а реальный запрос - >>  нет. > > что у нас есть: > > 1. если backend не смог ответить на health check, > то он с вероятностью 99.999% не сможет ответить на реальный запрос. > > 2. если backend смог ответить на health check, то скорее всего > он сможет ответить и на реальный запрос. (верятность этого 99%) > > т.е. health check помогает уменьшить количество неопределенности > сможет какой-то backend после сбоя обработать реальный запрос или нет. > > и ответ на вопрос "работает ли этот backend" можно будет > получить раньше, чем через fail_timeout секунд ожидания. пиши пачт > >>>  в результате: и повышение QoS для пользователей и более быстрое >>>  восстановление сервера после сбоя. если он уже поднялся - не будет >>>  простаивать 5-10 секунд, а буквально через секунду включится в работу. >>  Более быстрого восстановления - не будет, см. выше. > > например, если есть несколько backend`ов и все они помечены > как не работающие, то лучше посылать запрос клиента на тот backend, > который ответил на health check запрос - высока вероятность того, > что он сможет ответить и на реальный запрос. а если не ответил > на health check, то скорее всего такой backend не сможет > ответить и на реальный запрос. пиши пачт > > а если есть "живые" backend`ы, то да, можно и не спешить особо, > и ждать fail_timeout секунд, прежде чем слать туда реальный запрос. пиши пачт. > >>  Остаётся, соответственно, небольшое повышение QoS в случае очень >>  малого трафика (health check успевает раньше) или при сбое (можно >>  сэкономить единицы реальных запросов, т.к. не нужно посылать на >>  бекенд реальные запросы, пока health check'и продолжают >>  fail'иться). > > так это самое неприятное и есть - посылать реальные запросы клиентов > с интервалом в fail_timeout секунд на backend, который не работает. всем пофиг. никто из юзеров тебе не напишет, что его послали на неработающий бэкенд. да и фиг с ним, остальные 100000 тысяч довольны. Мы ведь говорим о высокой нагрузке? Nginx же! > > proxy_connect_timeout по умолчанию 60 секунд, если поставить > 1-2 секунды, то живые, но нагруженные backend`ы будут считаться > не работающими и на остальные живые backend`ы в результате > нагрузка еще больше вырастет и их все nginx начнет считать > нерабочими на ближайшие fail_timeout секунд. > > а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15) > то пользователь такую большую задержку заметит и может не дождавшись > ответа от сервера уйти, посчитав его не работающим или перегруженным, > хотя живые backend`ы были в наличии и ответ он мог получить быстрее. Да блин. Если ты (это собирательный образ) только и умеешь что писать на PHP, то сам себе злой буратино, тебе и апач подойдет, с твоими-то знаниями. Зачем тебе nginx, которые неведомым образом позаботится обо всех твоих пяти юзерах? (Четверых сразу да, а пятого погонять погонять по всем бекендам, включить AI, и все-таки отдать работающему бекенду). Если думаешь иначе - пиши пачт. > >>  Единственное интересное место, которое мне видится - это делать >>  другие (меньшие) таймауты для health check'ов.  Тогда можно будет, >>  теоретически, быстрее определять умершие бекенды по health >>  check'ам, чем по реальным запросам, и сохранять какое-то значимое >>  количество реальных запросов. > > это если реальные запросы приходят реже, чем интервалы health check'ов. > т.е. ответ backend`а на реальный запрос автоматически можно считать > и успешным ответом на health check запрос. таким образом - при средней > и высокой нагрузке на backend`ы - health check запросы на них вообще > не будут отсылаться. они пойдут только если какой-то backend падал, > или если на какой-то backend давно не было реальных запросов. > Ребята, куда вас вообще понесло? Лучше учите народ правильно писать бекенды, а не придумывайте зеленки для их кровоточащих ран. Nginx - open source. Доволен - скажи спасибо. Не доволен - пиши пачт. И Гена, завязывай троллить в каждом топике. Или тебе за это платят? Ну и - с пятницей! -- br, Denis F. Latypoff. From zzz на zzz.org.ua Fri Dec 2 20:12:49 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Fri, 2 Dec 2011 22:12:49 +0200 Subject: php-fpm upstream pool In-Reply-To: <656771322855991@web115.yandex.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> Message-ID: > пиши пачт > пиши пачт > пиши пачт. Все так и делают :) 3rd party уже намного больше, чем сам nginx Просто комьюнити версии у них нету и на гитхаб они не переходят, вот с contribution и трудности. From roman.vasilyev на yousendit.com Fri Dec 2 22:09:59 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 2 Dec 2011 14:09:59 -0800 Subject: =?UTF-8?Q?nginx_embedded_perl_=D0=B8_upload_module?= Message-ID: <4ED94CB7.2010902@yousendit.com> добрался до следующей проблемы: требуется перед обработчиком upload module дернуть perl handler с мелкими проверками загружаемого файла. sub handler { my $r = shift; return 402 if $r->request_method ne "POST"; ...... return 410 if $time > $exp; return 405 if $maxSize >0 and $size>$maxSize; } location /upload { perl my::handler; upload_pass blah; upload_store blah/blah; } не срабатывет, посмотрев в исходник вижу следующее: ngx_http_perl_module.c: ============================= static char * ngx_http_perl(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { ... clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); clcf->handler = ngx_http_perl_handler; ... } ngx_http_upload_module.c ============================= static char * /* {{{ ngx_http_upload_pass */ ngx_http_upload_pass(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { ... clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); clcf->handler = ngx_http_upload_handler; ... } похоже, что обработчик одного модуля перетирает другой. Понимаю что оба модуля лазят достаточно глубоко в потроха сервера, хотел спросить, есть ли выход из данной ситуации, кто бы что мог посоветовать? From gmm на csdoc.com Fri Dec 2 22:17:14 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Sat, 03 Dec 2011 00:17:14 +0200 Subject: php-fpm upstream pool In-Reply-To: <656771322855991@web115.yandex.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> Message-ID: <4ED94E6A.2020202@csdoc.com> On 02.12.2011 21:59, Denis F. Latypoff wrote: >>> Остаётся, соответственно, небольшое повышение QoS в случае очень >>> малого трафика (health check успевает раньше) или при сбое (можно >>> сэкономить единицы реальных запросов, т.к. не нужно посылать на >>> бекенд реальные запросы, пока health check'и продолжают >>> fail'иться). >> >> так это самое неприятное и есть - посылать реальные запросы клиентов >> с интервалом в fail_timeout секунд на backend, который не работает. > всем пофиг. не всем пофиг. например, в haproxy такая функциональность (health check) есть. >> proxy_connect_timeout по умолчанию 60 секунд, если поставить >> 1-2 секунды, то живые, но нагруженные backend`ы будут считаться >> не работающими и на остальные живые backend`ы в результате >> нагрузка еще больше вырастет и их все nginx начнет считать >> нерабочими на ближайшие fail_timeout секунд. >> а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15) >> то пользователь такую большую задержку заметит и может не дождавшись >> ответа от сервера уйти, посчитав его не работающим или перегруженным, >> хотя живые backend`ы были в наличии и ответ он мог получить быстрее. > Да блин. а если без истерики, в чем я по Вашему мнению неправ и какой есть лучший способ? если есть health check - реальный запрос на нерабочий backend не уйдет, потому что nginx еще раньше будет знать, что этот backend не работает. > Nginx - open source. Доволен - скажи спасибо. Не доволен - пиши пачт. > > И Гена, завязывай троллить в каждом топике. Или тебе за это платят? > > Ну и - с пятницей! ===================================================================== Термин ?тролль? очень субъективен. Некоторые читатели могут характеризовать сообщение как троллинг, в то время как другие могут расценить то же самое сообщение как законный вклад в обсуждение, даже если высказанное в нём мнение и спорное. Это понятие часто используется, чтобы дискредитировать оппонента или его сторонника аргументом, рассчитанным на предубеждения. ===================================================================== -- Best regards, Gena From zzz на zzz.org.ua Fri Dec 2 22:22:43 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Sat, 3 Dec 2011 00:22:43 +0200 Subject: =?UTF-8?Q?Re=3A_nginx_embedded_perl_=D0=B8_upload_module?= In-Reply-To: <4ED94CB7.2010902@yousendit.com> References: <4ED94CB7.2010902@yousendit.com> Message-ID: On Sat, Dec 3, 2011 at 12:09 AM, Roman Vasilyev wrote: >    clcf->handler = ngx_http_perl_handler; >    clcf->handler = ngx_http_upload_handler; > спросить, есть ли выход из данной ситуации, кто бы что мог посоветовать? У меня в форке есть perl_access, сработает на access фазе, т.е. до content фазы. https://github.com/zzzcpan/nginx-perl Официальный API там весь есть, отличия только два: - perl_handler вместо perl в конфиге; - вырезана MULTIPLICITY; Если есть желаение попробовать, покажи текущий handler. From valery+nginx на grid.net.ru Fri Dec 2 22:40:06 2011 From: valery+nginx на grid.net.ru (Valery Kholodkov) Date: Fri, 2 Dec 2011 23:40:06 +0100 Subject: =?UTF-8?Q?Re=3A_nginx_embedded_perl_=D0=B8_upload_module?= In-Reply-To: <4ED94CB7.2010902@yousendit.com> References: <4ED94CB7.2010902@yousendit.com> Message-ID: Делать internal redirect из перлового хэндлера. -- Best regards, Valery Kholodkov On 2 Dec 2011, at 23:09, Roman Vasilyev wrote: > добрался до следующей проблемы: > требуется перед обработчиком upload module дернуть perl handler с мелкими проверками загружаемого файла. > > sub handler { > my $r = shift; > return 402 if $r->request_method ne "POST"; > ...... > return 410 if $time > $exp; > return 405 if $maxSize >0 and $size>$maxSize; > } > > location /upload { > perl my::handler; > upload_pass blah; > upload_store blah/blah; > } > > не срабатывет, посмотрев в исходник вижу следующее: > > ngx_http_perl_module.c: > ============================= > static char * > ngx_http_perl(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) > { > ... > clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); > clcf->handler = ngx_http_perl_handler; > ... > } > > ngx_http_upload_module.c > ============================= > static char * /* {{{ ngx_http_upload_pass */ > ngx_http_upload_pass(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) > { > ... > clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); > clcf->handler = ngx_http_upload_handler; > ... > } > > похоже, что обработчик одного модуля перетирает другой. > Понимаю что оба модуля лазят достаточно глубоко в потроха сервера, хотел спросить, есть ли выход из данной ситуации, кто бы что мог посоветовать? From roman.vasilyev на yousendit.com Fri Dec 2 23:31:21 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 2 Dec 2011 15:31:21 -0800 Subject: =?UTF-8?Q?Re=3A_nginx_embedded_perl_=D0=B8_upload_module?= In-Reply-To: References: <4ED94CB7.2010902@yousendit.com> Message-ID: <4ED95FC9.5040300@yousendit.com> On 12/02/2011 02:40 PM, Valery Kholodkov wrote: > Делать internal redirect из перлового хэндлера. > > Супер, все заработало. From nginx-forum на nginx.us Sat Dec 3 09:59:07 2011 From: nginx-forum на nginx.us (darmen) Date: Sat, 03 Dec 2011 04:59:07 -0500 Subject: =?UTF-8?B?UmU6INCg0LXRgdCw0LnQtyDQsiDQvNC+0LTRg9C70LUgaW1hZ2UgZmlsdGVyINC/?= =?UTF-8?B?0L4g0L7QtNC90L7QvNGDINC40Lcg0YDQsNC30LzQtdGA0L7Qsg==?= In-Reply-To: <1aec1814be5e92ba79b47658a5428f16.NginxMailingListRussian@forum.nginx.org> References: <1aec1814be5e92ba79b47658a5428f16.NginxMailingListRussian@forum.nginx.org> Message-ID: <728eb98f1c47c8b1c4f2ed87ed430cd5.NginxMailingListRussian@forum.nginx.org> Спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,218625,219545#msg-219545 From rush.zlo на gmail.com Sat Dec 3 10:36:48 2011 From: rush.zlo на gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40LkgJ1J1c2gnINCd0LXQv9C+0LzQvdGP0YnQuNC5?=) Date: Sat, 3 Dec 2011 14:36:48 +0400 Subject: =?UTF-8?B?UmU6IFJlWzJdOiBOWFdFQiDDiSBuZ2lueA==?= In-Reply-To: <506326677.20111202173743@mtu-net.ru> References: <817357842.20111202142148@softsearch.ru> <506326677.20111202173743@mtu-net.ru> Message-ID: 2 декабря 2011 г. 17:37 пользователь Andrey Repin написал: > И, пожалуйста, постарайтесь, по возможности, не топ-постить. И топ-постнул за него. Как это вообще получается? -- Cogito ergo sum From postmaster на softsearch.ru Sat Dec 3 16:48:14 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 3 Dec 2011 20:48:14 +0400 Subject: =?UTF-8?B?UmVbMl06IE5YV0VCINC4IG5naW54?= In-Reply-To: <201112021426.42093.ne@vbart.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> Message-ID: <413264895.20111203204814@softsearch.ru> Здравствуйте, Валентин. >> Наткнулся на новый вебсервер: >> https://bitbucket.org/yarosla/nxweb/wiki/Home >> Автор, судя по имени, русский: Yaroslav yarosla на gmail.com >> >> Там в ссылке есть тест производительности, где приводятся цифры по >> кроме всего прочего и по nginx-у . Выглядят они почему-то >> значительно хуже, чем цифры по другим веб-серверам, особенно при >> работе с keep-alive запросами. А 10000 конкурентных запросов nginx >> в тестах не смог переварить. Подозреваю, что дело в неправильной >> настройке nginx-а. >> >> Есть автор NXWEB в этой рассылке? Можно увидеть конфиг nginx-а, >> используемый при тестах производительности? > Там ниже и написано: nginx: using default setup as installed from > ubuntu 11.10 repo (v.1.0.5); in "hello" tests request /.htaccess > file, which gives an error [hopefully] without invlving filesystem; > no aio/directio/sendfile optimizations turned on > Причем, в стандартном конфиге worker_processes 1;, а тестировалось > наверняка на многоядерной системе. Мне кажется, что тесты, в которых с одной стороны участвует софтина, которую её автор знает наизусть, знает её как её тюнить и оптимизировать, а с другой участвуют неизвестные тестеру программы, которые тюнить и оптимизировать и разбираться в которых не хочется, то это - фуфло, а не публичные тесты. Даже если внизу есть приписки мелким почерком, якобы снимающие с автора тестов ответственность за результат. И я прошу автора NXWEB по возможности провести другие тесты, где все вебсервера будут настроены под создаваемую нагрузку. -- С уважением, Михаил mailto:postmaster на softsearch.ru From zzz на zzz.org.ua Sat Dec 3 17:02:45 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Sat, 3 Dec 2011 19:02:45 +0200 Subject: =?UTF-8?B?UmU6IFJlWzJdOiBOWFdFQiDQuCBuZ2lueA==?= In-Reply-To: <413264895.20111203204814@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> Message-ID: On Sat, Dec 3, 2011 at 6:48 PM, Михаил Монашёв wrote: > Мне  кажется,  что тесты, в которых с одной стороны участвует софтина, > которую  её  автор  знает  наизусть,  знает  её  как  её  тюнить     и > оптимизировать,  а  с  другой участвуют неизвестные тестеру программы, > которые тюнить и оптимизировать и разбираться в которых не хочется, то > это  -  фуфло,  а  не  публичные  тесты. Даже если внизу есть приписки > мелким  почерком,  якобы  снимающие с автора тестов ответственность за > результат.  И  я  прошу  автора  NXWEB  по возможности провести другие > тесты, где все вебсервера будут настроены под создаваемую нагрузку. Почему фуфло? Довольно просто сделать сервер, который будет заметно быстрее в бэнчмарках, чем nginx, если в нем ничего нет. Но вэбсервер без ничего в общем-то никому и не нужен :) From postmaster на softsearch.ru Sat Dec 3 18:19:47 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 3 Dec 2011 22:19:47 +0400 Subject: =?UTF-8?B?UmVbNF06IE5YV0VCINC4IG5naW54?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> Message-ID: <1401296003.20111203221947@softsearch.ru> Здравствуйте, Alexandr. >> Мне  кажется,  что тесты, в которых с одной стороны участвует софтина, >> которую  её  автор  знает  наизусть,  знает  её  как  её  тюнить     и >> оптимизировать,  а  с  другой участвуют неизвестные тестеру программы, >> которые тюнить и оптимизировать и разбираться в которых не хочется, то >> это  -  фуфло,  а  не  публичные  тесты. Даже если внизу есть приписки >> мелким  почерком,  якобы  снимающие с автора тестов ответственность за >> результат.  И  я  прошу  автора  NXWEB  по возможности провести другие >> тесты, где все вебсервера будут настроены под создаваемую нагрузку. > Почему фуфло? Довольно просто сделать сервер, который будет заметно > быстрее в бэнчмарках, чем nginx, если в нем ничего нет. > Но вэбсервер без ничего в общем-то никому и не нужен :) Тесты - фуфло, а не вебсервер. Будет ли простой сервер заметно быстрее - это тоже вопрос. Ну может процентов на 10% и будет быстрее, но навряд ли более. Если Ярослав сможет провести новые тесты, то ещё посмотрим кто кого ;-) -- С уважением, Михаил mailto:postmaster на softsearch.ru From valery+nginxru на grid.net.ru Sun Dec 4 10:48:12 2011 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Sun, 4 Dec 2011 11:48:12 +0100 Subject: =?UTF-8?B?UmU6IFJlWzJdOiBOWFdFQiDQuCBuZ2lueA==?= In-Reply-To: <413264895.20111203204814@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> Message-ID: <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> Согласен, есть конфликт интересов -- тесты выполняет сторона заинтересованая в результатах. Нужно, чтобы кто-нибудь незаинтересованный в результатах провел тесты. -- Best regards, Valery Kholodkov On 3 Dec 2011, at 17:48, Михаил Монашёв wrote: > Здравствуйте, Валентин. > >>> Наткнулся на новый вебсервер: >>> https://bitbucket.org/yarosla/nxweb/wiki/Home >>> Автор, судя по имени, русский: Yaroslav yarosla на gmail.com >>> >>> Там в ссылке есть тест производительности, где приводятся цифры по >>> кроме всего прочего и по nginx-у . Выглядят они почему-то >>> значительно хуже, чем цифры по другим веб-серверам, особенно при >>> работе с keep-alive запросами. А 10000 конкурентных запросов nginx >>> в тестах не смог переварить. Подозреваю, что дело в неправильной >>> настройке nginx-а. >>> >>> Есть автор NXWEB в этой рассылке? Можно увидеть конфиг nginx-а, >>> используемый при тестах производительности? > >> Там ниже и написано: nginx: using default setup as installed from >> ubuntu 11.10 repo (v.1.0.5); in "hello" tests request /.htaccess >> file, which gives an error [hopefully] without invlving filesystem; >> no aio/directio/sendfile optimizations turned on > >> Причем, в стандартном конфиге worker_processes 1;, а тестировалось >> наверняка на многоядерной системе. > > Мне кажется, что тесты, в которых с одной стороны участвует софтина, > которую её автор знает наизусть, знает её как её тюнить и > оптимизировать, а с другой участвуют неизвестные тестеру программы, > которые тюнить и оптимизировать и разбираться в которых не хочется, то > это - фуфло, а не публичные тесты. Даже если внизу есть приписки > мелким почерком, якобы снимающие с автора тестов ответственность за > результат. И я прошу автора NXWEB по возможности провести другие > тесты, где все вебсервера будут настроены под создаваемую нагрузку. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на nginx.us Sun Dec 4 11:17:29 2011 From: nginx-forum на nginx.us (alex_ru) Date: Sun, 04 Dec 2011 06:17:29 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: Ничего у меня не вышло и более того, я не представляю что делать. Инструкцию я читаю, но судя по всему надо быть С-шником, что бы ее понять. По порядку: Microsoft Visual C compiler. Microsoft Visual Studio? 8 and 10 are known to work. - С не нашел вообще, скачал С++, выше сказали пойдет. MSYS - для чего это надо не понял, но установил, запустил msys.bat, открылось какое-то окно, его предназначение - загадка. Perl, if you want to build OpenSSL? and nginx with SSL support. For example ActivePerl or Strawberry Perl. - у меня стоит 1.1.6 stable release, я хочу собрать такой же (1.1.10 правда), но с 3 дополнительными модулями - мне это все надо? Subversion? client. Choose any from the list - тут проблем нет PCRE, zlib and OpenSSL libraries sources. - нужны сорцы или скомпилированное? Дальше интереснее: Start MSYS bash - открылось консольное окно, так и оставлять или в нем надо работать? Run configure script: auto/configure --with-cc=cl --builddir=objs --prefix= \ --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \ --http-log-path=logs/access.log --error-log-path=logs/error.log \ --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \ --http-proxy-temp-path=temp/proxy_temp \ --http-fastcgi-temp-path=temp/fastcgi_temp \ --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre-8.12 \ --with-zlib=objs/lib/zlib-1.2.5 --withopenssl=objs/lib/openssl-1.0.0e \ --with-select_module --with-http_ssl_module --with-ipv6 тут я вообще потерялся. какой скрипт? тот файл который лежит auto/configure, без расширения, чем его запустить? попробовал открыть в C++ студии - не вышло. Run make: nmake -f objs/Makefile где это запускать? Задал сразу все непонятные моменты. Я java-dev и не знаком с С вообще, буду благодарен за ответ, так как чувствую, что без помощи или С-шника мне не разобраться. И еще хотел одну штуку прокоментировать: Check out nginx sources from the svn.nginx.org repository. For example: svn co svn://svn.nginx.org/tags/release-1.1.6 СВН переехал на svn://svn.nginx.org/nginx Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219572#msg-219572 From ano на bestmx.ru Sun Dec 4 12:22:58 2011 From: ano на bestmx.ru (Andrey N. Oktyabrski) Date: Sun, 04 Dec 2011 15:22:58 +0300 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> Message-ID: <4EDB6622.2070003@bestmx.ru> On 04.12.11 13:48, Valery Kholodkov wrote: > Согласен, есть конфликт интересов -- тесты выполняет сторона > заинтересованая в результатах. Нужно, чтобы кто-нибудь > незаинтересованный в результатах провел тесты. Незаинтересованному в результатах не нужны никакие тесты :-) From nginx-forum на nginx.us Sun Dec 4 11:36:43 2011 From: nginx-forum на nginx.us (alex_ru) Date: Sun, 04 Dec 2011 06:36:43 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: <5c279792f0d7ed527c479de036573af8.NginxMailingListRussian@forum.nginx.org> Немного продвинулся вперед, но нашел еще одну опечатку в инструкции: --withopenssl=objs/lib/openssl-1.0.0e --with-openssl=objs/lib/openssl-1.0.0e пропущено тире запустить скрипт с горем пополам получилось, но вот nmake не выходит сделать: sh: nmake: command not found Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219574#msg-219574 From nginx-forum на nginx.us Sun Dec 4 12:16:41 2011 From: nginx-forum на nginx.us (Art) Date: Sun, 04 Dec 2011 07:16:41 -0500 Subject: Nginx+SSI+Memcached Message-ID: <843f41579d25595a8d88ba42bd1a5280.NginxMailingListRussian@forum.nginx.org> Всем доброго времени суток! Есть проект, на котором используется кэширование блоков HTML Возник вопрос, как написать ssi-инструкцию, чтобы nginx работал по следующему алгоритму: a). nginx запрашивает memcached по ключу, указанному в ssi-инструкции, если возвращается ответ, вставляет его на место инструкции, при этом проверяет, нет ли в ответе других ssi-инструкций. б) если в пункте а) - ошибка, запрашивает бэкенд по адресу, указанному в ssi-инструкции, при этом к адресу добавляются GET-параметры основного запроса. Ответ проверяется на наличие ssi-инструкций тоже, ответ выводится клиенту. Помогите, примерами, если можно. Пример SSI-инструкции и конфига nginx. Заранее спасибо за ответ. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219575,219575#msg-219575 From valery+nginxru на grid.net.ru Sun Dec 4 13:50:11 2011 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Sun, 4 Dec 2011 14:50:11 +0100 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <4EDB6622.2070003@bestmx.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <4EDB6622.2070003@bestmx.ru> Message-ID: <44243B3F-813F-4CDE-8E19-E1EA60FD2699@grid.net.ru> Но заинтересованные в тестах заинтересованы в незаинтересованном в результатах! -- Best regards, Valery Kholodkov On 4 Dec 2011, at 13:22, "Andrey N. Oktyabrski" wrote: > On 04.12.11 13:48, Valery Kholodkov wrote: >> Согласен, есть конфликт интересов -- тесты выполняет сторона >> заинтересованая в результатах. Нужно, чтобы кто-нибудь >> незаинтересованный в результатах провел тесты. > Незаинтересованному в результатах не нужны никакие тесты :-) > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From postmaster на softsearch.ru Sun Dec 4 13:53:43 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 4 Dec 2011 17:53:43 +0400 Subject: =?UTF-8?B?UmVbNF06IE5YV0VCINC4IG5naW54?= In-Reply-To: <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> Message-ID: <688241256.20111204175343@softsearch.ru> Здравствуйте, Valery. > Согласен, есть конфликт интересов -- тесты выполняет сторона > заинтересованая в результатах. Нужно, чтобы кто-нибудь > незаинтересованный в результатах провел тесты. Вот тоже тесты, в которых авторы своего веб-сервера побеждают nginx и лайти в разы: http://gwan.ch/benchmark . Тенденция однако. Там тест проводил независимый "специалист" с форума G-WAN: http://forum.gwan.com/index.php?p=/discussion/525/nginx1.0.6-vs-lighttpd1.4.29-vs-g-wan2.9.30-rpscpuram -- С уважением, Михаил mailto:postmaster на softsearch.ru From valery+nginxru на grid.net.ru Sun Dec 4 14:31:22 2011 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Sun, 4 Dec 2011 15:31:22 +0100 Subject: =?UTF-8?B?UmU6IFJlWzRdOiBOWFdFQiDQuCBuZ2lueA==?= In-Reply-To: <688241256.20111204175343@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <688241256.20111204175343@softsearch.ru> Message-ID: Вот этот тест как раз более-менее независимый. И GWAN там не по всем параметрам побеждает. В частности по потреблямой памяти. Неудивительно -- GWAN делает софтверную разблокировку системных вызовов, а значит ему как минимум приходится таскать копию стэка за каждым запросом. -- Best regards, Valery Kholodkov On 4 Dec 2011, at 14:53, Михаил Монашёв wrote: > Здравствуйте, Valery. > >> Согласен, есть конфликт интересов -- тесты выполняет сторона >> заинтересованая в результатах. Нужно, чтобы кто-нибудь >> незаинтересованный в результатах провел тесты. > > Вот тоже тесты, в которых авторы своего веб-сервера побеждают nginx и > лайти в разы: http://gwan.ch/benchmark . Тенденция однако. Там тест > проводил независимый "специалист" с форума G-WAN: > http://forum.gwan.com/index.php?p=/discussion/525/nginx1.0.6-vs-lighttpd1.4.29-vs-g-wan2.9.30-rpscpuram > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From latypoff на yandex.ru Sun Dec 4 14:41:14 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Sun, 04 Dec 2011 21:41:14 +0700 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> Message-ID: <8771323009674@web16.yandex.ru> 04.12.2011, 17:48, "Valery Kholodkov" : > Согласен, есть конфликт интересов -- тесты выполняет сторона заинтересованая в результатах. Нужно, чтобы кто-нибудь незаинтересованный в результатах провел тесты. libev знаю очень хорошо, там нет поддержки для edge triggered возвратов из ядра. В nginx, насколько я понимаю, по сути своя реализация libev, во всеми блекджеками и шахматами. Так что nxweb может слить там где скорость упрется в ведро. Ну и чую, что если nxweb обрастет инфраструктурой как у nginx, то там подавно сольет. IMHO сравнивать их лоб в лоб - нет смысла. > > -- > Best regards, > Valery Kholodkov > > On 3 Dec 2011, at 17:48, Михаил Монашёв wrote: > >> Здравствуйте, Валентин. >> >>>> Наткнулся на новый вебсервер: >>>> https://bitbucket.org/yarosla/nxweb/wiki/Home >>>> Автор, судя по имени, русский: Yaroslav yarosla на gmail.com >>>> >>>> Там  в ссылке есть тест производительности, где приводятся цифры по >>>> кроме   всего  прочего  и  по  nginx-у  .  Выглядят  они  почему-то >>>> значительно  хуже,  чем  цифры по другим веб-серверам, особенно при >>>> работе  с keep-alive запросами. А 10000 конкурентных запросов nginx >>>> в  тестах  не  смог переварить. Подозреваю, что дело в неправильной >>>> настройке nginx-а. >>>> >>>> Есть  автор  NXWEB  в  этой рассылке? Можно увидеть конфиг nginx-а, >>>> используемый при тестах производительности? >> >>> Там  ниже  и  написано: nginx: using default setup as installed from >>> ubuntu  11.10  repo  (v.1.0.5);  in "hello" tests request /.htaccess >>> file,  which gives an error [hopefully] without invlving filesystem; >>> no aio/directio/sendfile optimizations turned on >> >>> Причем,  в  стандартном конфиге worker_processes 1;, а тестировалось >>> наверняка на многоядерной системе. >> >> Мне  кажется,  что тесты, в которых с одной стороны участвует софтина, >> которую  её  автор  знает  наизусть,  знает  её  как  её  тюнить     и >> оптимизировать,  а  с  другой участвуют неизвестные тестеру программы, >> которые тюнить и оптимизировать и разбираться в которых не хочется, то >> это  -  фуфло,  а  не  публичные  тесты. Даже если внизу есть приписки >> мелким  почерком,  якобы  снимающие с автора тестов ответственность за >> результат.  И  я  прошу  автора  NXWEB  по возможности провести другие >> тесты, где все вебсервера будут настроены под создаваемую нагрузку. >> >> -- >> С уважением, >> Михаил                          mailto:postmaster на softsearch.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 -- br, Denis F. Latypoff. From postmaster на softsearch.ru Sun Dec 4 14:42:40 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 4 Dec 2011 18:42:40 +0400 Subject: =?UTF-8?B?UmVbNl06IE5YV0VCINC4IG5naW54?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <688241256.20111204175343@softsearch.ru> Message-ID: <89172852.20111204184240@softsearch.ru> Здравствуйте, Valery. > Вот этот тест как раз более-менее независимый. И GWAN там не по всем > параметрам побеждает. В частности по потреблямой памяти. > Неудивительно -- GWAN делает софтверную разблокировку системных > вызовов, а значит ему как минимум приходится таскать копию стэка за > каждым запросом. Более-менее. Только какой смысл в таком тесте, если его автор не совсем понимает, что значат настраиваемые им параметры в конфиге и видимо даже не подозревает, что, например, nginx можно собрать без gzip и других ненужных модулей? -- С уважением, Михаил mailto:postmaster на softsearch.ru From valery+nginxru на grid.net.ru Sun Dec 4 16:40:32 2011 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Sun, 4 Dec 2011 17:40:32 +0100 Subject: =?UTF-8?B?UmU6IFJlWzZdOiBOWFdFQiDQuCBuZ2lueA==?= In-Reply-To: <89172852.20111204184240@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <688241256.20111204175343@softsearch.ru> <89172852.20111204184240@softsearch.ru> Message-ID: <9B6DC7E2-C51C-4D8D-A56A-1108F490A647@grid.net.ru> В этом как раз и смысл -- сравниваются параметры инсталляции из коробки. 90% пользователей вряд ли будут что-то настраивать. -- Best regards, Valery Kholodkov On 4 Dec 2011, at 15:42, Михаил Монашёв wrote: > Здравствуйте, Valery. > >> Вот этот тест как раз более-менее независимый. И GWAN там не по всем >> параметрам побеждает. В частности по потреблямой памяти. >> Неудивительно -- GWAN делает софтверную разблокировку системных >> вызовов, а значит ему как минимум приходится таскать копию стэка за >> каждым запросом. > > Более-менее. Только какой смысл в таком тесте, если его автор не > совсем понимает, что значат настраиваемые им параметры в конфиге и > видимо даже не подозревает, что, например, nginx можно собрать без > gzip и других ненужных модулей? > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zzz на zzz.org.ua Sun Dec 4 16:46:34 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Sun, 4 Dec 2011 18:46:34 +0200 Subject: =?UTF-8?B?UmU6IFJlWzZdOiBOWFdFQiDQuCBuZ2lueA==?= In-Reply-To: <9B6DC7E2-C51C-4D8D-A56A-1108F490A647@grid.net.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <688241256.20111204175343@softsearch.ru> <89172852.20111204184240@softsearch.ru> <9B6DC7E2-C51C-4D8D-A56A-1108F490A647@grid.net.ru> Message-ID: On Sun, Dec 4, 2011 at 6:40 PM, Valery Kholodkov wrote: > В этом как раз и смысл -- сравниваются параметры инсталляции из коробки. 90% пользователей вряд ли будут что-то настраивать. Как раз с nginx'ом все совсем наоборот. Из коробки он ничего полезного не делает. Нужно под конкретную задачу настроить. From ano на bestmx.ru Sun Dec 4 18:52:14 2011 From: ano на bestmx.ru (Andrey N. Oktyabrski) Date: Sun, 04 Dec 2011 21:52:14 +0300 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <44243B3F-813F-4CDE-8E19-E1EA60FD2699@grid.net.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <4EDB6622.2070003@bestmx.ru> <44243B3F-813F-4CDE-8E19-E1EA60FD2699@grid.net.ru> Message-ID: <4EDBC15E.3090401@bestmx.ru> On 04.12.11 16:50, Valery Kholodkov wrote: > Но заинтересованные в тестах заинтересованы в незаинтересованном в результатах! Нет. Просто тестирование должно проводиться всеми заинтересованными сторонами по совместно разработанной методике. From nginx-forum на nginx.us Sun Dec 4 17:55:54 2011 From: nginx-forum на nginx.us (alex_ru) Date: Sun, 04 Dec 2011 12:55:54 -0500 Subject: =?UTF-8?B?UmU6INGB0LHQvtGA0LrQsCBjIHdpdGgtaHR0cCBpbWFnZSBmaWx0ZXIgbW9kdWxl?= In-Reply-To: References: Message-ID: <99ae0a21b4e53784090f1dad78057990.NginxMailingListRussian@forum.nginx.org> Всем привет, Хочу собрать nginx с модулем http_image_filter_module, но не могу нигде скачать libgd под винду. Попробовал скачал сорцы, но оно у меня не компилится. Может быть у кого-то завалялся архивчик с этой штукой? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,212832,219590#msg-219590 From postmaster на softsearch.ru Sun Dec 4 20:57:00 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 5 Dec 2011 00:57:00 +0400 Subject: =?UTF-8?B?UmVbOF06IE5YV0VCINC4IG5naW54?= In-Reply-To: <9B6DC7E2-C51C-4D8D-A56A-1108F490A647@grid.net.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <688241256.20111204175343@softsearch.ru> <89172852.20111204184240@softsearch.ru> <9B6DC7E2-C51C-4D8D-A56A-1108F490A647@grid.net.ru> Message-ID: <1744930467.20111205005700@softsearch.ru> Здравствуйте, Valery. > В этом как раз и смысл -- сравниваются параметры инсталляции из > коробки. 90% пользователей вряд ли будут что-то настраивать. 90% используют апач. Туда им и дорога. Сравните бенчмарки старые (из коробки) и новые: https://bitbucket.org/yarosla/nxweb/wiki/Benchmarks . Результаты заметно различаются. Если следовать Вашему подходу, то следует тогда уж в одном тесте замерять и параметры из коробки и с тюнингом под конретную задачу. Тогда тест будет реально полезен: из него будет видно, что надо оптимизировать конфиг. -- С уважением, Михаил mailto:postmaster на softsearch.ru From yarosla на gmail.com Sun Dec 4 21:19:40 2011 From: yarosla на gmail.com (Yaroslav) Date: Mon, 5 Dec 2011 01:19:40 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <1744930467.20111205005700@softsearch.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <688241256.20111204175343@softsearch.ru> <89172852.20111204184240@softsearch.ru> <9B6DC7E2-C51C-4D8D-A56A-1108F490A647@grid.net.ru> <1744930467.20111205005700@softsearch.ru> Message-ID: 2011/12/5 Михаил Монашёв > Здравствуйте, Valery. > > > В этом как раз и смысл -- сравниваются параметры инсталляции из > > коробки. 90% пользователей вряд ли будут что-то настраивать. > > 90% используют апач. Туда им и дорога. > > Сравните бенчмарки старые (из коробки) и новые: > https://bitbucket.org/yarosla/nxweb/wiki/Benchmarks . Результаты > заметно различаются. Если следовать Вашему подходу, то следует тогда > уж в одном тесте замерять и параметры из коробки и с тюнингом под > конретную задачу. Тогда тест будет реально полезен: из него будет > видно, что надо оптимизировать конфиг. > > Добрый вечер всем! Михаил, каким-то чудом обнаруживший мой проект в первый же день существования, и теперь заметил новые бенчмарки в первые же пять минут после их опубликования. :) Первым делом хочу извиниться перед nginx-сообществом. С первыми бенчмарками я действительно облажался. Главное, не уделил внимания любимому nginx, сравниваться с ним задачи не было, поэтому отнесся поверхностно. У меня была задача создать легковесную, но в то же время производительную платформу для вывода в интернет мини-приложений на C, так как имеющиеся меня не устроили (хотя, после тестирования новым инструментом и они оказались не так плохи). К тому же, повелся на пропаганду конкурентов nginx и посчитал, что раз в их тестах nginx не так быстр, то так и должно быть. В общем, исправляюсь. Хочу сразу сказать, что меня не удовлетворил ни httperf ни weighttp, поэтому программу для создания нагрузки и измерения производительности я написал свою. Как выяснилось, неудачи некоторых предыдущих прогонов при большом числе соединений были исключительно по вине программы тестирования. Знаю, что будете меня за это гнобить, ибо как лицо заинтересованное написал специально так, чтобы мой сервер выглядел получше. Но если гнобить, то гнобить предметно. Изучайте исходник ( https://bitbucket.org/yarosla/httpress/) и критикуйте по существу. В новых бенчмарках для nginx я использовал конфигурацию, присланную Михаилом. За что ему очередное спасибо. Спасибо за внимание! Ярослав Ставничий ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Sun Dec 4 21:59:50 2011 From: nginx-forum на nginx.us (alex_ru) Date: Sun, 04 Dec 2011 16:59:50 -0500 Subject: Nginx+SSI+Memcached In-Reply-To: <843f41579d25595a8d88ba42bd1a5280.NginxMailingListRussian@forum.nginx.org> References: <843f41579d25595a8d88ba42bd1a5280.NginxMailingListRussian@forum.nginx.org> Message-ID: <2a6db46fa79015ffe6e5e9d9b134d2a6.NginxMailingListRussian@forum.nginx.org> Я не спец, может быть вот это поможет http://highload.com.ua/index.php/2010/04/06/nginx-memcached-ssi-%D0%BA%D0%B5%D1%88%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86-%D0%B8-%D0%B1%D0%BB%D0%BE%D0%BA%D0%BE%D0%B2-partials/ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219575,219602#msg-219602 From sb на waeme.net Mon Dec 5 07:36:49 2011 From: sb на waeme.net (Sergey Budnevitch) Date: Mon, 5 Dec 2011 11:36:49 +0400 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: <5c279792f0d7ed527c479de036573af8.NginxMailingListRussian@forum.nginx.org> References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> <5c279792f0d7ed527c479de036573af8.NginxMailingListRussian@forum.nginx.org> Message-ID: On 04.12.2011, at 15:17, alex_ru wrote: > Subversion? client. Choose any from the list - тут проблем > нет > PCRE, zlib and OpenSSL libraries sources. - нужны сорцы или > скомпилированное? sources переводится как исходники. On 04.12.2011, at 15:36, alex_ru wrote: > Немного продвинулся вперед, но нашел > еще одну опечатку в инструкции: > --withopenssl=objs/lib/openssl-1.0.0e > --with-openssl=objs/lib/openssl-1.0.0e пропущено тире Спасибо, исправил. > > запустить скрипт с горем пополам > получилось, но вот nmake не выходит > сделать: > sh: nmake: command not found В той же инструкции чуть ранее написано: Ensure that paths to Perl, Subversion and MSYS bin directories are added to PATH environment variable before you start build. To set Visual C environment run vcvarsall.bat script from Visual C directory. Вы не запускали vcvarsall.bat, поэтому nmake не находится. From nginx-forum на nginx.us Mon Dec 5 09:08:49 2011 From: nginx-forum на nginx.us (yokodzun) Date: Mon, 05 Dec 2011 04:08:49 -0500 Subject: alias issue again In-Reply-To: References: Message-ID: <96f9d3371c9a4d61049b61e27354fa88.NginxMailingListRussian@forum.nginx.org> Alexander Moskalenko Wrote: ------------------------------------------------------- > - location ~ "\/pma\/(?P\.php)$ { > + location ~ "\/pma\/(?P.+\.php)$ { > Вот такой вышел локейшен: location /pma/ { alias /usr/local/www/phpMyAdmin/; index index.php; location ~ \/pma\/(?P.+\.php)$ { fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin; fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin$script_name; include fastcgi_params; } } Но все выглядит как и раньше: Броузер: Oops! This link appears to be broken. acess: x.x.x.x - - [05/Dec/2011:16:00:28 +0700] "GET /pma/ HTTP/1.1" 404 5 "-" x.x.x.x - - [05/Dec/2011:16:00:46 +0700] "-" 400 0 "-" "-" x.x.x.x - - [05/Dec/2011:16:00:46 +0700] "-" 400 0 "-" "-" Err - пусто. Не очень понятно, на чем ломается конструкция, и что не нравиться броузеру. Не очень понимаю, Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219608#msg-219608 From igor на sysoev.ru Mon Dec 5 09:14:53 2011 From: igor на sysoev.ru (Igor Sysoev) Date: Mon, 5 Dec 2011 13:14:53 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <8771323009674@web16.yandex.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> Message-ID: <20111205091453.GA57801@nginx.com> On Sun, Dec 04, 2011 at 09:41:14PM +0700, Denis F. Latypoff wrote: > 04.12.2011, 17:48, "Valery Kholodkov" : > > Согласен, есть конфликт интересов -- тесты выполняет сторона заинтересованая в результатах. Нужно, чтобы кто-нибудь незаинтересованный в результатах провел тесты. > > libev знаю очень хорошо, там нет поддержки для edge triggered возвратов из ядра. > В nginx, насколько я понимаю, по сути своя реализация libev, во всеми блекджеками > и шахматами. Так что nxweb может слить там где скорость упрется в ведро. > Ну и чую, что если nxweb обрастет инфраструктурой как у nginx, то там подавно сольет. > IMHO сравнивать их лоб в лоб - нет смысла. Не факт, что edge triggered в том чистом виде, как он реализован в epoll лучше level triggered. Например, если на момент добавления сокета в epoll данные уже есть в сокете, то edge triggered epoll про них не раскажет. Приходится делать лишний read после добавления. Кроме того, есть и просто ошибка реализации edge triggered, когда нужно делать read до получения EAGAIN, иначе можно пропустить EOF. А вот EV_CLEAR в kqueue сделан явно с применением мозга. -- Игорь Сысоев http://sysoev.ru From ne на vbart.ru Mon Dec 5 09:28:58 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 5 Dec 2011 13:28:58 +0400 Subject: alias issue again In-Reply-To: <96f9d3371c9a4d61049b61e27354fa88.NginxMailingListRussian@forum.nginx.org> References: <96f9d3371c9a4d61049b61e27354fa88.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112051328.58613.ne@vbart.ru> On Monday 05 December 2011 13:08:49 yokodzun wrote: > Alexander Moskalenko Wrote: > ------------------------------------------------------- > > > - location ~ "\/pma\/(?P\.php)$ { > > + location ~ "\/pma\/(?P.+\.php)$ { > > Вот такой вышел локейшен: > > location /pma/ { > alias /usr/local/www/phpMyAdmin/; > index index.php; > > location ~ \/pma\/(?P.+\.php)$ { > fastcgi_pass unix:/tmp/php-fpm.sock; > fastcgi_index index.php; > fastcgi_param DOCUMENT_ROOT > /usr/local/www/phpMyAdmin; > fastcgi_param SCRIPT_FILENAME > /usr/local/www/phpMyAdmin$script_name; > include fastcgi_params; > } > } > -location ~ \/pma\/(?P.+\.php)$ { +location ~ ^/pma(?/.+\.php)$ { Либо, я бы даже лучше так сделал: -location ~ \/pma\/(?P.+\.php)$ { +location ~ ^/pma/(?.+)\.php$ { -fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin$script_name; +fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$script_name.php; И включите же наконец debug log, он вам скажет где, когда и на чем и где ломается. Неужели вместо этого проще вопросы задавать? -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 5 09:36:53 2011 From: nginx-forum на nginx.us (alex_ru) Date: Mon, 05 Dec 2011 04:36:53 -0500 Subject: =?UTF-8?B?UmU6INCh0LDQvNC+0YHRgtC+0Y/RgtC10LvRjNC90LDRjyDRgdCx0L7RgNC60LAg?= =?UTF-8?B?bmdpbngg0L/QvtC0IFdpbmRvd3M=?= In-Reply-To: <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> References: <5450578b339553eb54a7ae887fb5c48f.NginxMailingListRussian@forum.nginx.org> <3a1a67a8f0e140c733f8ecaef10e4dd7.NginxMailingListRussian@forum.nginx.org> Message-ID: <002418f30bbe62726c3acea3cc71ade8.NginxMailingListRussian@forum.nginx.org> Разобрался, спасибо :) Получилось собрать. PCRE, zlib and OpenSSL libraries sources - чего-то я не то качнул, когда заново повыкачивал, прошло нормально. Теперь не могу собрать libgd, но то уже другая история. Спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,113759,219615#msg-219615 From zaabjuda на gmail.com Mon Dec 5 10:00:07 2011 From: zaabjuda на gmail.com (=?KOI8-R?B?5M3J1NLJyiD2yczYw8/X?=) Date: Mon, 5 Dec 2011 14:00:07 +0400 Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDRgSDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtdC8?= Message-ID: Здравствуйте, участники рассылки. Возникла проблема необходимо настроить проксирование с http://host1.ru на http://host.ru/data/sql как делаю server { server_name host1.ru ; location / { rewrite ^/(.*)$ "/data/sql/" break; proxy_pass http://backend01:80; proxy_set_header Host host.ru; proxy_set_header X-Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; } Ничего не выходит... помогите пожалуйста. From nginx-forum на nginx.us Mon Dec 5 10:01:14 2011 From: nginx-forum на nginx.us (yokodzun) Date: Mon, 05 Dec 2011 05:01:14 -0500 Subject: alias issue again In-Reply-To: <201112051328.58613.ne@vbart.ru> References: <201112051328.58613.ne@vbart.ru> Message-ID: <50644688b1d3dc2f7a6f3e786be46e00.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: > > И включите же наконец debug log, > он вам скажет где, когда и > на чем > и где ломается. Неужели > вместо этого проще вопросы > задавать? > В том-то и дело, он включен. И для php или nginx* error_log /var/log/nginx/error.log debug; Сам nginx собран с поддержкой debug. Или есть еще больее детальная отладка? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219617#msg-219617 From mdounin на mdounin.ru Mon Dec 5 10:06:46 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 5 Dec 2011 14:06:46 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YEg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LXQvA==?= In-Reply-To: References: Message-ID: <20111205100646.GO67687@mdounin.ru> Hello! On Mon, Dec 05, 2011 at 02:00:07PM +0400, Дмитрий Жильцов wrote: > Здравствуйте, участники рассылки. > > Возникла проблема необходимо настроить проксирование с http://host1.ru > на http://host.ru/data/sql > > как делаю > > server { > server_name host1.ru ; > > location / { > rewrite ^/(.*)$ "/data/sql/" break; > proxy_pass http://backend01:80; > proxy_set_header Host host.ru; > proxy_set_header X-Host $http_host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; > } > > Ничего не выходит... Зачем rewrite? Rewrite тут не нужен. server { server_name host1.ru; location / { proxy_pass http://host.ru/data/sql/; } } Ну и "proxy_set_header X-..." по вкусу. Maxim Dounin From zaabjuda на gmail.com Mon Dec 5 10:17:58 2011 From: zaabjuda на gmail.com (=?KOI8-R?B?5M3J1NLJyiD2yczYw8/X?=) Date: Mon, 5 Dec 2011 14:17:58 +0400 Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0YEg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?= =?UTF-8?B?0LXQvA==?= In-Reply-To: <20111205100646.GO67687@mdounin.ru> References: <20111205100646.GO67687@mdounin.ru> Message-ID: Максим спасибо. ошибка была в регистре локейшенов и никак не связана с конфигов что я дал. Ваш метод не подходит в данной ситуации ибо на сервере где выполняется проксирование сйт по url http://host.ru/ не доступен Влюбом случае спасибо. 5 декабря 2011 г. 14:06 пользователь Maxim Dounin написал: > Hello! > > On Mon, Dec 05, 2011 at 02:00:07PM +0400, Дмитрий Жильцов wrote: > >> Здравствуйте, участники рассылки. >> >> Возникла проблема необходимо настроить проксирование с http://host1.ru >> на http://host.ru/data/sql >> >> как делаю >> >> server { >>         server_name host1.ru ; >> >>         location / { >>                rewrite ^/(.*)$ "/data/sql/" break; >>                 proxy_pass          http://backend01:80; >>                 proxy_set_header    Host               host.ru; >>                 proxy_set_header    X-Host             $http_host; >>                 proxy_set_header    X-Real-IP          $remote_addr; >>                 proxy_set_header    X-Forwarded-Proto  $http_x_forwarded_proto; >>         } >> >> Ничего не выходит... > > Зачем rewrite?  Rewrite тут не нужен. > > server { >    server_name host1.ru; > >    location / { >        proxy_pass http://host.ru/data/sql/; >    } > } > > Ну и "proxy_set_header X-..." по вкусу. > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ne на vbart.ru Mon Dec 5 10:27:57 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 5 Dec 2011 14:27:57 +0400 Subject: alias issue again In-Reply-To: <50644688b1d3dc2f7a6f3e786be46e00.NginxMailingListRussian@forum.nginx.org> References: <201112051328.58613.ne@vbart.ru> <50644688b1d3dc2f7a6f3e786be46e00.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112051427.58031.ne@vbart.ru> On Monday 05 December 2011 14:01:14 yokodzun wrote: > error_log /var/log/nginx/error.log debug; И там пусто? Или есть все-таки интересная информация, касающаяся того, как происходит обработка запроса? -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 5 10:58:07 2011 From: nginx-forum на nginx.us (yokodzun) Date: Mon, 05 Dec 2011 05:58:07 -0500 Subject: alias issue again In-Reply-To: <201112051427.58031.ne@vbart.ru> References: <201112051427.58031.ne@vbart.ru> Message-ID: <393ed89a81c6473f0695931b47de4f79.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Monday 05 December 2011 14:01:14 yokodzun > wrote: > > error_log /var/log/nginx/error.log debug; > > И там пусто? Или есть > все-таки интересная > информация, касающаяся > того, как > происходит обработка > запроса? Отротейтил лог, перезапустил сервер. Похоже, передается неправильная переменная SCRIPT_FILENAME 2011/12/05 17:42:13 [debug] 4809#0: *1 open index "/usr/local/www/phpMyAdmin/index.php" 2011/12/05 17:42:13 [debug] 4809#0: *1 internal redirect: "/pma/index.php?" 2011/12/05 17:42:13 [debug] 4809#0: *1 rewrite phase: 0 2011/12/05 17:42:13 [debug] 4809#0: *1 test location: "/" 2011/12/05 17:42:13 [debug] 4809#0: *1 test location: "pma/" 2011/12/05 17:42:13 [debug] 4809#0: *1 test location: ~ "^/pma/(?.+)\.php$" 2011/12/05 17:42:13 [debug] 4809#0: *1 http regex set $script_name to "index" 2011/12/05 17:42:13 [debug] 4809#0: *1 using configuration "^/pma/(?.+)\.php$" 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: "DOCUMENT_ROOT" 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: "/usr/local/www/phpMyAdmin" 2011/12/05 17:42:13 [debug] 4809#0: *1 fastcgi param: "DOCUMENT_ROOT: /usr/local/www/phpMyAdmin" 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: "SCRIPT_FILENAME" 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: "/usr/local/www/phpMyAdmin" 2011/12/05 17:42:13 [debug] 4809#0: *1 http script var: "index" 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: ".php" ****2011/12/05 17:42:13 [debug] 4809#0: *1 fastcgi param: "SCRIPT_FILENAME: /usr/local/www/phpMyAdminindex.php" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219624#msg-219624 From ne на vbart.ru Mon Dec 5 11:08:23 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 5 Dec 2011 15:08:23 +0400 Subject: alias issue again In-Reply-To: <393ed89a81c6473f0695931b47de4f79.NginxMailingListRussian@forum.nginx.org> References: <201112051427.58031.ne@vbart.ru> <393ed89a81c6473f0695931b47de4f79.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112051508.24064.ne@vbart.ru> On Monday 05 December 2011 14:58:07 yokodzun wrote: [...] > 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: > "SCRIPT_FILENAME" > 2011/12/05 17:42:13 [debug] 4809#0: *1 http script copy: > "/usr/local/www/phpMyAdmin" [...] Ну а вы данное изменение внесли? -fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin$script_name; +fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$script_name.php; Есть разница между: /usr/local/www/phpMyAdmin$script_name и /usr/local/www/phpMyAdmin/$script_name В случае location ~ ^/pma/(?.+)\.php$ { слеша в начале $script_name не будет. -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 5 11:22:02 2011 From: nginx-forum на nginx.us (yokodzun) Date: Mon, 05 Dec 2011 06:22:02 -0500 Subject: alias issue again In-Reply-To: <201112051508.24064.ne@vbart.ru> References: <201112051508.24064.ne@vbart.ru> Message-ID: Валентин Бартенев Wrote: > > В случае > location ~ ^/pma/(?.+)\.php$ { > > слеша в начале $script_name не > будет. Действительно, недосмотрел. Спасибо, все работает. Спасибо, всем кто отозвался и принял участие. Оставлю тут рабочий вариант, чтобы нашелся гуглом. Как я смотрю, подобный вопрос возникает часто. Может в каом FAQ пригодится. location /pma/ { alias /usr/local/www/phpMyAdmin/; index index.php; location ~ ^/pma/(?.+)\.php$ { fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin; fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$script_name.php; include fastcgi_params; } } Еще раз, всем спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219626#msg-219626 From ne на vbart.ru Mon Dec 5 11:33:46 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 5 Dec 2011 15:33:46 +0400 Subject: alias issue again In-Reply-To: References: <201112051508.24064.ne@vbart.ru> Message-ID: <201112051533.46723.ne@vbart.ru> On Monday 05 December 2011 15:22:02 yokodzun wrote: [...] > > location /pma/ { > alias /usr/local/www/phpMyAdmin/; > index index.php; > > > > location ~ ^/pma/(?.+)\.php$ { > fastcgi_pass unix:/tmp/php-fpm.sock; > fastcgi_index index.php; > fastcgi_param DOCUMENT_ROOT > /usr/local/www/phpMyAdmin; > fastcgi_param SCRIPT_FILENAME > /usr/local/www/phpMyAdmin/$script_name.php; > include fastcgi_params; > } > } > > Еще раз, всем спасибо! > fastcgi_index index.php; тут лишний, такой запрос, заканчивающий на /, сюда просто не попадет. Да и пожалуй зря я предложил вынести \.php за пределы regexp capture, это добавляет еще по одному коду в VM. С т.з. производительности, вариант ^/pma/(?.+\.php)$ чуть оптимальнее. -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 5 11:53:28 2011 From: nginx-forum на nginx.us (yokodzun) Date: Mon, 05 Dec 2011 06:53:28 -0500 Subject: alias issue again In-Reply-To: <201112051533.46723.ne@vbart.ru> References: <201112051533.46723.ne@vbart.ru> Message-ID: Валентин Бартенев Wrote: > > Да и пожалуй зря я > предложил вынести \.php за > пределы regexp capture, > это добавляет еще по одному > коду в VM. С т.з. > производительности, > вариант ^/pma/(?.+\.php)$ > чуть оптимальнее. > В моем случае большой нагрузки не ожидается, да и машина сильно overkill (так уж случилось), но красоты ради, оставил такой вариант: location /pma/ { alias /usr/local/www/phpMyAdmin/; index index.php; location ~ ^/pma/(?.+\.php)$ { fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_param DOCUMENT_ROOT /usr/local/www/phpMyAdmin; fastcgi_param SCRIPT_FILENAME /usr/local/www/phpMyAdmin/$script_name; include fastcgi_params; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219314,219628#msg-219628 From hell-for-yahoo на umail.ru Mon Dec 5 12:32:50 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Mon, 5 Dec 2011 16:32:50 +0400 Subject: Помогите с проксированием In-Reply-To: References: <20111205100646.GO67687@mdounin.ru> Message-ID: <1117381105.20111205163250@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Дмитрий Жильцов! ДЖ> ошибка была в регистре локейшенов и никак не связана с конфигов что я дал. ДЖ> Ваш метод не подходит в данной ситуации ибо на сервере где выполняется ДЖ> проксирование сйт по url http://host.ru/ не доступен Напишите тот URL, по которому он доступен. Либо учитесь ставить задачи нормально, чтобы не вводить сообщество в заблуждение. А то вы пишете >>> Возникла проблема необходимо настроить проксирование с http://host1.ru >>> на http://host.ru/data/sql а потом вдруг возникает >>> proxy_pass http://backend01:80; ... Вот и напишите proxy_pass http://backend01:80/data/sql/; P.S. И постарайтесь не топ-постить в следующий раз. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) понедельник, 05.12.2011, <16:30> From nginx-forum на nginx.us Mon Dec 5 12:48:25 2011 From: nginx-forum на nginx.us (www) Date: Mon, 05 Dec 2011 07:48:25 -0500 Subject: =?UTF-8?B?ZmFzdGNnaSBjYWNoZSwgUE9TVC3Qt9Cw0L/RgNC+0YHRiyDQuCBjb29raWU=?= Message-ID: <611575bd9e9583209bbbec7db1e25e73.NginxMailingListRussian@forum.nginx.org> Делаю кэширование так fastcgi_cache my_cache; fastcgi_cache_valid 200 301 302 5m; fastcgi_cache_key "$request_method|$host|$request_uri"; fastcgi_hide_header "Set-Cookie"; fastcgi_ignore_headers "Cache-Control" "Expires"; fastcgi_cache_use_stale error timeout invalid_header http_500; fastcgi_temp_path /cache/nginx/tmp 1 2; fastcgi_cache_methods не переопределял, поэтому POST-запросы не кэшируются (это хорошо), но и cookie в POST-запросах не сохраняются (это плохо). Как я понимаю, из-за fastcgi_hide_header. Как сделать так, чтобы при POST-запросе fastcgi_hide_header не использовался? Пробовал манипуляции с if ($request_method != POST ) { ... } , ругается на синтаксис. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219631,219631#msg-219631 From nginx-forum на nginx.us Mon Dec 5 13:02:07 2011 From: nginx-forum на nginx.us (www) Date: Mon, 05 Dec 2011 08:02:07 -0500 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUsIFBPU1Qt0LfQsNC/0YDQvtGB0Ysg0LggY29va2ll?= In-Reply-To: <611575bd9e9583209bbbec7db1e25e73.NginxMailingListRussian@forum.nginx.org> References: <611575bd9e9583209bbbec7db1e25e73.NginxMailingListRussian@forum.nginx.org> Message-ID: <9f992bd1933fcbd802772ba117b484ca.NginxMailingListRussian@forum.nginx.org> Нашёл в другой теме http://forum.nginx.org/read.php?21,136867,136890 > В 0.8.44+ ответы с Set-Cookie по умолчанию не кешируются, Т.е. если я уберу fastcgi_hide_header "Set-Cookie";, то у меня не будут кэшироваться все запросы c заголовком Set-Cookie? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219631,219632#msg-219632 From mdounin на mdounin.ru Mon Dec 5 13:36:54 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 5 Dec 2011 17:36:54 +0400 Subject: =?UTF-8?B?UmU6IGZhc3RjZ2kgY2FjaGUsIFBPU1Qt0LfQsNC/0YDQvtGB0Ysg0LggY29va2ll?= In-Reply-To: <9f992bd1933fcbd802772ba117b484ca.NginxMailingListRussian@forum.nginx.org> References: <611575bd9e9583209bbbec7db1e25e73.NginxMailingListRussian@forum.nginx.org> <9f992bd1933fcbd802772ba117b484ca.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111205133653.GR67687@mdounin.ru> Hello! On Mon, Dec 05, 2011 at 08:02:07AM -0500, www wrote: > Нашёл в другой теме > http://forum.nginx.org/read.php?21,136867,136890 > > > В 0.8.44+ ответы с Set-Cookie по умолчанию не > кешируются, > > Т.е. если я уберу fastcgi_hide_header "Set-Cookie";, то у > меня не будут кэшироваться все запросы > c заголовком Set-Cookie? Все *ответы* с заголовком Set-Cookie. Впрочем, они у вас и так не кешируются, чтобы кешировались - надо явно указать fastcgi_ignore_headers Set-Cookie. Maxim Dounin From nginx-forum на nginx.us Mon Dec 5 14:41:37 2011 From: nginx-forum на nginx.us (Art) Date: Mon, 05 Dec 2011 09:41:37 -0500 Subject: Nginx+SSI+Memcached In-Reply-To: <2a6db46fa79015ffe6e5e9d9b134d2a6.NginxMailingListRussian@forum.nginx.org> References: <843f41579d25595a8d88ba42bd1a5280.NginxMailingListRussian@forum.nginx.org> <2a6db46fa79015ffe6e5e9d9b134d2a6.NginxMailingListRussian@forum.nginx.org> Message-ID: Приветствую! Я уже все перечитал и перерыл, и эту статью в том числе. :-) К сожалению, рецепта, который бы удовлетворял требованиям, изложенным выше не нашел... Просто, прежде чем приступать к реальным экспериментам, хотел проконсультироваться со специалистами (участниками рассылки, то есть), чтобы выбрать правильную стратегию кэширования с участием nginx. В процессе работы над проектом пришлось доработать memcached, разработать систему поддержки тэгов в нем. Сейчас сайты и так летают, но все-таки для генерации страницы приходится дергать бэкенд, а хочется большего, чего уж технологиям простаивать. Коллеги, подскажите, пожалуйста! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219575,219635#msg-219635 From nginx-forum на nginx.us Mon Dec 5 19:01:36 2011 From: nginx-forum на nginx.us (Sergey Biryuzov) Date: Mon, 05 Dec 2011 14:01:36 -0500 Subject: =?UTF-8?B?YmFzaWMg0LDQstGC0L7RgNC40LfQsNGG0LjRjyDQvdC1INGA0LDQsdC+0YLQsNC1?= =?UTF-8?B?0YIgcGhw?= Message-ID: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> Всем доброго времени суток! У меня возникла проблема с модулем ngx_http_auth_basic_module. Конкретнее, в настройке виртуального хоста выставил закрытую директорию. Защитил ее паролем, логин и пароль принимает, но php скрипты не работают, а загружаются на PC. Как сделать чтобы php исполнялся? Имеем: server { root /var/www/site/; ... location /admin/ { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd/passwd; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219645,219645#msg-219645 From sytar.alex на gmail.com Mon Dec 5 19:11:57 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Mon, 5 Dec 2011 23:11:57 +0400 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> References: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> Message-ID: 5 декабря 2011 г. 23:01 пользователь Sergey Biryuzov написал: > Всем доброго времени суток! > У меня возникла проблема с модулем > ngx_http_auth_basic_module. Конкретнее, в настройке > виртуального хоста выставил закрытую > директорию. Защитил ее паролем, логин и > пароль принимает, но php скрипты не > работают, а загружаются на PC. Как > сделать чтобы php исполнялся? > > Имеем: > > server > { > root /var/www/site/; > ... > location /admin/ > { >        auth_basic "Restricted"; >        auth_basic_user_file /etc/nginx/.htpasswd/passwd; > } > } > Как-то так location /admin/ {        auth_basic "Restricted";        auth_basic_user_file /etc/nginx/.htpasswd/passwd; location ~* \.php$ { proxy_pass|fastcgi_pass .... } } From yarosla на gmail.com Mon Dec 5 19:32:31 2011 From: yarosla на gmail.com (Yaroslav) Date: Mon, 5 Dec 2011 23:32:31 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <20111205091453.GA57801@nginx.com> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> Message-ID: 2011/12/5 Igor Sysoev > > Не факт, что edge triggered в том чистом виде, как он реализован в epoll > лучше level triggered. Например, если на момент добавления сокета в epoll > данные уже есть в сокете, то edge triggered epoll про них не раскажет. > Приходится делать лишний read после добавления. Кроме того, есть и просто > ошибка реализации edge triggered, когда нужно делать read до получения > EAGAIN, иначе можно пропустить EOF. > > А вот EV_CLEAR в kqueue сделан явно с применением мозга. > > > Автор libev тоже не очень лестно высказывается насчет epoll. В частности он пишет об ошибках в его работе: The epoll mechanism deserves honorable mention as the most misdesigned of > the more advanced event mechanisms: mere annoyances include *silently > dropping file descriptors*, requiring a system call per change per file > descriptor (and unnecessary guessing of parameters), problems with dup, > returning before the timeout value, resulting in additional iterations (and > only giving 5ms accuracy while select on the same platform gives 0.1ms) and > so on. Epoll is also notoriously buggy - embedding epoll fds should work, > but of course doesn't, and epoll just loves to *report events for totally > different file descriptors* (even already closed ones, so one cannot even > remove them from the set) than registered in the set (especially on SMP > systems). Epoll also *erroneously rounds down timeouts*, but gives you no > way to know when and by how much, so sometimes you have to busy-wait > because epoll returns immediately despite a nonzero timeout. And last not > least, it also refuses to work with some file descriptors which work > perfectly fine with select (files, many character devices...). Хотелось бы узнать по Вашему опыту, такие проблемы действительно имеют место? Или может они исправлены в более свежих версиях ядра? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From yarosla на gmail.com Mon Dec 5 20:51:16 2011 From: yarosla на gmail.com (Yaroslav) Date: Tue, 6 Dec 2011 00:51:16 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> Message-ID: Я тут призадумался, как mongoose сервер с 2500 потоками (thread pool) смог пройти тест с 10000 одновременных соединений в режиме keep-alive. И понял простую вещь. Программа тестирования httpress открыла 10 тыс. соединений с сервером и прогнала через них 1 млн. запросов. При этом у всех серверов (кроме nxweb) при тестировании возникали ошибки: часть запросов подвисала, программа принудительно обрывала их по завершении основной фазы тестирования. Процент ошибок был невелик. В районе 8..9.5 тыс. ошибок из миллиона. Ошибочные запросы не учитывались при расчете результирующего RPS. Так как это возникало со всеми, я грешил на TCP-стек. Тем более, что и у nxweb тоже иногда ошибки проскакивали (пока я вчера не убрал mutex из accept-цикла). А теперь меня осенило, и я добавил в httpress оценку реальной одновременности (real concurrency) - только что закоммитил. И вот что получается при тестировании 10 тыс. одновремнных keep-alive: nxweb: real concurrecny = 10000 (через каждое соединение прошел хотя бы один успешный запрос) g-wan: real concurrecny = 4-7 тыс. (т.е. часть соединений зависла сходу, и не использовалась в процессе теста) mongoose: real concurrecny = ~1700 (ведь он при всем желании больше 2500 не может в моей конфигурации, а по факту и тех не задействует) libevent: real concurrecny = 10000 microhttpd: real concurrecny = 800-1000 nginx: real concurrecny = 2-7 тыс. Почему пишу об этом здесь, потому что не понимаю, почему у nginx не 10 000. У меня в конфиге: worker_processes 4; events { worker_connections 16384; } Вроде бы должен он 10 тыс. соединений держать... Может, надо еще что-то подкрутить? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From wangsamp на gmail.com Mon Dec 5 20:57:15 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Mon, 5 Dec 2011 22:57:15 +0200 (EET) Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> Message-ID: Tomorrow Dec 6, 2011 at 00:51 Yaroslav wrote: > nginx: real concurrecny = 2-7 тыс. > > Почему пишу об этом здесь, потому что не понимаю, почему у nginx не 10 000. > > У меня в конфиге: > > worker_processes 4; > events { > worker_connections 16384; > } > > Вроде бы должен он 10 тыс. соединений держать... Может, надо еще что-то > подкрутить? А если добавить в events "accept_mutex off;"? -- WNGS-RIPE From zzz на zzz.org.ua Mon Dec 5 21:01:08 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Mon, 5 Dec 2011 23:01:08 +0200 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> Message-ID: On Mon, Dec 5, 2011 at 10:57 PM, Oleksandr V. Typlyns'kyi wrote: >> Вроде бы должен он 10 тыс. соединений держать... Может, надо еще что-то >> подкрутить? > >  А если добавить в events "accept_mutex off;"? А если заглянуть в error.log? From yarosla на gmail.com Mon Dec 5 21:27:26 2011 From: yarosla на gmail.com (Yaroslav) Date: Tue, 6 Dec 2011 01:27:26 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> Message-ID: 2011/12/6 Alexandr Gomoliako > On Mon, Dec 5, 2011 at 10:57 PM, Oleksandr V. Typlyns'kyi > wrote: > >> Вроде бы должен он 10 тыс. соединений держать... Может, надо еще что-то > >> подкрутить? > > > > А если добавить в events "accept_mutex off;"? > Надо же. Тут тоже есть accept_mutex У меня он, правда, для другой цели использовался. accept происходил вне мутекса, а мутексом была защищена часть, помещающая запрос в очередь для обработки сетевыми воркерами. Но, надо сказать, помогло. Не на 100%, но теперь real concurrency совсем близок к 10 тыс. - 9679, 9457, ... А в чем недостаток такого режима? Ведь не зря же он по умолчанию ON. > > А если заглянуть в error. Голяк там. Даже пришлось специально провоцировать ошибки, чтобы убедиться, что он жив. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Mon Dec 5 21:54:08 2011 From: nginx-forum на nginx.us (alex_ru) Date: Mon, 05 Dec 2011 16:54:08 -0500 Subject: =?UTF-8?B?UmU6INGB0LHQvtGA0LrQsCBjIHdpdGgtaHR0cCBpbWFnZSBmaWx0ZXIgbW9kdWxl?= In-Reply-To: References: Message-ID: Скачал GnuWin32, он идет с libgd. Вроде бы установил, но сервер не находит: + MINGW32_NT-6.1 1.0.17(0.48/3/2) i686 + using Microsoft Visual C++ compiler checking for MINGW32_NT-6.1 specific features checking for GD library ... not found checking for GD library in /usr/local/ ... not found checking for GD library in /usr/pkg/ ... not found checking for GD library in /opt/local/ ... not found Собираю под Windows 7. Подскажите пожалуйста куда ложить и что? libgd2.dll как я понял, но не понял куда :(( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,212832,219656#msg-219656 From latypoff на yandex.ru Tue Dec 6 01:03:10 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Tue, 06 Dec 2011 08:03:10 +0700 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> Message-ID: <163501323133390@web79.yandex.ru> 06.12.2011, 02:32, "Yaroslav" : > 2011/12/5 Igor Sysoev >> Не факт, что edge triggered в том чистом виде, как он реализован в epoll >> лучше level triggered. Например, если на момент добавления сокета в epoll >> данные уже есть в сокете, то edge triggered epoll про них не раскажет. >> Приходится делать лишний read после добавления. Кроме того, есть и просто >> ошибка реализации edge triggered, когда нужно делать read до получения >> EAGAIN, иначе можно пропустить EOF. >> >> А вот EV_CLEAR в kqueue сделан явно с применением мозга. > Автор libev тоже не очень лестно высказывается насчет epoll. В частности он пишет об ошибках в его работе: >> The epoll mechanism deserves honorable mention as the most misdesigned of the more advanced event mechanisms: mere annoyances include silently dropping file descriptors, requiring a system call per change per file descriptor (and unnecessary guessing of parameters), problems with dup, returning before the timeout value, resulting in additional iterations (and only giving 5ms accuracy while select on the same platform gives 0.1ms) and so on. Epoll is also notoriously buggy - embedding epoll fds should work, but of course doesn't, and epoll just loves to report events for totally different file descriptors (even already closed ones, so one cannot even remove them from the set) than registered in the set (especially on SMP systems). Epoll also erroneously rounds down timeouts, but gives you no way to know when and by how much, so sometimes you have to busy-wait because epoll returns immediately despite a nonzero timeout. And last not least, it also refuses to work with some file descriptors which work perfectly fine with select (files, many character devices...). > Хотелось бы узнать по Вашему опыту, такие проблемы действительно имеют место? Или может они исправлены в более свежих версиях ядра? > Да дело даже не в том, что еполл на каких-то ядрах недозапилен, а в том, что libev by design таков, что не позволяет использовать нестандартные фичи event-движков ядра. То есть если во фре, например, можно узнать об EOF прямо из kqueue, то с libev на той же фре - только через дополнительный read, который вернет -1 и установит errno в EAGAIN. libev использует только базовые механизмы, в то время как nginx все прелести event-движков с целью уменьшения кол-ва передергивания контекста. -- br, Denis F. Latypoff. From yarosla на gmail.com Tue Dec 6 01:10:19 2011 From: yarosla на gmail.com (Yaroslav) Date: Tue, 6 Dec 2011 05:10:19 +0400 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <163501323133390@web79.yandex.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> <163501323133390@web79.yandex.ru> Message-ID: 2011/12/6 Denis F. Latypoff > 06.12.2011, 02:32, "Yaroslav" : > > 2011/12/5 Igor Sysoev > >> Не факт, что edge triggered в том чистом виде, как он реализован в epoll > >> лучше level triggered. Например, если на момент добавления сокета в > epoll > >> данные уже есть в сокете, то edge triggered epoll про них не раскажет. > >> Приходится делать лишний read после добавления. Кроме того, есть и > просто > >> ошибка реализации edge triggered, когда нужно делать read до получения > >> EAGAIN, иначе можно пропустить EOF. > >> > >> А вот EV_CLEAR в kqueue сделан явно с применением мозга. > > Автор libev тоже не очень лестно высказывается насчет epoll. В частности > он пишет об ошибках в его работе: > >> The epoll mechanism deserves honorable mention as the most misdesigned > of the more advanced event mechanisms: mere annoyances include silently > dropping file descriptors, requiring a system call per change per file > descriptor (and unnecessary guessing of parameters), problems with dup, > returning before the timeout value, resulting in additional iterations (and > only giving 5ms accuracy while select on the same platform gives 0.1ms) and > so on. Epoll is also notoriously buggy - embedding epoll fds should work, > but of course doesn't, and epoll just loves to report events for totally > different file descriptors (even already closed ones, so one cannot even > remove them from the set) than registered in the set (especially on SMP > systems). Epoll also erroneously rounds down timeouts, but gives you no way > to know when and by how much, so sometimes you have to busy-wait because > epoll returns immediately despite a nonzero timeout. And last not least, it > also refuses to work with some file descriptors which work perfectly fine > with select (files, many character devices...). > > Хотелось бы узнать по Вашему опыту, такие проблемы действительно имеют > место? Или может они исправлены в более свежих версиях ядра? > > > > Да дело даже не в том, что еполл на каких-то ядрах недозапилен, > а в том, что libev by design таков, что не позволяет использовать > нестандартные фичи event-движков ядра. То есть если во фре, > например, можно узнать об EOF прямо из kqueue, то с libev на той > же фре - только через дополнительный read, который вернет -1 > и установит errno в EAGAIN. libev использует только базовые > механизмы, в то время как nginx все прелести event-движков > с целью уменьшения кол-ва передергивания контекста. > > Про libev я все понял. Знал про отсутствие поддержки ET изначально. Но мой вопрос сейчас не про libev, а про epoll. Понимаю также, что kqueue более продвинут, но у меня Linux. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From latypoff на yandex.ru Tue Dec 6 01:22:26 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Tue, 06 Dec 2011 08:22:26 +0700 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> <163501323133390@web79.yandex.ru> Message-ID: <141901323134546@web96.yandex.ru> 06.12.2011, 08:10, "Yaroslav" : > 2011/12/6 Denis F. Latypoff >> 06.12.2011, 02:32, "Yaroslav" : >>> 2011/12/5 Igor Sysoev >>>> Не факт, что edge triggered в том чистом виде, как он реализован в epoll >>>> лучше level triggered. Например, если на момент добавления сокета в epoll >>>> данные уже есть в сокете, то edge triggered epoll про них не раскажет. >>>> Приходится делать лишний read после добавления. Кроме того, есть и просто >>>> ошибка реализации edge triggered, когда нужно делать read до получения >>>> EAGAIN, иначе можно пропустить EOF. >>>> >>>> А вот EV_CLEAR в kqueue сделан явно с применением мозга. >>> Автор libev тоже не очень лестно высказывается насчет epoll. В частности он пишет об ошибках в его работе: >>>> The epoll mechanism deserves honorable mention as the most misdesigned of the more advanced event mechanisms: mere annoyances include silently dropping file descriptors, requiring a system call per change per file descriptor (and unnecessary guessing of parameters), problems with dup, returning before the timeout value, resulting in additional iterations (and only giving 5ms accuracy while select on the same platform gives 0.1ms) and so on. Epoll is also notoriously buggy - embedding epoll fds should work, but of course doesn't, and epoll just loves to report events for totally different file descriptors (even already closed ones, so one cannot even remove them from the set) than registered in the set (especially on SMP systems). Epoll also erroneously rounds down timeouts, but gives you no way to know when and by how much, so sometimes you have to busy-wait because epoll returns immediately despite a nonzero timeout. And last not least, it also refuses to work with some file descriptors which work perfectly fine with select (files, many character devices...). >>> Хотелось бы узнать по Вашему опыту, такие проблемы действительно имеют место? Или может они исправлены в более свежих версиях ядра? >>> >> >> Да дело даже не в том, что еполл на каких-то ядрах недозапилен, >> а в том, что libev by design таков, что не позволяет использовать >> нестандартные фичи event-движков ядра. То есть если во фре, >> например, можно узнать об EOF прямо из kqueue, то с libev на той >> же фре - только через дополнительный read, который вернет -1 >> и установит errno в EAGAIN. libev использует только базовые >> механизмы, в то время как nginx все прелести event-движков >> с целью уменьшения кол-ва передергивания контекста. > Про libev я все понял. Знал про отсутствие поддержки ET изначально. Но мой вопрос сейчас не про libev, а про epoll. Понимаю также, что kqueue более продвинут, но у меня Linux. > А насчет кривости ядер - не парься, это все равно не твоя вина. В этом плане в libev все что, можно - за'workaround'ено -- br, Denis F. Latypoff. From zzz на zzz.org.ua Tue Dec 6 01:40:31 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Tue, 6 Dec 2011 03:40:31 +0200 Subject: =?UTF-8?Q?Re=3A_NXWEB_=D0=B8_nginx?= In-Reply-To: <141901323134546@web96.yandex.ru> References: <817357842.20111202142148@softsearch.ru> <201112021426.42093.ne@vbart.ru> <413264895.20111203204814@softsearch.ru> <724E59E6-C427-4D4F-9E2C-F89E069BD242@grid.net.ru> <8771323009674@web16.yandex.ru> <20111205091453.GA57801@nginx.com> <163501323133390@web79.yandex.ru> <141901323134546@web96.yandex.ru> Message-ID: > А насчет кривости ядер - не парься, это все равно не твоя вина. > В этом плане в libev все что, можно - за'workaround'ено Марк багрепортил их, должны уже давно быть пофиксены. From nginx-forum на nginx.us Tue Dec 6 04:46:54 2011 From: nginx-forum на nginx.us (Maxim Ko) Date: Mon, 05 Dec 2011 23:46:54 -0500 Subject: =?UTF-8?B?0JjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUg0YDQtdC/0L7Qt9C40YLQvtGA0Lg=?= =?UTF-8?B?0Y8gbmdpbngg0LIgRGViaWFuL1VidW50dSDQuCBncGcg0LrQu9GO0Ycu?= Message-ID: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Подскажите пожалуйста, в случае подключения репозитория к Debian, все нормально работает, но нет gpg ключа, из-за этого apt ругается, что нельзя проверить источник. Подскажите, gpg ключ вообще существует, для http://nginx.org/packages/debian/? Просто я облазил весь сайт, но его так и не нашел. Если есть, дайте пожалуйста ссылку на него. Заранее спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219666,219666#msg-219666 From bediev на gmail.com Tue Dec 6 05:21:32 2011 From: bediev на gmail.com (Marat Bediev) Date: Tue, 6 Dec 2011 11:21:32 +0600 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> Message-ID: а так же, можно узнать с какими ключами скомпилирован nginx в репозиториях? -- Marat Bediev, System Administrator _________________________ Tel: +996555990584 E-mail: bediev на gmail.com Skype: p1gmale0n Twitter: @p1gmale0n ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From latypoff на yandex.ru Tue Dec 6 05:39:58 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Tue, 06 Dec 2011 12:39:58 +0700 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> Message-ID: <232321323149998@web43.yandex.ru> 06.12.2011, 12:21, "Marat Bediev" : > а так же, можно узнать с какими ключами скомпилирован nginx в репозиториях? nginx -V -- br, Denis F. Latypoff. From bediev на gmail.com Tue Dec 6 05:59:58 2011 From: bediev на gmail.com (Marat Bediev) Date: Tue, 6 Dec 2011 11:59:58 +0600 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <232321323149998@web43.yandex.ru> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <232321323149998@web43.yandex.ru> Message-ID: если б он был у меня установлен, я бы не спрашивал. просто может кто уже поставил :) 2011/12/6 Denis F. Latypoff > nginx -V -- Marat Bediev, System Administrator _________________________ Tel: +996555990584 E-mail: bediev на gmail.com Skype: p1gmale0n Twitter: @p1gmale0n ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From latypoff на yandex.ru Tue Dec 6 06:04:20 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Tue, 06 Dec 2011 13:04:20 +0700 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <232321323149998@web43.yandex.ru> Message-ID: <244811323151460@web61.yandex.ru> 06.12.2011, 12:59, "Marat Bediev" : > если б он был у меня установлен, я бы не спрашивал.просто может кто уже поставил :) Есть у меня один сервак с бедианом: # nginx -V nginx: nginx version: nginx/1.1.7 nginx: TLS SNI support enabled nginx: configure arguments: --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --http-scgi-temp-path=/var/lib/nginx/scgi --with-debug --with-file-aio --with-http_stub_status_module --with-http_addition_module --with-http_random_index_module --with-http_flv_module --with-http_ssl_module --with-http_dav_module --with-http_realip_module --with-http_secure_link_module --with-http_xslt_module --with-http_addition_module --with-http_image_filter_module --with-http_mp4_module --add-module=mod_zip-1.1.6 --add-module=nginx_uploadprogress_module-0.8.1 --with-http_geoip_module --with-http_sub_module --add-module=nginx_upload_module-2.0.12 --add-module=nginx_substitutions_filter > > 2011/12/6 Denis F. Latypoff >> nginx -V > -- br, Denis F. Latypoff. From sytar.alex на gmail.com Tue Dec 6 07:08:32 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 6 Dec 2011 11:08:32 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <244811323151460@web61.yandex.ru> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <232321323149998@web43.yandex.ru> <244811323151460@web61.yandex.ru> Message-ID: 6 декабря 2011 г. 10:04 пользователь Denis F. Latypoff написал: > 06.12.2011, 12:59, "Marat Bediev" : >> если б он был у меня установлен, я бы не спрашивал.просто может кто уже поставил :) > Есть у меня один сервак с бедианом: > > # nginx -V > nginx: nginx version: nginx/1.1.7 > nginx: TLS SNI support enabled > nginx: configure arguments: --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --http-scgi-temp-path=/var/lib/nginx/scgi --with-debug --with-file-aio --with-http_stub_status_module --with-http_addition_module --with-http_random_index_module --with-http_flv_module --with-http_ssl_module --with-http_dav_module --with-http_realip_module --with-http_secure_link_module --with-http_xslt_module --with-http_addition_module --with-http_image_filter_module --with-http_mp4_module --add-module=mod_zip-1.1.6 --add-module=nginx_uploadprogress_module-0.8.1 --with-http_geoip_module --with-http_sub_module --add-module=nginx_upload_module-2.0.12 --add-module=nginx_substitutions_filter > apt-cache policy nginx nginx: Installed: 1.0.10-1 Candidate: 1.0.10-1 Version table: *** 1.0.10-1 0 500 http://nginx.org/packages/debian/ squeeze/nginx amd64 Packages 100 /var/lib/dpkg/status 1.0.10-1~dotdeb.1 0 500 http://packages.dotdeb.org/ squeeze/all amd64 Packages 0.7.67-3 0 500 http://mirror.hetzner.de/debian/packages/ squeeze/main amd64 Packages 500 http://ftp.uni-bayreuth.de/linux/Debian/debian/ squeeze/main amd64 Packages 500 http://mirror.yandex.ru/debian/ squeeze/main amd64 Packages nginx: nginx version: nginx/1.0.10 nginx: TLS SNI support enabled nginx: 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 --user=nginx --group=nginx --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_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 Это если вы про версию в репозитании nginx.org From nginx-forum на nginx.us Tue Dec 6 07:09:17 2011 From: nginx-forum на nginx.us (Sergey Biryuzov) Date: Tue, 06 Dec 2011 02:09:17 -0500 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: References: Message-ID: Не совсем понимаю, что должно быть тут location ~* \.php$ { proxy_pass|fastcgi_pass .... } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219645,219671#msg-219671 From stalker на altlinux.ru Tue Dec 6 07:21:07 2011 From: stalker на altlinux.ru (Anton Gorlov) Date: Tue, 06 Dec 2011 11:21:07 +0400 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: References: Message-ID: <4EDDC263.6040100@altlinux.ru> 06.12.2011 11:09, Sergey Biryuzov пишет: > Не совсем понимаю, что должно быть тут > location ~* \.php$ { > proxy_pass|fastcgi_pass > .... > } то что у вас будет обрабатывать php-скрипты From nginx-forum на nginx.us Tue Dec 6 07:34:44 2011 From: nginx-forum на nginx.us (Sergey Biryuzov) Date: Tue, 06 Dec 2011 02:34:44 -0500 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: <4EDDC263.6040100@altlinux.ru> References: <4EDDC263.6040100@altlinux.ru> Message-ID: <88caee63f058829d6416d59136516b93.NginxMailingListRussian@forum.nginx.org> указываю директиву location ~* \.php$ { proxy_pass http://127.0.0.1:81/; } nginx выдает ошибку Restarting nginx: [emerg]: "proxy_pass" may not have URI part in location given by regular expression, or inside named location, or inside the "if" statement, or inside the "limit_except" block in /etc/nginx/sites-enabled/rexer:36 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219645,219674#msg-219674 From stalker на altlinux.ru Tue Dec 6 07:41:37 2011 From: stalker на altlinux.ru (Anton Gorlov) Date: Tue, 06 Dec 2011 11:41:37 +0400 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: <88caee63f058829d6416d59136516b93.NginxMailingListRussian@forum.nginx.org> References: <4EDDC263.6040100@altlinux.ru> <88caee63f058829d6416d59136516b93.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EDDC731.5050407@altlinux.ru> 06.12.2011 11:34, Sergey Biryuzov пишет: > указываю директиву > location ~* \.php$ { > proxy_pass http://127.0.0.1:81/; > } > nginx выдает ошибку > Restarting nginx: [emerg]: "proxy_pass" may not have URI part in > location given by regular expression, or inside named location, or > inside the "if" statement, or inside the "limit_except" block in > /etc/nginx/sites-enabled/rexer:36 > proxy_buffering on; proxy_buffer_size 32k; proxy_buffers 16 16k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; proxy_pass http://127.0.0.1; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; set_real_ip_from xx.zz.yy.41; real_ip_header X-Real-IP; From bediev на gmail.com Tue Dec 6 08:53:59 2011 From: bediev на gmail.com (Marat Bediev) Date: Tue, 6 Dec 2011 14:53:59 +0600 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <232321323149998@web43.yandex.ru> <244811323151460@web61.yandex.ru> Message-ID: ок. спасибо большое :) -- Marat Bediev, System Administrator _________________________ Tel: +996555990584 E-mail: bediev на gmail.com Skype: p1gmale0n Twitter: @p1gmale0n ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Tue Dec 6 10:34:17 2011 From: nginx-forum на nginx.us (Craken) Date: Tue, 06 Dec 2011 05:34:17 -0500 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> References: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> Message-ID: Где-то вот так: location /admin/ { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd/passwd; location ~* ^.+.(php)$ { fastcgi_pass unix:/usr/local/php/sock/fcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /home/mysite$fastcgi_script_name; include fastcgi_params; } } Только пути подправьте под себя! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219645,219693#msg-219693 From ne на vbart.ru Tue Dec 6 10:42:18 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 6 Dec 2011 14:42:18 +0400 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: References: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112061442.18967.ne@vbart.ru> On Tuesday 06 December 2011 14:34:17 Craken wrote: > Где-то вот так: > > location /admin/ > { > auth_basic "Restricted"; > auth_basic_user_file /etc/nginx/.htpasswd/passwd; > > location ~* ^.+.(php)$ { location ~* \.php$ { -- Валентин Бартенев From nginx-forum на nginx.us Tue Dec 6 11:01:31 2011 From: nginx-forum на nginx.us (Sergey Biryuzov) Date: Tue, 06 Dec 2011 06:01:31 -0500 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: References: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> Message-ID: <453286f00963567c50e310cd4b21de99.NginxMailingListRussian@forum.nginx.org> А лучше настраивать php через fast cgi? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219645,219695#msg-219695 From sb на waeme.net Tue Dec 6 12:59:45 2011 From: sb на waeme.net (Sergey Budnevitch) Date: Tue, 6 Dec 2011 16:59:45 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> Message-ID: On 06.12.2011, at 8:46, Maxim Ko wrote: > Здравствуйте. > Подскажите пожалуйста, в случае > подключения репозитория к Debian, все > нормально работает, но нет gpg ключа, > из-за этого apt ругается, что нельзя > проверить источник. Подскажите, gpg ключ > вообще существует, для > http://nginx.org/packages/debian/? Просто я облазил > весь сайт, но его так и не нашел. > Если есть, дайте пожалуйста ссылку на > него. gpg --recv-key 7BD9BF62 gpg --list-key 7BD9BF62 pub 2048R/7BD9BF62 2011-08-19 [expires: 2016-08-17] uid nginx signing key From nginx-forum на nginx.us Tue Dec 6 13:11:08 2011 From: nginx-forum на nginx.us (nikolayb) Date: Tue, 06 Dec 2011 08:11:08 -0500 Subject: =?UTF-8?B?JGh0dHAgQWNjZXB0LUVuY29kaW5nINC/0YDQtdCy0YDQsNGJ0LDQtdGC0YHRjyA=?= =?UTF-8?B?0LIgJGh0dHAgQWNjZXB0?= Message-ID: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> Здравствуйте, господа! Я изучаю nginx и пробую настроить кэширование бэкенда на Amiro.CMS. Среди прочих проблем столкнулся с кэшированием gzip-контента и отдачей его клиенту не поддерживающему сжатие. В топике http://forum.nginx.org/read.php?21,158471,158471#msg-158471 было предложено (1) добавить в ключ кэша $http_Accept-Encoding, Сысоев предложил отключить вовсе gzip на бэкенде и оставить на совесть nginx (2). 1. При попытке добавить переменную в ключ, nginx решил что $http_Accept-Encoding есть $http_Accept плюс строка "-Encoding". Я попробовал создать дополнительную переменную, но nginx показал стойкость и также представил $http_Accept-Encoding как $http_Accept. кусок конфига: set $ae "$http_Accept-Encoding"; proxy_cache_key "BASE $request_method|$http_if_modified_since|$http_if_none_match|$ae|$host|$uri$is_args$args"; кусок кэша для Firefox (с gzip): KEY: BASE GET|||text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8-Encoding|www.site.ru|/katalog/products/aksessuary кусок кэша для curl (без gzip) KEY: BASE GET|||*/*-Encoding|www.site.ru|/katalog/products/aksessuary Т.е. ключ разделил на два случая Accept-Encoding за счет разного заголовка. Плохо то, что может придти клиент с Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 и отключенным gzip, а nginx по ключу отдаст gzip-содержимое кэша. 2. Если отключить gzip на бэкенде удалив заголовок с помощью proxy_set_header Accept-Encoding "", то в кэш будут падать страницы полновесные, и это существенно увеличит размер кэша, плюс nginx будет постоянно занят gzipованием попавших в кэш страниц для отдачи клиентам с поддержкой кэширования. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219698,219698#msg-219698 From unera на uvw.ru Tue Dec 6 13:11:30 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Tue, 6 Dec 2011 17:11:30 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111206131130.GE31845@apache.rbscorp.ru> > Здравствуйте. > Подскажите пожалуйста, в случае > подключения репозитория к Debian, все > нормально работает, но нет gpg ключа, > из-за этого apt ругается, что нельзя > проверить источник. Подскажите, gpg ключ > вообще существует, для > http://nginx.org/packages/debian/? Просто я облазил > весь сайт, но его так и не нашел. > Если есть, дайте пожалуйста ссылку на > него. > Заранее спасибо. А чем не устраивает nginx из Debian'овского репозитария? -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nginx-forum на nginx.us Tue Dec 6 13:16:31 2011 From: nginx-forum на nginx.us (nikolayb) Date: Tue, 06 Dec 2011 08:16:31 -0500 Subject: =?UTF-8?B?UmU6ICRodHRwIEFjY2VwdC1FbmNvZGluZyDQv9GA0LXQstGA0LDRidCw0LXRgtGB?= =?UTF-8?B?0Y8g0LIgJGh0dHAgQWNjZXB0?= In-Reply-To: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> References: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> Message-ID: nginx: nginx version: nginx/1.0.10 nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50) nginx: TLS SNI support disabled nginx: 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 --user=nginx --group=nginx --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_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-cc-opt='-O2 -g -m64 -mtune=generic' Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219698,219700#msg-219700 From nginx-forum на nginx.us Tue Dec 6 13:36:08 2011 From: nginx-forum на nginx.us (Maxim Ko) Date: Tue, 06 Dec 2011 08:36:08 -0500 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> Message-ID: <797e1068d09aa3f943ecde895845665a.NginxMailingListRussian@forum.nginx.org> так он старый там... А тут 1.0.10-1 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219666,219703#msg-219703 From a.vasilishin на kpi.ua Tue Dec 6 13:42:11 2011 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Tue, 06 Dec 2011 15:42:11 +0200 Subject: =?UTF-8?B?0KHQutC+0YDQvtGB0YLRjCDRgNCw0LHQvtGC0YsgbG9jYXRpb24=?= Message-ID: <4EDE1BB3.50501@kpi.ua> Что будет быстрее работать куча location video1, video2 ... location /video1 { location ~ \.flv$ { root /var/www; try_files /video-1.site.com-st8$uri /video-1.site.com-st7$uri /video-1.site.com-st3$uri /video-1.site.com-st4$uri /video-1.site.com-st5$uri /video-1.site.com-st6$uri /video-1.site.com-st1$uri /video-1.site.com-st2$uri =404; internal; flv; } location ~ \.mp4$ { root /var/www; try_files /video-1.site.com-st8$uri /video-1.site.com-st7$uri /video-1.site.com-st3$uri /video-1.site.com-st4$uri /video-1.site.com-st5$uri /video-1.site.com-st6$uri /video-1.site.com-st1$uri /video-1.site.com-st2$uri =404; internal; mp4; mp4_buffer_size 1m; # default 512k mp4_max_buffer_size 10m; # default 5m } или один location ^ /(video1|video2|video3) { location ~ \.flv$ { root /var/www; try_files /video-1.site.com-st8$uri /video-1.site.com-st7$uri /video-1.site.com-st3$uri /video-1.site.com-st4$uri /video-1.site.com-st5$uri /video-1.site.com-st6$uri /video-1.site.com-st1$uri /video-1.site.com-st2$uri =404; internal; flv; } location ~ \.mp4$ { root /var/www; try_files /video-1.site.com-st8$uri /video-1.site.com-st7$uri /video-1.site.com-st3$uri /video-1.site.com-st4$uri /video-1.site.com-st5$uri /video-1.site.com-st6$uri /video-1.site.com-st1$uri /video-1.site.com-st2$uri =404; internal; mp4; mp4_buffer_size 1m; # default 512k mp4_max_buffer_size 10m; # default 5m } Спрашиваю, потому что судя по дебаг-логу, каждый запрос сравнивается со всеми локейшинами и потом выбирается правильный, может легче один с регексом написать и конфиг короче будет и сравнивать меньше? -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From latypoff на yandex.ru Tue Dec 6 13:44:54 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Tue, 06 Dec 2011 20:44:54 +0700 Subject: =?UTF-8?B?UmU6ICRodHRwIEFjY2VwdC1FbmNvZGluZyDQv9GA0LXQstGA0LDRidCw0LXRgtGB?= =?UTF-8?B?0Y8g0LIgJGh0dHAgQWNjZXB0?= In-Reply-To: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> References: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> Message-ID: <34201323179094@web146.yandex.ru> 06.12.2011, 20:11, "nikolayb" : > Здравствуйте, господа! > > Я изучаю nginx и пробую настроить > кэширование бэкенда на Amiro.CMS. Среди > прочих проблем столкнулся с > кэшированием gzip-контента и отдачей его > клиенту не поддерживающему сжатие. > > В топике > http://forum.nginx.org/read.php?21,158471,158471#msg-158471 было > предложено (1) добавить в ключ кэша > $http_Accept-Encoding, Сысоев предложил > отключить вовсе gzip на бэкенде и > оставить на совесть nginx (2). > > 1. При попытке добавить переменную в > ключ, nginx решил что $http_Accept-Encoding есть > $http_Accept плюс строка "-Encoding". > Я попробовал создать дополнительную > переменную, но nginx показал стойкость и > также представил $http_Accept-Encoding как > $http_Accept. > > кусок конфига: >         set $ae                 "$http_Accept-Encoding"; а зачем set? >         proxy_cache_key         "BASE - $request_method|$http_if_modified_since|$http_if_none_match|$ae|$host|$uri$is_args$args"; + $request_method|$http_if_modified_since|$http_if_none_match|$http_accept_encoding|$host|$uri$is_args$args"; > > кусок кэша для Firefox (с gzip): > KEY: BASE > GET|||text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8-Encoding|www.site.ru|/katalog/products/aksessuary > > кусок кэша для curl (без gzip) > KEY: BASE GET|||*/*-Encoding|www.site.ru|/katalog/products/aksessuary > > Т.е. ключ разделил на два случая > Accept-Encoding за счет разного заголовка. > Плохо то, что может придти клиент с > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > и отключенным gzip, а nginx по ключу отдаст > gzip-содержимое кэша. > > 2. Если отключить gzip на бэкенде удалив > заголовок с помощью proxy_set_header Accept-Encoding > "", то в кэш будут падать страницы > полновесные, и это существенно > увеличит размер кэша, плюс nginx будет > постоянно занят gzipованием попавших в > кэш страниц для отдачи клиентам с > поддержкой кэширования. > то что выше - не читал, лениво. -- br, Denis F. Latypoff. From a.vasilishin на kpi.ua Tue Dec 6 13:44:58 2011 From: a.vasilishin на kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Tue, 06 Dec 2011 15:44:58 +0200 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <20111206131130.GE31845@apache.rbscorp.ru> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <20111206131130.GE31845@apache.rbscorp.ru> Message-ID: <4EDE1C5A.9070505@kpi.ua> 06.12.2011 15:11, Dmitry E. Oboukhov пишет: >> Здравствуйте. >> Подскажите пожалуйста, в случае >> подключения репозитория к Debian, все >> нормально работает, но нет gpg ключа, >> из-за этого apt ругается, что нельзя >> проверить источник. Подскажите, gpg ключ >> вообще существует, для >> http://nginx.org/packages/debian/? Просто я облазил >> весь сайт, но его так и не нашел. >> Если есть, дайте пожалуйста ссылку на >> него. >> Заранее спасибо. > > А чем не устраивает nginx из Debian'овского репозитария? > Мея, например, не устраивает его наполнение, есть 3 версии, и только в extras есть то что мне надо + куча всего third party сомнительного качества, что не надо. Поэтому я делаю свой пакет с блекджеком и ... -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From mdounin на mdounin.ru Tue Dec 6 14:06:25 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Dec 2011 18:06:25 +0400 Subject: =?UTF-8?B?UmU6ICRodHRwIEFjY2VwdC1FbmNvZGluZyDQv9GA0LXQstGA0LDRidCw0LXRgtGB?= =?UTF-8?B?0Y8g0LIgJGh0dHAgQWNjZXB0?= In-Reply-To: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> References: <97fd1c9e0a860e45080736c9067cc5b8.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111206140624.GH67687@mdounin.ru> Hello! On Tue, Dec 06, 2011 at 08:11:08AM -0500, nikolayb wrote: > Здравствуйте, господа! > > Я изучаю nginx и пробую настроить > кэширование бэкенда на Amiro.CMS. Среди > прочих проблем столкнулся с > кэшированием gzip-контента и отдачей его > клиенту не поддерживающему сжатие. > > В топике > http://forum.nginx.org/read.php?21,158471,158471#msg-158471 было > предложено (1) добавить в ключ кэша > $http_Accept-Encoding, Переменная называется $http_accept_encoding. > Сысоев предложил > отключить вовсе gzip на бэкенде и > оставить на совесть nginx (2). Это более правильный вариант. При добавлении в ключ Accept-Encoding'а у вас в кеше будет масса вариантов закешированных страниц, по количеству вариаций написания содержимого заголовка Accept-Encoding различными браузерами. [...] > 2. Если отключить gzip на бэкенде удалив > заголовок с помощью proxy_set_header Accept-Encoding > "", то в кэш будут падать страницы > полновесные, и это существенно > увеличит размер кэша, плюс nginx будет > постоянно занят gzipованием попавших в > кэш страниц для отдачи клиентам с > поддержкой кэширования. Если хочется поэкономить, то можно развернуть ситуацию в обратную сторону: на бекенд всегда отпралять "Accept-Encoding: gzip" (и хранить в кеше сжатые ответы), а при необходимости их разжимать. proxy_set_header Accept-Encoding "gzip"; gunzip on; http://mdounin.ru/hg/ngx_http_gunzip_filter_module README где-то тут: http://mdounin.ru/hg/ngx_http_gunzip_filter_module/file/tip/README Maxim Dounin From nginx-forum на nginx.us Tue Dec 6 14:47:07 2011 From: nginx-forum на nginx.us (nikolayb) Date: Tue, 06 Dec 2011 09:47:07 -0500 Subject: =?UTF-8?B?UmU6ICRodHRwIEFjY2VwdC1FbmNvZGluZyDQv9GA0LXQstGA0LDRidCw0LXRgtGB?= =?UTF-8?B?0Y8g0LIgJGh0dHAgQWNjZXB0?= In-Reply-To: <20111206140624.GH67687@mdounin.ru> References: <20111206140624.GH67687@mdounin.ru> Message-ID: <61b38cb7e3e6c24fc5df6616bf2234d9.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > Переменная называется > $http_accept_encoding. === Nginx не обращает внимание на регистр: nginx.conf: proxy_cache_key "BASE $request_method|$http_if_modified_since|$http_if_none_match|$http_accept-encoding|$host|$uri$is_args$args"; кэш: KEY: BASE GET|||*/*-encoding|www.site.ru|/katalog/products/aksessuary KEY: BASE GET|||text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8-encoding|www.site.ru|/ KEY: BASE GET|||text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8-encoding|www.site.ru|/katalog/products/striralnye-mashiny > Если хочется поэкономить, > то можно развернуть > ситуацию в обратную > сторону: на бекенд всегда > отпралять "Accept-Encoding: gzip" (и > хранить в кеше сжатые > ответы), а при > необходимости их > разжимать. > > proxy_set_header Accept-Encoding "gzip"; > gunzip on; > > http://mdounin.ru/hg/ngx_http_gunzip_filter_module > > README где-то тут: > http://mdounin.ru/hg/ngx_http_gunzip_filter_module > /file/tip/README === Спасибо, почитаю. В первой версии кеширования, видимо придётся отказаться от gzip бэкендом... Но нужна конечно статистика. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219707,219708#msg-219708 From nginx-forum на nginx.us Tue Dec 6 14:53:03 2011 From: nginx-forum на nginx.us (nikolayb) Date: Tue, 06 Dec 2011 09:53:03 -0500 Subject: =?UTF-8?B?UmU6ICRodHRwIEFjY2VwdC1FbmNvZGluZyDQv9GA0LXQstGA0LDRidCw0LXRgtGB?= =?UTF-8?B?0Y8g0LIgJGh0dHAgQWNjZXB0?= In-Reply-To: <20111206140624.GH67687@mdounin.ru> References: <20111206140624.GH67687@mdounin.ru> Message-ID: <4c938e9f2ce40d4ed49945d02a389835.NginxMailingListRussian@forum.nginx.org> Кажется нашел баг у себя, извините $http_accept_encoding а не $http_accept-encoding Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219707,219709#msg-219709 From postmaster на softsearch.ru Tue Dec 6 15:07:18 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 6 Dec 2011 19:07:18 +0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0YDQsNCx0L7RgtGLIGxvY2F0aW9u?= In-Reply-To: <4EDE1BB3.50501@kpi.ua> References: <4EDE1BB3.50501@kpi.ua> Message-ID: <1483331074.20111206190718@softsearch.ru> Здравствуйте, Андрей. > Что будет быстрее работать куча location video1, video2 ... > location /video1 { > или один > location ^ /(video1|video2|video3) { > Спрашиваю, потому что судя по дебаг-логу, каждый запрос сравнивается со > всеми локейшинами и потом выбирается правильный, может легче один с > регексом написать и конфиг короче будет и сравнивать меньше? При отдаче видео, поиск нужного локейшна никакой роли не сыграет. У Вас всё упрётся скорее в диски, а не процессор. Но вообще много локейнов сработает быстрее, чем один с регэкспом. -- С уважением, Михаил mailto:postmaster на softsearch.ru From anton.vorobev на gmail.com Tue Dec 6 16:08:56 2011 From: anton.vorobev на gmail.com (Anton Vorobev) Date: Tue, 6 Dec 2011 17:08:56 +0100 Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQvdC+INC/0YDQviB2YWxpZCDRgyByZXNvbHZlcg==?= Message-ID: Здравствуйте. Возникла проблема, не могу докопаться до сути. Пробую новый параметр "valid" для "resolver": ... http { resolver 111.222.333.444 valid=10s; ... server { ... location / { proxy_pass http://backend.test:8885; } ... } ... } При изменении DNS записи, nginx не пытается получить IP ни через интервал, установленный в valid, ни через TTL, полученный от DNS сервера.Судя по tcpdump, nginx получает IP бэкенда только при старте. Не могу понять в чём дело, сломал всю голобу. Удалось добраться только до того, что u->resolved == NULL в ngx_http_upstream_init_request(). Кто-нибудь уже использовал valid? Есть идеи в чём дело? Заранее, Спасибо. Антон. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Dec 6 16:17:59 2011 From: chipitsine на gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 6 Dec 2011 22:17:59 +0600 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: <29a1c02ce0a0ee8643854e8f4a190103.NginxMailingListRussian@forum.nginx.org> References: <4ED7BBFC.7020209@amhost.net> <29a1c02ce0a0ee8643854e8f4a190103.NginxMailingListRussian@forum.nginx.org> Message-ID: силами приложения логично было бы неплохо уметь при необходимости отключать conntrack, что-то тиа setrlimit :-) 2 декабря 2011 г. 6:03 пользователь INF[SZ] написал: > Alex Vorona Wrote: > ------------------------------------------------------- >> А зачем conntrack'ать коннекты к >> 80-му порту? -j NOTRACK в raw table и >> все счастливы? > > Это понятно, я пытался понять возможно > ли выкрутиться средствами приложения. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219451#msg-219451 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ru на nginx.com Tue Dec 6 16:25:53 2011 From: ru на nginx.com (Ruslan Ermilov) Date: Tue, 6 Dec 2011 20:25:53 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QviDQv9GA0L4gdmFsaWQg0YMgcmVzb2x2ZXI=?= In-Reply-To: References: Message-ID: <20111206162553.GB46828@lo0.su> On Tue, Dec 06, 2011 at 05:08:56PM +0100, Anton Vorobev wrote: > Здравствуйте. > Возникла проблема, не могу докопаться до сути. Пробую новый параметр "valid" для "resolver": > > ... > http { > resolver 111.222.333.444 valid=10s; > ... > server { > > ... > location / { > proxy_pass [1]http://backend.test:8885; > } > ... > } > ... > } > > При изменении DNS записи, nginx не пытается получить IP ни через интервал, установленный в valid, ни через TTL, полученный от DNS сервера.Судя по tcpdump, nginx получает IP бэкенда только при старте. > > Не могу понять в чём дело, сломал всю голобу. Удалось добраться только до того, что u->resolved == NULL в ngx_http_upstream_init_request(). > Кто-нибудь уже использовал valid? Есть идеи в чём дело? Этот resolver работает если имя upstream сервера содержит переменные, иначе резолвинг происходит лишь на старте. Если хочется динамичности со статическим именем, следует имя сервера поместить в переменную, и использовать её в качестве аргумента директивы proxy_pass. From mdounin на mdounin.ru Tue Dec 6 16:23:36 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Dec 2011 20:23:36 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QviDQv9GA0L4gdmFsaWQg0YMgcmVzb2x2ZXI=?= In-Reply-To: References: Message-ID: <20111206162336.GI67687@mdounin.ru> Hello! On Tue, Dec 06, 2011 at 05:08:56PM +0100, Anton Vorobev wrote: > Здравствуйте. > Возникла проблема, не могу докопаться до сути. Пробую новый параметр > "valid" для "resolver": > > ... > http { > resolver 111.222.333.444 valid=10s; > ... > server { > ... > location / { > proxy_pass http://backend.test:8885; > } > ... > } > ... > } > > > > При изменении DNS записи, nginx не пытается получить IP ни через > интервал, установленный в valid, ни через TTL, полученный от DNS > сервера.Судя по tcpdump, nginx получает IP бэкенда только при старте. > Не могу понять в чём дело, сломал всю голобу. Удалось добраться только > до того, что u->resolved == NULL в ngx_http_upstream_init_request(). > Кто-нибудь уже использовал valid? Есть идеи в чём дело? Resolver используется только в том случае, если используется proxy_pass с переменными и имя сервера на старте [может быть] неизвестно. Если proxy_pass без переменных, и соответственно имя сервера известно на старте, nginx на старте же сделает gethostbyname() и будет использовать полученные ip-адреса до следующей переконфигурации. Если очень надо, чтобы nginx всегда ходил в DNS, то можно сделать так: resolver ... location / { set $nop ""; proxy_pass http://backend.test:8885$nop; } Maxim Dounin From anton.vorobev на gmail.com Tue Dec 6 16:32:44 2011 From: anton.vorobev на gmail.com (Anton Vorobev) Date: Tue, 6 Dec 2011 17:32:44 +0100 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QviDQv9GA0L4gdmFsaWQg0YMgcmVzb2x2ZXI=?= In-Reply-To: <20111206162336.GI67687@mdounin.ru> References: <20111206162336.GI67687@mdounin.ru> Message-ID: Спасибо! Присвоил имя сервера переменной, всё работает как часы. Антон. 2011/12/6 Maxim Dounin > Resolver используется только в том случае, если используется > proxy_pass с переменными и имя сервера на старте [может быть] > неизвестно. > > Если proxy_pass без переменных, и соответственно имя сервера > известно на старте, nginx на старте же сделает gethostbyname() и > будет использовать полученные ip-адреса до следующей > переконфигурации. > > Если очень надо, чтобы nginx всегда ходил в DNS, то можно сделать > так: > > resolver ... > > location / { > set $nop ""; > proxy_pass http://backend.test:8885$nop; > } > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From anton.vorobev на gmail.com Tue Dec 6 16:56:26 2011 From: anton.vorobev на gmail.com (Anton Vorobev) Date: Tue, 6 Dec 2011 17:56:26 +0100 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QviDQv9GA0L4gdmFsaWQg0YMgcmVzb2x2ZXI=?= In-Reply-To: <20111206162336.GI67687@mdounin.ru> References: <20111206162336.GI67687@mdounin.ru> Message-ID: Еще вопрос на ту же тему: Как быть, если backend надо использовать в upstream? resolver ... upstream upstrm { server backend.test:885; } location / { proxy_pass http://upstrm; } Заранее спасибо. Антон. 2011/12/6 Maxim Dounin > Hello! > Resolver используется только в том случае, если используется > proxy_pass с переменными и имя сервера на старте [может быть] > неизвестно. > > Если proxy_pass без переменных, и соответственно имя сервера > известно на старте, nginx на старте же сделает gethostbyname() и > будет использовать полученные ip-адреса до следующей > переконфигурации. > > Если очень надо, чтобы nginx всегда ходил в DNS, то можно сделать > так: > > resolver ... > > location / { > set $nop ""; > proxy_pass http://backend.test:8885$nop; > } > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From a.vasilishin на kpi.ua Tue Dec 6 17:01:45 2011 From: a.vasilishin на kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Tue, 06 Dec 2011 19:01:45 +0200 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0YDQsNCx0L7RgtGLIGxvY2F0aW9u?= In-Reply-To: <1483331074.20111206190718@softsearch.ru> References: <4EDE1BB3.50501@kpi.ua> <1483331074.20111206190718@softsearch.ru> Message-ID: <4EDE4A79.5060701@kpi.ua> 06.12.2011 17:07, Михаил Монашёв пишет: > Здравствуйте, Андрей. > >> Что будет быстрее работать куча location video1, video2 ... >> location /video1 { > > > >> или один > >> location ^ /(video1|video2|video3) { > > >> Спрашиваю, потому что судя по дебаг-логу, каждый запрос сравнивается со >> всеми локейшинами и потом выбирается правильный, может легче один с >> регексом написать и конфиг короче будет и сравнивать меньше? > > При отдаче видео, поиск нужного локейшна никакой роли не сыграет. У > Вас всё упрётся скорее в диски, а не процессор. > > Но вообще много локейнов сработает быстрее, чем один с регэкспом. > > Спасибо за ответ, про диски - знаем. -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From mdounin на mdounin.ru Tue Dec 6 17:11:56 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Dec 2011 21:11:56 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3QviDQv9GA0L4gdmFsaWQg0YMgcmVzb2x2ZXI=?= In-Reply-To: References: <20111206162336.GI67687@mdounin.ru> Message-ID: <20111206171155.GO67687@mdounin.ru> Hello! On Tue, Dec 06, 2011 at 05:56:26PM +0100, Anton Vorobev wrote: > Еще вопрос на ту же тему: > > Как быть, если backend надо использовать в upstream? > > resolver ... > > upstream upstrm { > server backend.test:885; > } > > location / { > proxy_pass http://upstrm; > } > > > Заранее спасибо. Никак. Maxim Dounin > > Антон. > > > 2011/12/6 Maxim Dounin > > > Hello! > > Resolver используется только в том случае, если используется > > proxy_pass с переменными и имя сервера на старте [может быть] > > неизвестно. > > > > Если proxy_pass без переменных, и соответственно имя сервера > > известно на старте, nginx на старте же сделает gethostbyname() и > > будет использовать полученные ip-адреса до следующей > > переконфигурации. > > > > Если очень надо, чтобы nginx всегда ходил в DNS, то можно сделать > > так: > > > > resolver ... > > > > location / { > > set $nop ""; > > proxy_pass http://backend.test:8885$nop; > > } > > > > Maxim Dounin > > > > _______________________________________________ > > 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 mdounin на mdounin.ru Tue Dec 6 17:20:27 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Dec 2011 21:20:27 +0400 Subject: =?UTF-8?B?UmU6IEZlYXR1cmUgcmVxdWVzdDogbGltaXQgY29ubiDQvdC1INGF0LLQsNGC0LA=?= =?UTF-8?B?0LXRgiDQvtC/0YbQuNC4INGB0LHRgNC+0YHQsCDRgdC+0LXQtNC40L3QtdC9?= =?UTF-8?B?0LjRjw==?= In-Reply-To: References: <4ED7BBFC.7020209@amhost.net> <29a1c02ce0a0ee8643854e8f4a190103.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111206172027.GP67687@mdounin.ru> Hello! On Tue, Dec 06, 2011 at 10:17:59PM +0600, Илья Шипицин wrote: > силами приложения логично было бы неплохо уметь при необходимости > отключать conntrack, что-то тиа setrlimit :-) Кнопка нужна, кнопка. Всё остальное - полумеры. ;) Maxim Dounin > > 2 декабря 2011 г. 6:03 пользователь INF[SZ] написал: > > Alex Vorona Wrote: > > ------------------------------------------------------- > >> А зачем conntrack'ать коннекты к > >> 80-му порту? -j NOTRACK в raw table и > >> все счастливы? > > > > Это понятно, я пытался понять возможно > > ли выкрутиться средствами приложения. > > > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219406,219451#msg-219451 > > > > _______________________________________________ > > 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 nginx-forum на nginx.us Tue Dec 6 18:57:35 2011 From: nginx-forum на nginx.us (Craken) Date: Tue, 06 Dec 2011 13:57:35 -0500 Subject: =?UTF-8?B?UmU6IGJhc2ljINCw0LLRgtC+0YDQuNC30LDRhtC40Y8g0L3QtSDRgNCw0LHQvtGC?= =?UTF-8?B?0LDQtdGCIHBocA==?= In-Reply-To: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> References: <4cd282ace596e6f5278e8f313fad5d4a.NginxMailingListRussian@forum.nginx.org> Message-ID: ммм... а с помощью nginx'a Вы по другому вроде как и не запустите! Ну разве что у Вас на бэкенде будет что-то типа апача! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219645,219727#msg-219727 From unera на uvw.ru Tue Dec 6 19:05:34 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Tue, 6 Dec 2011 23:05:34 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <4EDE1C5A.9070505@kpi.ua> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <20111206131130.GE31845@apache.rbscorp.ru> <4EDE1C5A.9070505@kpi.ua> Message-ID: <20111206190534.GI31845@apache.rbscorp.ru> >>> Здравствуйте. >>> Подскажите пожалуйста, в случае >>> подключения репозитория к Debian, все >>> нормально работает, но нет gpg ключа, >>> из-за этого apt ругается, что нельзя >>> проверить источник. Подскажите, gpg ключ >>> вообще существует, для >>> http://nginx.org/packages/debian/? Просто я облазил >>> весь сайт, но его так и не нашел. >>> Если есть, дайте пожалуйста ссылку на >>> него. >>> Заранее спасибо. >> >> А чем не устраивает nginx из Debian'овского репозитария? >> > Мея, например, не устраивает его наполнение, есть 3 версии, и только > в extras есть то что мне надо у меня на пяти хостах стоит лайт на одном full и только на одном (+ одном тестовом) extras. > + куча всего third party сомнительного > качества, что не надо. Поэтому я делаю свой пакет с блекджеком и ... в extras не включено что-то что должно быть включено в full? напишите репорт если так. или речь идет о сторонних модулях? два модуля (chunkin и headers) я добавлял: мы тут с яндексовыми сервисами работаем и они на чанки колотят запросы. к сожалению без third-party nginx с чанками не умеет работать :( а другие модули какие мешают? я просто майнтеню его в Debian. потому интересно -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From a.vasilishin на kpi.ua Tue Dec 6 19:28:06 2011 From: a.vasilishin на kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Tue, 06 Dec 2011 21:28:06 +0200 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <20111206190534.GI31845@apache.rbscorp.ru> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <20111206131130.GE31845@apache.rbscorp.ru> <4EDE1C5A.9070505@kpi.ua> <20111206190534.GI31845@apache.rbscorp.ru> Message-ID: <4EDE6CC6.2090207@kpi.ua> 06.12.2011 21:05, Dmitry E. Oboukhov пишет: >>>> Здравствуйте. >>>> Подскажите пожалуйста, в случае >>>> подключения репозитория к Debian, все >>>> нормально работает, но нет gpg ключа, >>>> из-за этого apt ругается, что нельзя >>>> проверить источник. Подскажите, gpg ключ >>>> вообще существует, для >>>> http://nginx.org/packages/debian/? Просто я облазил >>>> весь сайт, но его так и не нашел. >>>> Если есть, дайте пожалуйста ссылку на >>>> него. >>>> Заранее спасибо. >>> >>> А чем не устраивает nginx из Debian'овского репозитария? >>> > >> Мея, например, не устраивает его наполнение, есть 3 версии, и только >> в extras есть то что мне надо > у меня на пяти хостах стоит лайт > > на одном full и только на одном (+ одном тестовом) extras. > >> + куча всего third party сомнительного >> качества, что не надо. Поэтому я делаю свой пакет с блекджеком и ... > > > в extras не включено что-то что должно быть включено в full? напишите > репорт если так. или речь идет о сторонних модулях? Не поверите, но писал http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613175 > > два модуля (chunkin и headers) я добавлял: мы тут с яндексовыми > сервисами работаем и они на чанки колотят запросы. к сожалению без > third-party nginx с чанками не умеет работать :( > > а другие модули какие мешают? > > я просто майнтеню его в Debian. потому интересно > например, http push, у меня в конфиге про него ни слова, а вот в ерор лог частенько попадали от него сообщения, да и расход памяти на графиках заметен при в нативном nginx-extras где-то на гиг памяти больше чем при моем, собранном с дебиановских сорцов, но без всего лишнего. Вот что использую я: # nginx -V nginx: nginx version: nginx/1.1.3 nginx: configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-file-aio --with-http_flv_module --with-http_mp4_module --with-http_geoip_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --without-http_memcached_module --without-http_scgi_module --without-http_split_clients_module --without-http_uwsgi_module -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From unera на uvw.ru Tue Dec 6 19:52:38 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Tue, 6 Dec 2011 23:52:38 +0400 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <4EDE6CC6.2090207@kpi.ua> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <20111206131130.GE31845@apache.rbscorp.ru> <4EDE1C5A.9070505@kpi.ua> <20111206190534.GI31845@apache.rbscorp.ru> <4EDE6CC6.2090207@kpi.ua> Message-ID: <20111206195237.GL31845@apache.rbscorp.ru> >> в extras не включено что-то что должно быть включено в full? напишите >> репорт если так. или речь идет о сторонних модулях? > Не поверите, но писал > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613175 ну опции которые нельзя отключить логично не включать. я бы на вашем месте попросил собрать еще один пакет -full-что-то там кроме aio есть еще что включить в таком пакете? >> >> два модуля (chunkin и headers) я добавлял: мы тут с яндексовыми >> сервисами работаем и они на чанки колотят запросы. к сожалению без >> third-party nginx с чанками не умеет работать :( >> >> а другие модули какие мешают? >> >> я просто майнтеню его в Debian. потому интересно >> > например, http push, у меня в конфиге про него ни слова, а вот в > ерор лог частенько попадали от него сообщения, да и расход памяти на > графиках заметен при в нативном nginx-extras где-то на гиг памяти > больше чем при моем, собранном с дебиановских сорцов, но без всего > лишнего. Вот что использую я: ну вообще если заводить разговор то собирать nginx без third-party однозначно стоит причем возможно в нескольких инкарнациях. только вопрос в скольки. Вы там писали что хотите попробовать aio. > I just want to test aio. дает aio что-то хорошее на системе с медленным hdd? а вообще конечно, если речь идет о хайлоаде то возможно стоит играть опциями на нем. но надо понимать что если речь идет о дистрибутиве то тут опции будут выбираться исходя из *возможно кажущегося* более широкого охвата аудитории. и будет борьба включать - не включать. хотя если вернуться к хайлоадам если игра уже идет о опциях то возможно все-таки флопсы дешевле трудов по пересборке? я соответственно когда мне модули понадобились влез к ним в комайнтенеры по принципу "мне надо вот эту фичу, я ее возьмусь майнтенить", вполне можно этот путь повторять :) -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From a.vasilishin на kpi.ua Tue Dec 6 20:11:26 2011 From: a.vasilishin на kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Tue, 06 Dec 2011 22:11:26 +0200 Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INGA0LXQv9C+0LfQuNGC0L4=?= =?UTF-8?B?0YDQuNGPIG5naW54INCyIERlYmlhbi9VYnVudHUg0LggZ3BnINC60LvRjtGH?= =?UTF-8?B?Lg==?= In-Reply-To: <20111206195237.GL31845@apache.rbscorp.ru> References: <425c9b1e4f35b2b309b564de7a74f95d.NginxMailingListRussian@forum.nginx.org> <20111206131130.GE31845@apache.rbscorp.ru> <4EDE1C5A.9070505@kpi.ua> <20111206190534.GI31845@apache.rbscorp.ru> <4EDE6CC6.2090207@kpi.ua> <20111206195237.GL31845@apache.rbscorp.ru> Message-ID: <4EDE76EE.8090303@kpi.ua> 06.12.2011 21:52, Dmitry E. Oboukhov пишет: >>> в extras не включено что-то что должно быть включено в full? напишите >>> репорт если так. или речь идет о сторонних модулях? > >> Не поверите, но писал >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613175 > > ну опции которые нельзя отключить логично не включать. я бы на вашем > месте попросил собрать еще один пакет -full-что-то там > > кроме aio есть еще что включить в таком пакете? > Ну, как Вы могли понять, нгинкс используется для видеостримминга. То есть надо flv, mp4 и aio. >>> два модуля (chunkin и headers) я добавлял: мы тут с яндексовыми >>> сервисами работаем и они на чанки колотят запросы. к сожалению без >>> third-party nginx с чанками не умеет работать :( >>> >>> а другие модули какие мешают? >>> >>> я просто майнтеню его в Debian. потому интересно >>> > >> например, http push, у меня в конфиге про него ни слова, а вот в >> ерор лог частенько попадали от него сообщения, да и расход памяти на >> графиках заметен при нативном nginx-extras где-то на гиг памяти >> больше чем при моем, собранном с дебиановских сорцов, но без всего >> лишнего. Вот что использую я: > > ну вообще если заводить разговор то собирать nginx без third-party > однозначно стоит причем возможно в нескольких инкарнациях. только > вопрос в скольки. Я предлагал там сделать на подобии фри, менюшку, в которой можно выбрать что тебе надо и потом скомпилится модуль, не знаю правда как это к apt привязать. > Вы там писали что хотите попробовать aio. > >> I just want to test aio. > > дает aio что-то хорошее на системе с медленным hdd? > Да, дает, у меня есть сервера и с аио и без него и комбинацией с/без. > а вообще конечно, если речь идет о хайлоаде то возможно стоит играть > опциями на нем. но надо понимать что если речь идет о дистрибутиве то > тут опции будут выбираться исходя из *возможно кажущегося* более > широкого охвата аудитории. и будет борьба включать - не включать. Согласен, именно поэтому и решил свой собрать, мало кому понадобится именно такой набор. > хотя если вернуться к хайлоадам если игра уже идет о опциях то > возможно все-таки флопсы дешевле трудов по пересборке? Как сказать, как сказать, пересобрать в принципе не сложно, 5 минут времени, зато исключаются возможные проблемы от third-party > я соответственно когда мне модули понадобились влез к ним в > комайнтенеры по принципу "мне надо вот эту фичу, я ее возьмусь > майнтенить", вполне можно этот путь повторять :) Тоже хотел одно время, даже мануал для мантайнеров начал читать, но потом как-то времени стало не так много, вот даже застрял на версии 1.1.3, хоть и с накатанными патчами, которые в 1.1.4 вошли. -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From nginx-forum на nginx.us Tue Dec 6 22:45:10 2011 From: nginx-forum на nginx.us (alex_ru) Date: Tue, 06 Dec 2011 17:45:10 -0500 Subject: =?UTF-8?B?UmU6INGB0LHQvtGA0LrQsCBjIHdpdGgtaHR0cCBpbWFnZSBmaWx0ZXIgbW9kdWxl?= In-Reply-To: References: Message-ID: Покопавшись в конфиге обнаружил, что под виндовс конфигрурация не написана. Моих скромных знаний С не хватает, что бы дописать эту штуку (покрайней мере пока). Подскажите хотя бы, есть ли вообще возможность реализовать данную вещь под виндовс или прийдется ставить unix? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,212832,219734#msg-219734 From roman.vasilyev на yousendit.com Tue Dec 6 23:53:32 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Tue, 6 Dec 2011 15:53:32 -0800 Subject: =?UTF-8?B?0L/QsNGA0LDQvNC10YLRgNGLINC00LvRjyBwb3N0X2FjdGlvbg==?= Message-ID: <4EDEAAFC.5020907@yousendit.com> Следующая проблемка, кусок конфига location /download { rewrite ^ /uwsgi/download.py last; location /download/storage/ { internal; alias /$1; post_action /uwsgi/last.py; } } download определяет положение файла из python скрипта с помощью "X-Accel-Redirect" нужно дернуть post_action с параметрами файла? наткнулся на следующее поведение, когда дописываю вопрос в параметре post_action скрипт вообще прекращает вызываться, не посоветуете как туда передать дополнительные параметры? тоесть нужно написать нечто вроде post_action /uwsgi/last.py?file=$1; # /usr/sbin/nginx -V nginx version: nginx/1.1.8 built by gcc 4.1.2 20080704 (Red Hat 4.1.2-51) TLS SNI support disabled configure arguments: --with-debug --user=fileservices --group=fileservices --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/fileservices/tmp/client_body --http-proxy-temp-path=/var/lib/fileservices/tmp/proxy --http-fastcgi-temp-path=/var/lib/fileservices/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --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-mail --with-mail_ssl_module --with-http_secure_link_module --with-http_random_index_module --with-http_xslt_module --with-cc-opt='-O2 -g -m64 -mtune=generic' --add-module=../src/ngx_http_body_size_module --add-module=../src/ngx_subrequest_module --add-module=/root/work/nginx/branches/1.1.8/BUILD/nginx-1.1.8/vkholodkov-nginx-upload-module-8d271b1 From roman.vasilyev на yousendit.com Wed Dec 7 00:16:13 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Tue, 6 Dec 2011 16:16:13 -0800 Subject: =?UTF-8?B?UmU6INC/0LDRgNCw0LzQtdGC0YDRiyDQtNC70Y8gcG9zdF9hY3Rpb24=?= In-Reply-To: <4EDEAAFC.5020907@yousendit.com> References: <4EDEAAFC.5020907@yousendit.com> Message-ID: <4EDEB04D.7090202@yousendit.com> я так понимаю это единственный метод :( как то коряво получается :( http://abarmotik.livejournal.com/7496.html # В этот локейшн переходим по хедеру X-Accel-Redirect от бэк-енда. # (предполагается, что все раздаваемые файлы лежат в папке /storage) location /storage { set $postURI $uri; set $postIP $remote_addr; set $postHOST $host; post_action @postDownload; root /; internal; } location @postDownload { proxy_pass http://127.0.0.1:8888/nginxds/postDownload?domain=$postHOST&uri=$postURI; proxy_set_header X-Real-IP $postIP; proxy_set_header BytesSent $body_bytes_sent; } On 12/06/2011 03:53 PM, Roman Vasilyev wrote: > Следующая проблемка, кусок конфига > location /download { > rewrite ^ /uwsgi/download.py last; > location /download/storage/ { > internal; > alias /$1; > post_action /uwsgi/last.py; > } > } > download определяет положение файла из python скрипта с помощью > "X-Accel-Redirect" > > нужно дернуть post_action с параметрами файла? наткнулся на следующее > поведение, когда дописываю вопрос в параметре post_action скрипт > вообще прекращает вызываться, не посоветуете как туда передать > дополнительные параметры? > тоесть нужно написать нечто вроде post_action /uwsgi/last.py?file=$1; > > # /usr/sbin/nginx -V > nginx version: nginx/1.1.8 > built by gcc 4.1.2 20080704 (Red Hat 4.1.2-51) > TLS SNI support disabled > configure arguments: --with-debug --user=fileservices > --group=fileservices --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/fileservices/tmp/client_body > --http-proxy-temp-path=/var/lib/fileservices/tmp/proxy > --http-fastcgi-temp-path=/var/lib/fileservices/tmp/fastcgi > --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx > --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-mail --with-mail_ssl_module > --with-http_secure_link_module --with-http_random_index_module > --with-http_xslt_module --with-cc-opt='-O2 -g -m64 -mtune=generic' > --add-module=../src/ngx_http_body_size_module > --add-module=../src/ngx_subrequest_module > --add-module=/root/work/nginx/branches/1.1.8/BUILD/nginx-1.1.8/vkholodkov-nginx-upload-module-8d271b1 > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на nginx.us Wed Dec 7 07:00:49 2011 From: nginx-forum на nginx.us (crashX) Date: Wed, 07 Dec 2011 02:00:49 -0500 Subject: =?UTF-8?B?bmdpbngg0Lgg0L3QtdGB0YLQsNC90LTQsNGA0YLQvdGL0Lkg0L/QvtGA0YI=?= Message-ID: <2098698e8b4bdf8d63c4984f2ece462e.NginxMailingListRussian@forum.nginx.org> у меня на linux установлен nginx и висит он на 8082 порту, для локального использования. для внешки сделан проброс на 80 порт. все работает. но вот незадача, если попытаться зайти из внешки в любую директорию на http://my_ip/any_dir, то соединения не происходит и в строке адреса появляется внутрений порт (http://my_ip:8082/any_dir). если убрать порт - все работает как и должно. вопрос в том, как сделать чтобы внутренний порт не появлялся в строке. заранее благодарен. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219747,219747#msg-219747 From ano на bestmx.ru Wed Dec 7 08:42:13 2011 From: ano на bestmx.ru (Andrey N. Oktyabrski) Date: Wed, 07 Dec 2011 11:42:13 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC4INC90LXRgdGC0LDQvdC00LDRgNGC0L3Ri9C5INC/0L7RgNGC?= In-Reply-To: <2098698e8b4bdf8d63c4984f2ece462e.NginxMailingListRussian@forum.nginx.org> References: <2098698e8b4bdf8d63c4984f2ece462e.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EDF26E5.7010508@bestmx.ru> On 07.12.11 10:00, crashX wrote: > у меня на linux установлен nginx и висит он на 8082 порту, для > локального использования. для внешки сделан проброс на 80 порт. все > работает. но вот незадача, если попытаться зайти из внешки в любую > директорию на http://my_ip/any_dir, то соединения не происходит и в > строке адреса появляется внутрений порт (http://my_ip:8082/any_dir). > если убрать порт - все работает как и должно. вопрос в том, как > сделать чтобы внутренний порт не появлялся в строке. заранее > благодарен. Пальцем в небо: http://nginx.org/ru/docs/http/ngx_http_core_module.html#port_in_redirect Если не оно, описывайте конфигурацию, иначе ответа не получите. From dado на korolev-net.ru Wed Dec 7 07:44:35 2011 From: dado на korolev-net.ru (Evgenii Davidov) Date: Wed, 7 Dec 2011 11:44:35 +0400 Subject: out of tcptw Message-ID: <20111207074435.GA13485@korolev-net.ru> товарищи ученые вчера я на 5 минут выбежал из tcptw: ITEM SIZE LIMIT USED FREE REQUESTS FAILURES tcptw: 52, 40968, 11922, 22638, 47803752, 0 tcptw: 52, 40968, 31451, 3109, 47835019, 0 tcptw: 52, 40968, 39130, 686, 47873887, 0 tcptw: 52, 40968, 40335, 633, 47889337, 26837 tcptw: 52, 40968, 40397, 571, 47889399, 69815 tcptw: 52, 40968, 40465, 503, 47889471, 112430 tcptw: 52, 40968, 40522, 446, 47889530, 153805 tcptw: 52, 40968, 35654, 5314, 47904332, 173111 tcptw: 52, 40968, 27982, 12986, 47932049, 173111 stub status при этом показывал: Reading: 351 Writing: 50 Waiting: 6801 Reading: 649 Writing: 78 Waiting: 6502 Reading: 880 Writing: 152 Waiting: 6457 Reading: 856 Writing: 209 Waiting: 6238 Reading: 854 Writing: 167 Waiting: 6120 Reading: 579 Writing: 43 Waiting: 6421 Reading: 443 Writing: 41 Waiting: 6368 как вы думаете, правильно ли я понимаю что это произошло потому что было настроено: worker_processes 4; worker_connections 2000; и при приближении к 8000 nginx стал в срочном порядке закрывать соединения и этих закрытых соединений в состоянии протухания стало слишком много? (по моим прикидкам клиентов было тыщ 11) также было настроено sysctl net.inet.tcp.fast_finwait2_recycle=1 sysctl net.inet.tcp.finwait2_timeout=5000 за эти 5 минут успел 500 раз ругнуться named типа: client 84.53.200.24#1202: error sending response: not enough free resources 7.2-STABLE i386 nginx/1.0.2 apache: 2 requests currently being processed, 1 idle servers top -I : last pid: 16701; load averages: 1.41, 0.84, 0.58 up 24+07:33:33 01:39:00 70 processes: 2 running, 68 sleeping Mem: 606M Active, 2327M Inact, 275M Wired, 146M Cache, 112M Buf, 154M Free Swap: 8192M Total, 168K Used, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 676 football 1 4 0 110M 4784K kqread 3 376:25 28.37% nginx 677 football 1 4 0 110M 4568K kqread 3 356:35 25.59% nginx 674 football 1 4 0 110M 4276K kqread 3 294:21 13.09% nginx 675 football 1 4 0 109M 3900K kqread 0 272:31 5.76% nginx 13234 www 1 4 0 16904K 10276K accept 3 0:26 4.05% httpd 15537 www 1 4 0 17012K 10180K accept 0 0:18 3.86% httpd 15260 www 1 4 0 17776K 11124K accept 3 0:15 3.37% httpd 621 mysql 16 20 0 328M 202M kserel 3 138:41 1.56% mysqld vmstat -z : UMA Kegs: 128, 0, 82, 8, 82, 0 UMA Zones: 480, 0, 82, 6, 82, 0 UMA Slabs: 64, 0, 2719, 585, 123228, 0 UMA RCntSlabs: 104, 0, 6087, 18, 137964, 0 UMA Hash: 128, 0, 3, 27, 7, 0 16 Bucket: 76, 0, 26, 74, 111, 0 32 Bucket: 140, 0, 66, 102, 246, 0 64 Bucket: 268, 0, 43, 97, 497, 82 128 Bucket: 524, 0, 2330, 267, 167059, 16334 VM OBJECT: 128, 0, 90686, 934, 60252229, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 68, 57456, 25, 2775, 2830203, 0 MAP ENTRY: 68, 0, 1908, 3020, 266844593, 0 DP fakepg: 72, 0, 0, 212, 20, 0 mt_zone: 1032, 0, 181, 2, 181, 0 16: 16, 0, 2692, 1165, 233417157, 0 32: 32, 0, 1942, 1787, 240579919, 0 64: 64, 0, 4304, 6493, 388300570, 0 128: 128, 0, 2048, 2002, 78236147, 0 256: 256, 0, 878, 1147, 61735665, 0 512: 512, 0, 504, 1896, 41332494, 0 1024: 1024, 0, 52, 748, 43001389, 0 2048: 2048, 0, 174, 912, 10085, 0 4096: 4096, 0, 134, 701, 31993215, 0 Files: 76, 0, 8440, 660, 911860153, 0 TURNSTILE: 76, 0, 428, 148, 428, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 704, 0, 93, 157, 1514550, 0 THREAD: 572, 0, 268, 159, 928968, 0 UPCALL: 44, 0, 15, 375, 43, 0 SLEEPQUEUE: 32, 0, 428, 363, 428, 0 VMSPACE: 236, 0, 56, 200, 1514513, 0 cpuset: 40, 0, 2, 182, 2, 0 audit_record: 864, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 1359, 817, 2417792721, 0 mbuf: 256, 0, 8758, 976, 4193507441, 0 mbuf_cluster: 2048, 200000, 2176, 770, 127104, 0 mbuf_jumbo_pagesize: 4096, 12800, 4031, 583, 281822622, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 4050, 822, 568097356, 0 ACL UMA zone: 388, 0, 0, 0, 0, 0 g_bio: 132, 0, 0, 3306, 158378233, 0 ata_request: 192, 0, 0, 1700, 35106790, 0 ata_composite: 184, 0, 0, 0, 0, 0 VNODE: 276, 0, 89870, 10440, 203908212, 0 VNODEPOLL: 64, 0, 4, 173, 5, 0 S VFS Cache: 68, 0, 94941, 10003, 207282902, 0 L VFS Cache: 291, 0, 588, 2103, 4320525, 0 NAMEI: 1024, 0, 0, 656, 1813579725, 0 DIRHASH: 1024, 0, 1834, 726, 1371844, 0 pipe: 396, 0, 56, 724, 711044, 0 ksiginfo: 80, 0, 221, 115, 221, 0 itimer: 220, 0, 0, 0, 0, 0 KNOTE: 68, 0, 10633, 791, 1248327164, 0 socket: 416, 204804, 10679, 634, 132615432, 0 unpcb: 168, 204815, 79, 588, 2036358, 0 ipq: 32, 6328, 0, 565, 380793, 0 udp_inpcb: 180, 204820, 3, 217, 527580, 0 udpcb: 8, 204827, 3, 809, 527580, 0 inpcb: 180, 204820, 50932, 680, 130051395, 0 tcpcb: 464, 204800, 10597, 635, 130051395, 0 tcptw: 52, 40968, 40335, 633, 47889337, 26837 syncache: 104, 15392, 325, 748, 119415191, 0 hostcache: 76, 15400, 8969, 2081, 14104552, 0 tcpreass: 20, 12506, 1, 844, 414209, 0 sackhole: 20, 0, 55, 959, 29266551, 0 sctp_ep: 816, 25600, 0, 0, 0, 0 sctp_asoc: 1436, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 290, 2, 0 sctp_raddr: 388, 80000, 0, 0, 0, 0 sctp_chunk: 96, 400000, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 180, 204820, 0, 110, 98, 0 rtentry: 124, 0, 16, 356, 5231, 0 IPFW dynamic rule: 108, 0, 0, 0, 0, 0 SWAPMETA: 276, 121576, 24, 60, 241, 0 Mountpoints: 720, 0, 5, 10, 5, 0 FFS inode: 124, 0, 89835, 10326, 203905281, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 89835, 10275, 203905281, 0 nginx.conf: user foo www; worker_processes 4; pid /var/run/nginx.pid; events { worker_connections 2000; use kqueue; } http { proxy_temp_path /var/nginx/tmp ; proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=cache:90m max_size=90m ; proxy_cache_valid 60m; proxy_cache_min_uses 2; proxy_cache_bypass $cookie_nocache $arg_nocache $http_pragma $http_authorization $arg_f ; proxy_no_cache $cookie_nocache $arg_nocache $http_pragma $http_authorization $arg_f ; proxy_store_access user:rw group:rw all:rw; proxy_cache_use_stale error timeout invalid_header http_500 http_502 http_503 http_504; client_max_body_size 10m ; log_format combined1 '$remote_addr $server_name $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; error_log /var/log/nginx-error.log warn ; access_log /dev/null ; server_names_hash_bucket_size 128 ; include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$gzip_ratio"'; log_format download '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$http_range" "$sent_http_content_range"'; client_header_timeout 10; client_body_timeout 10; send_timeout 10; client_header_buffer_size 1k; large_client_header_buffers 4 16k; gzip on; gzip_min_length 1100; gzip_buffers 4 8k; gzip_types text/plain; output_buffers 1 32k; postpone_output 1460; sendfile on; tcp_nopush on; tcp_nodelay on; send_lowat 12000; keepalive_timeout 50 ; reset_timedout_connection on; limit_zone one $binary_remote_addr 16m; server { listen x.x.x.x:80 ; server_name bar ; location / { proxy_pass http://127.0.0.1:80/ ; limit_conn one 10; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location ~* .(jpg|jpeg|gif|png|css|js|ico)$ { root /home/wit/ ; expires 30d; } location /stub_status { stub_status on; allow x.x.x.x/32; deny all; } } server { listen x.x.x.x:80 ; server_name foo ; location / { proxy_pass http://127.0.0.1:80/ ; limit_conn one 10; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Range ""; proxy_set_header Request-Range ""; proxy_buffer_size 4k; proxy_buffers 4 128k; proxy_busy_buffers_size 256k; proxy_temp_file_write_size 256k; proxy_cache cache; expires -1 ; charset windows-1251 ; } location ^~ /buttons { root /home/foo/public_html ; expires 1h; } location ~* .(jpg|jpeg|gif|png|css|js|ico|xml|rss)$ { root /home/foo/public_html ; expires 30d; } location /stub_status { stub_status on; allow x.x.x.x/32; deny all; } } } спасибо! -- Evgenii V Davidov From nginx-forum на nginx.us Wed Dec 7 08:44:27 2011 From: nginx-forum на nginx.us (crashX) Date: Wed, 07 Dec 2011 03:44:27 -0500 Subject: =?UTF-8?B?UmU6IG5naW54INC4INC90LXRgdGC0LDQvdC00LDRgNGC0L3Ri9C5INC/0L7RgNGC?= In-Reply-To: <4EDF26E5.7010508@bestmx.ru> References: <4EDF26E5.7010508@bestmx.ru> Message-ID: <03c6a79a30c8d755240101cbeef5c9cd.NginxMailingListRussian@forum.nginx.org> большое спасибо! палецем вы попали) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219747,219754#msg-219754 From i.lobahin на nikitaonline.ru Wed Dec 7 11:24:35 2011 From: i.lobahin на nikitaonline.ru (Ilya Lobahin) Date: Wed, 7 Dec 2011 15:24:35 +0400 Subject: =?UTF-8?Q?include_=D0=B2_if-=D0=B5?= Message-ID: <171344872.20111207152435@nikitaonline.ru> Здравствуйте, коллеги. Пытаюсь сделать так: location ~ \.php$ { if ( $uri !~ "^/images/" ){ include /etc/nginx/fastcgi.conf; } } Получаю: nginx: [emerg] "include" directive is not allowed here Почему? В описании директивы контекст любой. Приходится извращаться так: location ~ \.php$ { if ( $uri !~ "^/images/" ){ fastcgi_pass 127.0.0.1:8181; # By all means use a different server for the fcgi processes if you need to } include /etc/nginx/fastcgi2.conf; } -- С уважением, Лобахин Илья Системный администратор NIKITA.ONLINE 115201, Москва, Каширское шоссе д. 22/4 строение 7 e-mail: mailto:i.lobahin на nikitaonline.ru Тел./Факс: +7 (495) 788-7936 http://www.nikitaonline.ru http://www.gamexp.ru From sytar.alex на gmail.com Wed Dec 7 11:41:43 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Wed, 7 Dec 2011 15:41:43 +0400 Subject: =?UTF-8?B?UmU6IGluY2x1ZGUg0LIgaWYt0LU=?= In-Reply-To: <171344872.20111207152435@nikitaonline.ru> References: <171344872.20111207152435@nikitaonline.ru> Message-ID: 7 декабря 2011 г. 15:24 пользователь Ilya Lobahin написал: > Здравствуйте, коллеги. > > Пытаюсь сделать так: > location ~ \.php$ { >    if ( $uri !~ "^/images/" ){ >        include /etc/nginx/fastcgi.conf; >    } > } > > Получаю: > nginx: [emerg] "include" directive is not allowed here > Почему? В описании директивы контекст любой. > > Приходится извращаться так: > location ~ \.php$ { >    if ( $uri !~ "^/images/" ){ >        fastcgi_pass   127.0.0.1:8181;  # By all means use a different server for the fcgi processes if you need to >    } >        include /etc/nginx/fastcgi2.conf; > } А почему не хотите так: location /images { ... location ~ \.php$ { fastcgi_pass   127.0.0.1:8181;  # By all means use a different server for the fcgi processes if you need to } } location ~\.php$ { include /etc/nginx/fastcgi2.conf; } From i.lobahin на nikitaonline.ru Wed Dec 7 12:00:54 2011 From: i.lobahin на nikitaonline.ru (Ilya Lobahin) Date: Wed, 7 Dec 2011 16:00:54 +0400 Subject: =?UTF-8?B?UmVbMl06IGluY2x1ZGUg0LIgaWYt0LU=?= In-Reply-To: References: <171344872.20111207152435@nikitaonline.ru> Message-ID: <1876013801.20111207160054@nikitaonline.ru> Здравствуйте, Aleksandr. Вы писали 7 декабря 2011 г., 15:41:43: >> Пытаюсь сделать так: >> location ~ \.php$ { >> if ( $uri !~ "^/images/" ){ >> include /etc/nginx/fastcgi.conf; >> } >> } >> >> Получаю: >> nginx: [emerg] "include" directive is not allowed here >> Почему? В описании директивы контекст любой. >> >> Приходится извращаться так: >> location ~ \.php$ { >> if ( $uri !~ "^/images/" ){ >> fastcgi_pass 127.0.0.1:8181; # By all means use a different server for the fcgi processes if you need to >> } >> include /etc/nginx/fastcgi2.conf; >> } > А почему не хотите так: > location /images { > ... > location ~ \.php$ { > fastcgi_pass 127.0.0.1:8181; # By all means use a different > server for the fcgi processes if you need to > } > } > location ~\.php$ { > include /etc/nginx/fastcgi2.conf; > } так писанины больше. основная цель - закрыть директории с загружаемыми картинками от выполнения php вот таким образом: /some/path/site/images/qqq.png/.php -- С уважением, Лобахин Илья Системный администратор NIKITA.ONLINE 115201, Москва, Каширское шоссе д. 22/4 строение 7 e-mail: mailto:i.lobahin на nikitaonline.ru Тел./Факс: +7 (495) 788-7936 http://www.nikitaonline.ru http://www.gamexp.ru From mdounin на mdounin.ru Wed Dec 7 15:52:57 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 7 Dec 2011 19:52:57 +0400 Subject: out of tcptw In-Reply-To: <20111207074435.GA13485@korolev-net.ru> References: <20111207074435.GA13485@korolev-net.ru> Message-ID: <20111207155257.GE67687@mdounin.ru> Hello! On Wed, Dec 07, 2011 at 11:44:35AM +0400, Evgenii Davidov wrote: > > товарищи ученые > > вчера я на 5 минут выбежал из tcptw: > > ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > tcptw: 52, 40968, 11922, 22638, 47803752, 0 > tcptw: 52, 40968, 31451, 3109, 47835019, 0 > tcptw: 52, 40968, 39130, 686, 47873887, 0 > tcptw: 52, 40968, 40335, 633, 47889337, 26837 > tcptw: 52, 40968, 40397, 571, 47889399, 69815 > tcptw: 52, 40968, 40465, 503, 47889471, 112430 > tcptw: 52, 40968, 40522, 446, 47889530, 153805 > tcptw: 52, 40968, 35654, 5314, 47904332, 173111 > tcptw: 52, 40968, 27982, 12986, 47932049, 173111 > > stub status при этом показывал: > > Reading: 351 Writing: 50 Waiting: 6801 > Reading: 649 Writing: 78 Waiting: 6502 > Reading: 880 Writing: 152 Waiting: 6457 > Reading: 856 Writing: 209 Waiting: 6238 > Reading: 854 Writing: 167 Waiting: 6120 > Reading: 579 Writing: 43 Waiting: 6421 > Reading: 443 Writing: 41 Waiting: 6368 > > как вы думаете, правильно ли я понимаю что это произошло потому что было настроено: > > worker_processes 4; > worker_connections 2000; > > и при приближении к 8000 nginx стал в срочном порядке закрывать > соединения и этих закрытых соединений в состоянии протухания > стало слишком много? Это произошло потому, что количество открываемых соединений было большое. Вообще, вылезать за tcptw - это не страшно. Ну не будет TIME_WAIT сокета, самое плохое что может случиться - это RST там, где его быть не должно. > (по моим прикидкам клиентов было тыщ 11) > > также было настроено > > sysctl net.inet.tcp.fast_finwait2_recycle=1 > sysctl net.inet.tcp.finwait2_timeout=5000 > > за эти 5 минут успел 500 раз ругнуться named типа: client 84.53.200.24#1202: error sending response: not enough free resources Это - отдельная и малосвязанная проблема (т.е. причина может быть та же самая, e.g. DoS, но никакого отношения к time_wait оно не имеет). Скорее всего - переполнялась очередь на интерфейсе, и от этого происходил ENOBUFS, смотрите netstat -nid. Maxim Dounin From hell-for-yahoo на umail.ru Wed Dec 7 21:47:23 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Thu, 8 Dec 2011 01:47:23 +0400 Subject: Feature request: limit conn не хватает опции сброса соединения In-Reply-To: <20111206172027.GP67687@mdounin.ru> References: <4ED7BBFC.7020209@amhost.net> <29a1c02ce0a0ee8643854e8f4a190103.NginxMailingListRussian@forum.nginx.org> <20111206172027.GP67687@mdounin.ru> Message-ID: <1057793004.20111208014723@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin! >> силами приложения логично было бы неплохо уметь при необходимости >> отключать conntrack, что-то тиа setrlimit :-) MD> Кнопка нужна, кнопка. Всё остальное - полумеры. ;) Дык, ыть... Есть кнопка! http://button.dekel.ru/ -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) четверг, 08.12.2011, <01:46> From dado на korolev-net.ru Wed Dec 7 22:03:51 2011 From: dado на korolev-net.ru (Evgenii Davidov) Date: Thu, 8 Dec 2011 02:03:51 +0400 Subject: out of tcptw In-Reply-To: <20111207155257.GE67687@mdounin.ru> References: <20111207074435.GA13485@korolev-net.ru> <20111207155257.GE67687@mdounin.ru> Message-ID: <20111207220351.GA68806@korolev-net.ru> Здравствуйте, On Wed, Dec 07, 2011 at 07:52:57PM +0400, Maxim Dounin пишет: > > Reading: 880 Writing: 152 Waiting: 6457 > > Это произошло потому, что количество открываемых соединений было > большое. > > > > за эти 5 минут успел 500 раз ругнуться named типа: client 84.53.200.24#1202: error sending response: not enough free resources > > Это - отдельная и малосвязанная проблема (т.е. причина может быть > та же самая, e.g. DoS, но никакого отношения к time_wait оно не > имеет). Скорее всего - переполнялась очередь на интерфейсе, и от > этого происходил ENOBUFS, смотрите netstat -nid. спасибо! (это не DoS а сайт про "футбол" -- после матча там бывает такое, например сегодня: Reading: 1605 Writing: 134 Waiting: 10070 Evgenii V Davidov From roman.vasilyev на yousendit.com Thu Dec 8 00:54:00 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Wed, 7 Dec 2011 16:54:00 -0800 Subject: =?UTF-8?B?0L/QtdGA0LXQvNC10L3QvdGL0LUg0LjQtyBIdHRwU3R1YlN0YXR1c01vZHVsZQ==?= Message-ID: <4EE00AA8.6000800@yousendit.com> Возможно ли "Reading: 6 Writing: 179 Waiting: 106" e.t.c. получить как переменные что бы потом передать их на backend? From zaabjuda на gmail.com Thu Dec 8 03:26:47 2011 From: zaabjuda на gmail.com (=?KOI8-R?B?5M3J1NLJyiD2yczYw8/X?=) Date: Thu, 8 Dec 2011 07:26:47 +0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0YDQsNCx0L7RgtGLIGxvY2F0aW9u?= In-Reply-To: <4EDE4A79.5060701@kpi.ua> References: <4EDE1BB3.50501@kpi.ua> <1483331074.20111206190718@softsearch.ru> <4EDE4A79.5060701@kpi.ua> Message-ID: Вот так будет ещё быстрее location = video1 { ...... } location = video2 { ........ } если стоит знак равно, в случае если локейшн попал под условия запроса, остальные допущены уже не проверяются. Если знак равенства не используними то проверяются каждый локейшн, и используется последний попавший под условия запроса. 06.12.2011 21:01 пользователь "Андрей Василишин" написал: > 06.12.2011 17:07, Михаил Монашёв пишет: > >> Здравствуйте, Андрей. >> >> Что будет быстрее работать куча location video1, video2 ... >>> location /video1 { >>> >> >> >> >> или один >>> >> >> location ^ /(video1|video2|video3) { >>> >> >> >> Спрашиваю, потому что судя по дебаг-логу, каждый запрос сравнивается со >>> всеми локейшинами и потом выбирается правильный, может легче один с >>> регексом написать и конфиг короче будет и сравнивать меньше? >>> >> >> При отдаче видео, поиск нужного локейшна никакой роли не сыграет. У >> Вас всё упрётся скорее в диски, а не процессор. >> >> Но вообще много локейнов сработает быстрее, чем один с регэкспом. >> >> >> > Спасибо за ответ, про диски - знаем. > > -- > WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE > > ______________________________**_________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/**mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From corochoone на gmail.com Thu Dec 8 07:33:54 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 10:33:54 +0300 Subject: =?UTF-8?B?bGltaXRfY29uLCBsaW1pdF9yZXEg0Lgg0L/RgNC+0YfQsNGPIChmZWF0dXJlIHJl?= =?UTF-8?B?cXVlc3Qp?= Message-ID: Привет всем. Тема, конечно, заезженная до безумия, но тем не менее... Да, вчера я заметил, что nginx-0.6.39 который у меня стоял неправильно работает с limit_con и плевать хотел на выставленные ограничения, да поменял я его на nginx 1.0.6 и эта проблема исчезла, зато я вдруг обратил внимание на другую. На одном из клиентских сайтов яндекс получает 503-ю, хотя стоит ограничение с одного IP в 4-штуки, а четыре яндекса на этот сайт не лезут мегастопудово. Да, наконец-то я допёр (простите за тупость), что хэш-таблица для limit_zone ОБЩАЯ НА ВСЕ ВИРТУАЛХОСТЫ, а не как я почему-то был уверен, что в каждом случае она своя - ещё раз простите за тупость, но тут как раз и грабельки нарисовались! Мне надо ограничить соединения с одного IP так, чтобы было не более 4-х на каждый ВИРТУАЛХОСТ. Зарывшись носом в документацию, я понял, что обломинго и limit_zone и limit_req не даёт такой возможности, потому что как уже писалось выше. Я не буду заумно и долго рассуждать правильно это или нет, я просто прошу у Игоря сделать ВСТРОЕННУЮ ПЕРЕМЕННУЮ, которая бы содержала ВМЕСТЕ: $binary_remote_address и $server_name Такая переменная даст возможность эффективно использовать limit_zone или limit_req_zone для ограничения числа IP соединений не только с одного IP но и ОДНОВРЕМЕННО к одному виртуалхосту. Спасибо за внимание, успехов! From voron на amhost.net Thu Dec 8 08:11:30 2011 From: voron на amhost.net (Alex Vorona) Date: Thu, 08 Dec 2011 10:11:30 +0200 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: Message-ID: <4EE07132.6080002@amhost.net> А limit_conn_zone $limit zone=myzone:10m; И в нужном location set $limit $server_name$binary_remote_addr; limit_conn myzone 4; разве не работает? From corochoone на gmail.com Thu Dec 8 08:16:52 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 11:16:52 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <4EE07132.6080002@amhost.net> References: <4EE07132.6080002@amhost.net> Message-ID: А вы сами подумайте. limit_zone нужно объявлять в ГЛОБАЛЬНОЙ секции http, где ничего о вашей переменной $limit неизвестно К тому же set это директива из rewrite внутри которой limit_conn не работает :) 8 декабря 2011 г. 12:11 пользователь Alex Vorona написал: > А > > limit_conn_zone  $limit  zone=myzone:10m; > > И в нужном location > > set $limit $server_name$binary_remote_addr; > limit_conn myzone 4; > > разве не работает? > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From voron на amhost.net Thu Dec 8 08:23:37 2011 From: voron на amhost.net (Alex Vorona) Date: Thu, 08 Dec 2011 10:23:37 +0200 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: <4EE07132.6080002@amhost.net> Message-ID: <4EE07409.3060202@amhost.net> 08.12.2011 10:16, Виктор Вислобоков wrote: > А вы сами подумайте. Конфиг-тест проходит. Попробуйте, возможно и работает :) From ne на vbart.ru Thu Dec 8 08:25:35 2011 From: ne на vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 8 Dec 2011 12:25:35 +0400 Subject: =?UTF-8?B?UmU6INCh0LrQvtGA0L7RgdGC0Ywg0YDQsNCx0L7RgtGLIGxvY2F0aW9u?= In-Reply-To: References: <4EDE1BB3.50501@kpi.ua> <4EDE4A79.5060701@kpi.ua> Message-ID: <201112081225.35394.ne@vbart.ru> On Thursday 08 December 2011 07:26:47 Дмитрий Жильцов wrote: > Вот так будет ещё быстрее > > location = video1 { > ...... > } > location = video2 { > ........ > } > > если стоит знак равно, в случае если локейшн попал под условия запроса, > остальные допущены уже не проверяются. Это не так. Если стоит модификатор "=", то проверяется точное совпадение с локейшном. Если написать: location = /img/ { } то любые запросы отличные от /img/ (например /img/file.jpg) в него не попадут. А в эти два: > > location = video1 { > ...... > } > location = video2 { > ........ > } > не попадет ни один запрос (включая /video1 и /video2). > Если знак равенства не используними > то проверяются каждый локейшн, и используется последний попавший под > условия запроса. И это тоже не так. Правильно написано в документации: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location -- Валентин Бартенев From corochoone на gmail.com Thu Dec 8 08:26:06 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 11:26:06 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <4EE07409.3060202@amhost.net> References: <4EE07132.6080002@amhost.net> <4EE07409.3060202@amhost.net> Message-ID: Попробую, но если это действительно работает, то тогда нужно попросить исправить документацию :) Потому что это с ног на голову ставит мои представления о видимости переменных и не только. 8 декабря 2011 г. 12:23 пользователь Alex Vorona написал: > 08.12.2011 10:16, Виктор Вислобоков wrote: >> А вы сами подумайте. > > Конфиг-тест проходит. Попробуйте, возможно и работает :) > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ne на vbart.ru Thu Dec 8 08:36:15 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Dec 2011 12:36:15 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: Message-ID: <201112081236.16168.ne@vbart.ru> On Thursday 08 December 2011 11:33:54 Виктор Вислобоков wrote: [...] > Мне надо ограничить соединения с одного IP так, чтобы было не более > 4-х на каждый ВИРТУАЛХОСТ. > Зарывшись носом в документацию, я понял, что обломинго и limit_zone и > limit_req не даёт такой возможности, потому что как уже писалось выше. > [...] Что вам помешало создать по отдельной зоне на каждый виртуалхост? Для этого и существуют названия у зон. Чтобы можно было определить несколько разных зон и их использовать. for example: http { limit_zone one $binary_remote_addr 4m; limit_zone two $binary_remote_addr 4m; server { listen 80; server_name localhost; location /one { limit_conn one 10; } location /two { limit_conn two 5; } } } -- Валентин Бартенев From ne на vbart.ru Thu Dec 8 08:42:20 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Dec 2011 12:42:20 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <201112081236.16168.ne@vbart.ru> References: <201112081236.16168.ne@vbart.ru> Message-ID: <201112081242.20989.ne@vbart.ru> On Thursday 08 December 2011 12:36:15 Валентин Бартенев wrote: > > for example: > > http { > limit_zone one $binary_remote_addr 4m; > limit_zone two $binary_remote_addr 4m; > > server { > listen 80; > server_name localhost; > > location /one { > limit_conn one 10; > } > > location /two { > limit_conn two 5; > } > } > } > Хм... я от чего-то написал с локейшенами, видимо предыдущий вопрос про них сбил столку. Но с виртуалхостами всё полностью аналогично: http { limit_zone one $binary_remote_addr 4m; limit_zone two $binary_remote_addr 4m; server { listen 80; server_name host1; limit_conn one 10; } server { listen 80; server_name host2; limit_conn two 5; } } Вы просто не оценили всю гибкость существующего синтаксиса. -- Валентин Бартенев From corochoone на gmail.com Thu Dec 8 08:56:53 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 11:56:53 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <201112081236.16168.ne@vbart.ru> References: <201112081236.16168.ne@vbart.ru> Message-ID: > Что вам помешало создать по отдельной зоне на каждый виртуалхост? Именно это и помешало - каждая зона жрёт память и затрудняет автоматическое конфигурирование. > Для этого и существуют названия у зон. Чтобы можно было определить несколько > разных зон и их использовать. Согласен, только не сильно удобно это. Удобней было бы наличие той переменной, о которой я говорил вначале. From ne на vbart.ru Thu Dec 8 09:12:32 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Dec 2011 13:12:32 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: <201112081236.16168.ne@vbart.ru> Message-ID: <201112081312.32516.ne@vbart.ru> On Thursday 08 December 2011 12:56:53 Виктор Вислобоков wrote: > > Что вам помешало создать по отдельной зоне на каждый виртуалхост? > > Именно это и помешало - каждая зона жрёт память и затрудняет > автоматическое конфигурирование. > Одна большая зона будет потреблять памяти не меньше, чем несколько маленьких. Каким образом это затрудняет некое "автоматическое" конфигурирование? > > Для этого и существуют названия у зон. Чтобы можно было определить > > несколько разных зон и их использовать. > > Согласен, только не сильно удобно это. Удобней было бы наличие той > переменной, о которой я говорил вначале. rbtree имеет сложность O(log n) для поиска, вставки и удаления. Большая зона будет работать медленнее. -- Валентин Бартенев From corochoone на gmail.com Thu Dec 8 09:30:07 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 12:30:07 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <201112081312.32516.ne@vbart.ru> References: <201112081236.16168.ne@vbart.ru> <201112081312.32516.ne@vbart.ru> Message-ID: > Одна большая зона будет потреблять памяти не меньше, чем несколько маленьких. Не соглашусь. Нам неизвестно заранее хватит ли 4Mb или даже 2Mb это много. Но допустим 4Mb Когда виртуалхостов 10-ть это всего 40Mb - это не страшно. А если их 100? Это получается, что я 400Mb оперативки отдал не зная пригодится она или нет. А на практике виртуалхостов может быть не одна сотня и таким образом вопрос нехватки оперативки встаёт очень остро. Нет уж, лучше одна большая зона. Дать мегабайт 100 с запасом и иметь практически 99% уверенность, что хватит! > Каким образом это затрудняет некое "автоматическое" конфигурирование? Таким образом, что виртуалхост может быть описан в отдельном файле, который подключается через include не трогая основной конфиг. А тут получается либо надо каждый раз править основной конфиг, внося в него дополнительную limit_zone (потому что limit_zone объявляется в http секции согласно доке) либо городить отдельные include файлы под это дело, что приводит нас к возможности ситуации, когда есть include файл с виртуалхостом, но по какой-то причине нет include файла с limit_zone для этого виртуалхоста. Но это не существенная проблема - можно на неё не отвлекаться (пока писал, подумал, что можно вставлять описание limit_zone в тот же include перед server) > rbtree имеет сложность O(log n) для поиска, вставки и удаления. Большая зона > будет работать медленнее. Возможно. Надо понять насколько. Если это некритично, то удобства перевесят. В любом случае главное дать возможность людям выбирать варианты, а пользоваться или нет по той или иной причине, люди сами решат From ne на vbart.ru Thu Dec 8 09:55:58 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Dec 2011 13:55:58 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: <201112081312.32516.ne@vbart.ru> Message-ID: <201112081355.59184.ne@vbart.ru> On Thursday 08 December 2011 13:30:07 Виктор Вислобоков wrote: [...] > главное дать возможность людям выбирать варианты, а пользоваться или > нет по той или иной причине, люди сами решат Предполагаю, что если такая возможность и будет сделана, то точно не в виде отдельной избыточной переменной. Лично вам захотелось IP + Host, кому-то другому может быть нужно another var1 + another var2, и делать отдельные переменные для всех возможных комбинаций из двух и более других переменных - абсурд. Можно сделать поддержку указания комбинации из нескольких переменных для зоны, но скорее только как синтаксический сахар. Ибо, на первый взгляд, не вижу причин, почему может не сработать предложенное Alex Vorona решение с использованием set. -- Валентин Бартенев From ru на nginx.com Thu Dec 8 10:34:19 2011 From: ru на nginx.com (Ruslan Ermilov) Date: Thu, 8 Dec 2011 14:34:19 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: <4EE07132.6080002@amhost.net> Message-ID: <20111208103419.GA91204@lo0.su> On Thu, Dec 08, 2011 at 11:16:52AM +0300, Виктор Вислобоков wrote: > 8 декабря 2011 г. 12:11 пользователь Alex Vorona написал: > > А > > > > limit_conn_zone  $limit  zone=myzone:10m; > > > > И в нужном location > > > > set $limit $server_name$binary_remote_addr; > > limit_conn myzone 4; > > > > разве не работает? > А вы сами подумайте. > > limit_zone нужно объявлять в ГЛОБАЛЬНОЙ секции http, где ничего о > вашей переменной $limit неизвестно > К тому же set это директива из rewrite внутри которой limit_conn не работает :) Хороший совет, подумать. :) О переменных $binary_remote_addr и $server_name в глобальной секции тоже ничего неизвестно, однако же они там почему-то работают. Также работают всякие переменные, которые существуют только на момент запроса ($http_*). Работать будут любые переменные и их комбинации, для которых после парсинга конфига будет известен способ их получения (get_handler в коде). From ne на vbart.ru Thu Dec 8 10:42:06 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Dec 2011 14:42:06 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: <4EE07409.3060202@amhost.net> Message-ID: <201112081442.06893.ne@vbart.ru> On Thursday 08 December 2011 12:26:06 Виктор Вислобоков wrote: > Попробую, но если это действительно работает, то тогда нужно попросить > исправить документацию :) > Потому что это с ног на голову ставит мои представления о видимости > переменных и не только. > В документации ни о какой "видимости переменных" не сказано. Такого понятия по отношению к конфигам nginx не существует. Это вы из языков программирования притянули. Значения переменных вычисляются в момент обращения к ним. -- Валентин Бартенев From corochoone на gmail.com Thu Dec 8 11:32:37 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 14:32:37 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <201112081442.06893.ne@vbart.ru> References: <4EE07409.3060202@amhost.net> <201112081442.06893.ne@vbart.ru> Message-ID: Накритиковали :) Я просто стараюсь быть логичным. 1. Объявляем limit_zone в http секции на неизвестную переменную. 2. Она становится известной только в момент обращения к location, потому что вычисляется именно там. 3. Но хэш под эту переменную должен быть выделен у момент запуска nginx, так или нет? Вот собственно это и вызывает у меня непонимание - получается мы выделяем хэш не зная ещё собственно на что. Логика работы становится непонятной. 8 декабря 2011 г. 13:42 пользователь Валентин Бартенев написал: > On Thursday 08 December 2011 12:26:06 Виктор Вислобоков wrote: >> Попробую, но если это действительно работает, то тогда нужно попросить >> исправить документацию :) >> Потому что это с ног на голову ставит мои представления о видимости >> переменных и не только. >> > > В документации ни о какой "видимости переменных" не сказано. Такого понятия > по отношению к конфигам nginx не существует. Это вы из языков программирования > притянули. > > Значения переменных вычисляются в момент обращения к ним. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From corochoone на gmail.com Thu Dec 8 11:36:27 2011 From: corochoone на gmail.com (=?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?=) Date: Thu, 8 Dec 2011 14:36:27 +0300 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: <20111208103419.GA91204@lo0.su> References: <4EE07132.6080002@amhost.net> <20111208103419.GA91204@lo0.su> Message-ID: > О переменных $binary_remote_addr и $server_name в > глобальной секции тоже ничего неизвестно, однако > же они там почему-то работают.  Также работают > всякие переменные, которые существуют только на > момент запроса ($http_*). Простите, но эти переменные ВСТРОЕНЫ в nginx о чём написано в документации, так что nginx должен он них знать по-любому несмотря на то что они содержат неопределённое значение. Само имя зарегистрировано и зарезервировано. > Работать будут любые переменные и их комбинации, для > которых после парсинга конфига будет известен способ > их получения (get_handler в коде). Угу. Вот об этом бы ещё в доку написать в раздел переменных, было бы просто замечательно. From ne на vbart.ru Thu Dec 8 12:58:21 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Thu, 8 Dec 2011 16:58:21 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0X2NvbiwgbGltaXRfcmVxINC4INC/0YDQvtGH0LDRjyAoZmVhdHVy?= =?UTF-8?B?ZSByZXF1ZXN0KQ==?= In-Reply-To: References: <201112081442.06893.ne@vbart.ru> Message-ID: <201112081658.22051.ne@vbart.ru> On Thursday 08 December 2011 15:32:37 Виктор Вислобоков wrote: > Накритиковали :) > Я просто стараюсь быть логичным. > > 1. Объявляем limit_zone в http секции на неизвестную переменную. > 2. Она становится известной только в момент обращения к location, > потому что вычисляется именно там. > 3. Но хэш под эту переменную должен быть выделен у момент запуска > nginx, так или нет? Но и чтение конфига происходит в момент запуска. Причем набор доступных переменных зависит от конфига, а он имеет декларативную природу. Сформировать полный набор доступных переменных возможно только после парсинга всего конфига целиком. Если вы попытаетесь указать в limit_zone переменную, которая действительно не существует, т.е. не была зарегистрирована ни одним из модулей (включая модуль rewrite с его директивой set) и не является magic-переменной, вроде http_*, cookie_*, arg_* - то при запуске получите ошибку. -- Валентин Бартенев From nginx-forum на nginx.us Thu Dec 8 14:20:09 2011 From: nginx-forum на nginx.us (excanoe) Date: Thu, 08 Dec 2011 09:20:09 -0500 Subject: =?UTF-8?B?U0NHSSDQuCDRgdC20LDRgtC40LUg0L7RgtCy0LXRgtC+0LI=?= Message-ID: Здравствуйте уважаемые форумчане! Столкнулся с данной ошибкой: ответы от scgi сервера не сжимаются. привожу код сервера на руби и конфигурацию nginx (конфигурация тестовая): ###################################################################### worker_processes 1; events{ worker_connections 1024; } http{ server_tokens off; default_type text/plain; gzip on; gzip_types text/plain; types{ text/plain js css txt; } server{ return 404; } server{ server_name localhost; scgi_buffering off; location / { try_files $uri @engine; } location @engine { include scgi_params; scgi_pass 127.0.0.1:9000; } } } ###################################################################### #coding: utf-8 require "socket" require "thread" require "openssl" require "erb" scgid=Socket.new(Socket::AF_INET,Socket::SOCK_STREAM,0) scgid.bind(Socket.pack_sockaddr_in(9000,"127.0.0.1")) scgid.listen(1) loop{ scgi=scgid.accept[0] Thread.new{ begin f=File.new(Time.now.to_f.to_s+".bin","wb") while(f.syswrite scgi.sysread 4096)==4096 end f.close File.unlink f.path scgi.syswrite "Status: 200 OK\r\nContent-Type: text/plain\r\n\r\n" scgi.syswrite "ok" #header_size ="" #header_pairs ="" #while (header_size=~/:/)==nil # header_size+=scgi.sysread 1 #end #header_size=header_size.to_i #while header_pairs.sizeerr p err end } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219800,219800#msg-219800 From vromanov на gmail.com Thu Dec 8 16:09:26 2011 From: vromanov на gmail.com (Vladimir Romanov) Date: Thu, 8 Dec 2011 19:09:26 +0300 Subject: ustats & nginx 1.xx Message-ID: Добрый день! Для 8.хх был модуль ustats. Для 1.ххх он слету не завелся. Портировал ли его ето-то? Может появилось что-то подобное? Интересуте статистика запросов по апстримам. У нас сделан хитрый модуль, который перенаправляет запросы на различные кластера в зависимости от id пользователя и других параметров. Хотелось бы мониторить живость как самих апстримов, так и серверов внутри апстримов. -- Vladimir Romanov From hell-for-yahoo на umail.ru Thu Dec 8 16:45:21 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Thu, 8 Dec 2011 20:45:21 +0400 Subject: SCGI и сжатие ответов In-Reply-To: References: Message-ID: <1978196654.20111208204521@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) excanoe! e> Столкнулся с данной ошибкой: ответы от e> scgi сервера не сжимаются. И как вы это определили? curl -siIH "Accept-Encoding: deflate,gzip" http://хост/адрес_скрипта что говорит? e> привожу код сервера на руби и e> конфигурацию nginx (конфигурация e> тестовая): e> ###################################################################### e> worker_processes 1; e> events{ e> worker_connections 1024; e> } e> http{ e> server_tokens off; e> default_type text/plain; e> gzip on; e> gzip_types text/plain; e> types{ e> text/plain js css txt; e> } e> server{ e> return 404; e> } e> server{ e> server_name localhost; e> scgi_buffering off; e> location / { e> try_files $uri @engine; e> } e> location @engine { e> include scgi_params; e> scgi_pass 127.0.0.1:9000; e> } e> } e> } e> ###################################################################### e> #coding: utf-8 e> require "socket" e> require "thread" e> require "openssl" e> require "erb" e> scgid=Socket.new(Socket::AF_INET,Socket::SOCK_STREAM,0) e> scgid.bind(Socket.pack_sockaddr_in(9000,"127.0.0.1")) e> scgid.listen(1) e> loop{ e> scgi=scgid.accept[0] e> Thread.new{ e> begin e> f=File.new(Time.now.to_f.to_s+".bin","wb") e> while(f.syswrite scgi.sysread 4096)==4096 e> end e> f.close e> File.unlink f.path e> scgi.syswrite "Status: 200 OK\r\nContent-Type: e> text/plain\r\n\r\n" e> scgi.syswrite "ok" e> #header_size ="" e> #header_pairs ="" e> #while (header_size=~/:/)==nil e> # header_size+=scgi.sysread 1 e> #end e> #header_size=header_size.to_i e> #while header_pairs.size # header_pairs+=scgi.sysread 1 e> #end e> #env=Hash[*header_pairs.split("\0")] e> #scgi.syswrite "Status: 200 OK\r\nContent-Type: e> text/plain\r\nContent-Length: "+env.to_s.size.to_s+"\r\n\r\n" e> #scgi.syswrite env.to_s e> scgi.close e> rescue=>err e> p err e> end e> } e> } e> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219800,219800#msg-219800 e> _______________________________________________ e> nginx-ru mailing list e> nginx-ru на nginx.org e> http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) четверг, 08.12.2011, <20:43> From nginx-forum на nginx.us Thu Dec 8 17:16:42 2011 From: nginx-forum на nginx.us (excanoe) Date: Thu, 08 Dec 2011 12:16:42 -0500 Subject: SCGI In-Reply-To: <1978196654.20111208204521@mtu-net.ru> References: <1978196654.20111208204521@mtu-net.ru> Message-ID: <65bd4cb96364340a20934aa0ae14a455.NginxMailingListRussian@forum.nginx.org> Andrey Repin Wrote: ------------------------------------------------------- > Здравствуйте, > Уважаемый(-ая, -ое) excanoe! > > e> Столкнулся с данной > ошибкой: ответы от > e> scgi сервера не сжимаются. > > И как вы это определили? > > curl -siIH "Accept-Encoding: deflate,gzip" > http://хост/адрес_скрипта > что говорит? > > e> привожу код сервера на > руби и > e> конфигурацию nginx > (конфигурация > e> тестовая): > > e> > ################################################## > #################### > > e> worker_processes 1; > > e> events{ > e> worker_connections 1024; > e> } > > e> http{ > e> server_tokens off; > > e> default_type text/plain; > > e> gzip on; > e> gzip_types text/plain; > > e> types{ > e> text/plain js css txt; > e> } > > e> server{ > e> return 404; > e> } > > e> server{ > e> server_name localhost; > > e> scgi_buffering off; > > e> location / { > e> try_files $uri @engine; > e> } > > e> location @engine { > e> include scgi_params; > e> scgi_pass 127.0.0.1:9000; > e> } > e> } > e> } > > e> > ################################################## > #################### > > e> #coding: utf-8 > > e> require "socket" > e> require "thread" > e> require "openssl" > e> require "erb" > > e> > scgid=Socket.new(Socket::AF_INET,Socket::SOCK_STRE > AM,0) > e> > scgid.bind(Socket.pack_sockaddr_in(9000,"127.0.0.1 > ")) > e> scgid.listen(1) > > e> loop{ > e> scgi=scgid.accept[0] > e> Thread.new{ > e> begin > > e> > f=File.new(Time.now.to_f.to_s+".bin","wb") > e> while(f.syswrite scgi.sysread 4096)==4096 > e> end > e> f.close > e> File.unlink f.path > > e> scgi.syswrite "Status: 200 > OK\r\nContent-Type: > e> text/plain\r\n\r\n" > > e> scgi.syswrite "ok" > > e> #header_size ="" > e> #header_pairs ="" > e> #while (header_size=~/:/)==nil > e> # header_size+=scgi.sysread 1 > e> #end > e> #header_size=header_size.to_i > e> #while header_pairs.size e> # header_pairs+=scgi.sysread 1 > e> #end > > e> #env=Hash[*header_pairs.split("\0")] > > e> #scgi.syswrite "Status: 200 > OK\r\nContent-Type: > e> text/plain\r\nContent-Length: > "+env.to_s.size.to_s+"\r\n\r\n" > e> #scgi.syswrite env.to_s > > e> scgi.close > e> rescue=>err > e> p err > e> end > e> } > e> } > > e> Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,219800,219800#m > sg-219800 > > e> _______________________________________________ > e> nginx-ru mailing list > e> nginx-ru на nginx.org > e> > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > С уважением > > Andrey Repin (hell-for-yahoo на umail.ru) > четверг, 08.12.2011, <20:43> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ответ curl d:\temp\db\scgi>curl -siIH "Accept-Encoding: deflate,gzip" http://localhost HTTP/1.1 200 OK Server: nginx Date: Thu, 08 Dec 2011 17:11:15 GMT Content-Type: text/plain Connection: keep-alive я тестирую под windows в данный момент, проверял ответы fastcgi php, отдаются как gzip. также проверял простой текстовый файл (который в папке по умолчанию docroot). d:\temp\db\scgi>curl -siIH "Accept-Encoding: deflate,gzip" http://localhost/index.html HTTP/1.1 200 OK Server: nginx Date: Thu, 08 Dec 2011 17:15:59 GMT Content-Type: text/plain Last-Modified: Mon, 04 Oct 2004 13:04:06 GMT Connection: keep-alive Content-Encoding: gzip Posted at Nginx Forum: http://forum.nginx.org/read.php?21,143458,219807#msg-219807 From belov1985 на gmail.com Thu Dec 8 18:24:56 2011 From: belov1985 на gmail.com (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0=?=) Date: Thu, 08 Dec 2011 20:24:56 +0200 Subject: =?UTF-8?B?0J/RgNCw0LLQsCDQtNC+0YHRgtGD0L/QsCDQvdCwIGZhc3RjZ2lfY2FjaGVfcGF0?= =?UTF-8?B?aA==?= Message-ID: <4EE100F8.70607@gmail.com> Здравствуйте! Подскажите, как можно задавать права доступа для создаваемых файлов и каталогов (нужны rw для группы, по умолчанию используется 700) при использовании кеширования. Значение переменной fastcgi_store_access похоже на это никак не влияет :( При необходимости бы пересобрал nginx с нужными патчами, знать бы где это исправить :) С уважением, Константин. From nginx-forum на nginx.us Fri Dec 9 02:37:20 2011 From: nginx-forum на nginx.us (simple) Date: Thu, 08 Dec 2011 21:37:20 -0500 Subject: =?UTF-8?B?0JfQsNC/0YDQtdGC0LjRgtGMINC/0YDRj9C80L7QuSDQtNC+0YHRgtGD0L8g0Log?= =?UTF-8?B?0YTQsNC50LvQsNC8?= Message-ID: Как можно сделать чтобы например файлы .js были доступны только из html документов и не доступны по прямой ссылке, например: site/index.html подключенные js файлы работают а по ссылке site/script.js выдавало бы страницу 403 как так сделать? пробовал с internal но тогда скрипты перестают вообще работать, а мне нужно лишь чтоб по ссылке на них сервер не выдовал бы их содиржимого Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219811,219811#msg-219811 From trent.clainor на gmail.com Fri Dec 9 03:20:19 2011 From: trent.clainor на gmail.com (Albert Mikhaylov) Date: Fri, 9 Dec 2011 07:20:19 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQv9GA0Y/QvNC+0Lkg0LTQvtGB0YLRg9C/?= =?UTF-8?B?INC6INGE0LDQudC70LDQvA==?= In-Reply-To: References: Message-ID: предлагаю следующие варианты 1. самый простой это использовать для локейшена с js referer_module http://nginx.org/ru/docs/http/ngx_http_referer_module.html, но тогда те клиенты, которые не передают referer не получат js 2. Формировать динамически ссылку на js динамически и отдавая контент модулем secure_link http://nginx.org/ru/docs/http/ngx_http_secure_link_module.html используя как параметр айпи пользователя, этот способ более универсален, но требует динамического формирования index.html 9 декабря 2011 г. 6:37 пользователь simple написал: > Как можно сделать чтобы например файлы > .js были доступны только из html > документов и не доступны по прямой > ссылке, например: > site/index.html подключенные js файлы работают > а по ссылке > site/script.js выдавало бы страницу 403 > > как так сделать? > > пробовал с internal но тогда скрипты > перестают вообще работать, а мне нужно > лишь чтоб по ссылке на них сервер не > выдовал бы их содиржимого > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,219811,219811#msg-219811 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Fri Dec 9 03:50:12 2011 From: nginx-forum на nginx.us (simple) Date: Thu, 08 Dec 2011 22:50:12 -0500 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQv9GA0Y/QvNC+0Lkg0LTQvtGB0YLRg9C/?= =?UTF-8?B?INC6INGE0LDQudC70LDQvA==?= In-Reply-To: References: Message-ID: <84289839dd3a620135a2cdab1d49ccdd.NginxMailingListRussian@forum.nginx.org> Спасибо за советы..не знал что это так сложно в NGINX... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219811,219813#msg-219813 From ano на bestmx.ru Fri Dec 9 06:00:48 2011 From: ano на bestmx.ru (Andrey N. Oktyabrski) Date: Fri, 09 Dec 2011 09:00:48 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQv9GA0LXRgtC40YLRjCDQv9GA0Y/QvNC+0Lkg0LTQvtGB0YLRg9C/?= =?UTF-8?B?INC6INGE0LDQudC70LDQvA==?= In-Reply-To: <84289839dd3a620135a2cdab1d49ccdd.NginxMailingListRussian@forum.nginx.org> References: <84289839dd3a620135a2cdab1d49ccdd.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EE1A410.6050301@bestmx.ru> On 09.12.11 06:50, simple wrote: > Спасибо за советы..не знал что это так > сложно в NGINX... Это сложно в принципе, а не в nginx. From rush.zlo на gmail.com Fri Dec 9 05:26:44 2011 From: rush.zlo на gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40LkgJ1J1c2gnINCd0LXQv9C+0LzQvdGP0YnQuNC5?=) Date: Fri, 9 Dec 2011 09:26:44 +0400 Subject: ustats & nginx 1.xx In-Reply-To: References: Message-ID: Ох не царское это дело :) Впрочем на http://code.google.com/p/ustats/ написано, что тестился для 1.0.10. У вас он как не завёлся (компиляция/рантайм) и с какой версией? 8 декабря 2011 г. 20:09 пользователь Vladimir Romanov написал: > ustats -- Cogito ergo sum From vromanov на gmail.com Fri Dec 9 05:34:56 2011 From: vromanov на gmail.com (Vladimir Romanov) Date: Fri, 9 Dec 2011 08:34:56 +0300 Subject: ustats & nginx 1.xx In-Reply-To: References: Message-ID: Он у меня приводит к сигфолту на первом запросе к бакенду. "nginx падает на 1149 строчке nginx/nginx/src/http/ngx_http_upstream.c, код как-раз под ustats-овым ifdef-ом. Хронология следующая - ддф находит апстрим, открывает соединение с сервером, однако ничего не успевает передать, падает в районе ngx_atomic_fetch_add" Страница статистики (с нулями) показывается, но в ней нет backup серверов. 2011/12/9 Евгений 'Rush' Непомнящий : > Ох не царское это дело :) Впрочем на http://code.google.com/p/ustats/ > написано, что тестился для 1.0.10. У вас он как не завёлся > (компиляция/рантайм) и с какой версией? > > 8 декабря 2011 г. 20:09 пользователь Vladimir Romanov > написал: >> ustats > > > > -- > Cogito ergo sum > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Vladimir Romanov From hell-for-yahoo на umail.ru Fri Dec 9 05:40:59 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Fri, 9 Dec 2011 09:40:59 +0400 Subject: Запретить прямой доступ к файлам In-Reply-To: <84289839dd3a620135a2cdab1d49ccdd.NginxMailingListRussian@forum.nginx.org> References: <84289839dd3a620135a2cdab1d49ccdd.NginxMailingListRussian@forum.nginx.org> Message-ID: <397040220.20111209094059@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) simple! s> Спасибо за советы..не знал что это так s> сложно в NGINX... Аааа... вам, видимо, надо что-то типа этого: http://button.dekel.ru/ -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) пятница, 09.12.2011, <09:40> From nginx-forum на nginx.us Fri Dec 9 06:01:00 2011 From: nginx-forum на nginx.us (ast) Date: Fri, 09 Dec 2011 01:01:00 -0500 Subject: ustats & nginx 1.xx In-Reply-To: References: Message-ID: <902a53380ef42ff89c758e905809e9be.NginxMailingListRussian@forum.nginx.org> Rush Wrote: ------------------------------------------------------- > Ох не царское это дело :) > Впрочем на > http://code.google.com/p/ustats/ > написано, что тестился для > 1.0.10. У вас он как не завёлся > (компиляция/рантайм) и с > какой версией? > > 8 декабря 2011 г. 20:09 > пользователь Vladimir Romanov > написал: > > ustats > > > > -- > Cogito ergo sum > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru У меня работал на 0.8, на 1.0.9, и сейчас нормально работает на 1.1.8 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219804,219819#msg-219819 From ne на vbart.ru Fri Dec 9 09:09:27 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 9 Dec 2011 13:09:27 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQsNCy0LAg0LTQvtGB0YLRg9C/0LAg0L3QsCBmYXN0Y2dpX2NhY2hl?= =?UTF-8?B?X3BhdGg=?= In-Reply-To: <4EE100F8.70607@gmail.com> References: <4EE100F8.70607@gmail.com> Message-ID: <201112091309.27898.ne@vbart.ru> On Thursday 08 December 2011 22:24:56 Константин wrote: > Здравствуйте! > > Подскажите, как можно задавать права доступа для создаваемых файлов и > каталогов (нужны rw для группы, по умолчанию используется 700) при > использовании кеширования. > > Значение переменной fastcgi_store_access похоже на это никак не влияет :( > > При необходимости бы пересобрал nginx с нужными патчами, знать бы где > это исправить :) > А для чего это понадобилось, если не секрет? -- Валентин Бартенев From nginx-forum на nginx.us Fri Dec 9 09:36:48 2011 From: nginx-forum на nginx.us (vgoncharov) Date: Fri, 09 Dec 2011 04:36:48 -0500 Subject: =?UTF-8?B?0LrQsNC6INGD0LTQsNC70LjRgtGMINC60YPQutGDINC40LcgcmVxdWVzdCBoZWFk?= =?UTF-8?B?ZXI/?= Message-ID: <7b889e288e09f93aa83746622dc892a2.NginxMailingListRussian@forum.nginx.org> Всем привет! Подскажите, как правильно удалить куку из заголовка запроса? При этом в заголовке кук несколько, а надо удалить только одну с именем jstree_open. Вот подробная причина, по которой это надо. Backend достаточно неповоротливый в настройках: Oracle XML DB Server Frontend: nginx Веб-приложение использует jstree для отображения иерархических данных. Состояние узлов дерева (открыто/закрыто) запоминается в куке jstree_open. При этом это приложение использует и другие куки. Каждая из кук нужна для правильной работы backend'а, однако кука jstree_open на бакэнде совергенно бесполезна. Прои этом на больших деревьях создается большая кука jstree_open. Backend при получении такой большой куки выдает 500 Internal Server Error. Предполагаемое решение: необходимо удалить одну (только одну) куку jstree_open из заголовка запроса перед передачей его на backend. Предполагаемое неправильное понимание вопроса: client_header_buffer_size и large_client_header_buffers не могут решить проблемы, так как проблема не в nginx, а в backend. Nginx же с имеющимися куками справляется (благодаря этим настройкам). Другое предполагаемое неправильное решение: Удаление заголовка запроса Cookie: не поможет, так как приложение требует наличия всех остальных кук (несколько штук). Заранее спасибо за любую подсказку. Владимир Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219824,219824#msg-219824 From mdounin на mdounin.ru Fri Dec 9 10:49:04 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 9 Dec 2011 14:49:04 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDRg9C00LDQu9C40YLRjCDQutGD0LrRgyDQuNC3IHJlcXVlc3Qg?= =?UTF-8?B?aGVhZGVyPw==?= In-Reply-To: <7b889e288e09f93aa83746622dc892a2.NginxMailingListRussian@forum.nginx.org> References: <7b889e288e09f93aa83746622dc892a2.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111209104904.GT67687@mdounin.ru> Hello! On Fri, Dec 09, 2011 at 04:36:48AM -0500, vgoncharov wrote: > Всем привет! > > Подскажите, как правильно удалить куку > из заголовка запроса? > При этом в заголовке кук несколько, а > надо удалить только одну с именем > jstree_open. > > Вот подробная причина, по которой это > надо. > > Backend достаточно неповоротливый в > настройках: Oracle XML DB Server > Frontend: nginx > > Веб-приложение использует jstree для > отображения иерархических данных. > Состояние узлов дерева > (открыто/закрыто) запоминается в куке > jstree_open. > При этом это приложение использует и > другие куки. > > Каждая из кук нужна для правильной > работы backend'а, однако кука jstree_open на > бакэнде совергенно бесполезна. Прои > этом на больших деревьях создается > большая кука jstree_open. Backend при получении > такой большой куки выдает 500 Internal Server > Error. > > Предполагаемое решение: необходимо > удалить одну (только одну) куку jstree_open > из заголовка запроса перед передачей > его на backend. > > Предполагаемое неправильное понимание > вопроса: client_header_buffer_size и large_client_header_buffers > не могут решить проблемы, так как > проблема не в nginx, а в backend. Nginx же с > имеющимися куками справляется > (благодаря этим настройкам). > > Другое предполагаемое неправильное > решение: Удаление заголовка запроса > Cookie: не поможет, так как приложение > требует наличия всех остальных кук > (несколько штук). Выкусывайте нужное из $http_cookie, а дальше proxy_set_header Cookie "то что осталось"; Выкусить, наверное, даже получится с помощью модуля rewrite (if с регулярым выражением + set). Как-то так: set $rest $http_cookie; if ($http_cookie ~ "^(.*[,; ])?jstree_open=[^,;]*(.*)$") { set $rest "$1$2"; } proxy_set_header Cookie $rest; Completely untested, регулярное выражение скорее всего требует доработки. Maxim Dounin From lvm на citylink-rk.ru Fri Dec 9 13:08:39 2011 From: lvm на citylink-rk.ru (=?UTF-8?B?0JLQsNC00LjQvCDQm9Cw0LfQvtCy0YHQutC40Lk=?=) Date: Fri, 09 Dec 2011 17:08:39 +0400 Subject: =?UTF-8?B?ZXJyb3JfcGFnZSDQsiDQuNC80LXQvdC+0LLQsNC90L3QvtC8IGxvY2F0aW9u?= Message-ID: <4EE20857.3090709@citylink-rk.ru> Здравствуйте. Есть конфигурация вида: server { ... error_page 418 = @forbid; if($forbidden) { return 418; } location @forbid { error_page 403 = /403_opera.html; if ($opera_trubo) { return 403; } rewrite ^ http://domain.ru/forbidden.html permanent; } } Версия 1.0.0. Отдается стандартная 403 вместо 403_opera.html Подскажите, пожалуйста, что не так? 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 event timer del: 177: 1323434688174 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 generic phase: 0 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 rewrite phase: 1 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script var 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http map started 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http geo started: 10.0.43.213 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http geo: none 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script var: "none" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http map: "none" "1" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script var: "1" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script if 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http finalize request: 418, "/?" a:1, c:1 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http special response: 418, "/?" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 test location: "@forbid" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 using location: @forbid "/?" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 rewrite phase: 3 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script var 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http geo started: 10.0.43.213 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http geo: 1 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script var: "1" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http script if 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http finalize request: 403, "/?" a:1, c:2 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http special response: 403, "/?" 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 http set discard body 2011/12/09 16:43:43 [debug] 27306#0: *2537648734 HTTP/1.1 403 Forbidden Server: nginx/1.0.0 Date: Fri, 09 Dec 2011 12:43:43 GMT Content-Type: text/html Content-Length: 570 Connection: keep-alive From mdounin на mdounin.ru Fri Dec 9 13:11:00 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 9 Dec 2011 17:11:00 +0400 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0LIg0LjQvNC10L3QvtCy0LDQvdC90L7QvCBsb2NhdGlv?= =?UTF-8?B?bg==?= In-Reply-To: <4EE20857.3090709@citylink-rk.ru> References: <4EE20857.3090709@citylink-rk.ru> Message-ID: <20111209131100.GA67687@mdounin.ru> Hello! On Fri, Dec 09, 2011 at 05:08:39PM +0400, Вадим Лазовский wrote: > Здравствуйте. > > Есть конфигурация вида: > > server { > > ... > > error_page 418 = @forbid; > > if($forbidden) { > return 418; > } > > location @forbid { > error_page 403 = /403_opera.html; > > if ($opera_trubo) { > return 403; > } > > rewrite ^ http://domain.ru/forbidden.html permanent; > } > > } > > Версия 1.0.0. > > Отдается стандартная 403 вместо 403_opera.html > > Подскажите, пожалуйста, что не так? http://nginx.org/ru/docs/http/ngx_http_core_module.html#recursive_error_pages Maxim Dounin From lvm на citylink-rk.ru Fri Dec 9 13:39:57 2011 From: lvm на citylink-rk.ru (=?KOI8-R?Q?=F7=C1=C4=C9=CD_=EC=C1=DA=CF=D7=D3=CB=C9=CA?=) Date: Fri, 09 Dec 2011 17:39:57 +0400 Subject: =?UTF-8?B?UmU6IGVycm9yX3BhZ2Ug0LIg0LjQvNC10L3QvtCy0LDQvdC90L7QvCBsb2NhdGlv?= =?UTF-8?B?bg==?= In-Reply-To: <20111209131100.GA67687@mdounin.ru> References: <4EE20857.3090709@citylink-rk.ru> <20111209131100.GA67687@mdounin.ru> Message-ID: <4EE20FAD.8030205@citylink-rk.ru> 09.12.2011 17:11, Maxim Dounin пишет: > Hello! > > On Fri, Dec 09, 2011 at 05:08:39PM +0400, Вадим Лазовский wrote: > >> Здравствуйте. >> >> Есть конфигурация вида: >> >> server { >> >> ... >> >> error_page 418 = @forbid; >> >> if($forbidden) { >> return 418; >> } >> >> location @forbid { >> error_page 403 = /403_opera.html; >> >> if ($opera_trubo) { >> return 403; >> } >> >> rewrite ^ http://domain.ru/forbidden.html permanent; >> } >> >> } >> >> Версия 1.0.0. >> >> Отдается стандартная 403 вместо 403_opera.html >> >> Подскажите, пожалуйста, что не так? > http://nginx.org/ru/docs/http/ngx_http_core_module.html#recursive_error_pages > > Maxim Dounin > Спасибо! From chipitsine на gmail.com Fri Dec 9 13:52:16 2011 From: chipitsine на gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Fri, 9 Dec 2011 19:52:16 +0600 Subject: =?UTF-8?B?UmU6IG5naW54INC4INC90LXRgdGC0LDQvdC00LDRgNGC0L3Ri9C5INC/0L7RgNGC?= In-Reply-To: <2098698e8b4bdf8d63c4984f2ece462e.NginxMailingListRussian@forum.nginx.org> References: <2098698e8b4bdf8d63c4984f2ece462e.NginxMailingListRussian@forum.nginx.org> Message-ID: причина такого поведения - редиректы, т.е. коды 30x. По умолчанию если nginx видит, что приложение делает редирект на адрес upstream-а, то подменяет его на внешний адрес самого nginx-а, это регулируется директивой "proxy_redirect default", посмотрите ее внимательно, там будут нужные вам настройки. А вообще, из-за этих редиректов лучше nginx вешать сразу на белый адрес на правильный порт. особенно забавные спецэффекты появляются, если снаружи nginx работает по https, а внутри по http :-) 7 декабря 2011 г. 13:00 пользователь crashX написал: > у меня на linux установлен nginx и висит он > на 8082 порту, для локального > использования. для внешки сделан > проброс на 80 порт. все работает. но вот > незадача, если попытаться зайти из > внешки в любую директорию на > http://my_ip/any_dir, то соединения не > происходит и в строке адреса > появляется внутрений порт > (http://my_ip:8082/any_dir). если убрать порт - все > работает как и должно. вопрос в том, как > сделать чтобы внутренний порт не > появлялся в строке. > заранее благодарен. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219747,219747#msg-219747 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From belov1985 на gmail.com Fri Dec 9 19:00:24 2011 From: belov1985 на gmail.com (=?KOI8-R?Q?=EB=CF=CE=D3=D4=C1=CE=D4=C9=CE?=) Date: Fri, 09 Dec 2011 21:00:24 +0200 Subject: =?UTF-8?B?UmU6INCf0YDQsNCy0LAg0LTQvtGB0YLRg9C/0LAg0L3QsCBmYXN0Y2dpX2NhY2hl?= =?UTF-8?B?X3BhdGg=?= In-Reply-To: <201112091309.27898.ne@vbart.ru> References: <4EE100F8.70607@gmail.com> <201112091309.27898.ne@vbart.ru> Message-ID: <4EE25AC8.7050408@gmail.com> 09.12.11 11:09, Валентин Бартенев пишет: > On Thursday 08 December 2011 22:24:56 Константин wrote: >> Здравствуйте! >> >> Подскажите, как можно задавать права доступа для создаваемых файлов и >> каталогов (нужны rw для группы, по умолчанию используется 700) при >> использовании кеширования. >> >> Значение переменной fastcgi_store_access похоже на это никак не влияет :( >> >> При необходимости бы пересобрал nginx с нужными патчами, знать бы где >> это исправить :) >> > > А для чего это понадобилось, если не секрет? Иногда требуется быстро удалить закешированный ответ. Как это сделать через nginx я не знаю. Самый просто вариант, который сейчас реализован - это по крону от пользователя www запускается скрипт, который удаляет нужные файлы. Да я вроде бы как нашел фун-ию ngx_create_path в core/ngx_file.c но как бы не затронуть чего лишнего :) From postmaster на softsearch.ru Sat Dec 10 10:08:28 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Dec 2011 14:08:28 +0400 Subject: =?UTF-8?B?0JHQvtC70YzRiNCw0Y8g0YDQsNC30L3QuNGG0LAg0LzQtdC20LTRgyAkcmVxdWVz?= =?UTF-8?B?dF90aW1lINC4ICR1cHN0cmVhbV9yZXNwb25zZV90aW1l?= Message-ID: <325120510.20111210140828@softsearch.ru> Здравствуйте. В логах вижу иногда разницу почти в секунду между $request_time и $upstream_response_time . Т.е. бэкенд сгенерил страничку быстро, а nginx почему-то отдаёт её долго. Странички обычно размером 260-300 кб. Могут быть уже загзиплены бэкендом (если это nginx) или нет(если пришли от апача). Гзипование не влияет. Конфиг вот такой: worker_processes 10; error_log /opt/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 16384; use kqueue; } http { server_names_hash_max_size 8192; memcached_gzip_flag 2; gunzip on; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; types { text/html html htm shtml; text/css css; text/xml xml; image/gif gif; image/jpeg jpeg jpg; application/x-javascript js; text/plain txt; image/png png; image/x-icon ico; application/x-shockwave-flash swf; audio/mpeg mp3; application/x-gzip gz; } default_type application/octet-stream; sendfile on; tcp_nopush on; tcp_nodelay on; send_lowat 12000; aio sendfile; ignore_invalid_headers on; real_ip_header X-Forwarded-For; gzip on; gzip_min_length 1100; gzip_types application/x-javascript text/css text/xml text/plain; client_body_temp_path /var/tmp/nginx/client_body_temp_path; client_max_body_size 20m; client_body_buffer_size 128k; client_header_timeout 3m; client_header_buffer_size 2k; client_body_timeout 3m; send_timeout 3m; postpone_output 9176; keepalive_timeout 75 60; reset_timedout_connection on; proxy_redirect off; proxy_buffers 1024 64k; proxy_temp_path /var/tmp/nginx/proxy_temp_path; -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Sat Dec 10 10:19:36 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Dec 2011 14:19:36 +0400 Subject: =?UTF-8?B?0YDQsNGB0YfRkdGCIHBvc3Rwb25lX291dHB1dA==?= Message-ID: <1491903522.20111210141936@softsearch.ru> Здравствуйте. Смотрю tcpdump и вижу, что mss на интерфейсе в интернет варьируется от 1360 до до 1460 . Сколько правильно ставить postpone_output в этом случае? -- С уважением, Михаил mailto:postmaster на softsearch.ru From ne на vbart.ru Sat Dec 10 10:41:54 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 10 Dec 2011 14:41:54 +0400 Subject: =?UTF-8?B?UmU6ICDQkdC+0LvRjNGI0LDRjyDRgNCw0LfQvdC40YbQsCDQvNC10LbQtNGDICRy?= =?UTF-8?B?ZXF1ZXN0X3RpbWUg0LggJHVwc3RyZWFtX3Jlc3BvbnNlX3RpbWU=?= In-Reply-To: <325120510.20111210140828@softsearch.ru> References: <325120510.20111210140828@softsearch.ru> Message-ID: <201112101441.55033.ne@vbart.ru> On Saturday 10 December 2011 14:08:28 Михаил Монашёв wrote: > В логах вижу иногда разницу почти в секунду между $request_time и > $upstream_response_time . Т.е. бэкенд сгенерил страничку быстро, а > nginx почему-то отдаёт её долго. Странички обычно размером 260-300 кб. > Могут быть уже загзиплены бэкендом (если это nginx) или нет(если > пришли от апача). Гзипование не влияет. > Медленный клиент например. Чего тут удивительного? -- Валентин Бартенев From mdounin на mdounin.ru Sat Dec 10 13:06:59 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 10 Dec 2011 17:06:59 +0400 Subject: =?UTF-8?B?UmU6INGA0LDRgdGH0ZHRgiBwb3N0cG9uZV9vdXRwdXQ=?= In-Reply-To: <1491903522.20111210141936@softsearch.ru> References: <1491903522.20111210141936@softsearch.ru> Message-ID: <20111210130659.GH67687@mdounin.ru> Hello! On Sat, Dec 10, 2011 at 02:19:36PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Смотрю tcpdump и вижу, что mss на интерфейсе в интернет варьируется от > 1360 до до 1460 . Сколько правильно ставить postpone_output в этом > случае? 1460. В случае меньшего значения теоретически возможно, что заголовки превысят размер postpone_output и уйдут неполным пакетом. Maxim Dounin From postmaster на softsearch.ru Sat Dec 10 13:50:54 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 10 Dec 2011 17:50:54 +0400 Subject: =?UTF-8?B?UmVbMl06INGA0LDRgdGH0ZHRgiBwb3N0cG9uZV9vdXRwdXQ=?= In-Reply-To: <20111210130659.GH67687@mdounin.ru> References: <1491903522.20111210141936@softsearch.ru> <20111210130659.GH67687@mdounin.ru> Message-ID: <38433069.20111210175054@softsearch.ru> Здравствуйте, Maxim. >> Смотрю tcpdump и вижу, что mss на интерфейсе в интернет варьируется от >> 1360 до до 1460 . Сколько правильно ставить postpone_output в этом >> случае? > 1460. > В случае меньшего значения теоретически возможно, что заголовки > превысят размер postpone_output и уйдут неполным пакетом. А postpone_output только к первому пакету относится или ко всем? Вдогонку... gzip_min_length 1100; - это 1460 минус 360 байт на http-заголовки? Т.е. когда тело с заголовками в один пакет влезает, то нет смысла его сжимать? -- С уважением, Михаил mailto:postmaster на softsearch.ru From nginx-forum на nginx.us Sun Dec 11 08:33:17 2011 From: nginx-forum на nginx.us (shawn) Date: Sun, 11 Dec 2011 03:33:17 -0500 Subject: =?UTF-8?B?UmU6INCk0YDQvtC90YLRjdC90LQg0Log0JDQv9Cw0YfRgyDQuCDQstC40YDRgtGD?= =?UTF-8?B?0LDQu9GM0L3Ri9C1INGF0L7RgdGC0YsgLSDQv9GA0L7QsdC70LXQvNCw?= In-Reply-To: <2c3ccaf49bc9ad397c68587aeba95399.NginxMailingListRussian@forum.nginx.org> References: <2c3ccaf49bc9ad397c68587aeba95399.NginxMailingListRussian@forum.nginx.org> Message-ID: <8c267440b90bded9e0c90f6d3d1cf815.NginxMailingListRussian@forum.nginx.org> Доброго времени суток всем ! Помогите пожалуйста у меня похожая задача с фронтэнд'ом Есть два DNS имени, есть хост с двумя интерфейсами, один с выделенным статическим ip в интернет, второй интерфейс смотрит в локалку. В локальной сети два компа с apache на которых работает wordpress. Как настроить nginx чтоб в зависимости от запрашиваемого имени пробрасывало на нужный apache в локалке, нужен ли для этого mod_rpaf? При указанной ниже конфигурации в virtual.conf, всегда попадаю на первый apache. server { listen 80; server_name example01.edu; ... location / { proxy_pass http://192.168.1.1/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } server { listen 80; server_name example02.edu; ... location / { proxy_pass http://192.168.1.2/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,211281,219865#msg-219865 From nginx-forum на nginx.us Sun Dec 11 10:17:57 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Sun, 11 Dec 2011 05:17:57 -0500 Subject: 301 Moved permanently Message-ID: Hi! Есть такой вопрос - при каких условиях броузер показывает ошибку 301 Moved permanently? То-есть, например, есть location: location /interface/ { {skip} } Когда пользователь набирает http://url/interface (без слеша), nginx отвечает 301 и перенаправляет на http://url/interface/ (со слешом) и это правильно. Однако, пользователи иногда видят 301 и перенаправления не происходит. Броузер firefox (не знаю точно какой) под макось. Я воспроизвести такое поведение не смог. Что первое приходит в голову, это то, что после request http://url/interface броузер пользователя не получил ответ с новым заголовком Location: , то-есть например сетевая проблема. А что может быть еще? --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219867,219867#msg-219867 From mdounin на mdounin.ru Sun Dec 11 13:02:57 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 11 Dec 2011 17:02:57 +0400 Subject: =?UTF-8?B?UmU6INGA0LDRgdGH0ZHRgiBwb3N0cG9uZV9vdXRwdXQ=?= In-Reply-To: <38433069.20111210175054@softsearch.ru> References: <1491903522.20111210141936@softsearch.ru> <20111210130659.GH67687@mdounin.ru> <38433069.20111210175054@softsearch.ru> Message-ID: <20111211130257.GJ67687@mdounin.ru> Hello! On Sat, Dec 10, 2011 at 05:50:54PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> Смотрю tcpdump и вижу, что mss на интерфейсе в интернет варьируется от > >> 1360 до до 1460 . Сколько правильно ставить postpone_output в этом > >> случае? > > > 1460. > > > В случае меньшего значения теоретически возможно, что заголовки > > превысят размер postpone_output и уйдут неполным пакетом. > > А postpone_output только к первому пакету относится или ко всем? Ко всем отправляемым данным. Т.е. если данных скопилось меньше, чем postpone_output, и нет явной команды "отправлять без задержек", то данные будут задержаны. > Вдогонку... > gzip_min_length 1100; - это 1460 минус 360 байт на http-заголовки? > Т.е. когда тело с заголовками в один пакет влезает, то нет смысла его > сжимать? Значение по умолчанию - 20, т.е. когда gzip гарантированно не даст никакой экономии, а только ухудшит ситуацию. Ставить из расчёта "не жать, если влезает в один пакет" - вполне разумно для многих ситуаций. Maxim Dounin From nginx-forum на nginx.us Sun Dec 11 15:11:06 2011 From: nginx-forum на nginx.us (0xc0dec) Date: Sun, 11 Dec 2011 10:11:06 -0500 Subject: ustats & nginx 1.xx In-Reply-To: References: Message-ID: <70cb6ddcf6130cedbdb34365e42387f7.NginxMailingListRussian@forum.nginx.org> Так получилось, что я немного "забил" на этот модуль, когда ушел с того места работы, где его разработка входила в мои основные обязанности. Сейчас я занимаюсь им очень нерегулярно. Однако, раз модулем кто-то пользуется, я постараюсь в будущем уделять ему больше внимания :) Если не трудно, заведите, пожалуйста, баг на гуглокоде. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219804,219878#msg-219878 From nginx-forum на nginx.us Sun Dec 11 17:30:35 2011 From: nginx-forum на nginx.us (anon) Date: Sun, 11 Dec 2011 12:30:35 -0500 Subject: ustats & nginx 1.xx In-Reply-To: <70cb6ddcf6130cedbdb34365e42387f7.NginxMailingListRussian@forum.nginx.org> References: <70cb6ddcf6130cedbdb34365e42387f7.NginxMailingListRussian@forum.nginx.org> Message-ID: 0xc0dec Wrote: ------------------------------------------------------- > Так получилось, что я > немного "забил" на этот > модуль, когда ушел с того > места работы, где его > разработка входила в мои > основные обязанности. > Сейчас я занимаюсь им очень > нерегулярно. Однако, раз > модулем кто-то пользуется, > я постараюсь в будущем > уделять ему больше > внимания :) Если не трудно, > заведите, пожалуйста, баг > на гуглокоде. Как печально. Вы уж пожалуйста не забрасывайте его, т.к. вполне юзабельный для большого количества апстримов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219804,219881#msg-219881 From nginx-forum на nginx.us Sun Dec 11 20:25:41 2011 From: nginx-forum на nginx.us (mennanov) Date: Sun, 11 Dec 2011 15:25:41 -0500 Subject: =?UTF-8?B?cGhwINGE0LDQudC7INC90LUg0L/QsNGA0YHQuNGC0YHRjywg0LAg0L7RgtC00LA=?= =?UTF-8?B?0ZHRgtGB0Y8g0LrQsNC6INC10YHRgtGM?= Message-ID: Здравствуйте, у меня на проекте следующая структура папок: engine/ __index.php webroot/ __images/ __css/ __cms/ ______engine/ _________index.php ______webroot/ _________images/ _________css/ _________js/ ___________uploader/ _____________upload.php ___________jquery/ others/ И такой конфиг: server { listen 8080; server_name glinka.fm; root /home/renat/www/glinka; index index.php index.html; location / { try_files /webroot/$uri /engine/index.php?$args; } location ~ ^/cms/?(.*)$ { try_files /webroot/cms/webroot/$1 /webroot/cms/engine/index.php?$args; } location ~ \.php$ { try_files $uri /webroot/$uri =404; include fastcgi.conf; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219884,219884#msg-219884 From nginx-forum на nginx.us Sun Dec 11 20:27:35 2011 From: nginx-forum на nginx.us (mennanov) Date: Sun, 11 Dec 2011 15:27:35 -0500 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: References: Message-ID: <37a4058acbb9b63a9e01d1317de03778.NginxMailingListRussian@forum.nginx.org> При запросе файла /cms/js/uploader/upload.php (физически это файл /webroot/cms/webroot/js/uploader/upload.php) отдается (скачивается) этот самый php файл, исходный код, т.е. не парсится.. Помогите пжлст Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219884,219885#msg-219885 From nginx-forum на nginx.us Sun Dec 11 22:14:54 2011 From: nginx-forum на nginx.us (VadimK) Date: Sun, 11 Dec 2011 17:14:54 -0500 Subject: =?UTF-8?B?YWxpYXMg0YHQvtC30LTQsNC10YIg0YDQtdC00LjRgNC10LrRgg==?= Message-ID: <7d9813df63b87ffce01967396e7c1031.NginxMailingListRussian@forum.nginx.org> Ситуация следующая: 1. есть сайт site.com расположенный по пути /www/site.com 2. есть движок, расположенный вне сайта. Скажем /www/core Теперь необходимо, что бы при запросе site.com/cms/any.file.txt запрашивался файл /www/core/any.file.txt На локальном компьютере это сделано следующим образом: location ~ ^/cms { alias /www/core/; } и это работает. Но как только ставлю на сервер, то идентичная структура уже не роботает. Почему то получает редирект: Connecting to site.com[XXX.XXX.XXX.XXX]:82... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://site.com:82/cms/license.txt/ [following] --00:05:51-- http://site.com:82/cms/license.txt/ => `index.html' Connecting to site.com[XXX.XXX.XXX.XXX]:82... connected. HTTP request sent, awaiting response... 403 Forbidden 00:05:51 ERROR 403: Forbidden. В логах идет следующее: 2011/12/12 10:58:45 [debug] 25987#0: delete posted event 09EFEEE0 2011/12/12 10:58:45 [debug] 25987#0: accept on 0.0.0.0:82, ready: 0 2011/12/12 10:58:45 [debug] 25987#0: posix_memalign: 09EBCFF0:256 @16 2011/12/12 10:58:45 [debug] 25987#0: *18 accept: 78.56.111.111 fd:5 2011/12/12 10:58:45 [debug] 25987#0: *18 event timer add: 5: 60000:834058065 2011/12/12 10:58:45 [debug] 25987#0: *18 epoll add event: fd:5 op:1 ev:80000001 2011/12/12 10:58:45 [debug] 25987#0: *18 post event 09EFEF48 2011/12/12 10:58:45 [debug] 25987#0: *18 delete posted event 09EFEF48 2011/12/12 10:58:45 [debug] 25987#0: *18 malloc: 09EBED68:660 2011/12/12 10:58:45 [debug] 25987#0: *18 malloc: 09EBF000:1024 2011/12/12 10:58:45 [debug] 25987#0: *18 posix_memalign: 09EBF420:4096 @16 2011/12/12 10:58:45 [debug] 25987#0: *18 http process request line 2011/12/12 10:58:45 [debug] 25987#0: *18 recv: fd:5 119 of 1024 2011/12/12 10:58:45 [debug] 25987#0: *18 http request line: "GET /cms/license.txt HTTP/1.0" 2011/12/12 10:58:45 [debug] 25987#0: *18 http uri: "/cms/license.txt" 2011/12/12 10:58:45 [debug] 25987#0: *18 http args: "" 2011/12/12 10:58:45 [debug] 25987#0: *18 http exten: "txt" 2011/12/12 10:58:45 [debug] 25987#0: *18 http process request header line 2011/12/12 10:58:45 [debug] 25987#0: *18 http header: "User-Agent: Wget/1.8.2" 2011/12/12 10:58:45 [debug] 25987#0: *18 http header: "Host: site.com:82" 2011/12/12 10:58:45 [debug] 25987#0: *18 http header: "Accept: */*" 2011/12/12 10:58:45 [debug] 25987#0: *18 http header: "Connection: Keep-Alive" 2011/12/12 10:58:45 [debug] 25987#0: *18 http header done 2011/12/12 10:58:45 [debug] 25987#0: *18 event timer del: 5: 834058065 2011/12/12 10:58:45 [debug] 25987#0: *18 rewrite phase: 0 2011/12/12 10:58:45 [debug] 25987#0: *18 http script value: "/www/site.com/" 2011/12/12 10:58:45 [debug] 25987#0: *18 http script set $server_web_root 2011/12/12 10:58:45 [debug] 25987#0: *18 test location: ~ "^/cms" 2011/12/12 10:58:45 [debug] 25987#0: *18 using configuration "^/cms" 2011/12/12 10:58:45 [debug] 25987#0: *18 http cl:-1 max:1048576 2011/12/12 10:58:45 [debug] 25987#0: *18 rewrite phase: 2 2011/12/12 10:58:45 [debug] 25987#0: *18 post rewrite phase: 3 2011/12/12 10:58:45 [debug] 25987#0: *18 generic phase: 4 2011/12/12 10:58:45 [debug] 25987#0: *18 generic phase: 5 2011/12/12 10:58:45 [debug] 25987#0: *18 access phase: 6 2011/12/12 10:58:45 [debug] 25987#0: *18 access phase: 7 2011/12/12 10:58:45 [debug] 25987#0: *18 post access phase: 8 2011/12/12 10:58:45 [debug] 25987#0: *18 content phase: 9 2011/12/12 10:58:45 [debug] 25987#0: *18 content phase: 10 2011/12/12 10:58:45 [debug] 25987#0: *18 content phase: 11 2011/12/12 10:58:45 [debug] 25987#0: *18 http script copy: "/www/core/" 2011/12/12 10:58:45 [debug] 25987#0: *18 http filename: "/www/core/" 2011/12/12 10:58:45 [debug] 25987#0: *18 add cleanup: 09EBF998 2011/12/12 10:58:45 [debug] 25987#0: *18 http static fd: -1 2011/12/12 10:58:45 [debug] 25987#0: *18 http dir 2011/12/12 10:58:45 [debug] 25987#0: *18 http finalize request: 301, "/cms/license.txt?" a:1, c:1 2011/12/12 10:58:45 [debug] 25987#0: *18 http special response: 301, "/cms/license.txt?" 2011/12/12 10:58:45 [debug] 25987#0: *18 http set discard body 2011/12/12 10:58:45 [debug] 25987#0: *18 HTTP/1.1 301 Moved Permanently Server: nginx/1.1.10 Date: Mon, 12 Dec 2011 09:58:45 GMT Content-Type: text/html Content-Length: 185 Location: http://site.com:82/cms/license.txt/ Connection: keep-alive Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219890,219890#msg-219890 From zzz на zzz.org.ua Sun Dec 11 22:26:46 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Mon, 12 Dec 2011 00:26:46 +0200 Subject: =?UTF-8?B?UmU6IGFsaWFzINGB0L7Qt9C00LDQtdGCINGA0LXQtNC40YDQtdC60YI=?= In-Reply-To: <7d9813df63b87ffce01967396e7c1031.NginxMailingListRussian@forum.nginx.org> References: <7d9813df63b87ffce01967396e7c1031.NginxMailingListRussian@forum.nginx.org> Message-ID: On Mon, Dec 12, 2011 at 12:14 AM, VadimK wrote: > Ситуация следующая: > 1. есть сайт site.com расположенный по пути > /www/site.com > 2. есть движок, расположенный вне сайта. > Скажем /www/core > > Теперь необходимо, что бы при запросе > site.com/cms/any.file.txt запрашивался файл > /www/core/any.file.txt > > На локальном компьютере это сделано > следующим образом: > location ~ ^/cms { >   alias /www/core/; > } > и это работает. Нужно так: location /cms/ { alias /www/core/; } From server_inc на list.ru Mon Dec 12 04:28:10 2011 From: server_inc на list.ru (=?KOI8-R?Q?=F3=D4=C1=CE=C9=D3=CC=C1=D7?=) Date: Mon, 12 Dec 2011 06:28:10 +0200 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: References: Message-ID: <4EE582DA.8010708@list.ru> 11.12.2011 22:25, mennanov пишет: > Здравствуйте, у меня на проекте > следующая структура папок: > > engine/ > __index.php > webroot/ > __images/ > __css/ > __cms/ > ______engine/ > _________index.php > ______webroot/ > _________images/ > _________css/ > _________js/ > ___________uploader/ > _____________upload.php > ___________jquery/ > others/ > > И такой конфиг: > server { > listen 8080; > server_name glinka.fm; > root /home/renat/www/glinka; > index index.php index.html; > > location / { > try_files /webroot/$uri /engine/index.php?$args; > } > > location ~ ^/cms/?(.*)$ { > try_files /webroot/cms/webroot/$1 > /webroot/cms/engine/index.php?$args; > } > > location ~ \.php$ { > try_files $uri /webroot/$uri =404; > include fastcgi.conf; > } > } > локейшены "~ ^/cms/?(.*)$" и "~ \.php$ " местами поменяйте. From nginx-forum на nginx.us Mon Dec 12 05:56:05 2011 From: nginx-forum на nginx.us (redline) Date: Mon, 12 Dec 2011 00:56:05 -0500 Subject: =?UTF-8?B?YXV0b2luZGV4INC00LvRjyAiPSIgbG9jYXRpb24=?= Message-ID: Нужно для конкретной директории задать "autoindex on". Если указать точный location с "autoindex on", то при обращении к нему выдается 403 Пример конфигурации: ===== #user nobody; worker_processes 1; events { worker_connections 1024; } http { server { listen 80; server_name localhost; charset utf-8; #без этого autoindex не работает совсем root ../root; index index.html location = /img { autoindex on; } } } ===== "location /img" и "location ^~ /img" работает как надо. "location ~* ^\/img$" не работает. Существует ли решение или это баг? error_log: [error] 384#6520: *35 directory index of "disk:\folder\nginx/../root/img/" is forbidden, client: 127.0.0.1, server: localhost, request: "GET /img/ HTTP/1.1", host: "localhost" OS WinXP/nginx v1.1.10 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219897,219897#msg-219897 From ekruglov на gmail.com Mon Dec 12 07:30:43 2011 From: ekruglov на gmail.com (Kruglov Eugenie) Date: Mon, 12 Dec 2011 10:30:43 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQsNCy0LAg0LTQvtGB0YLRg9C/0LAg0L3QsCBmYXN0Y2dpX2NhY2hl?= =?UTF-8?B?X3BhdGg=?= In-Reply-To: <4EE25AC8.7050408@gmail.com> References: <4EE100F8.70607@gmail.com> <201112091309.27898.ne@vbart.ru> <4EE25AC8.7050408@gmail.com> Message-ID: http://labs.frickle.com/nginx_ngx_cache_purge/ этот модуль вам поможет. 2011/12/9 Константин > 09.12.11 11:09, Валентин Бартенев пишет: > > On Thursday 08 December 2011 22:24:56 Константин wrote: > >> Здравствуйте! > >> > >> Подскажите, как можно задавать права доступа для создаваемых файлов и > >> каталогов (нужны rw для группы, по умолчанию используется 700) при > >> использовании кеширования. > >> > >> Значение переменной fastcgi_store_access похоже на это никак не влияет > :( > >> > >> При необходимости бы пересобрал nginx с нужными патчами, знать бы где > >> это исправить :) > >> > > > > А для чего это понадобилось, если не секрет? > > Иногда требуется быстро удалить закешированный ответ. Как это сделать > через nginx я не знаю. > Самый просто вариант, который сейчас реализован - это по крону от > пользователя www запускается скрипт, который удаляет нужные файлы. > > > Да я вроде бы как нашел фун-ию ngx_create_path в core/ngx_file.c но как > бы не затронуть чего лишнего :) > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Faithfully yours, Eugenie ICQ #701217 GTalk ekruglov на gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на nginx.us Mon Dec 12 08:23:11 2011 From: nginx-forum на nginx.us (mennanov) Date: Mon, 12 Dec 2011 03:23:11 -0500 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: <4EE582DA.8010708@list.ru> References: <4EE582DA.8010708@list.ru> Message-ID: <5aae9e7df7570473a29225d3428b4fbc.NginxMailingListRussian@forum.nginx.org> San Wrote: ------------------------------------------------------- > 11.12.2011 22:25, mennanov пишет: > > Здравствуйте, у меня на > проекте > > следующая структура > папок: > > > > engine/ > > __index.php > > webroot/ > > __images/ > > __css/ > > __cms/ > > ______engine/ > > _________index.php > > ______webroot/ > > _________images/ > > _________css/ > > _________js/ > > ___________uploader/ > > _____________upload.php > > ___________jquery/ > > others/ > > > > И такой конфиг: > > server { > > listen 8080; > > server_name glinka.fm; > > root /home/renat/www/glinka; > > index index.php index.html; > > > > location / { > > try_files /webroot/$uri > /engine/index.php?$args; > > } > > > > location ~ ^/cms/?(.*)$ { > > try_files /webroot/cms/webroot/$1 > > /webroot/cms/engine/index.php?$args; > > } > > > > location ~ \.php$ { > > try_files $uri /webroot/$uri =404; > > include fastcgi.conf; > > } > > } > > > локейшены "~ ^/cms/?(.*)$" и "~ \.php$ " > местами поменяйте. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Поменял, теперь 404 ошибка. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219884,219899#msg-219899 From ne на vbart.ru Mon Dec 12 08:36:10 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 12:36:10 +0400 Subject: =?UTF-8?B?UmU6IGF1dG9pbmRleCDQtNC70Y8gIj0iIGxvY2F0aW9u?= In-Reply-To: References: Message-ID: <201112121236.10648.ne@vbart.ru> On Monday 12 December 2011 09:56:05 redline wrote: > Нужно для конкретной директории задать > "autoindex on". > Если указать точный location с "autoindex on", то > при обращении к нему выдается 403 > Пример конфигурации: > ===== > #user nobody; > worker_processes 1; > events { > worker_connections 1024; > } > http { > server { > listen 80; > server_name localhost; > charset utf-8; #без этого autoindex не работает > совсем > root ../root; > index index.html > location = /img { > autoindex on; > } > } > } location = /img { autoindex on; } Обращение к директории, т. е. к /img/ сюда очевидно не попадет. > "location ~* ^\/img$" не работает. И сюда тоже. > Существует ли решение или это баг? location = /img/ { autoindex on; } -- Валентин Бартенев From ingvar на westsib.ru Mon Dec 12 08:36:56 2011 From: ingvar на westsib.ru (Igor V. Fatkulin) Date: Mon, 12 Dec 2011 15:36:56 +0700 Subject: =?UTF-8?B?0L3QtSDRgdC+0LHQuNGA0LDQtdGC0YHRjyByZXdyaXRl?= Message-ID: <14610141630.20111212153656@westsib.ru> Всего доброго дня. Такая проблема - поставил nginx 1.0.10 из портов на FreeBSD 9.0-RC3, тестовая виртуалка. При сборке галка на rewrite стояла, в конфигах порта тоже вроде бы опции сохранились, но nginx -V не показывает rewrite среди включенных модулей и конструкция в конфиге if( !-e $request_filename ) { rewrite (.*) /index.php$1 } при старте выдает testation# ./nginx start Performing sanity check on nginx configuration: nginx: [emerg] unknown directive "if(" in /usr/local/etc/nginx/nginx.conf:42 nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed В чем может быть дело? Спасибо, Игорь -------------- next part -------------- An HTML attachment was scrubbed... URL: From trent.clainor на gmail.com Mon Dec 12 08:39:21 2011 From: trent.clainor на gmail.com (Albert Mikhaylov) Date: Mon, 12 Dec 2011 12:39:21 +0400 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: <5aae9e7df7570473a29225d3428b4fbc.NginxMailingListRussian@forum.nginx.org> References: <4EE582DA.8010708@list.ru> <5aae9e7df7570473a29225d3428b4fbc.NginxMailingListRussian@forum.nginx.org> Message-ID: если в fastcgi.conf не содержится fastcgi_pass, то добавьте его в локейшн location ~ \.php$ { 12 декабря 2011 г. 12:23 пользователь mennanov написал: > San Wrote: > ------------------------------------------------------- > > 11.12.2011 22:25, mennanov пишет: > > > Здравствуйте, у меня на > > проекте > > > следующая структура > > папок: > > > > > > engine/ > > > __index.php > > > webroot/ > > > __images/ > > > __css/ > > > __cms/ > > > ______engine/ > > > _________index.php > > > ______webroot/ > > > _________images/ > > > _________css/ > > > _________js/ > > > ___________uploader/ > > > _____________upload.php > > > ___________jquery/ > > > others/ > > > > > > И такой конфиг: > > > server { > > > listen 8080; > > > server_name glinka.fm; > > > root /home/renat/www/glinka; > > > index index.php index.html; > > > > > > location / { > > > try_files /webroot/$uri > > /engine/index.php?$args; > > > } > > > > > > location ~ ^/cms/?(.*)$ { > > > try_files /webroot/cms/webroot/$1 > > > /webroot/cms/engine/index.php?$args; > > > } > > > > > > location ~ \.php$ { > > > try_files $uri /webroot/$uri =404; > > > include fastcgi.conf; > > > } > > > } > > > > > локейшены "~ ^/cms/?(.*)$" и "~ \.php$ " > > местами поменяйте. > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Поменял, теперь 404 ошибка. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,219884,219899#msg-219899 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на nginx.us Mon Dec 12 09:01:58 2011 From: nginx-forum на nginx.us (redline) Date: Mon, 12 Dec 2011 04:01:58 -0500 Subject: =?UTF-8?B?UmU6IGF1dG9pbmRleCDQtNC70Y8gIj0iIGxvY2F0aW9u?= In-Reply-To: <201112121236.10648.ne@vbart.ru> References: <201112121236.10648.ne@vbart.ru> Message-ID: <75d0b859c5893cb02ed8909794ab236e.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > > location = /img/ { > autoindex on; > } > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru --------------------- Большое спасибо! Невнимательно прочитал документацию, каюсь. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219897,219904#msg-219904 From nginx-forum на nginx.us Mon Dec 12 09:18:43 2011 From: nginx-forum на nginx.us (mennanov) Date: Mon, 12 Dec 2011 04:18:43 -0500 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: References: Message-ID: <7caab47dbd29865b422108f34e4eb04e.NginxMailingListRussian@forum.nginx.org> Albert Mikhaylov Wrote: ------------------------------------------------------- > если в fastcgi.conf не содержится > fastcgi_pass, то добавьте его в > локейшн location > ~ \.php$ { > > 12 декабря 2011 г. 12:23 > пользователь mennanov > написал: > > > San Wrote: > > > -------------------------------------------------- > ----- > > > 11.12.2011 22:25, mennanov пишет: > > > > Здравствуйте, у меня на > > > проекте > > > > следующая структура > > > папок: > > > > > > > > engine/ > > > > __index.php > > > > webroot/ > > > > __images/ > > > > __css/ > > > > __cms/ > > > > ______engine/ > > > > _________index.php > > > > ______webroot/ > > > > _________images/ > > > > _________css/ > > > > _________js/ > > > > ___________uploader/ > > > > _____________upload.php > > > > ___________jquery/ > > > > others/ > > > > > > > > И такой конфиг: > > > > server { > > > > listen 8080; > > > > server_name glinka.fm; > > > > root /home/renat/www/glinka; > > > > index index.php index.html; > > > > > > > > location / { > > > > try_files /webroot/$uri > > > /engine/index.php?$args; > > > > } > > > > > > > > location ~ ^/cms/?(.*)$ { > > > > try_files /webroot/cms/webroot/$1 > > > > /webroot/cms/engine/index.php?$args; > > > > } > > > > > > > > location ~ \.php$ { > > > > try_files $uri /webroot/$uri =404; > > > > include fastcgi.conf; > > > > } > > > > } > > > > > > > локейшены "~ ^/cms/?(.*)$" и "~ > \.php$ " > > > местами поменяйте. > > > > > > > _______________________________________________ > > > nginx-ru mailing list > > > nginx-ru на nginx.org > > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > Поменял, теперь 404 ошибка. > > > > Posted at Nginx Forum: > > > http://forum.nginx.org/read.php?21,219884,219899#m > sg-219899 > > > > _______________________________________________ > > 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 Там всё есть, всё ок. Дело в том что ДРУГИЕ php файлы работают отлично. Например /webroot/cms/engine/index.php Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219884,219908#msg-219908 From ne на vbart.ru Mon Dec 12 09:25:22 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 13:25:22 +0400 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sICDQsCDQvtGC?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: <7caab47dbd29865b422108f34e4eb04e.NginxMailingListRussian@forum.nginx.org> References: <7caab47dbd29865b422108f34e4eb04e.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112121325.22603.ne@vbart.ru> On Monday 12 December 2011 13:18:43 mennanov wrote: [...] > > Там всё есть, всё ок. Дело в том что > ДРУГИЕ php файлы работают отлично. > Например /webroot/cms/engine/index.php > Потому, что они попадают в другой location. У вас в корне не верный конфиг. Запрос: /cms/js/uploader/upload.php попадет сюда: location ~ ^/cms/?(.*)$ { try_files /webroot/cms/webroot/$1 /webroot/cms/engine/index.php?$args; } try_files убедиться, что файл существует, и он будет обработан в текущем локейшене, т. е. отдан как статический. -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 12 09:28:51 2011 From: nginx-forum на nginx.us (mennanov) Date: Mon, 12 Dec 2011 04:28:51 -0500 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: <201112121325.22603.ne@vbart.ru> References: <201112121325.22603.ne@vbart.ru> Message-ID: А как его передать в php-fpm? Или какой тогда location сделать..? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219884,219910#msg-219910 From mdounin на mdounin.ru Mon Dec 12 09:50:04 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 12 Dec 2011 13:50:04 +0400 Subject: =?UTF-8?B?UmU6INC90LUg0YHQvtCx0LjRgNCw0LXRgtGB0Y8gcmV3cml0ZQ==?= In-Reply-To: <14610141630.20111212153656@westsib.ru> References: <14610141630.20111212153656@westsib.ru> Message-ID: <20111212095004.GM67687@mdounin.ru> Hello! On Mon, Dec 12, 2011 at 03:36:56PM +0700, Igor V. Fatkulin wrote: > > Всего доброго дня. > > Такая проблема - поставил nginx 1.0.10 из портов на FreeBSD > 9.0-RC3, тестовая виртуалка. > При сборке галка на rewrite стояла, в конфигах порта тоже вроде > бы опции сохранились, но nginx -V не показывает rewrite среди > включенных модулей и конструкция в конфиге Модуль rewrite собирается по умолчанию, если сборка не запрещена явно. > if( !-e $request_filename ) { > rewrite (.*) /index.php$1 > } > при старте выдает > testation# ./nginx start > Performing sanity check on nginx configuration: > nginx: [emerg] unknown directive "if(" in /usr/local/etc/nginx/nginx.conf:42 > nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed > > В чем может быть дело? Директива называется "if", а не "if(". Пробел нужен. Впрочем, скорее всего в данной конструкции правильнее использовать try_files. Maxim Dounin From public-mail на alekciy.ru Mon Dec 12 09:54:03 2011 From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Mon, 12 Dec 2011 13:54:03 +0400 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sINCwINC+0YI=?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: References: <201112121325.22603.ne@vbart.ru> Message-ID: При таком конфиге: server { listen 8080; server_name glinka.fm; root /home/renat/www/glinka; index index.php index.html; location / { try_files $uri $uri/ @backend; } location ~ \.php$ { try_files $uri @backend; fastcgi_pass unix:путь_до_сокета; include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /home/renat/www/glinka$fastcgi_script_name; } location @backend { fastcgi_pass unix:путь_до_сокета; include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /home/renat/www/glinka/index.php; fastcgi_param SCRIPT_NAME index.php; fastcgi_param QUERY_STRING q=$uri&$args; fastcgi_param REQUEST_URI q=$uri&$args; fastcgi_param DOCUMENT_ROOT /home/renat/www/glinka; } } Если PHP файл существует, то будет выполнен как PHP, а не отдан как статика. Если файла нет, то запрос будет отдан в /home/renat/www/glinka/index.php который будет обрабатывается как PHP файл. Возможный минус - запрос будет отдан для любого несуществующего файла (jpg, png и прочие подобные статические), т.е. PHP бэкэнд будет каждый раз дергаться и должен будет самостоятельно отдать nginx 404 статус (если необходимо). Хотя лично для меня это плюс ибо позволяет на уровне приложения получать все запросы и в зависимости по ситуации возвращать результат. К примеру, динамически создать картинку. 12 декабря 2011 г. 13:28 пользователь mennanov написал: > А как его передать в php-fpm? Или какой > тогда location сделать..? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219884,219910#msg-219910 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ne на vbart.ru Mon Dec 12 09:55:52 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 13:55:52 +0400 Subject: =?UTF-8?B?UmU6IHBocCDRhNCw0LnQuyDQvdC1INC/0LDRgNGB0LjRgtGB0Y8sICDQsCDQvtGC?= =?UTF-8?B?0LTQsNGR0YLRgdGPINC60LDQuiDQtdGB0YLRjA==?= In-Reply-To: References: <201112121325.22603.ne@vbart.ru> Message-ID: <201112121355.52590.ne@vbart.ru> On Monday 12 December 2011 13:28:51 mennanov wrote: > А как его передать в php-fpm? Или какой > тогда location сделать..? > В зависимости от того, что вам нужно. Из вашего конфига вообще не очень понятно что вы хотели изобразить. Читайте документацию. Подозреваю, что хотели что-то вроде этого: server { listen 8080; server_name glinka.fm; root /home/renat/www/glinka/webroot; location / { try_files $uri @cms_engine; } location /cms/ { alias /cms/webroot/; try_files $uri @engine; } location /cms/js/uploader/upload.php { # соответствующие настройки fastcgi } location @engine { # соответствующие настройки fastcgi } location @cms_engine { # соответствующие настройки fastcgi } } -- Валентин Бартенев From ingvar на westsib.ru Mon Dec 12 10:08:11 2011 From: ingvar на westsib.ru (Igor V. Fatkulin) Date: Mon, 12 Dec 2011 17:08:11 +0700 Subject: =?UTF-8?B?UmU6INC90LUg0YHQvtCx0LjRgNCw0LXRgtGB0Y8gcmV3cml0ZQ==?= In-Reply-To: <20111212095004.GM67687@mdounin.ru> References: <14610141630.20111212153656@westsib.ru> <20111212095004.GM67687@mdounin.ru> Message-ID: <852206891.20111212170811@westsib.ru> MD> Директива называется "if", а не "if(". Пробел нужен. Точно, спасибо. Давно не конфигурил, забыл) MD> Впрочем, скорее всего в данной конструкции правильнее использовать MD> try_files. Поясните, если не трудно, почему и как именно правильнее? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Mon Dec 12 10:11:14 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 12 Dec 2011 14:11:14 +0400 Subject: =?UTF-8?B?UmU6INC90LUg0YHQvtCx0LjRgNCw0LXRgtGB0Y8gcmV3cml0ZQ==?= In-Reply-To: <852206891.20111212170811@westsib.ru> References: <14610141630.20111212153656@westsib.ru> <20111212095004.GM67687@mdounin.ru> <852206891.20111212170811@westsib.ru> Message-ID: <20111212101114.GQ67687@mdounin.ru> Hello! On Mon, Dec 12, 2011 at 05:08:11PM +0700, Igor V. Fatkulin wrote: > > > MD> Директива называется "if", а не "if(". Пробел нужен. > > Точно, спасибо. Давно не конфигурил, забыл) > > MD> Впрочем, скорее всего в данной конструкции правильнее использовать > MD> try_files. > > Поясните, если не трудно, почему и как именно правильнее? http://wiki.nginx.org/IfIsEvil http://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files Maxim Dounin From thresh на videolan.org Mon Dec 12 11:41:58 2011 From: thresh на videolan.org (Konstantin Pavlov) Date: Mon, 12 Dec 2011 15:41:58 +0400 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzRiyDRgSBuZ2lueCDQsiDRgNC10LbQuNC80LUgcHJveHlf?= =?UTF-8?B?cGFzcyDRgSBhbWF6b24g0LggY2hyb21lL2Nocm9taXVt?= Message-ID: <20111212114158.GX13414@snowwhite.immo> Добрый день. Есть некоторые проблемы с google chrome / chromium и nginx при использовании nginx как кэширующего сервера для забирания bucket'ов с amazon. Примерно один из 10ти запросов на mp3-файл приводит к тому, что google chrome / chromium не воспроизводит этот mp3-файл. При запросах напрямую на amazon bucket проблема не проявляется. /etc/nginx/nginx.conf: worker_processes 30; events { worker_connections 1024; } http { client_max_body_size 1024m; proxy_connect_timeout 30s; proxy_read_timeout 60s; proxy_send_timeout 60s; proxy_cache_path /var/lib/nginx/tmp/proxy/cache/ keys_zone=cache:1024m max_size=30000m; merge_slashes off; ignore_invalid_headers off; proxy_temp_path /var/lib/nginx/tmp/proxy; fastcgi_temp_path /var/lib/nginx/tmp/fastcgi; client_body_temp_path /var/lib/nginx/tmp/client; include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent $sent_http_content_length ' '"$http_user_agent" "$http_x_forwarded_for"'; keepalive_timeout 0; sendfile off; gzip off; server { listen 80; server_name download-mp3.domain.tld; location = /favicon.ico { return 204; } location / { proxy_pass http://downloadtld-mp3.s3.amazonaws.com/; proxy_next_upstream error timeout http_500 http_502 http_503 http_504; proxy_redirect off; proxy_cache cache; proxy_cache_valid 1d; expires 604800; proxy_hide_header X-Amz-Id-2; proxy_hide_header X-Amz-Request-Id; proxy_hide_header ETag; proxy_hide_header Last-Modified; } access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log debug; } } При возникновении проблемы, в error.log трижды пишется "client closed prematurely connection while reading upstream". От файла не зависит, при вызове URL в строке браузера один раз может пройти ошибка, второй раз файл может закачаться и воспроизводиться нормально. Сслучается такое и на файлы, которые уже должны быть в кэше, т.е. когда иду по списку URL'ов заново, оно опять может проявиться на тех файлах, на которые уже были запросы. debug_connection по моему адресу выдаёт огромную тонну информации, разобраться что именно идёт не так не получается. Что может быть не так? -- Konstantin Pavlov VideoLAN team From nginx-forum на nginx.us Mon Dec 12 14:50:17 2011 From: nginx-forum на nginx.us (Maximus43) Date: Mon, 12 Dec 2011 09:50:17 -0500 Subject: =?UTF-8?B?0JrQsNC6ICLQv9C+0YfQuNGB0YLQuNGC0YwiINC90LXQstC10YDQvdGD0Y4g0YE=?= =?UTF-8?B?0YHRi9C70LrRgyDQvdCwINGB0LDQudGCPw==?= Message-ID: <2e0a56ddd813bb1690d5af2012f75f8b.NginxMailingListRussian@forum.nginx.org> С добавлением слеша в конец ссылки (если нет расширения) и редиректом тут разобрались (http://forum.nginx.org/read.php?21,215281,215281#msg-215281), спасибо большое! У меня возникла задачка "почистить" неверные ссылки на сайт. Смотрю лог ошибок и вижу, что есть несколько ссылок со сторонних ресурсов, которые оканчиваются на %C2%A0. Т.е. получается примерно такая ссылка: http://example.com/topic1/%C2%A0 Эти символы не отображаются, после добавления слеша получается http://example.com/topic1/%C2%A0/, что в строке браузера выглядит как http://example.com/topic1/ / Естественно, сервер выдает 404 ошибку. Это ошибка на стороне клиента, но все равно не хочется терять этот трафик. Как почистить запрос от таких символов в конце без ущерба кириллице (у меня нет кириллических разделов на сайте, но интересует системное решение)? Заранее спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219933,219933#msg-219933 From mdounin на mdounin.ru Mon Dec 12 15:06:54 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 12 Dec 2011 19:06:54 +0400 Subject: nginx-1.1.11 Message-ID: <20111212150654.GX67687@mdounin.ru> Изменения в nginx 1.1.11 12.12.2011 *) Добавление: параметр so_keepalive в директиве listen. Спасибо Всеволоду Стахову. *) Добавление: параметр if_not_empty в директивах fastcgi/scgi/uwsgi_param. *) Добавление: переменная $https. *) Добавление: директива proxy_redirect поддерживает переменные в первом параметре. *) Добавление: директива proxy_redirect поддерживает регулярные выражения. *) Исправление: переменная $sent_http_cache_control могла содержать неверное значение при использовании директивы expires. Спасибо Yichun Zhang. *) Исправление: директива read_ahead могла не работать при использовании совместно с try_files и open_file_cache. *) Исправление: если в параметре inactive директивы proxy_cache_path было указано малое время, в рабочем процессе мог произойти segmentation fault. *) Исправление: ответы из кэша могли зависать. Maxim Dounin From postmaster на softsearch.ru Mon Dec 12 16:26:23 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 12 Dec 2011 20:26:23 +0400 Subject: nginx-1.1.11 In-Reply-To: <20111212150654.GX67687@mdounin.ru> References: <20111212150654.GX67687@mdounin.ru> Message-ID: <653185266.20111212202623@softsearch.ru> Здравствуйте, Maxim. > *) Добавление: параметр so_keepalive в директиве listen. > Спасибо Всеволоду Стахову. А что он делает? -- С уважением, Михаил mailto:postmaster на softsearch.ru From ne на vbart.ru Mon Dec 12 16:29:05 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 20:29:05 +0400 Subject: nginx-1.1.11 In-Reply-To: <653185266.20111212202623@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <653185266.20111212202623@softsearch.ru> Message-ID: <201112122029.06053.ne@vbart.ru> On Monday 12 December 2011 20:26:23 Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Добавление: параметр so_keepalive в директиве listen. > > > > Спасибо Всеволоду Стахову. > > А что он делает? Управляет флагом SO_KEEPALIVE на сокете. http://nginx.org/en/docs/http/ngx_http_core_module.html#listen -- Валентин Бартенев From ne на vbart.ru Mon Dec 12 16:39:59 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 20:39:59 +0400 Subject: =?UTF-8?B?UmU6IFNDR0kg0Lgg0YHQttCw0YLQuNC1INC+0YLQstC10YLQvtCy?= In-Reply-To: References: Message-ID: <201112122039.59347.ne@vbart.ru> On Thursday 08 December 2011 18:20:09 excanoe wrote: > Столкнулся с данной ошибкой: ответы от > scgi сервера не сжимаются. > [...] Попробуйте в конфиге прописать: gzip_http_version 1.0; -- Валентин Бартенев From postmaster на softsearch.ru Mon Dec 12 16:57:34 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 12 Dec 2011 20:57:34 +0400 Subject: nginx-1.1.11 In-Reply-To: <201112122029.06053.ne@vbart.ru> References: <20111212150654.GX67687@mdounin.ru> <653185266.20111212202623@softsearch.ru> <201112122029.06053.ne@vbart.ru> Message-ID: <1325537189.20111212205734@softsearch.ru> Здравствуйте, Валентин. >> > *) Добавление: параметр so_keepalive в директиве listen. >> > >> > Спасибо Всеволоду Стахову. >> >> А что он делает? > Управляет флагом SO_KEEPALIVE на сокете. > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen Спасибо. Смотрел русскую доку, там ничего не было. Скажите пожалуйста, для FreeBSD этот параметр работает? Я почему-то думал, что директива keepalive указывает когда закрывать tcp-соединения. Поясните пожалуйста, в чём разница? -- С уважением, Михаил mailto:postmaster на softsearch.ru From nginx-forum на nginx.us Mon Dec 12 17:02:20 2011 From: nginx-forum на nginx.us (excanoe) Date: Mon, 12 Dec 2011 12:02:20 -0500 Subject: =?UTF-8?B?UmU6IFNDR0kg0Lgg0YHQttCw0YLQuNC1INC+0YLQstC10YLQvtCy?= In-Reply-To: <201112122039.59347.ne@vbart.ru> References: <201112122039.59347.ne@vbart.ru> Message-ID: <1a1dfc86504fbe85040f8b9c9a1b8f27.NginxMailingListRussian@forum.nginx.org> Благодарю, работает. Но не могу понять, почему? В случае с php это ненужно если я не ошибаюсь. Есть ли у этого метода какие-либо недостатки? (я же использую протокол http 1.1) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219800,219945#msg-219945 From vladimir на greenmice.info Mon Dec 12 17:12:02 2011 From: vladimir на greenmice.info (Vladimir Rusinov) Date: Mon, 12 Dec 2011 21:12:02 +0400 Subject: nginx-1.1.11 In-Reply-To: <1325537189.20111212205734@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <653185266.20111212202623@softsearch.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> Message-ID: 2011/12/12 Михаил Монашёв > Здравствуйте, Валентин. > > >> > *) Добавление: параметр so_keepalive в директиве listen. > >> > > >> > Спасибо Всеволоду Стахову. > >> > >> А что он делает? > > > Управляет флагом SO_KEEPALIVE на сокете. > > > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > > Спасибо. Смотрел русскую доку, там ничего не было. > > Скажите пожалуйста, для FreeBSD этот параметр работает? > > Я почему-то думал, что директива keepalive указывает когда закрывать > tcp-соединения. Поясните пожалуйста, в чём разница? > keepalive относится к протоколу http и управляет как долго соединение может висеть открытым. so_keepalive включает/отключает периодическую отправке tcp пакетов для проверки живо ли еще соедниение, см h ttp://www.unixguide.net/network/socketfaq/4.7.shtml -- Vladimir Rusinov http://greenmice.info/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kobzar на itcraft.org Mon Dec 12 17:15:11 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Mon, 12 Dec 2011 19:15:11 +0200 Subject: nginx-1.1.11 In-Reply-To: <1325537189.20111212205734@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <653185266.20111212202623@softsearch.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> Message-ID: <4EE6369F.6090708@itcraft.org> On 12/12/11 18:57, Михаил Монашёв wrote: >> http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > > Спасибо. Смотрел русскую доку, там ничего не было. Так а какая документация на данный момент более полная - ru/en? Разницы нет - главное полнота изложения и своевременное обновление. From ne на vbart.ru Mon Dec 12 17:17:22 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 21:17:22 +0400 Subject: =?UTF-8?B?UmU6IFNDR0kg0Lgg0YHQttCw0YLQuNC1INC+0YLQstC10YLQvtCy?= In-Reply-To: <1a1dfc86504fbe85040f8b9c9a1b8f27.NginxMailingListRussian@forum.nginx.org> References: <201112122039.59347.ne@vbart.ru> <1a1dfc86504fbe85040f8b9c9a1b8f27.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112122117.22285.ne@vbart.ru> On Monday 12 December 2011 21:02:20 excanoe wrote: > Но не могу понять, почему? В случае с php > это ненужно если я не ошибаюсь. > Есть ли у этого метода какие-либо > недостатки? (я же использую протокол http > 1.1) > Это workaround. Баг действительно имел место быть. Можете воспользоваться патчем, устраняющим проблему: http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001587.html -- Валентин Бартенев From ne на vbart.ru Mon Dec 12 17:29:06 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 12 Dec 2011 21:29:06 +0400 Subject: nginx-1.1.11 In-Reply-To: <1325537189.20111212205734@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> Message-ID: <201112122129.06757.ne@vbart.ru> On Monday 12 December 2011 20:57:34 Михаил Монашёв wrote: [...] > > Скажите пожалуйста, для FreeBSD этот параметр работает? > Насколько мне известно, SO_KEEPALIVE (не путать с http keep-alive соединениями) во FreeBSD с давних пор по-умолчанию включен для всех сокетов: net.inet.tcp.always_keepalive=1 (/etc/defaults/rc.conf), если не переопределили. С помощью listen so_keepalive=off можно принудительно выключить для конкретного сокета nginx, если хочется. -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 12 17:32:52 2011 From: nginx-forum на nginx.us (excanoe) Date: Mon, 12 Dec 2011 12:32:52 -0500 Subject: =?UTF-8?B?UmU6IFNDR0kg0Lgg0YHQttCw0YLQuNC1INC+0YLQstC10YLQvtCy?= In-Reply-To: <201112122117.22285.ne@vbart.ru> References: <201112122117.22285.ne@vbart.ru> Message-ID: <8fd246587bd7eb518a963181c87004fa.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Monday 12 December 2011 21:02:20 excanoe wrote: > > Но не могу понять, почему? > В случае с php > > это ненужно если я не > ошибаюсь. > > Есть ли у этого метода > какие-либо > > недостатки? (я же > использую протокол http > > 1.1) > > > > Это workaround. Баг > действительно имел место > быть. > > Можете воспользоваться > патчем, устраняющим > проблему: > http://mailman.nginx.org/pipermail/nginx-devel/201 > 1-December/001587.html > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Благодарю! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219800,219952#msg-219952 From postmaster на softsearch.ru Mon Dec 12 18:06:32 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 12 Dec 2011 22:06:32 +0400 Subject: nginx-1.1.11 In-Reply-To: <201112122129.06757.ne@vbart.ru> References: <20111212150654.GX67687@mdounin.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> <201112122129.06757.ne@vbart.ru> Message-ID: <119815183.20111212220632@softsearch.ru> Здравствуйте, Валентин. Скажите пожалуйста, в каких задачах SO_KEEPALIVE может потребоваться? -- С уважением, Михаил mailto:postmaster на softsearch.ru From zzz на zzz.org.ua Mon Dec 12 18:22:04 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Mon, 12 Dec 2011 20:22:04 +0200 Subject: nginx-1.1.11 In-Reply-To: <119815183.20111212220632@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> <201112122129.06757.ne@vbart.ru> <119815183.20111212220632@softsearch.ru> Message-ID: On Mon, Dec 12, 2011 at 8:06 PM, Михаил Монашёв wrote: > Скажите пожалуйста, в каких задачах SO_KEEPALIVE может потребоваться? Тоже не очень понятен смысл фичи для HTTP. Тут же все операции с таймерами, никто не держит соединение, если оно неактивно, а закрывает по таймауту. From mdounin на mdounin.ru Mon Dec 12 18:24:14 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 12 Dec 2011 22:24:14 +0400 Subject: nginx-1.1.11 In-Reply-To: <119815183.20111212220632@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> <201112122129.06757.ne@vbart.ru> <119815183.20111212220632@softsearch.ru> Message-ID: <20111212182413.GA67687@mdounin.ru> Hello! On Mon, Dec 12, 2011 at 10:06:32PM +0400, Михаил Монашёв wrote: > Здравствуйте, Валентин. > > Скажите пожалуйста, в каких задачах SO_KEEPALIVE может потребоваться? В http - для всякого long polling'а. Maxim Dounin From chipitsine на gmail.com Mon Dec 12 18:24:31 2011 From: chipitsine на gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Tue, 13 Dec 2011 00:24:31 +0600 Subject: ustats & nginx 1.xx In-Reply-To: References: Message-ID: код самодельного модуля? конфиг, на котором все падает? 9 декабря 2011 г. 11:34 пользователь Vladimir Romanov написал: > Он у меня приводит к сигфолту на первом запросе к бакенду. > "nginx падает на 1149 строчке > nginx/nginx/src/http/ngx_http_upstream.c, код как-раз под ustats-овым > ifdef-ом. > Хронология следующая - ддф находит апстрим, открывает соединение с > сервером, однако ничего не успевает передать, падает в районе > ngx_atomic_fetch_add" > Страница статистики (с нулями) показывается, но в ней нет backup серверов. > > 2011/12/9 Евгений 'Rush' Непомнящий : >> Ох не царское это дело :) Впрочем на http://code.google.com/p/ustats/ >> написано, что тестился для 1.0.10. У вас он как не завёлся >> (компиляция/рантайм) и с какой версией? >> >> 8 декабря 2011 г. 20:09 пользователь Vladimir Romanov >> написал: >>> ustats >> >> >> >> -- >> Cogito ergo sum >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Vladimir Romanov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From public-mail на alekciy.ru Mon Dec 12 18:31:46 2011 From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Mon, 12 Dec 2011 22:31:46 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: <20111212114158.GX13414@snowwhite.immo> References: <20111212114158.GX13414@snowwhite.immo> Message-ID: "Не так" тут видимо google chrome. Не раз сталкивался с тем, что у него виденее того что и как нужно кэшировать и то, что работает как задумано в других браузерах не работает в хроме, причем даже принудительная зачистка кэша не спасает. Видится мне, что если проблема проявляется только в хроне и ни каких других браузерах, то дело в хроме, а не nginx. 12 декабря 2011 г. 15:41 пользователь Konstantin Pavlov написал: > Добрый день. > > Есть некоторые проблемы с google chrome / chromium и nginx при > использовании nginx как кэширующего сервера для забирания bucket'ов с > amazon. > > Примерно один из 10ти запросов на mp3-файл приводит к тому, что google > chrome / chromium не воспроизводит этот mp3-файл.  При запросах напрямую > на amazon bucket проблема не проявляется. > > /etc/nginx/nginx.conf: > > worker_processes  30; > > events { >    worker_connections  1024; > } > > http { >    client_max_body_size 1024m; >    proxy_connect_timeout 30s; >    proxy_read_timeout 60s; >    proxy_send_timeout 60s; > >    proxy_cache_path /var/lib/nginx/tmp/proxy/cache/ keys_zone=cache:1024m max_size=30000m; > >    merge_slashes off; >    ignore_invalid_headers  off; > >    proxy_temp_path /var/lib/nginx/tmp/proxy; >    fastcgi_temp_path /var/lib/nginx/tmp/fastcgi; >    client_body_temp_path /var/lib/nginx/tmp/client; > >    include       mime.types; >    default_type  application/octet-stream; > >    log_format main '$remote_addr - $remote_user [$time_local] ' >                        '"$request" $status $bytes_sent $sent_http_content_length ' >                        '"$http_user_agent" "$http_x_forwarded_for"'; > >    keepalive_timeout     0; >    sendfile        off; >    gzip  off; > >    server { > >        listen 80; >        server_name download-mp3.domain.tld; > >        location = /favicon.ico { >                return 204; >        } > >        location / { > >        proxy_pass http://downloadtld-mp3.s3.amazonaws.com/; >        proxy_next_upstream error timeout http_500 http_502 http_503 http_504; >        proxy_redirect     off; >        proxy_cache cache; >        proxy_cache_valid 1d; >        expires 604800; >        proxy_hide_header X-Amz-Id-2; >        proxy_hide_header X-Amz-Request-Id; >        proxy_hide_header ETag; >        proxy_hide_header Last-Modified; > >        } > >        access_log  /var/log/nginx/access.log main; >        error_log   /var/log/nginx/error.log debug; > >    } > > } > > > При возникновении проблемы, в error.log трижды пишется "client closed > prematurely connection while reading upstream". > От файла не зависит, при вызове URL в строке браузера один раз может пройти > ошибка, второй раз файл может закачаться и воспроизводиться нормально. > Сслучается такое и на файлы, которые уже должны быть в кэше, т.е. когда иду по > списку URL'ов заново, оно опять может проявиться на тех файлах, на которые уже > были запросы. > > debug_connection по моему адресу выдаёт огромную тонну информации, разобраться > что именно идёт не так не получается. > > Что может быть не так? > > -- > Konstantin Pavlov > VideoLAN team > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From public-mail на alekciy.ru Mon Dec 12 18:36:36 2011 From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Mon, 12 Dec 2011 22:36:36 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiAi0L/QvtGH0LjRgdGC0LjRgtGMIiDQvdC10LLQtdGA0L3Rg9GO?= =?UTF-8?B?INGB0YHRi9C70LrRgyDQvdCwINGB0LDQudGCPw==?= In-Reply-To: <2e0a56ddd813bb1690d5af2012f75f8b.NginxMailingListRussian@forum.nginx.org> References: <2e0a56ddd813bb1690d5af2012f75f8b.NginxMailingListRussian@forum.nginx.org> Message-ID: Создать свою 404-ую страницу с поддержкой серверного языка (например, PHP) и в нем реализовать логику обработки этих ситуаций. К примеру, слать редиректом на правильный адрес. 12 декабря 2011 г. 18:50 пользователь Maximus43 написал: > С добавлением слеша в конец ссылки > (если нет расширения) и редиректом тут > разобрались > (http://forum.nginx.org/read.php?21,215281,215281#msg-215281), > спасибо большое! > У меня возникла задачка "почистить" > неверные ссылки на сайт. Смотрю лог > ошибок и вижу, что есть несколько > ссылок со сторонних ресурсов, которые > оканчиваются на %C2%A0. > Т.е. получается примерно такая ссылка: > http://example.com/topic1/%C2%A0 > Эти символы не отображаются, после > добавления слеша получается > http://example.com/topic1/%C2%A0/, что в строке > браузера выглядит как  http://example.com/topic1/ / > Естественно, сервер выдает 404 ошибку. > Это ошибка на стороне клиента, но все > равно не хочется терять этот трафик. > Как почистить запрос от таких символов > в конце без ущерба кириллице (у меня нет > кириллических разделов на сайте, но > интересует системное решение)? > > Заранее спасибо! > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219933,219933#msg-219933 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From ru на nginx.com Mon Dec 12 19:45:16 2011 From: ru на nginx.com (Ruslan Ermilov) Date: Mon, 12 Dec 2011 23:45:16 +0400 Subject: nginx-1.1.11 In-Reply-To: <1325537189.20111212205734@softsearch.ru> References: <20111212150654.GX67687@mdounin.ru> <653185266.20111212202623@softsearch.ru> <201112122029.06053.ne@vbart.ru> <1325537189.20111212205734@softsearch.ru> Message-ID: <20111212194516.GA28534@lo0.su> On Mon, Dec 12, 2011 at 08:57:34PM +0400, Михаил Монашёв wrote: > Здравствуйте, Валентин. > > >> > *) Добавление: параметр so_keepalive в директиве listen. > >> > > >> > Спасибо Всеволоду Стахову. > >> > >> А что он делает? > > > Управляет флагом SO_KEEPALIVE на сокете. > > > http://nginx.org/en/docs/http/ngx_http_core_module.html#listen > > Спасибо. Смотрел русскую доку, там ничего не было. Русскую доку по ngx_http_core_module обновлю завтра-послезавтра. From nginx-forum на nginx.us Mon Dec 12 22:24:28 2011 From: nginx-forum на nginx.us (adept) Date: Mon, 12 Dec 2011 17:24:28 -0500 Subject: =?UTF-8?B?0JTQvtGA0LDQsdC+0YLQutCwINC/0LDRgtGH0LAu?= Message-ID: <274f0397ab44ef85f61d6b32f978b063.NginxMailingListRussian@forum.nginx.org> Собственно, есть пачт под версию 0.5, нужно допилить до версии 0.8.55 или 1, моих знаний на это не хватило, добились только сообщения в логах а не конечного результата. Сам патч: paste.org.ru/?u1a78l email для контактов, fire002 на ya.ru Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219972,219972#msg-219972 From thresh на videolan.org Tue Dec 13 05:57:08 2011 From: thresh на videolan.org (Konstantin Pavlov) Date: Tue, 13 Dec 2011 09:57:08 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: References: <20111212114158.GX13414@snowwhite.immo> Message-ID: <20111213055708.GA19992@snowwhite.immo> On Mon, Dec 12, 2011 at 10:31:46PM +0400, Алексей Сундуков wrote: > "Не так" тут видимо google chrome. Не раз сталкивался с тем, что у > него виденее того что и как нужно кэшировать и то, что работает как > задумано в других браузерах не работает в хроме, причем даже > принудительная зачистка кэша не спасает. > > Видится мне, что если проблема проявляется только в хроне и ни каких > других браузерах, то дело в хроме, а не nginx. Безусловно. Это однако не отменяет наличия проблемы и необходимости её решить. -- Konstantin Pavlov VideoLAN team From ingvar на westsib.ru Tue Dec 13 06:21:05 2011 From: ingvar на westsib.ru (Igor V. Fatkulin) Date: Tue, 13 Dec 2011 13:21:05 +0700 Subject: =?UTF-8?B?UmU6INC90LUg0YHQvtCx0LjRgNCw0LXRgtGB0Y8gcmV3cml0ZQ==?= In-Reply-To: <20111212101114.GQ67687@mdounin.ru> References: <14610141630.20111212153656@westsib.ru> <20111212095004.GM67687@mdounin.ru> <852206891.20111212170811@westsib.ru> <20111212101114.GQ67687@mdounin.ru> Message-ID: <257829623.20111213132105@westsib.ru> >> MD> Впрочем, скорее всего в данной конструкции правильнее использовать >> MD> try_files. >> Поясните, если не трудно, почему и как именно правильнее? MD> http://wiki.nginx.org/IfIsEvil MD> http://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files Спасибо! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sb на waeme.net Tue Dec 13 06:22:16 2011 From: sb на waeme.net (Sergey Budnevitch) Date: Tue, 13 Dec 2011 10:22:16 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: <20111213055708.GA19992@snowwhite.immo> References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> Message-ID: On 13.12.2011, at 9:57, Konstantin Pavlov wrote: > On Mon, Dec 12, 2011 at 10:31:46PM +0400, Алексей Сундуков wrote: >> "Не так" тут видимо google chrome. Не раз сталкивался с тем, что у >> него виденее того что и как нужно кэшировать и то, что работает как >> задумано в других браузерах не работает в хроме, причем даже >> принудительная зачистка кэша не спасает. >> >> Видится мне, что если проблема проявляется только в хроне и ни каких >> других браузерах, то дело в хроме, а не nginx. > > Безусловно. > > Это однако не отменяет наличия проблемы и необходимости её решить. В хроме с помощью developers tools -> network посмотрите получает ли он этот mp3-файл вообще, какого размера, сравните с тем, что должно быть. aws content-length отдает? Если раздавать эти же файлы напрямую nginx'ом проблема воспроизводится? From thresh на videolan.org Tue Dec 13 07:23:22 2011 From: thresh на videolan.org (Konstantin Pavlov) Date: Tue, 13 Dec 2011 11:23:22 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> Message-ID: <20111213072322.GA3220@snowwhite.immo> On Tue, Dec 13, 2011 at 10:22:16AM +0400, Sergey Budnevitch wrote: > > On 13.12.2011, at 9:57, Konstantin Pavlov wrote: > > > On Mon, Dec 12, 2011 at 10:31:46PM +0400, Алексей Сундуков wrote: > >> "Не так" тут видимо google chrome. Не раз сталкивался с тем, что у > >> него виденее того что и как нужно кэшировать и то, что работает как > >> задумано в других браузерах не работает в хроме, причем даже > >> принудительная зачистка кэша не спасает. > >> > >> Видится мне, что если проблема проявляется только в хроне и ни каких > >> других браузерах, то дело в хроме, а не nginx. > > > > Безусловно. > > > > Это однако не отменяет наличия проблемы и необходимости её решить. > > > В хроме с помощью developers tools -> network посмотрите получает ли он этот > mp3-файл вообще, какого размера, сравните с тем, что должно быть. Когда ошибка проявляется, chrome делает 4 запроса, ниже следует copy&paste из developer tools/network: 1-ый запрос: GET http://yo-fm-mp3.yo.fm/fa04ec7c59e6bdf27e04f0a3db9bdf92?t=39532&p=2056&po=337002 HTTP/1.1 1-ый ответ: HTTP/1.1 0 undefined 2-ой запрос: GET http://yo-fm-mp3.yo.fm/fa04ec7c59e6bdf27e04f0a3db9bdf92?t=39532&p=2056&po=337002 HTTP/1.1 Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.5 Safari/535.2 Referer: http://yo.fm/ Range: bytes=0- 2-ой ответ: HTTP/1.1 0 undefined 3-ий запрос: GET /fa04ec7c59e6bdf27e04f0a3db9bdf92?t=39532&p=2056&po=337002 HTTP/1.1 Host: yo-fm-mp3.yo.fm Connection: keep-alive Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.5 Safari/535.2 Accept: */* Referer: http://yo.fm/ Accept-Language: ru-RU,en;q=0.8,en-US;q=0.6,ru;q=0.4 Accept-Charset: UTF-8,*;q=0.5 Cookie: __utma=223490707.1901084029.1319019904.1323693066.1323757632.12; __utmb=223490707.3.10.1323757632; __utmc=223490707; __utmz=223490707.1319019904.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) 3-ий ответ: HTTP/1.1 200 OK Server: nginx/0.8.55 Date: Tue, 13 Dec 2011 06:44:47 GMT Content-Type: audio/mpeg Connection: close Accept-Ranges: bytes Content-Length: 21165453 Expires: Tue, 20 Dec 2011 06:44:47 GMT Cache-Control: max-age=604800 4-ый запрос: GET http://yo-fm-mp3.yo.fm/fa04ec7c59e6bdf27e04f0a3db9bdf92?t=39532&p=2056&po=337002 HTTP/1.1 Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.5 Safari/535.2 Referer: http://yo.fm/ Range: bytes=21165325- 4-ый ответ: HTTP/1.1 0 undefined При этом на первый запрос status в developer tools - "(pending)", на остальные "(canceled)". При третьем запросе скачалось при этом ~34 KB из 21165453 байт. (Content-length в третьем ответе правильный). Далее случай когда mp3-шка скачивается нормально: 1-ый запрос: GET http://yo-fm-mp3.yo.fm/dcc27468ccd029c31943ad16da657c9e?t=37460&p=2056&po=337002 HTTP/1.1 1-ый ответ: HTTP/1.1 0 undefined 2-ой запрос: GET http://yo-fm-mp3.yo.fm/dcc27468ccd029c31943ad16da657c9e?t=37460&p=2056&po=337002 HTTP/1.1 Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.5 Safari/535.2 Referer: http://yo.fm/ Range: bytes=0- 2-ой ответ: HTTP/1.1 0 undefined 3-ий запрос: GET /dcc27468ccd029c31943ad16da657c9e?t=37460&p=2056&po=337002 HTTP/1.1 Host: yo-fm-mp3.yo.fm Connection: keep-alive Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.5 Safari/535.2 Accept: */* Referer: http://yo.fm/ Accept-Language: ru-RU,en;q=0.8,en-US;q=0.6,ru;q=0.4 Accept-Charset: UTF-8,*;q=0.5 Cookie: __utma=223490707.1901084029.1319019904.1323693066.1323757632.12; __utmc=223490707; __utmz=223490707.1319019904.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) 3-ий ответ: HTTP/1.1 200 OK Server: nginx/0.8.55 Date: Tue, 13 Dec 2011 07:03:18 GMT Content-Type: audio/mpeg Connection: close Accept-Ranges: bytes Content-Length: 5950780 Expires: Tue, 20 Dec 2011 07:03:18 GMT Cache-Control: max-age=604800 4-го запроса не следует. Видно, что в 4-м запросе chromium запрашивает последние 128 байт mp3-файла, видимо хочет прочитать мета-данные. Я проверил, что chromium всегда корректно скачивает файлы, в которых есть ID3v1-тэг, но не всегда корректно скачивает те, где этого тэга нет. Однако при запросе напрямую с amazon S3 файлы всегда воспроизводятся корректно. > aws content-length отдает? Отдаёт. > Если раздавать эти же файлы напрямую nginx'ом проблема воспроизводится? Нет. Также проблема не воспроизводится, если запросы делать напрямую на amazon s3. -- Konstantin Pavlov VideoLAN team From sb на waeme.net Tue Dec 13 08:56:13 2011 From: sb на waeme.net (Sergey Budnevitch) Date: Tue, 13 Dec 2011 12:56:13 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: <20111213072322.GA3220@snowwhite.immo> References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> <20111213072322.GA3220@snowwhite.immo> Message-ID: On 13.12.2011, at 11:23, Konstantin Pavlov wrote: > On Tue, Dec 13, 2011 at 10:22:16AM +0400, Sergey Budnevitch wrote: > > Видно, что в 4-м запросе chromium запрашивает последние 128 байт mp3-файла, > видимо хочет прочитать мета-данные. > > Я проверил, что chromium всегда корректно скачивает файлы, в которых есть > ID3v1-тэг, но не всегда корректно скачивает те, где этого тэга нет. Однако при > запросе напрямую с amazon S3 файлы всегда воспроизводятся корректно. Судя по всему, хром, если не видит id3v1 тег, пытается получить id3v2, который в конце файла. nginx не может отдать хвост файла, пока не скачает его целиком, а хром, видимо, не дожидается и отваливается по таймауту. Очевидный workaround добавить id3v1 тэг. From sb на waeme.net Tue Dec 13 09:08:14 2011 From: sb на waeme.net (Sergey Budnevitch) Date: Tue, 13 Dec 2011 13:08:14 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> <20111213072322.GA3220@snowwhite.immo> Message-ID: <740D527B-F839-41E0-A705-56EA0C3899B2@waeme.net> On 13.12.2011, at 12:56, Sergey Budnevitch wrote: > > On 13.12.2011, at 11:23, Konstantin Pavlov wrote: > >> On Tue, Dec 13, 2011 at 10:22:16AM +0400, Sergey Budnevitch wrote: >> >> Видно, что в 4-м запросе chromium запрашивает последние 128 байт mp3-файла, >> видимо хочет прочитать мета-данные. >> >> Я проверил, что chromium всегда корректно скачивает файлы, в которых есть >> ID3v1-тэг, но не всегда корректно скачивает те, где этого тэга нет. Однако при >> запросе напрямую с amazon S3 файлы всегда воспроизводятся корректно. > > Судя по всему, хром, если не видит id3v1 тег, пытается получить id3v2, который в конце файла. > nginx не может отдать хвост файла, пока не скачает его целиком, а хром, видимо, > не дожидается и отваливается по таймауту. > Очевидный workaround добавить id3v1 тэг. И попробуйте добавить: proxy_set_header Range $http_range; proxy_no_cache $http_range; From thresh на videolan.org Tue Dec 13 09:13:02 2011 From: thresh на videolan.org (Konstantin Pavlov) Date: Tue, 13 Dec 2011 13:13:02 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> <20111213072322.GA3220@snowwhite.immo> Message-ID: <20111213091302.GB3220@snowwhite.immo> On Tue, Dec 13, 2011 at 12:56:13PM +0400, Sergey Budnevitch wrote: > > On 13.12.2011, at 11:23, Konstantin Pavlov wrote: > > > On Tue, Dec 13, 2011 at 10:22:16AM +0400, Sergey Budnevitch wrote: > > > > Видно, что в 4-м запросе chromium запрашивает последние 128 байт mp3-файла, > > видимо хочет прочитать мета-данные. > > > > Я проверил, что chromium всегда корректно скачивает файлы, в которых есть > > ID3v1-тэг, но не всегда корректно скачивает те, где этого тэга нет. Однако при > > запросе напрямую с amazon S3 файлы всегда воспроизводятся корректно. > > Судя по всему, хром, если не видит id3v1 тег, пытается получить id3v2, который в конце файла. > nginx не может отдать хвост файла, пока не скачает его целиком, а хром, видимо, > не дожидается и отваливается по таймауту. > Очевидный workaround добавить id3v1 тэг. Да, это понятно, но, к сожалению, контентом управлять не могу. Добавил: proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range; proxy_no_cache $http_range $http_if_range; в конфигурационный файл, будем тестировать. -- Konstantin Pavlov VideoLAN team From nginx-forum на nginx.us Tue Dec 13 11:03:34 2011 From: nginx-forum на nginx.us (Maximus43) Date: Tue, 13 Dec 2011 06:03:34 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiAi0L/QvtGH0LjRgdGC0LjRgtGMIiDQvdC10LLQtdGA0L3Rg9GO?= =?UTF-8?B?INGB0YHRi9C70LrRgyDQvdCwINGB0LDQudGCPw==?= In-Reply-To: <2e0a56ddd813bb1690d5af2012f75f8b.NginxMailingListRussian@forum.nginx.org> References: <2e0a56ddd813bb1690d5af2012f75f8b.NginxMailingListRussian@forum.nginx.org> Message-ID: <899b517ec5e773d3c6332ffd0a1682b6.NginxMailingListRussian@forum.nginx.org> Хотелось бы решить данную проблему средствами nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219933,219987#msg-219987 From belov1985 на gmail.com Tue Dec 13 12:22:18 2011 From: belov1985 на gmail.com (=?KOI8-R?Q?=EB=CF=CE=D3=D4=C1=CE=D4=C9=CE?=) Date: Tue, 13 Dec 2011 14:22:18 +0200 Subject: =?UTF-8?B?UmU6INCf0YDQsNCy0LAg0LTQvtGB0YLRg9C/0LAg0L3QsCBmYXN0Y2dpX2NhY2hl?= =?UTF-8?B?X3BhdGg=?= In-Reply-To: References: <4EE100F8.70607@gmail.com> <201112091309.27898.ne@vbart.ru> <4EE25AC8.7050408@gmail.com> Message-ID: <4EE7437A.8090505@gmail.com> 12.12.11 9:30, Kruglov Eugenie пишет: > http://labs.frickle.com/nginx_ngx_cache_purge/ этот модуль вам поможет. > Спасибо большое!! То что доктор прописал :) P. S. А он даже в freebsd порте есть, как я его не заметил :( From xasima на gmail.com Tue Dec 13 16:26:41 2011 From: xasima на gmail.com (Xasima) Date: Tue, 13 Dec 2011 19:26:41 +0300 Subject: =?UTF-8?B?0JrQsNC6INC70YPRh9GI0LUg0YDQtdCw0LvQuNC30L7QstCw0YLRjCDRhNGD0L0=?= =?UTF-8?B?0LrRhtC40L7QvdCw0LvRjNC90L7RgdGC0YwgYmlncGlwZQ==?= Message-ID: Добрый день. Хочу поинтересоваться, какие существующие модули можно использовать (стоит посмотреть как пример) для разработки следующего функционала: по приходящему запросу вида url?pipe=a.js,b.js,c.json&separator=xxx nginx должен отдать данные {a.js, b.js, c.json} друг за другом через keep/alive соединение, разделяя их c помощью xxxx, правильно при этом высчитывая http chunk length и помещая нужный content-type? Сами ресурсы также отдаются (проксируются) через nginx, например, из файловой системы, memcache, бэкенда. HTTP/1.1 200 OK Content-Type: multipart/mixed; boundary=xxx Transfer-Encoding: chunked --xxx Content-Type: application/x-javascript Content-Length: 123 { ... a.js ... } --xxx Content-Type: application/x-javascript Content-Length: 123 { ... b.js ... } --xxx Content-Type: application/json Content-Length: 123 { ... c.json .. } Connection: close Насколько я понимаю, примеры похожей функциональности есть на node.js / java jetty continuation. Однако кажется, что такую отдачу контента (особенно закешированного или находящегося на файловой системе) будет выгоднее осуществлять через nginx и использовать специализированные бэкенды лишь для изменяемых данных. Использовать вместо такой динамической отдачи подготовленные (скомпилированные) наборы js скриптов тоже не хочется, потому как в общем случае набор параметров url?pipe=a.js,е.js, g.js динамичен и определяется "деревом зависимостей" js модуля (который в заданный момент пользователь "запросил" нажав на какую-то кнопку с редким функционалом на пользовательском интерфейсе) и наличием уже загруженных подобным образом скриптов. -- Best regards, ~ Xasima ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangsamp на gmail.com Tue Dec 13 16:38:29 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Tue, 13 Dec 2011 18:38:29 +0200 (EET) Subject: =?UTF-8?B?UmU6INCa0LDQuiDQu9GD0YfRiNC1INGA0LXQsNC70LjQt9C+0LLQsNGC0Ywg0YQ=?= =?UTF-8?B?0YPQvdC60YbQuNC+0L3QsNC70YzQvdC+0YHRgtGMIGJpZ3BpcGU=?= In-Reply-To: References: Message-ID: Today Dec 13, 2011 at 19:26 Xasima wrote: > Добрый день. > > Хочу поинтересоваться, какие существующие модули можно использовать (стоит > посмотреть как пример) для разработки следующего функционала: > > по приходящему запросу вида url?pipe=a.js,b.js,c.json&separator=xxx nginx > должен отдать данные {a.js, b.js, c.json} друг за другом через keep/alive > соединение, разделяя их c помощью xxxx, правильно при этом высчитывая http > chunk length и помещая нужный content-type? Похожий модуль: https://github.com/perusio/nginx-http-concat > Насколько я понимаю, примеры похожей функциональности есть на node.js / > java jetty continuation. Однако кажется, что такую отдачу контента > (особенно закешированного или находящегося на файловой системе) будет > выгоднее осуществлять через nginx и использовать специализированные бэкенды > лишь для изменяемых данных. Вариант настроить проксирование к такому бэкенду с кешированием на стороне nginx рассматривали? http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache -- WNGS-RIPE From hell-for-yahoo на umail.ru Tue Dec 13 17:25:00 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Tue, 13 Dec 2011 21:25:00 +0400 Subject: Проблемы с nginx в режиме proxy_pass с amazon и chrome/chromium In-Reply-To: References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> <20111213072322.GA3220@snowwhite.immo> Message-ID: <1447001241.20111213212500@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Sergey Budnevitch! SB> Судя по всему, хром, если не видит id3v1 тег, пытается получить id3v2, который в конце файла. SB> nginx не может отдать хвост файла, пока не скачает его целиком, а хром, видимо, SB> не дожидается и отваливается по таймауту. SB> Очевидный workaround добавить id3v1 тэг. Меня глючит и колбасит, или ID3v1 всегда в конце файла, тогда как v2 может теоретически располагаться в любом месте? -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) вторник, 13.12.2011, <21:24> From mdounin на mdounin.ru Tue Dec 13 17:55:47 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Dec 2011 21:55:47 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: <1447001241.20111213212500@mtu-net.ru> References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> <20111213072322.GA3220@snowwhite.immo> <1447001241.20111213212500@mtu-net.ru> Message-ID: <20111213175546.GI67687@mdounin.ru> Hello! On Tue, Dec 13, 2011 at 09:25:00PM +0400, Andrey Repin wrote: > Здравствуйте, Уважаемый(-ая, -ое) Sergey Budnevitch! > > SB> Судя по всему, хром, если не видит id3v1 тег, пытается получить id3v2, который в конце файла. > SB> nginx не может отдать хвост файла, пока не скачает его целиком, а хром, видимо, > SB> не дожидается и отваливается по таймауту. > SB> Очевидный workaround добавить id3v1 тэг. > > Меня глючит и колбасит, или ID3v1 всегда в конце файла, тогда как v2 может > теоретически располагаться в любом месте? Да, это Сергей перепутал ID3v1 и ID3v2. Добавлять, соответственно, надо ID3v2 в начало файла. Maxim Dounin From sergey.kobzar на itcraft.org Tue Dec 13 18:23:57 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Tue, 13 Dec 2011 20:23:57 +0200 Subject: =?UTF-8?B?0JfQsNC80LXQvdCwIGlmINC90LAgdHJ5X2ZpbGVz?= Message-ID: <4EE7983D.2080404@itcraft.org> Приветствую Пытаюсь заменить if (!-e $request_filename) { rewrite '(?i)^' /$subfolder/index.php last; } на location / { try_files $uri /$subfolder/index.php; } в server { server_name server.com; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log debug; if ($request_uri ~ ^/([^/]*).*$) { set $subfolder $1; } root /home/www/server.com/htdocs; index index.html index.php; error_page 404 /$subfolder/index.php?page=404; location / { try_files $uri /$subfolder/index.php; } location ^~ /$subfolder/errors/ { ... } location ~* \.(css|gif|html|ico|jpg|js|pdf|png)$ { ... } location ~ \.php$ { fastcgi_pass 127.0.0.1:9001; fastcgi_index index.php; include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SERVER_NAME $host; } } С if - все ОК. Если использую try_files - не видно GET в PHP из запроса вида http://server.com/project/?some_variable=1 Что не так? Видимо запрос попадает не в тот локейшн? From postmaster на softsearch.ru Tue Dec 13 20:02:11 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 14 Dec 2011 00:02:11 +0400 Subject: =?UTF-8?B?0JjQvdGC0LXQu9C10LrRgtGD0LDQu9GM0L3Ri9C5IHRyeV9maWxlcyDQv9C+INGB?= =?UTF-8?B?0LXRgtC4?= Message-ID: <10910298361.20111214000211@softsearch.ru> Здравствуйте. Было бы удобно иметь возможность прописывать вот такую логику: поискать файл на этих бэкендах, а если там не нашлось, то на этих. Это удобно в стандартной задаче, когда хочется показать только что загруженную фотку. Форму удобно постить на сервер с апачами, картинку раздавать с кэширующего сервера, а хранить картинку на сервере с файловым архивом. Т.е. сначала картика кладётся на апаческий хост, а потом в фоне копируется на хост с файловым архивом. Сейчас подобную схему можно сделать двумя способами: редиректить юзеров, чтобы браузер сам обходил все возможные сервера, или городить на кэширующем сервере кучу if-ов. -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Tue Dec 13 20:18:23 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 00:18:23 +0400 Subject: =?UTF-8?B?UmU6INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg0L8=?= =?UTF-8?B?0L4g0YHQtdGC0Lg=?= In-Reply-To: <10910298361.20111214000211@softsearch.ru> References: <10910298361.20111214000211@softsearch.ru> Message-ID: <20111213201823.GK67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 12:02:11AM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Было бы удобно иметь возможность прописывать вот такую логику: > поискать файл на этих бэкендах, а если там не нашлось, то на этих. Это > удобно в стандартной задаче, когда хочется показать только что > загруженную фотку. Форму удобно постить на сервер с апачами, картинку > раздавать с кэширующего сервера, а хранить картинку на сервере с > файловым архивом. Т.е. сначала картика кладётся на апаческий хост, а > потом в фоне копируется на хост с файловым архивом. > > Сейчас подобную схему можно сделать двумя способами: редиректить > юзеров, чтобы браузер сам обходил все возможные сервера, или городить > на кэширующем сервере кучу if-ов. А чем тебе старый добрый вариант с "error_page 404 = @fallback" не угодил? Собственно, от try_files его по большому счёту отличает только то, что try_files писать чуть проще для разных типичных случаев. (Ну и тем, что в отличие от try_files там нет race condition при проверке и отдаче файлов, но это тема, интересная только отдельным маньякам вроде меня.) Maxim Dounin From sergey.kobzar на itcraft.org Tue Dec 13 21:00:36 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Tue, 13 Dec 2011 23:00:36 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <4EE7983D.2080404@itcraft.org> References: <4EE7983D.2080404@itcraft.org> Message-ID: <4EE7BCF4.6060503@itcraft.org> On 12/13/11 20:23, Sergey Kobzar wrote: > Приветствую > > Пытаюсь заменить > > if (!-e $request_filename) { > rewrite '(?i)^' /$subfolder/index.php last; > } > > на > > location / { > try_files $uri /$subfolder/index.php; > } Называется "сам дурак". Вопрос пока снимается. From rush.zlo на gmail.com Tue Dec 13 21:12:31 2011 From: rush.zlo на gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40LkgJ1J1c2gnINCd0LXQv9C+0LzQvdGP0YnQuNC5?=) Date: Wed, 14 Dec 2011 01:12:31 +0400 Subject: =?UTF-8?B?UmU6INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg0L8=?= =?UTF-8?B?0L4g0YHQtdGC0Lg=?= In-Reply-To: <20111213201823.GK67687@mdounin.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> Message-ID: На самом деле тема интересна очень многим. Хотя бы расширить синтаксис try_files до вида try_files file [file ...] @uri [@uri ...] [=code] Выглядит вполне жизнеспособно, на первый взгляд достаточно легко реализуема. Впрочем мы сейчас для достижения такого же эффекта обходимся травокурным генерённым конфигом, абсолютно нечитаемым и громоздким. Было бы круто увидеть такой функционал в try_files или где то в другом месте. 14 декабря 2011 г. 0:18 пользователь Maxim Dounin написал: > Hello! > > On Wed, Dec 14, 2011 at 12:02:11AM +0400, Михаил Монашёв wrote: > >> Здравствуйте. >> >> Было  бы  удобно  иметь  возможность  прописывать  вот  такую  логику: >> поискать файл на этих бэкендах, а если там не нашлось, то на этих. Это >> удобно  в  стандартной  задаче,  когда  хочется  показать  только  что >> загруженную  фотку. Форму удобно постить на сервер с апачами, картинку >> раздавать  с  кэширующего  сервера,  а  хранить  картинку на сервере с >> файловым  архивом.  Т.е. сначала картика кладётся на апаческий хост, а >> потом в фоне копируется на хост с файловым архивом. >> >> Сейчас  подобную  схему  можно  сделать  двумя  способами: редиректить >> юзеров,  чтобы браузер сам обходил все возможные сервера, или городить >> на кэширующем сервере кучу if-ов. > > А чем тебе старый добрый вариант с "error_page 404 = @fallback" не > угодил? > > Собственно, от try_files его по большому счёту отличает только то, > что try_files писать чуть проще для разных типичных случаев.  (Ну > и тем, что в отличие от try_files там нет race condition при > проверке и отдаче файлов, но это тема, интересная только отдельным > маньякам вроде меня.) > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cogito ergo sum From a.vasilishin на kpi.ua Tue Dec 13 21:34:37 2011 From: a.vasilishin на kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Tue, 13 Dec 2011 23:34:37 +0200 Subject: =?UTF-8?B?UmU6INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg0L8=?= =?UTF-8?B?0L4g0YHQtdGC0Lg=?= In-Reply-To: References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> Message-ID: <4EE7C4ED.5090207@kpi.ua> 13.12.2011 23:12, Евгений 'Rush' Непомнящий пишет: > На самом деле тема интересна очень многим. Хотя бы расширить синтаксис > try_files до вида > > try_files file [file ...] @uri [@uri ...] [=code] > Тоже только хотел написать, что не хватает иногда нескольких именованных локейшинов в try_files -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From postmaster на softsearch.ru Tue Dec 13 21:35:15 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 14 Dec 2011 01:35:15 +0400 Subject: =?UTF-8?B?UmVbMl06INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg?= =?UTF-8?B?0L/QviDRgdC10YLQuA==?= In-Reply-To: <20111213201823.GK67687@mdounin.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> Message-ID: <133874615.20111214013515@softsearch.ru> Здравствуйте, Maxim. >> Было бы удобно иметь возможность прописывать вот такую логику: >> поискать файл на этих бэкендах, а если там не нашлось, то на этих. >> Это удобно в стандартной задаче, когда хочется показать только что >> загруженную фотку. Форму удобно постить на сервер с апачами, >> картинку раздавать с кэширующего сервера, а хранить картинку на >> сервере с файловым архивом. Т.е. сначала картика кладётся на >> апаческий хост, а потом в фоне копируется на хост с файловым >> архивом. >> >> Сейчас подобную схему можно сделать двумя способами: редиректить >> юзеров, чтобы браузер сам обходил все возможные сервера, или >> городить на кэширующем сервере кучу if-ов. > А чем тебе старый добрый вариант с "error_page 404 = @fallback" не > угодил? > Собственно, от try_files его по большому счёту отличает только то, > что try_files писать чуть проще для разных типичных случаев. (Ну и > тем, что в отличие от try_files там нет race condition при проверке > и отдаче файлов, но это тема, интересная только отдельным маньякам > вроде меня.) Под кучей if-ов и имел ввиду твой старый добрый вариант. Неправильно выразился, прошу прощения. Просто хотел заметить, что когда бэкендов десяток, то конфиг не блещет изяществом и похож на копипасту. Кроме того такая конструкция не позволяет всякие оптимизации типа выполнения сразу 10 запросов параллельно вместо последовательного перебора. И кажется, что работа с бэкендами - это ближе к апстриму. Ещё придумал третий вариан решения. Задача сейчас симпатичнее решается, если отделить статусы, вызывающие fail, от статусов, приводящих к выбору следующего бэкенда. Что-то вроде: proxy_next_upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | off] Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов с каждым бэкендом в отдельности. И сразу появляется лаконичность: попробовали эту группу серверов, если там нету, то пробуем эту. -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Tue Dec 13 23:52:26 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 03:52:26 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <4EE7983D.2080404@itcraft.org> References: <4EE7983D.2080404@itcraft.org> Message-ID: <20111213235226.GM67687@mdounin.ru> Hello! On Tue, Dec 13, 2011 at 08:23:57PM +0200, Sergey Kobzar wrote: [...] > location ^~ /$subfolder/errors/ { > ... > } Unrelated note: так работать не будет. В регулярных выражениях переменные не поддерживаются, т.к. регулярные выражения компилируются на стадии чтения конфигурации. Maxim Dounin From nginx-forum на nginx.us Wed Dec 14 00:29:36 2011 From: nginx-forum на nginx.us (shawn) Date: Tue, 13 Dec 2011 19:29:36 -0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSBmcm9udGVuZCfQvtC8?= Message-ID: Доброго времени суток всем ! Помогите пожалуйста у меня есть задача с фронтэнд'ом Есть два DNS имени, есть хост с двумя интерфейсами, один с выделенным статическим ip в интернет, второй интерфейс смотрит в локалку. В локальной сети два компа с apache на которых работает wordpress. Как настроить nginx чтоб в зависимости от запрашиваемого имени пробрасывало на нужный apache в локалке, нужен ли для этого mod_rpaf? При указанной ниже конфигурации в virtual.conf, всегда попадаю на первый apache. server { listen 80; server_name example01.edu; ... location / { proxy_pass http://192.168.1.1/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } server { listen 80; server_name example02.edu; ... location / { proxy_pass http://192.168.1.2/; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220019,220019#msg-220019 From nginx-forum на nginx.us Wed Dec 14 07:02:23 2011 From: nginx-forum на nginx.us (Craken) Date: Wed, 14 Dec 2011 02:02:23 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgZnJvbnRlbmQn0L7QvA==?= In-Reply-To: References: Message-ID: <9d3a6cc2d65c8e9a0db6535555224356.NginxMailingListRussian@forum.nginx.org> Если постоянно кидает на 1-й, то мне кажется что у Вас некая проблема с именами! Попробуйте добавить в директиву "listen" еще и IP адрес на котором слушать! Если проблема не исчезнет, то попробуйте добавить еще такой кусок: server { listen xxx.xxx.xxx.xxx:80 default; access_log off; return 404; } Если будет выдавать "404" - то проблема явно с "server_name"! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220019,220025#msg-220025 From mdounin на mdounin.ru Wed Dec 14 11:31:40 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 15:31:40 +0400 Subject: =?UTF-8?B?UmU6INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg0L8=?= =?UTF-8?B?0L4g0YHQtdGC0Lg=?= In-Reply-To: <133874615.20111214013515@softsearch.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> <133874615.20111214013515@softsearch.ru> Message-ID: <20111214113139.GO67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 01:35:15AM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> Было бы удобно иметь возможность прописывать вот такую логику: > >> поискать файл на этих бэкендах, а если там не нашлось, то на этих. > >> Это удобно в стандартной задаче, когда хочется показать только что > >> загруженную фотку. Форму удобно постить на сервер с апачами, > >> картинку раздавать с кэширующего сервера, а хранить картинку на > >> сервере с файловым архивом. Т.е. сначала картика кладётся на > >> апаческий хост, а потом в фоне копируется на хост с файловым > >> архивом. > >> > >> Сейчас подобную схему можно сделать двумя способами: редиректить > >> юзеров, чтобы браузер сам обходил все возможные сервера, или > >> городить на кэширующем сервере кучу if-ов. > > > А чем тебе старый добрый вариант с "error_page 404 = @fallback" не > > угодил? > > > Собственно, от try_files его по большому счёту отличает только то, > > что try_files писать чуть проще для разных типичных случаев. (Ну и > > тем, что в отличие от try_files там нет race condition при проверке > > и отдаче файлов, но это тема, интересная только отдельным маньякам > > вроде меня.) > > Под кучей if-ов и имел ввиду твой старый добрый вариант. Неправильно > выразился, прошу прощения. Просто хотел заметить, что когда бэкендов > десяток, то конфиг не блещет изяществом и похож на копипасту. Кроме > того такая конструкция не позволяет всякие оптимизации типа выполнения > сразу 10 запросов параллельно вместо последовательного перебора. И > кажется, что работа с бэкендами - это ближе к апстриму. Исходная задача "посмотреть файл на этих бекендах, а если не нашлось, то на этих" - не параллелится. > Ещё придумал третий вариан решения. Задача сейчас симпатичнее > решается, если отделить статусы, вызывающие fail, от статусов, > приводящих к выбору следующего бэкенда. Что-то вроде: > > proxy_next_upstream [error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | off] > > Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов > с каждым бэкендом в отдельности. И сразу появляется лаконичность: > попробовали эту группу серверов, если там нету, то пробуем эту. Сейчас так и есть. Если тебе нужно в рамках группы бекендов поискать файл, то proxy_next_upstream http_404; эту проблему решает (и не объявляет бекенд мёртвым, если он возвращает 404, а просто переходит к следующему бекенду). Maxim Dounin From kinwizard на gmail.com Wed Dec 14 11:40:35 2011 From: kinwizard на gmail.com (Zabazhanov Arkady) Date: Wed, 14 Dec 2011 15:40:35 +0400 Subject: =?UTF-8?B?UmU6INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg0L8=?= =?UTF-8?B?0L4g0YHQtdGC0Lg=?= In-Reply-To: <20111214113139.GO67687@mdounin.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> <133874615.20111214013515@softsearch.ru> <20111214113139.GO67687@mdounin.ru> Message-ID: gridfs решит проблему. 14 декабря 2011 г. 15:31 пользователь Maxim Dounin написал: > Hello! > > On Wed, Dec 14, 2011 at 01:35:15AM +0400, Михаил Монашёв wrote: > > > Здравствуйте, Maxim. > > > > >> Было бы удобно иметь возможность прописывать вот такую логику: > > >> поискать файл на этих бэкендах, а если там не нашлось, то на этих. > > >> Это удобно в стандартной задаче, когда хочется показать только что > > >> загруженную фотку. Форму удобно постить на сервер с апачами, > > >> картинку раздавать с кэширующего сервера, а хранить картинку на > > >> сервере с файловым архивом. Т.е. сначала картика кладётся на > > >> апаческий хост, а потом в фоне копируется на хост с файловым > > >> архивом. > > >> > > >> Сейчас подобную схему можно сделать двумя способами: редиректить > > >> юзеров, чтобы браузер сам обходил все возможные сервера, или > > >> городить на кэширующем сервере кучу if-ов. > > > > > А чем тебе старый добрый вариант с "error_page 404 = @fallback" не > > > угодил? > > > > > Собственно, от try_files его по большому счёту отличает только то, > > > что try_files писать чуть проще для разных типичных случаев. (Ну и > > > тем, что в отличие от try_files там нет race condition при проверке > > > и отдаче файлов, но это тема, интересная только отдельным маньякам > > > вроде меня.) > > > > Под кучей if-ов и имел ввиду твой старый добрый вариант. Неправильно > > выразился, прошу прощения. Просто хотел заметить, что когда бэкендов > > десяток, то конфиг не блещет изяществом и похож на копипасту. Кроме > > того такая конструкция не позволяет всякие оптимизации типа выполнения > > сразу 10 запросов параллельно вместо последовательного перебора. И > > кажется, что работа с бэкендами - это ближе к апстриму. > > Исходная задача "посмотреть файл на этих бекендах, а если не > нашлось, то на этих" - не параллелится. > > > Ещё придумал третий вариан решения. Задача сейчас симпатичнее > > решается, если отделить статусы, вызывающие fail, от статусов, > > приводящих к выбору следующего бэкенда. Что-то вроде: > > > > proxy_next_upstream [error | timeout | invalid_header | http_500 | > http_502 | http_503 | http_504 | http_404[=not_fail] | off] > > > > Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов > > с каждым бэкендом в отдельности. И сразу появляется лаконичность: > > попробовали эту группу серверов, если там нету, то пробуем эту. > > Сейчас так и есть. Если тебе нужно в рамках группы бекендов > поискать файл, то > > proxy_next_upstream http_404; > > эту проблему решает (и не объявляет бекенд мёртвым, если он > возвращает 404, а просто переходит к следующему бекенду). > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Wed Dec 14 12:59:13 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 14 Dec 2011 16:59:13 +0400 Subject: =?UTF-8?B?UmVbMl06INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg?= =?UTF-8?B?0L/QviDRgdC10YLQuA==?= In-Reply-To: <20111214113139.GO67687@mdounin.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> <133874615.20111214013515@softsearch.ru> <20111214113139.GO67687@mdounin.ru> Message-ID: <1665644324.20111214165913@softsearch.ru> Здравствуйте, Maxim. >> >> Было бы удобно иметь возможность прописывать вот такую логику: >> >> поискать файл на этих бэкендах, а если там не нашлось, то на этих. >> >> Это удобно в стандартной задаче, когда хочется показать только что >> >> загруженную фотку. Форму удобно постить на сервер с апачами, >> >> картинку раздавать с кэширующего сервера, а хранить картинку на >> >> сервере с файловым архивом. Т.е. сначала картика кладётся на >> >> апаческий хост, а потом в фоне копируется на хост с файловым >> >> архивом. >> >> >> >> Сейчас подобную схему можно сделать двумя способами: редиректить >> >> юзеров, чтобы браузер сам обходил все возможные сервера, или >> >> городить на кэширующем сервере кучу if-ов. >> >> > А чем тебе старый добрый вариант с "error_page 404 = @fallback" не >> > угодил? >> >> > Собственно, от try_files его по большому счёту отличает только то, >> > что try_files писать чуть проще для разных типичных случаев. (Ну и >> > тем, что в отличие от try_files там нет race condition при проверке >> > и отдаче файлов, но это тема, интересная только отдельным маньякам >> > вроде меня.) >> >> Под кучей if-ов и имел ввиду твой старый добрый вариант. Неправильно >> выразился, прошу прощения. Просто хотел заметить, что когда бэкендов >> десяток, то конфиг не блещет изяществом и похож на копипасту. Кроме >> того такая конструкция не позволяет всякие оптимизации типа выполнения >> сразу 10 запросов параллельно вместо последовательного перебора. И >> кажется, что работа с бэкендами - это ближе к апстриму. > Исходная задача "посмотреть файл на этих бекендах, а если не > нашлось, то на этих" - не параллелится. Параллелится "посмотреть файл на этих бекендах" и "то на этих". >> Ещё придумал третий вариан решения. Задача сейчас симпатичнее >> решается, если отделить статусы, вызывающие fail, от статусов, >> приводящих к выбору следующего бэкенда. Что-то вроде: >> >> proxy_next_upstream [error | timeout | invalid_header | >> http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | >> off] >> >> Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов >> с каждым бэкендом в отдельности. И сразу появляется лаконичность: >> попробовали эту группу серверов, если там нету, то пробуем эту. > Сейчас так и есть. Если тебе нужно в рамках группы бекендов > поискать файл, то > proxy_next_upstream http_404; > эту проблему решает (и не объявляет бекенд мёртвым, если он > возвращает 404, а просто переходит к следующему бекенду). Сорри, торможу. -- С уважением, Михаил mailto:postmaster на softsearch.ru From sergey.kobzar на itcraft.org Wed Dec 14 13:37:03 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Wed, 14 Dec 2011 15:37:03 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <20111213235226.GM67687@mdounin.ru> References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> Message-ID: <4EE8A67F.4010201@itcraft.org> On 12/14/11 01:52, Maxim Dounin wrote: > Hello! > > On Tue, Dec 13, 2011 at 08:23:57PM +0200, Sergey Kobzar wrote: > > [...] > >> location ^~ /$subfolder/errors/ { >> ... >> } > > Unrelated note: так работать не будет. В регулярных выражениях > переменные не поддерживаются, т.к. регулярные выражения > компилируются на стадии чтения конфигурации. Максим, спасибо. Видимо я неверно прочитал документацию. Т.е. если выражение попадает хотя бы под один локейшн с обычной строкой в шаблоне, то после такого локейшна location ^~ обрабатываться не будет? Можно немного поподробней? > Maxim Dounin From postmaster на softsearch.ru Wed Dec 14 13:40:26 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 14 Dec 2011 17:40:26 +0400 Subject: =?UTF-8?B?UmVbMl06INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg?= =?UTF-8?B?0L/QviDRgdC10YLQuA==?= In-Reply-To: <20111214113139.GO67687@mdounin.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> <133874615.20111214013515@softsearch.ru> <20111214113139.GO67687@mdounin.ru> Message-ID: <95801784.20111214174026@softsearch.ru> Здравствуйте, Maxim. >> Ещё придумал третий вариан решения. Задача сейчас симпатичнее >> решается, если отделить статусы, вызывающие fail, от статусов, >> приводящих к выбору следующего бэкенда. Что-то вроде: >> >> proxy_next_upstream [error | timeout | invalid_header | >> http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | >> off] >> >> Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов >> с каждым бэкендом в отдельности. И сразу появляется лаконичность: >> попробовали эту группу серверов, если там нету, то пробуем эту. > Сейчас так и есть. Если тебе нужно в рамках группы бекендов > поискать файл, то > proxy_next_upstream http_404; > эту проблему решает (и не объявляет бекенд мёртвым, если он > возвращает 404, а просто переходит к следующему бекенду). А какие ответы говорят о том, что бэкенд мёртвый? -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Wed Dec 14 13:49:41 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 17:49:41 +0400 Subject: =?UTF-8?B?UmU6INCY0L3RgtC10LvQtdC60YLRg9Cw0LvRjNC90YvQuSB0cnlfZmlsZXMg0L8=?= =?UTF-8?B?0L4g0YHQtdGC0Lg=?= In-Reply-To: <95801784.20111214174026@softsearch.ru> References: <10910298361.20111214000211@softsearch.ru> <20111213201823.GK67687@mdounin.ru> <133874615.20111214013515@softsearch.ru> <20111214113139.GO67687@mdounin.ru> <95801784.20111214174026@softsearch.ru> Message-ID: <20111214134941.GR67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 05:40:26PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> Ещё придумал третий вариан решения. Задача сейчас симпатичнее > >> решается, если отделить статусы, вызывающие fail, от статусов, > >> приводящих к выбору следующего бэкенда. Что-то вроде: > >> > >> proxy_next_upstream [error | timeout | invalid_header | > >> http_500 | http_502 | http_503 | http_504 | http_404[=not_fail] | > >> off] > >> > >> Тогда в @fallback можно писать сразу апстрим вместо кучи @fallback-ов > >> с каждым бэкендом в отдельности. И сразу появляется лаконичность: > >> попробовали эту группу серверов, если там нету, то пробуем эту. > > > Сейчас так и есть. Если тебе нужно в рамках группы бекендов > > поискать файл, то > > > proxy_next_upstream http_404; > > > эту проблему решает (и не объявляет бекенд мёртвым, если он > > возвращает 404, а просто переходит к следующему бекенду). > > А какие ответы говорят о том, что бэкенд мёртвый? Все, указанные в proxy_next_upstream, кроме http_404. Maxim Dounin From ne на vbart.ru Wed Dec 14 14:05:01 2011 From: ne на vbart.ru (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 14 Dec 2011 18:05:01 +0400 Subject: =?UTF-8?B?0KDQtdCw0LvQuNC30LDRhtC40Y8gbXVsdGlwbGUgbGltaXRfcmVx?= Message-ID: <201112141805.02107.ne@vbart.ru> Не алгоритм, а принцип работы: - Ищем лимит, который отклоняет запрос; - if found -- Отклоняем запрос. - else -- Учитываем запрос во всех лимитах; -- Ищем лимит, который устанавливает наибольший delay; -- if max delay == 0 --- Пропускаем запрос. -- else --- Задерживаем запрос на max delay. Хорошо? -- Валентин From mdounin на mdounin.ru Wed Dec 14 14:11:33 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 18:11:33 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <4EE8A67F.4010201@itcraft.org> References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> Message-ID: <20111214141133.GT67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 03:37:03PM +0200, Sergey Kobzar wrote: > On 12/14/11 01:52, Maxim Dounin wrote: > >Hello! > > > >On Tue, Dec 13, 2011 at 08:23:57PM +0200, Sergey Kobzar wrote: > > > >[...] > > > >> location ^~ /$subfolder/errors/ { > >> ... > >> } > > > >Unrelated note: так работать не будет. В регулярных выражениях > >переменные не поддерживаются, т.к. регулярные выражения > >компилируются на стадии чтения конфигурации. > > Максим, спасибо. Видимо я неверно прочитал документацию. > > Т.е. если выражение попадает хотя бы под один локейшн с обычной > строкой в шаблоне, то после такого локейшна location ^~ > обрабатываться не будет? Нет. Моё замечание относилось именно к использованию *переменных* в регулярном выражении. > Можно немного поподробней? Порядок выбора location подробно расписан тут: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location : Для определения соответствия location'а и запроса сначала : проверяются location'ы, заданные обычными строками. Среди них : ищется максимальное совпадение. Затем проверяются регулярные : выражения. В отличие от обычных строк, они не сортируются, а : проверяются в порядке их следования в конфигурационном файле. : Проверка регулярных выражений прекращается после первого же : совпадения. Если совпадение с регулярным выражением не найдено, то : используется конфигурация максимально совпавшего location'а. Регулярные выражения не проверяются, если это явно запрещено с помощью модификатора "^~", либо найдено точное совпадение с location'ом, заданным с модификатором "=". Maxim Dounin From mdounin на mdounin.ru Wed Dec 14 14:22:26 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 18:22:26 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <201112141805.02107.ne@vbart.ru> References: <201112141805.02107.ne@vbart.ru> Message-ID: <20111214142226.GU67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 06:05:01PM +0400, Валентин Бартенев wrote: > > Не алгоритм, а принцип работы: > > - Ищем лимит, который отклоняет запрос; > - if found > -- Отклоняем запрос. > - else > -- Учитываем запрос во всех лимитах; > -- Ищем лимит, который устанавливает наибольший delay; > -- if max delay == 0 > --- Пропускаем запрос. > -- else > --- Задерживаем запрос на max delay. > > Хорошо? Давай для начала распишем последствия обычного "последовательного" применения лимитов, чтобы было понятно что так нельзя. Или, наоборот, можно, но с какими ограничениями. Что касается принципа, то он мне не нравится: нам либо нужно всё это делать держа локи (deadlock expected), либо имеем race между проверкой и обновлением (и, опять же, локи придётся брать два раза, что тоже не очень хорошо). Maxim Dounin From mdounin на mdounin.ru Wed Dec 14 14:38:29 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 18:38:29 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> <20111214141133.GT67687@mdounin.ru> Message-ID: <20111214143828.GV67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 04:31:11PM +0200, Oleksandr V. Typlyns'kyi wrote: > Today Dec 14, 2011 at 18:11 Maxim Dounin wrote: > > > > >> location ^~ /$subfolder/errors/ { > > > >> ... > > > >> } > > > > > > > >Unrelated note: так работать не будет. В регулярных выражениях > > > >переменные не поддерживаются, т.к. регулярные выражения > > > >компилируются на стадии чтения конфигурации. > > > > > > Максим, спасибо. Видимо я неверно прочитал документацию. > > > > > > Т.е. если выражение попадает хотя бы под один локейшн с обычной > > > строкой в шаблоне, то после такого локейшна location ^~ > > > обрабатываться не будет? > > > > Нет. Моё замечание относилось именно к использованию *переменных* > > в регулярном выражении. > > > Регулярные выражения не проверяются, если это явно запрещено с > > помощью модификатора "^~", либо найдено точное совпадение с > > location'ом, заданным с модификатором "=". > > Максим, так у него же там "^~" - не регулярка, а её запрет. А, торрможу. Но всё равно работать не будет, в location'ах, заданных обычными строками, переменные с тем же успехом не поддерживаются. (cc'd to list, just in case it will be usefull for someone) Maxim Dounin From sergey.kobzar на itcraft.org Wed Dec 14 15:09:18 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Wed, 14 Dec 2011 17:09:18 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <20111214143828.GV67687@mdounin.ru> References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> <20111214141133.GT67687@mdounin.ru> <20111214143828.GV67687@mdounin.ru> Message-ID: <4EE8BC1E.3080305@itcraft.org> On 12/14/11 16:38, Maxim Dounin wrote: >>> Регулярные выражения не проверяются, если это явно запрещено с >>> помощью модификатора "^~", либо найдено точное совпадение с >>> location'ом, заданным с модификатором "=". >> >> Максим, так у него же там "^~" - не регулярка, а её запрет. Спасибо, что поправили, ат о я уже доку разу по 10му перечитываю :) > А, торрможу. Но всё равно работать не будет, в location'ах, > заданных обычными строками, переменные с тем же успехом не > поддерживаются. if ($request_uri ~ ^/([^/]*).*$) { set $subfolder $1; } root /home/www/test.com/htdocs; location / { rewrite ^/ /$subfolder/index.php; } /home/www/test.com/htdocs выглядит: test-1 test-2 test-3 Как-то же оно работает... # nginx -v nginx: nginx version: nginx/1.0.6 > (cc'd to list, just in case it will be usefull for someone) agree > > Maxim Dounin > From nginx-forum на nginx.us Wed Dec 14 15:19:46 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Wed, 14 Dec 2011 10:19:46 -0500 Subject: php-fpm upstream pool In-Reply-To: <20111202100736.GC67687@mdounin.ru> References: <20111202100736.GC67687@mdounin.ru> Message-ID: <971984b8109bf209ba4d02513b0d8e7c.NginxMailingListRussian@forum.nginx.org> Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Fri, Dec 02, 2011 at 03:47:31AM -0500, igor.goncharenko wrote: > > > > http://trac.nginx.org/nginx/ticket/64 > > > > Да. Очень похоже это оно. Тогда в продакшин двигать на 1.0.X нельзя пока :( > > Баг потенциально может проявится тогда и только тогда, когда более > одного бекенда в пуле - мёртвые. И почти не имеет шансов проявится, если при этом > более одного живого бекенда. А, интересно, что случается если мы имеем всего 2 бэкенда. Неработающий один считается больше одного или нет? :) > При этом мёртвый бекенд в пуле - это, вообще говоря, > чрезвычайная ситуация. Вот-вот, и пока я иду чинить мертвый бэкенд(ы), я должен быть уверен что nginx работает с живыми. > [...] > > > на эту ветку и сейчас вроде как время > > пришло, но появилась задача с fcgi пулом. > > И теперь оказалось, похоже, смысла > > мигрировать на 1.0.X нет - потому что для > > задач балансера этот баг - серьезный. > > В 0.8.x в этом месте те же проблемы, и существенно > хуже в других местах. Никто не меняет продукт в продакшине на новую версию только потому что он существенно лучше в каких-то местах. Я например, меняю только: a) если я наступил на баги которые были починены в новой ветке б) если таковых нет - раз в год или в два на новую стабл ветку, чтобы не отставать от жизни Некоторые вообще не трогают если работает, opennet например, вообще на 0.6, если не врут в хеадерах. > > Насчет 1.1.X. Ну во-первых, ветка позиционируется как девелопмент, соответственно, использовать на > > продакшине можно только в крайнем случае. > > Отличие stable состоит в первую очередь в том, что её, по возможности, не ломают, т.е. обновления с версии на > версию не должны приносить сюрпризов. В development нужно быть несколько осторожнее с обновлениями (желательно читать changelog). changelog читается всегда независимо от ветки. > По стабильности - 1.1.10 сейчас лучше, чем 1.0.10. Хорошо, убедили, может тогда есть смысл перевести 1.1.X в стейбл, если она по стабильности лучше и фич уже добалено много за полгода? > > Во-вторых, упомянутый вами вопрос с долгими запросами. У меня > > могут быть тяжелые запросы к базе, надо подумать как изменение в схеме > > балансинга может на них повлять - судя по всему тем, что "живые" > бэкенды будут нагружены больше чем раньше. > > Если вас это пугает - то зачем вы просите сделать merge этого > изменения в stable? :) Больше не буду :) > На самом деле там всё не очень страшно. Алгоритм такой: упавший > бекенд не будет призна снова работающим, пока не отработает > успешно хотя бы один запрос, на него отправленный. Запросы на > него будут отправляться 1 раз в fail_timeout. > > Если запросы долгие (много длиннее fail_timeout, т.е. не просто > "тяжёлые запросы к базе", какой-нибудь streaming или long > polling) это, потенциально, может привести к тому, что бекенд > (после смерти и оживания обратно) некоторое время будет продолжать > считаться мёртвым (пока хотя бы один запрос не завершится, или клиент его не закроет). > Нагрузка, соответственно, будет идти большей частью на другие > бекенды. > > Есть, впрочем, мнение, что для streaming/long polling подобное поведение тоже вполне > разумно, и максимум что в подобных ситуациях следует сделать - это > уменьшить fail_timeout. Все логично, спасибо за разъяснение. > > Я бы сделал изменение схемы > > балансировки в 1.0.x опциональным и > > выключенным по дефолту, если это > > возможно. > Нет. Ну, попробовать я должен был :) > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru PS. Тут развели холивар по поводу haproxy и alive чеков. Как человек, пользующийся haproxy тоже (как tcp балансировщик), скажу, что от таких чеков больше вреда чем пользы :) Я так скажу - в nginx такая функциональность не нужна, а если так нравятся alive чеки, никто не запрещает вместо nginxа пользовать haproxy благо он http тоже балансировать умеет (может уже и кэшировать, давно в новые версии haproxy не смотрел, хотя вряд ли :). --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219032,220048#msg-220048 From ne на vbart.ru Wed Dec 14 15:39:19 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 14 Dec 2011 19:39:19 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <20111214142226.GU67687@mdounin.ru> References: <201112141805.02107.ne@vbart.ru> <20111214142226.GU67687@mdounin.ru> Message-ID: <201112141939.19616.ne@vbart.ru> On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote: > Давай для начала распишем последствия обычного "последовательного" > применения лимитов, чтобы было понятно что так нельзя. Или, > наоборот, можно, но с какими ограничениями. > > Что касается принципа, то он мне не нравится: нам либо нужно всё > это делать держа локи (deadlock expected), либо имеем race между > проверкой и обновлением (и, опять же, локи придётся брать два > раза, что тоже не очень хорошо). > В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд, всё можно сделать по тому же принципу. Опять же, всё упирается в то, хотим ли мы считать отклоненные запросы или не хотим. "Счёт" только еще можно разделить на два уровня: - обновление времени последнего запроса; - увеличение очереди. Если мы будем просто последовательно проверять лимиты до первого срабатывания, то у нас получается ситуация, когда "иссякший" лимит стоящий на втором месте будет работать достаточно странно, имея причудливую зависимость от предшествующих. Странность заключается в том, что запросы будут отклоняться, когда предшествующие вообще не сработали, и не отклоняться, если предшествующие сработали на задержание. Иными словами, меньший rate по предшествующим лимитам будет приводить к более суровым мерам. Меньший rate -> более жесткие меры - IMHO, вот так быть не должно. -- Валентин Бартенев From belov1985 на gmail.com Wed Dec 14 17:05:01 2011 From: belov1985 на gmail.com (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0=?=) Date: Wed, 14 Dec 2011 19:05:01 +0200 Subject: =?UTF-8?B?0J7RiNC40LHQutCwIHVubGluayDQsiBlcnJvci5sb2c=?= Message-ID: <4EE8D73D.2090701@gmail.com> Здравствуйте. Подскажите, можно ли как-то отключить запись сообщений об ошибке unlink 2011/12/14 19:56:52 [crit] 42413#0: unlink() "/memory_cache/4/dd/c242f59f96ac0673b67966c7a575ddd4" failed (2: No such file or directory) 2011/12/14 19:56:52 [crit] 42413#0: unlink() "/memory_cache/f/ad/30d055a648a032cef2b281be11e00adf" failed (2: No such file or directory) 2011/12/14 19:56:52 [crit] 42413#0: unlink() "/memory_cache/c/e6/94523c69875f2648e0eb436eb5e79e6c" failed (2: No such file or directory) 2011/12/14 19:56:52 [crit] 42413#0: unlink() "/memory_cache/f/86/1ff62dd398c7d7d6569b7af8d6e5b86f" failed (2: No such file or directory) Я подозреваю, что это связано с тем, что мы используем свой скрипт для удаления кешей. Проблема только в том, что лог ошибок забивается ненужной информацией: cat /var/log/nginx-error.log | grep unlink | awk '{print $2}' | uniq -c 48 19:54:51 51 19:55:01 63 19:55:11 57 19:55:22 54 19:55:32 58 19:55:42 59 19:55:52 48 19:56:02 54 19:56:12 59 19:56:22 51 19:56:32 С уважением, Константин. From mdounin на mdounin.ru Wed Dec 14 16:24:24 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 20:24:24 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <201112141939.19616.ne@vbart.ru> References: <201112141805.02107.ne@vbart.ru> <20111214142226.GU67687@mdounin.ru> <201112141939.19616.ne@vbart.ru> Message-ID: <20111214162424.GW67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 07:39:19PM +0400, Валентин Бартенев wrote: > On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote: > > Давай для начала распишем последствия обычного "последовательного" > > применения лимитов, чтобы было понятно что так нельзя. Или, > > наоборот, можно, но с какими ограничениями. > > > > Что касается принципа, то он мне не нравится: нам либо нужно всё > > это делать держа локи (deadlock expected), либо имеем race между > > проверкой и обновлением (и, опять же, локи придётся брать два > > раза, что тоже не очень хорошо). > > > > В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд, > всё можно сделать по тому же принципу. В limit_conn они второй раз берутся, когда мы откатываем лимиты - либо по завершению запроса, либо по наступанию на лимит. И race'а там соответственно нет. > Опять же, всё упирается в то, хотим ли мы считать отклоненные запросы или > не хотим. > > "Счёт" только еще можно разделить на два уровня: > - обновление времени последнего запроса; > - увеличение очереди. > > Если мы будем просто последовательно проверять лимиты до первого > срабатывания, то у нас получается ситуация, когда "иссякший" лимит > стоящий на втором месте будет работать достаточно странно, имея > причудливую зависимость от предшествующих. Это понятно, и именно эти "странности" я и предлагаю проиллюстрировать на конкретных примерах, чтобы сомнений не оставалось. E.g. типичная ситуация для хостинга, когда лимиты хочется на каждый $host (чтобы один атакуемый сайт не мог съесть все ресурсы), и на ip (чтобы с одного ip-адреса, вздремнув на ^R, нельзя было съесть все ресурсы): limit_req ; limit_req ; Если атакуют $host, то всё хорошо. Если ^R, то проблема: легко "выедается" лимит на $host (хотя запросы реально не обслуживаются), и тем самым нужный хост фактически блокируется. В данном конкретном случае - проблема легко решается сменой порядка применения лимитов: сначала per-ip, потом per-host. Вопрос: есть ли в реальной жизни задачи, где проблема так *не* решается? (С теоретической точки зрения - понятно, что такие задачи есть. Интересуют сколько-нибудь относящиеся к реальной жизни примеры.) > Странность заключается в том, что запросы будут отклоняться, когда > предшествующие вообще не сработали, и не отклоняться, если предшествующие > сработали на задержание. Иными словами, меньший rate по предшествующим > лимитам будет приводить к более суровым мерам. Вот как раз в примере выше - подобное поведение вполне нормально, при условии правильного порядка лимитов. Мы хотим пускать людей на сайт, пока не превышен лимит на этот сайт, и мы хотим отсекать людей с ^R, чтобы они вообще никому никаких проблем не доставляли. Т.е. конструкция limit_req ; limit_req ; не должна никак считать в per-host лимит запросы, отклонённые на основании "ip-адресом не вышел". И в то же время должна считать суммарный лимит для хоста, и отклонять при необходимости запросы за него выходящие. Maxim Dounin From mdounin на mdounin.ru Wed Dec 14 16:27:10 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 20:27:10 +0400 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCB1bmxpbmsg0LIgZXJyb3IubG9n?= In-Reply-To: <4EE8D73D.2090701@gmail.com> References: <4EE8D73D.2090701@gmail.com> Message-ID: <20111214162710.GX67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 07:05:01PM +0200, Константин wrote: > Подскажите, можно ли как-то отключить запись сообщений об ошибке unlink Нет. [...] > 2011/12/14 19:56:52 [crit] 42413#0: unlink() > "/memory_cache/f/86/1ff62dd398c7d7d6569b7af8d6e5b86f" failed (2: No such > file or directory) > > Я подозреваю, что это связано с тем, что мы используем свой скрипт для > удаления кешей. Да. Maxim Dounin From mdounin на mdounin.ru Wed Dec 14 16:32:11 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 20:32:11 +0400 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <4EE8BC1E.3080305@itcraft.org> References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> <20111214141133.GT67687@mdounin.ru> <20111214143828.GV67687@mdounin.ru> <4EE8BC1E.3080305@itcraft.org> Message-ID: <20111214163211.GY67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 05:09:18PM +0200, Sergey Kobzar wrote: > On 12/14/11 16:38, Maxim Dounin wrote: > > >>>Регулярные выражения не проверяются, если это явно запрещено с > >>>помощью модификатора "^~", либо найдено точное совпадение с > >>>location'ом, заданным с модификатором "=". > >> > >> Максим, так у него же там "^~" - не регулярка, а её запрет. > > Спасибо, что поправили, ат о я уже доку разу по 10му перечитываю :) > > >А, торрможу. Но всё равно работать не будет, в location'ах, > >заданных обычными строками, переменные с тем же успехом не > >поддерживаются. > > if ($request_uri ~ ^/([^/]*).*$) { > set $subfolder $1; > } > > root /home/www/test.com/htdocs; > > location / { > rewrite ^/ /$subfolder/index.php; Вот тут - сработает rewrite, и подставит значение переменной $subfolder... > } > > /home/www/test.com/htdocs выглядит: > > test-1 > test-2 > test-3 > > Как-то же оно работает... ... а "location ^~ /$subfolder/..." - не сработает (если, конечно, запрос не будет содержать строку '$subfolder'). Вместо него запрос обработается в каком-нибудь "location ~ \.php$". Maxim Dounin From sergey.kobzar на itcraft.org Wed Dec 14 16:45:32 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Wed, 14 Dec 2011 18:45:32 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <20111214163211.GY67687@mdounin.ru> References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> <20111214141133.GT67687@mdounin.ru> <20111214143828.GV67687@mdounin.ru> <4EE8BC1E.3080305@itcraft.org> <20111214163211.GY67687@mdounin.ru> Message-ID: <4EE8D2AC.5020306@itcraft.org> On 12/14/11 18:32, Maxim Dounin wrote: >> /home/www/test.com/htdocs выглядит: >> >> test-1 >> test-2 >> test-3 >> >> Как-то же оно работает... > > ... а "location ^~ /$subfolder/..." - не сработает (если, конечно, > запрос не будет содержать строку '$subfolder'). Вместо него запрос > обработается в каком-нибудь "location ~ \.php$". Т.е. не отработает именно в этом локейшене определенном как ^~. Я правильно понимаю? > > Maxim Dounin > From sk на hlsrv.com Wed Dec 14 16:51:34 2011 From: sk на hlsrv.com (Sergej Kandyla) Date: Wed, 14 Dec 2011 18:51:34 +0200 Subject: php-fpm upstream pool In-Reply-To: <656771322855991@web115.yandex.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> Message-ID: <4EE8D416.7050108@hlsrv.com> On 02.12.2011 21:59, Denis F. Latypoff wrote: > > >>> Остаётся, соответственно, небольшое повышение QoS в случае очень >>> малого трафика (health check успевает раньше) или при сбое (можно >>> сэкономить единицы реальных запросов, т.к. не нужно посылать на >>> бекенд реальные запросы, пока health check'и продолжают >>> fail'иться). >>> >> так это самое неприятное и есть - посылать реальные запросы клиентов >> с интервалом в fail_timeout секунд на backend, который не работает. >> > всем пофиг. никто из юзеров тебе не напишет, что его послали на > неработающий бэкенд. да и фиг с ним, остальные 100000 тысяч довольны. > Мы ведь говорим о высокой нагрузке? Nginx же! > > >> proxy_connect_timeout по умолчанию 60 секунд, если поставить >> 1-2 секунды, то живые, но нагруженные backend`ы будут считаться >> не работающими и на остальные живые backend`ы в результате >> нагрузка еще больше вырастет и их все nginx начнет считать >> нерабочими на ближайшие fail_timeout секунд. >> >> а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15) >> то пользователь такую большую задержку заметит и может не дождавшись >> ответа от сервера уйти, посчитав его не работающим или перегруженным, >> хотя живые backend`ы были в наличии и ответ он мог получить быстрее. >> > Да блин. Если ты (это собирательный образ) только и умеешь что писать на > PHP, то сам себе злой буратино, тебе и апач подойдет, с твоими-то знаниями. > Зачем тебе nginx, которые неведомым образом позаботится обо всех твоих пяти > юзерах? (Четверых сразу да, а пятого погонять погонять по всем бекендам, > включить AI, и все-таки отдать работающему бекенду). > Если думаешь иначе - пиши пачт. > Геннадий прав. Проблемма актуальная. Nginx потому так и популярен, что разработчик прислушивается к коммунити и реализовывает нужные механизмы, в том числе и обработку ситуаций "кривых бекендов". Сам себе злой буратино с писаниной на пхп - это всё идет лесом при командной работе, где за бекенд и приложение отвечают и разрабатывают совершенно другие люди. Пример из жизни. Nginx load-balancer с ip_hash , бекенды - два томката. proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально. В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но при этом продолжал принимать соединения. Картина стала следующей: Юзер конектится на приложение (лоад-балансер отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой страничке - ситуация повторяется. Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял бекенды на "дохлость", и если бекенд не отвечает - то не слать на него запросы вообще, покуда он не подымется. Фича востребованная. Если вам она не нужна, то это не значит, что она не нужна вообще. From mdounin на mdounin.ru Wed Dec 14 16:50:36 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 20:50:36 +0400 Subject: php-fpm upstream pool In-Reply-To: <971984b8109bf209ba4d02513b0d8e7c.NginxMailingListRussian@forum.nginx.org> References: <20111202100736.GC67687@mdounin.ru> <971984b8109bf209ba4d02513b0d8e7c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111214165035.GZ67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 10:19:46AM -0500, igor.goncharenko wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > On Fri, Dec 02, 2011 at 03:47:31AM -0500, igor.goncharenko wrote: > > > > > > http://trac.nginx.org/nginx/ticket/64 > > > > > > Да. Очень похоже это оно. Тогда в > продакшин двигать на 1.0.X нельзя пока :( > > > > Баг потенциально может проявится > тогда и только тогда, когда более > > одного бекенда в пуле - мёртвые. И > почти не имеет шансов проявится, если > при этом > > более одного живого бекенда. > > А, интересно, что случается если мы > имеем всего 2 бэкенда. Неработающий > один считается больше одного или нет? :) Нет. > > При этом мёртвый бекенд в пуле - это, > вообще говоря, > > чрезвычайная ситуация. > > Вот-вот, и пока я иду чинить мертвый > бэкенд(ы), я должен быть уверен что nginx > работает с живыми. Есть мнение, что процедуру "иду чинить мёртвый бекенд" следует начинать с "убираю бекенд из пула". [...] > > По стабильности - 1.1.10 сейчас лучше, чем > 1.0.10. > > Хорошо, убедили, может тогда есть смысл > перевести 1.1.X в стейбл, если она по > стабильности лучше и фич уже добалено > много за полгода? В какой-то момент так и будет сделано. Пока у нас ещё есть планы на "поломать местами API". [...] Maxim Dounin From mdounin на mdounin.ru Wed Dec 14 17:05:44 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 21:05:44 +0400 Subject: php-fpm upstream pool In-Reply-To: <4EE8D416.7050108@hlsrv.com> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> <4EE8D416.7050108@hlsrv.com> Message-ID: <20111214170544.GA67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 06:51:34PM +0200, Sergej Kandyla wrote: > On 02.12.2011 21:59, Denis F. Latypoff wrote: > > > > > >>> Остаётся, соответственно, небольшое повышение QoS в случае очень > >>> малого трафика (health check успевает раньше) или при сбое (можно > >>> сэкономить единицы реальных запросов, т.к. не нужно посылать на > >>> бекенд реальные запросы, пока health check'и продолжают > >>> fail'иться). > >>так это самое неприятное и есть - посылать реальные запросы клиентов > >>с интервалом в fail_timeout секунд на backend, который не работает. > >всем пофиг. никто из юзеров тебе не напишет, что его послали на > >неработающий бэкенд. да и фиг с ним, остальные 100000 тысяч довольны. > >Мы ведь говорим о высокой нагрузке? Nginx же! > > > >>proxy_connect_timeout по умолчанию 60 секунд, если поставить > >>1-2 секунды, то живые, но нагруженные backend`ы будут считаться > >>не работающими и на остальные живые backend`ы в результате > >>нагрузка еще больше вырастет и их все nginx начнет считать > >>нерабочими на ближайшие fail_timeout секунд. > >> > >>а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15) > >>то пользователь такую большую задержку заметит и может не дождавшись > >>ответа от сервера уйти, посчитав его не работающим или перегруженным, > >>хотя живые backend`ы были в наличии и ответ он мог получить быстрее. > >Да блин. Если ты (это собирательный образ) только и умеешь что писать на > >PHP, то сам себе злой буратино, тебе и апач подойдет, с твоими-то знаниями. > >Зачем тебе nginx, которые неведомым образом позаботится обо всех твоих пяти > >юзерах? (Четверых сразу да, а пятого погонять погонять по всем бекендам, > >включить AI, и все-таки отдать работающему бекенду). > >Если думаешь иначе - пиши пачт. > > > Геннадий прав. Проблемма актуальная. > Nginx потому так и популярен, что разработчик прислушивается к > коммунити и реализовывает нужные механизмы, > в том числе и обработку ситуаций "кривых бекендов". > > Сам себе злой буратино с писаниной на пхп - это всё идет лесом при > командной работе, где за бекенд и приложение отвечают и > разрабатывают совершенно другие люди. > > Пример из жизни. > Nginx load-balancer с ip_hash , бекенды - два томката. > > proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально. > В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но при этом продолжал принимать соединения. > > Картина стала следующей: Юзер конектится на приложение (лоад-балансер отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой страничке - ситуация повторяется. > > > Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял > бекенды на "дохлость", и если бекенд не отвечает - то не слать на > него запросы вообще, покуда он не подымется. > > Фича востребованная. Если вам она не нужна, то это не значит, что > она не нужна вообще. Я стесняюсь спросить - вы 1.1.x (1.1.6+) на данном конкретном "примере из жизни" - пробовали? Maxim Dounin From sk на hlsrv.com Wed Dec 14 17:41:49 2011 From: sk на hlsrv.com (Sergej Kandyla) Date: Wed, 14 Dec 2011 19:41:49 +0200 Subject: php-fpm upstream pool In-Reply-To: <20111214170544.GA67687@mdounin.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> <4EE8D416.7050108@hlsrv.com> <20111214170544.GA67687@mdounin.ru> Message-ID: <4EE8DFDD.20606@hlsrv.com> On 14.12.2011 19:05, Maxim Dounin wrote: > >> Геннадий прав. Проблемма актуальная. >> Nginx потому так и популярен, что разработчик прислушивается к >> коммунити и реализовывает нужные механизмы, >> в том числе и обработку ситуаций "кривых бекендов". >> >> Сам себе злой буратино с писаниной на пхп - это всё идет лесом при >> командной работе, где за бекенд и приложение отвечают и >> разрабатывают совершенно другие люди. >> >> Пример из жизни. >> Nginx load-balancer с ip_hash , бекенды - два томката. >> >> proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально. >> В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но при этом продолжал принимать соединения. >> >> Картина стала следующей: Юзер конектится на приложение (лоад-балансер отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой страничке - ситуация повторяется. >> >> >> Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял >> бекенды на "дохлость", и если бекенд не отвечает - то не слать на >> него запросы вообще, покуда он не подымется. >> >> Фича востребованная. Если вам она не нужна, то это не значит, что >> она не нужна вообще. >> > Я стесняюсь спросить - вы 1.1.x (1.1.6+) на данном конкретном "примере из > жизни" - пробовали? > > нет. Это было пол года назад, еще до релиза 1.1.6, (и на nginx 0.8.54). Я не знал, что в 1.1.6 данный функционал переработан. Спасибо. From gmm на csdoc.com Wed Dec 14 17:54:05 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 14 Dec 2011 19:54:05 +0200 Subject: php-fpm upstream pool In-Reply-To: <971984b8109bf209ba4d02513b0d8e7c.NginxMailingListRussian@forum.nginx.org> References: <20111202100736.GC67687@mdounin.ru> <971984b8109bf209ba4d02513b0d8e7c.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EE8E2BD.1090207@csdoc.com> On 14.12.2011 17:19, igor.goncharenko wrote: > PS. Тут развели холивар по поводу haproxy > и alive чеков. Как человек, пользующийся > haproxy тоже (как tcp балансировщик), скажу, > что от таких чеков больше вреда чем > пользы :) Я так скажу - в nginx такая > функциональность не нужна спор на тему нужна / не нужна *без аргументации* - это как раз и будет "холивар". может быть не надо? -- Best regards, Gena From nginx-forum на nginx.us Wed Dec 14 17:55:30 2011 From: nginx-forum на nginx.us (shawn) Date: Wed, 14 Dec 2011 12:55:30 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgZnJvbnRlbmQn0L7QvA==?= In-Reply-To: <9d3a6cc2d65c8e9a0db6535555224356.NginxMailingListRussian@forum.nginx.org> References: <9d3a6cc2d65c8e9a0db6535555224356.NginxMailingListRussian@forum.nginx.org> Message-ID: Спасибо большое Алексей, была действительно проблема с именем. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220019,220067#msg-220067 From ne на vbart.ru Wed Dec 14 17:58:55 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 14 Dec 2011 21:58:55 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <20111214162424.GW67687@mdounin.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> Message-ID: <201112142158.55236.ne@vbart.ru> On Wednesday 14 December 2011 20:24:24 Maxim Dounin wrote: > On Wed, Dec 14, 2011 at 07:39:19PM +0400, Валентин Бартенев wrote: > > On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote: > > > Давай для начала распишем последствия обычного "последовательного" > > > применения лимитов, чтобы было понятно что так нельзя. Или, > > > наоборот, можно, но с какими ограничениями. > > > > > > Что касается принципа, то он мне не нравится: нам либо нужно всё > > > это делать держа локи (deadlock expected), либо имеем race между > > > проверкой и обновлением (и, опять же, локи придётся брать два > > > раза, что тоже не очень хорошо). > > > > В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд, > > всё можно сделать по тому же принципу. > > В limit_conn они второй раз берутся, когда мы откатываем лимиты - > либо по завершению запроса, либо по наступанию на лимит. И race'а > там соответственно нет. > Тут мы тоже можем сделать "откат лимитов", которые не были применены. Срабатывает лимит - сохраняем его delay и указатель на него, проверяем дальше, если находим лимит с большим delay, сохраняем новые значения и делаем откат лимита, за которым был установлен предыдущий delay. Если находим лимит, который должен отклонить запрос - отклоняем запрос и делаем откат лимита за которым был установлен delay (если ранее такой был), прекращаем дальнейшую проверку. Я лишь говорю о принципиальной возможность реализовать по предложенной схеме. В остальном - убедил. См. ниже. [...] > > Вот как раз в примере выше - подобное поведение вполне нормально, > при условии правильного порядка лимитов. Мы хотим пускать людей > на сайт, пока не превышен лимит на этот сайт, и мы хотим отсекать > людей с ^R, чтобы они вообще никому никаких проблем не доставляли. > Т.е. конструкция > > limit_req ; > limit_req ; > > не должна никак считать в per-host лимит запросы, отклонённые на основании > "ip-адресом не вышел". И в то же время должна считать суммарный > лимит для хоста, и отклонять при необходимости запросы за него > выходящие. > Озадачил, я думал-думал, но пока так и не смог придумать удачного контр-примера, который бы не решался правильным порядком. Если так и не смогу придумать, то сделаю последовательную проверку до первого срабатывания. Плюсы очевидны: проще, меньше локов и, соответственно, быстрее. -- Валентин Бартенев From zzz на zzz.org.ua Wed Dec 14 18:09:27 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Wed, 14 Dec 2011 20:09:27 +0200 Subject: php-fpm upstream pool In-Reply-To: <4EE8E2BD.1090207@csdoc.com> References: <20111202100736.GC67687@mdounin.ru> <971984b8109bf209ba4d02513b0d8e7c.NginxMailingListRussian@forum.nginx.org> <4EE8E2BD.1090207@csdoc.com> Message-ID: On Wed, Dec 14, 2011 at 7:54 PM, Gena Makhomed wrote: > On 14.12.2011 17:19, igor.goncharenko wrote: > >> PS. Тут развели холивар по поводу haproxy >> и alive чеков. Как человек, пользующийся >> haproxy тоже (как tcp балансировщик), скажу, >> что от таких чеков больше вреда чем >> пользы :) Я так скажу - в nginx такая >> функциональность не нужна > > > спор на тему нужна / не нужна *без аргументации* - > это как раз и будет "холивар". может быть не надо? Нужно конечно, что тут даже думать. Это вопрос скорее о том, что важнее, посетители или машины. И такое ощущение, что в nginx'е считают, что важнее второе. From mdounin на mdounin.ru Wed Dec 14 18:29:28 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Dec 2011 22:29:28 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <201112142158.55236.ne@vbart.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <201112142158.55236.ne@vbart.ru> Message-ID: <20111214182928.GD67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 09:58:55PM +0400, Валентин Бартенев wrote: > On Wednesday 14 December 2011 20:24:24 Maxim Dounin wrote: > > On Wed, Dec 14, 2011 at 07:39:19PM +0400, Валентин Бартенев wrote: > > > On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote: > > > > Давай для начала распишем последствия обычного "последовательного" > > > > применения лимитов, чтобы было понятно что так нельзя. Или, > > > > наоборот, можно, но с какими ограничениями. > > > > > > > > Что касается принципа, то он мне не нравится: нам либо нужно всё > > > > это делать держа локи (deadlock expected), либо имеем race между > > > > проверкой и обновлением (и, опять же, локи придётся брать два > > > > раза, что тоже не очень хорошо). > > > > > > В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд, > > > всё можно сделать по тому же принципу. > > > > В limit_conn они второй раз берутся, когда мы откатываем лимиты - > > либо по завершению запроса, либо по наступанию на лимит. И race'а > > там соответственно нет. > > > > Тут мы тоже можем сделать "откат лимитов", которые не были применены. > > Срабатывает лимит - сохраняем его delay и указатель на него, проверяем дальше, > если находим лимит с большим delay, сохраняем новые значения и делаем откат > лимита, за которым был установлен предыдущий delay. > > Если находим лимит, который должен отклонить запрос - отклоняем запрос и делаем > откат лимита за которым был установлен delay (если ранее такой был), прекращаем > дальнейшую проверку. > > Я лишь говорю о принципиальной возможность реализовать по предложенной схеме. > В остальном - убедил. См. ниже. Ну если свести схему к "атомарно применяем лимиты (не применяем, если хотя бы один сработал)" - то да, это принципиальная возможность "реализовать по предложенной схеме". :) > [...] > > > > Вот как раз в примере выше - подобное поведение вполне нормально, > > при условии правильного порядка лимитов. Мы хотим пускать людей > > на сайт, пока не превышен лимит на этот сайт, и мы хотим отсекать > > людей с ^R, чтобы они вообще никому никаких проблем не доставляли. > > Т.е. конструкция > > > > limit_req ; > > limit_req ; > > > > не должна никак считать в per-host лимит запросы, отклонённые на основании > > "ip-адресом не вышел". И в то же время должна считать суммарный > > лимит для хоста, и отклонять при необходимости запросы за него > > выходящие. > > > > Озадачил, я думал-думал, но пока так и не смог придумать удачного контр-примера, > который бы не решался правильным порядком. Если так и не смогу придумать, то > сделаю последовательную проверку до первого срабатывания. Плюсы очевидны: проще, > меньше локов и, соответственно, быстрее. Минусы, в общем, тоже очевидны: как минимум оно начинает зависить от порядка указания в конфиге, что плохо. Я, впрочем, подозреваю, что хорошие контрпримеры существуют. Maxim Dounin From belov1985 на gmail.com Wed Dec 14 19:51:10 2011 From: belov1985 на gmail.com (=?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0=?=) Date: Wed, 14 Dec 2011 21:51:10 +0200 Subject: =?UTF-8?B?0J7Qv9GA0LXQtNC10LvQtdC90LjQtSDRgNCw0LfQvNC10YDQsCBrZXlzX3pvbmU=?= Message-ID: <4EE8FE2E.9090708@gmail.com> Здравствуйте! Подскажите, как правильно рассчитать правильный размер keys_zone? Был 64m, при размере кеша 675M и кол-ве элементов 494к память закончилась :) Увеличил до 96m, посмотрим на сколько хватит. Просто не хочется постоянно лазить в error.log и смотреть, все ли там нормально) From nginx-forum на nginx.us Wed Dec 14 18:54:29 2011 From: nginx-forum на nginx.us (Craken) Date: Wed, 14 Dec 2011 13:54:29 -0500 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCB1bmxpbmsg0LIgZXJyb3IubG9n?= In-Reply-To: <4EE8D73D.2090701@gmail.com> References: <4EE8D73D.2090701@gmail.com> Message-ID: <3995f13d0229fc2d87cc3f9d4bba4375.NginxMailingListRussian@forum.nginx.org> > Подскажите, можно ли как-то отключить запись сообщений об ошибке unlink Только так: error_log /var/log/nginx-error.log alert; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220054,220077#msg-220077 From postmaster на softsearch.ru Wed Dec 14 18:54:46 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 14 Dec 2011 22:54:46 +0400 Subject: =?UTF-8?B?UmVbMl06INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <20111214182928.GD67687@mdounin.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <201112142158.55236.ne@vbart.ru> <20111214182928.GD67687@mdounin.ru> Message-ID: <323471646.20111214225446@softsearch.ru> Здравствуйте, Maxim. Простите, что встреваю в Ваш разговор. Хочу заметить, что весьма возможно очень многим людям подойдут не идеальные варианты, когда при ограничении в 1000 запросов в минуту проскочит не ровно 1000, а 1001 или даже 1002. Или наоборот, заблокирует 998 или 998-ый запрос. Т.е. весьма вероятно, что исключительная точностью в подобном вопросе востребована очень немногими, и потому возможно сэкономить на блокировках и написать код, работающий не с абсолютной точностью, но зато хорошо заточенный под недалёкое будущее, когда количество ядер будет исчисляться сотнями. Саму же небрежность в работе описать в документации, снабдив причинами, почему выбрана именно такая реализация. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Wed Dec 14 18:58:38 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 14 Dec 2011 22:58:38 +0400 Subject: =?UTF-8?B?UmU6INCe0L/RgNC10LTQtdC70LXQvdC40LUg0YDQsNC30LzQtdGA0LAga2V5c196?= =?UTF-8?B?b25l?= In-Reply-To: <4EE8FE2E.9090708@gmail.com> References: <4EE8FE2E.9090708@gmail.com> Message-ID: <763164252.20111214225838@softsearch.ru> Здравствуйте, Константин. > Подскажите, как правильно рассчитать правильный размер keys_zone? > Был 64m, при размере кеша 675M и кол-ве элементов 494к память > закончилась :) Увеличил до 96m, посмотрим на сколько хватит. Просто > не хочется постоянно лазить в error.log и смотреть, все ли там > нормально) Экспериментальным путём. Количество элементов в кэше ведь может не зависеть от размера кэша на диске, если, например, кэшируются не все файлы, а только те, которые запрашиваются более Х раз. В листе где-то уже был подобный вопрос. Игорь отвечал сколько байт тратится на один элемент кэша. Да Вы и сами можете прикинуть по приведённым Вами же цифрам. -- С уважением, Михаил mailto:postmaster на softsearch.ru From wangsamp на gmail.com Wed Dec 14 19:10:21 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 14 Dec 2011 21:10:21 +0200 (EET) Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: <4EE8D2AC.5020306@itcraft.org> References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> <20111214141133.GT67687@mdounin.ru> <20111214143828.GV67687@mdounin.ru> <4EE8BC1E.3080305@itcraft.org> <20111214163211.GY67687@mdounin.ru> <4EE8D2AC.5020306@itcraft.org> Message-ID: Today Dec 14, 2011 at 18:45 Sergey Kobzar wrote: > > ... а "location ^~ /$subfolder/..." - не сработает (если, конечно, > > запрос не будет содержать строку '$subfolder'). Вместо него запрос > > обработается в каком-нибудь "location ~ \.php$". > > Т.е. не отработает именно в этом локейшене определенном как ^~. Я > правильно понимаю? В любом location переменные не поддерживаются - обработка происходит на этапе чтения конфига. Можно регулярками задать выделения и потом их использовать, но не наоборот. -- WNGS-RIPE From sergey.kobzar на itcraft.org Wed Dec 14 19:23:36 2011 From: sergey.kobzar на itcraft.org (Sergey Kobzar) Date: Wed, 14 Dec 2011 21:23:36 +0200 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10L3QsCBpZiDQvdCwIHRyeV9maWxlcw==?= In-Reply-To: References: <4EE7983D.2080404@itcraft.org> <20111213235226.GM67687@mdounin.ru> <4EE8A67F.4010201@itcraft.org> <20111214141133.GT67687@mdounin.ru> <20111214143828.GV67687@mdounin.ru> <4EE8BC1E.3080305@itcraft.org> <20111214163211.GY67687@mdounin.ru> <4EE8D2AC.5020306@itcraft.org> Message-ID: <4EE8F7B8.4010100@itcraft.org> On 12/14/11 21:10, Oleksandr V. Typlyns'kyi wrote: > Today Dec 14, 2011 at 18:45 Sergey Kobzar wrote: > >>> ... а "location ^~ /$subfolder/..." - не сработает (если, конечно, >>> запрос не будет содержать строку '$subfolder'). Вместо него запрос >>> обработается в каком-нибудь "location ~ \.php$". >> >> Т.е. не отработает именно в этом локейшене определенном как ^~. Я >> правильно понимаю? > > В любом location переменные не поддерживаются - обработка происходит на этапе чтения конфига. > Можно регулярками задать выделения и потом их использовать, но не наоборот. Понял. Спасибо. From belov1985 на gmail.com Wed Dec 14 20:35:59 2011 From: belov1985 на gmail.com (=?KOI8-R?Q?=EB=CF=CE=D3=D4=C1=CE=D4=C9=CE?=) Date: Wed, 14 Dec 2011 22:35:59 +0200 Subject: =?UTF-8?B?UmU6INCe0L/RgNC10LTQtdC70LXQvdC40LUg0YDQsNC30LzQtdGA0LAga2V5c196?= =?UTF-8?B?b25l?= In-Reply-To: <763164252.20111214225838@softsearch.ru> References: <4EE8FE2E.9090708@gmail.com> <763164252.20111214225838@softsearch.ru> Message-ID: <4EE908AF.6070109@gmail.com> Здравствуйте, Михаил. 14.12.11 20:58, Михаил Монашёв пишет: > Экспериментальным путём. Количество элементов в кэше ведь может не > зависеть от размера кэша на диске, если, например, кэшируются не все > файлы, а только те, которые запрашиваются более Х раз. Да уже несколько раз увеличивали, пока никакой зависимости не нашли :) > В листе где-то уже был подобный вопрос. Игорь отвечал сколько байт > тратится на один элемент кэша. Да Вы и сами можете прикинуть по > приведённым Вами же цифрам. Честно, искал прежде чем написать в рассылку! Нашел похожий вопрос (http://www.lexa.ru/nginx-ru/msg33173.html) который остался без ответа :( Но если Вы говорите что есть, то буду дальше искать :) Спасибо. From nginx-forum на nginx.us Wed Dec 14 19:38:24 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Wed, 14 Dec 2011 14:38:24 -0500 Subject: php-fpm upstream pool In-Reply-To: <20111214165035.GZ67687@mdounin.ru> References: <20111214165035.GZ67687@mdounin.ru> Message-ID: Maxim Dounin Wrote: > > > При этом мёртвый бекенд в пуле - это, вообще говоря, чрезвычайная ситуация. > > > > Вот-вот, и пока я иду чинить мертвый > > бэкенд(ы), я должен быть уверен что nginx > > работает с живыми. > > Есть мнение, что процедуру "иду чинить мёртвый бекенд" следует > начинать с "убираю бекенд из пула". Само собой. Это если сразу понятно что с бэкендом и что это надолго. Бывают ситуации, когда починка бэкенда может быть быстрее чем убрать бэкенд из пула. А может быть наоборот, бэкенд умер, но системный администратор (я например), сможет его починить только через полчаса (в метро еду), что тогда? {skip} > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219032,220083#msg-220083 From nginx-forum на nginx.us Wed Dec 14 19:54:14 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Wed, 14 Dec 2011 14:54:14 -0500 Subject: php-fpm upstream pool In-Reply-To: References: Message-ID: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Alexandr Gomoliako Wrote: ------------------------------------------------------- > On Wed, Dec 14, 2011 at 7:54 PM, Gena Makhomed > wrote: > > On 14.12.2011 17:19, igor.goncharenko wrote: > > > >> PS. Тут развели холивар по поводу haproxy и alive чеков. Как человек, > пользующийся haproxy тоже (как tcp балансировщик), скажу, > >> что от таких чеков больше вреда чем > >> пользы :) Я так скажу - в nginx такая > >> функциональность не нужна > > > > > > спор на тему нужна / не нужна *без аргументации* - > > это как раз и будет "холивар". может быть не надо? > > Нужно конечно, что тут даже думать. Это вопрос скорее > о том, что важнее, посетители или машины. Тут я абсолютно согласен с Максимом - бывают ситуации когда alive чек говорит что все хорошо, но бэкенд тем не менее перекосило, и на самом деле он должен считаться нерабочим. Грамотно реализованный алгоритм выявления таких бэкендов лучше чем alive чеки. Кроме того, при серьезной нагрузке такие чеки вообще противопоказаны, потому что их надо конфигурять ну например раз в секунду, а если у вас 50 запросов в секунду, то они точно не помогут. А сколько при этом мусора будет в логах бэкенда при нормальной работе я уже не говорю. > > И такое ощущение, что в nginx'е считают, что важнее второе. Если бы "в nginxе" так считали, им бы никто не пользовался. "Выбрать то что _НЕ_ делать так же важно как то что _ДЕЛАТЬ_" (вольная цитата от Джобса). > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219032,220084#msg-220084 From zzz на zzz.org.ua Wed Dec 14 20:39:16 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Wed, 14 Dec 2011 22:39:16 +0200 Subject: php-fpm upstream pool In-Reply-To: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: On Wed, Dec 14, 2011 at 9:54 PM, igor.goncharenko wrote: > Тут я абсолютно согласен с Максимом - > бывают ситуации когда alive чек говорит > что все хорошо, но бэкенд тем не менее > перекосило, и на самом деле он должен > считаться нерабочим. Грамотно > реализованный алгоритм выявления > таких бэкендов лучше чем alive чеки. Да, и это нужно. Но посылать живого человека на нерабочий бэкенд, чтобы проверить - глупость. > Если бы "в nginxе" так считали, им бы никто > не пользовался. Если бы - не аргумент. Если бы не считали, уже бы давно вытеснили апач. From bdfy на mail.ru Wed Dec 14 21:37:39 2011 From: bdfy на mail.ru (=?UTF-8?B?SXZhbg==?=) Date: Thu, 15 Dec 2011 01:37:39 +0400 Subject: =?UTF-8?B?bmdpbnhfaHR0cF9wdXNoX21vZHVsZSAg0Lgg0YDQsNC30LzQtdGAINGB0L7QvtCx?= =?UTF-8?B?0YnQtdC90LjRjw==?= In-Reply-To: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: я использую пример описанный по этой ссылке: http://blog.jamieisaacs.com/2010/08/27/comet-with-nginx-and-jquery/ для эмуляции senderа используется следующий скрипт: !/usr/bin/python import urllib2 import urllib post = "" for i in range(0,100000): post = post + str(1) req2 = urllib2.Request("http://localhost/cheetah/pub", post, {}) response = urllib2.urlopen(req2, post) т е в двух словах - создается строчка состоящая из 100000 единичек и посылается методом POST в nginx. Проблема возникает в javascript listen: длина полученного сообщения каждый 2 раз < 100000. т е такое ощущение что часть полученного ответа теряется. В чем может быть проблема ? ( для кототких сообщений все в порядке ). From ano на bestmx.ru Thu Dec 15 08:38:14 2011 From: ano на bestmx.ru (Andrey N. Oktyabrski) Date: Thu, 15 Dec 2011 11:38:14 +0300 Subject: php-fpm upstream pool In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EE9B1F6.5010907@bestmx.ru> On 14.12.11 23:39, Alexandr Gomoliako wrote: > On Wed, Dec 14, 2011 at 9:54 PM, igor.goncharenko wrote: >> Тут я абсолютно согласен с Максимом - >> бывают ситуации когда alive чек говорит >> что все хорошо, но бэкенд тем не менее >> перекосило, и на самом деле он должен >> считаться нерабочим. Грамотно >> реализованный алгоритм выявления >> таких бэкендов лучше чем alive чеки. > > Да, и это нужно. Но посылать живого человека > на нерабочий бэкенд, чтобы проверить - глупость. Нет, это не глупость, это нормально. Про 50 запросов и одну проверку в секунду был хороший пример. >> Если бы "в nginxе" так считали, им бы никто >> не пользовался. > > Если бы - не аргумент. Если бы не считали, > уже бы давно вытеснили апач. Вы не должны этого хотеть. Правда, не надо. From thresh на videolan.org Thu Dec 15 07:46:35 2011 From: thresh на videolan.org (Konstantin Pavlov) Date: Thu, 15 Dec 2011 11:46:35 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80Ysg0YEgbmdpbngg0LIg0YDQtdC20LjQvNC1IHBy?= =?UTF-8?B?b3h5X3Bhc3Mg0YEgYW1hem9uINC4IGNocm9tZS9jaHJvbWl1bQ==?= In-Reply-To: <20111213091302.GB3220@snowwhite.immo> References: <20111212114158.GX13414@snowwhite.immo> <20111213055708.GA19992@snowwhite.immo> <20111213072322.GA3220@snowwhite.immo> <20111213091302.GB3220@snowwhite.immo> Message-ID: <20111215074635.GA9563@snowwhite.immo> On Tue, Dec 13, 2011 at 01:13:02PM +0400, Konstantin Pavlov wrote: > Добавил: > > proxy_set_header Range $http_range; > proxy_set_header If-Range $http_if_range; > proxy_no_cache $http_range $http_if_range; > > в конфигурационный файл, будем тестировать. Судя по всему, это помогло. Всем спасибо. -- Konstantin Pavlov VideoLAN team From ilya.pirogov на devels.info Thu Dec 15 07:53:15 2011 From: ilya.pirogov на devels.info (=?UTF-8?B?0JjQu9GM0Y8g0J/QuNGA0L7Qs9C+0LI=?=) Date: Thu, 15 Dec 2011 11:53:15 +0400 Subject: =?UTF-8?B?UmU6IG5naW54X2h0dHBfcHVzaF9tb2R1bGUg0Lgg0YDQsNC30LzQtdGAINGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Y8=?= In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: 15 декабря 2011 г. 1:37 пользователь Ivan написал: > > для эмуляции senderа используется следующий скрипт: > > ... > > post = "" > for i in range(0,100000): > post = post + str(1) > Прошу прощенья за offtop, но это на python'е можно сделать так: post = "1" * 100000 Будет на несколько порядков быстрее и нагляднее. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From latypoff на yandex.ru Thu Dec 15 08:55:46 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Thu, 15 Dec 2011 15:55:46 +0700 Subject: php-fpm upstream pool In-Reply-To: <4EE8D416.7050108@hlsrv.com> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> <4EE8D416.7050108@hlsrv.com> Message-ID: <138581323939346@web67.yandex.ru> 14.12.2011, 23:51, "Sergej Kandyla" : > On 02.12.2011 21:59, Denis F. Latypoff wrote: > >>>>    Остаётся, соответственно, небольшое повышение QoS в случае очень >>>>    малого трафика (health check успевает раньше) или при сбое (можно >>>>    сэкономить единицы реальных запросов, т.к. не нужно посылать на >>>>    бекенд реальные запросы, пока health check'и продолжают >>>>    fail'иться). >>>  так это самое неприятное и есть - посылать реальные запросы клиентов >>>  с интервалом в fail_timeout секунд на backend, который не работает. >>  всем пофиг. никто из юзеров тебе не напишет, что его послали на >>  неработающий бэкенд. да и фиг с ним, остальные 100000 тысяч довольны. >>  Мы ведь говорим о высокой нагрузке? Nginx же! >>>  proxy_connect_timeout по умолчанию 60 секунд, если поставить >>>  1-2 секунды, то живые, но нагруженные backend`ы будут считаться >>>  не работающими и на остальные живые backend`ы в результате >>>  нагрузка еще больше вырастет и их все nginx начнет считать >>>  нерабочими на ближайшие fail_timeout секунд. >>> >>>  а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15) >>>  то пользователь такую большую задержку заметит и может не дождавшись >>>  ответа от сервера уйти, посчитав его не работающим или перегруженным, >>>  хотя живые backend`ы были в наличии и ответ он мог получить быстрее. >>  Да блин. Если ты (это собирательный образ) только и умеешь что писать на >>  PHP, то сам себе злой буратино, тебе и апач подойдет, с твоими-то знаниями. >>  Зачем тебе nginx, которые неведомым образом позаботится обо всех твоих пяти >>  юзерах? (Четверых сразу да, а пятого погонять погонять по всем бекендам, >>  включить AI, и все-таки отдать работающему бекенду). >>  Если думаешь иначе - пиши пачт. > > Геннадий прав.  Проблемма актуальная. > Nginx потому так и популярен, что разработчик прислушивается к коммунити > и реализовывает нужные механизмы, > в том числе и обработку ситуаций "кривых бекендов". > > Сам себе злой буратино с писаниной на пхп - это всё идет лесом при > командной работе, где за бекенд и приложение отвечают и разрабатывают > совершенно другие люди. > > Пример из жизни. > Nginx load-balancer с  ip_hash , бекенды - два томката. > > proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально. О какой высокой нагрузке идет речь? У нас тут хайлоад так-то... > В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но при этом продолжал принимать соединения. > > Картина стала следующей:  Юзер конектится на приложение (лоад-балансер отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично.  Юзер шлет второй запрос к другой страничке - ситуация повторяется. > > Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял бекенды > на "дохлость" И этим самым добил бекенда. >, и если бекенд не отвечает - то не слать на него запросы > вообще, покуда он не подымется. > > Фича востребованная. Если вам она не нужна, то это не значит, что она не > нужна вообще. > -- br, Denis F. Latypoff. From nginx-forum на nginx.us Thu Dec 15 10:20:58 2011 From: nginx-forum на nginx.us (hg_04) Date: Thu, 15 Dec 2011 05:20:58 -0500 Subject: HttpUpstreamRequestHashModule Message-ID: <665ec8b8a04edffbcd644ff7e815e56a.NginxMailingListRussian@forum.nginx.org> Почему вы не хотите модуль включить в дефолтную сборку и объединить с iphash? неужели они на столько разные? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220099,220099#msg-220099 From mdounin на mdounin.ru Thu Dec 15 12:38:55 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Dec 2011 16:38:55 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <323471646.20111214225446@softsearch.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <201112142158.55236.ne@vbart.ru> <20111214182928.GD67687@mdounin.ru> <323471646.20111214225446@softsearch.ru> Message-ID: <20111215123854.GH67687@mdounin.ru> Hello! On Wed, Dec 14, 2011 at 10:54:46PM +0400, Михаил Монашёв wrote: > Простите, что встреваю в Ваш разговор. Хочу заметить, что весьма > возможно очень многим людям подойдут не идеальные варианты, когда при > ограничении в 1000 запросов в минуту проскочит не ровно 1000, а 1001 > или даже 1002. Или наоборот, заблокирует 998 или 998-ый запрос. Т.е. > весьма вероятно, что исключительная точностью в подобном вопросе > востребована очень немногими, и потому возможно сэкономить на > блокировках и написать код, работающий не с абсолютной точностью, но > зато хорошо заточенный под недалёкое будущее, когда количество ядер > будет исчисляться сотнями. Саму же небрежность в работе описать в > документации, снабдив причинами, почему выбрана именно такая > реализация. Совсем без блокировок - не обойтись, т.к. там обход дерева в разделяемой памяти, и потом ещё и обновление нескольких значений. Без блокировок будет не просто неточно, а в лучшем случае - просто мусор, в худшем - segmentation fault. Maxim Dounin p.s. Ты вот лучше кейсов накидай - как ты будешь использовать несколько одновременных limit_req, когда они будут? From mdounin на mdounin.ru Thu Dec 15 13:09:12 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Dec 2011 17:09:12 +0400 Subject: HttpUpstreamRequestHashModule In-Reply-To: <665ec8b8a04edffbcd644ff7e815e56a.NginxMailingListRussian@forum.nginx.org> References: <665ec8b8a04edffbcd644ff7e815e56a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111215130912.GJ67687@mdounin.ru> Hello! On Thu, Dec 15, 2011 at 05:20:58AM -0500, hg_04 wrote: > Почему вы не хотите модуль включить в > дефолтную сборку и объединить с iphash? > неужели они на столько разные? "Включить" его нельзя, можно написать заново правильно. В планах есть, но по срокам пока ясности нет. Объединить с ip_hash тоже нельзя, там алгоритмика совершенно разная. Maxim Dounin From swood на fotofor.biz Thu Dec 15 14:41:00 2011 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 15 Dec 2011 18:41:00 +0400 Subject: limit_zone Message-ID: У меня вопрос по документации. Вот тут: http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html Случаем опечатка не закралась? Почему-то у меня упорно nginx не хочет принимать директиву limit_conn_zone. -- Best regards, Anton Kiryushkin, From mdounin на mdounin.ru Thu Dec 15 15:02:22 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Dec 2011 19:02:22 +0400 Subject: nginx-1.0.11 Message-ID: <20111215150222.GP67687@mdounin.ru> Изменения в nginx 1.0.11 15.12.2011 *) Изменение: теперь двойные кавычки экранируется при выводе SSI-командой echo. Спасибо Зауру Абасмирзоеву. *) Добавление: директива image_filter_sharpen. *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовалось SNI; ошибка появилась в 1.0.9. *) Исправление: сигнал SIGWINCH переставал работать после первого обновления исполняемого файла; ошибка появилась в 1.0.9. *) Исправление: строки "If-Modified-Since", "If-Range" и им подобные в заголовке запроса клиента могли передаваться бэкенду при кэшировании; или не передаваться при выключенном кэшировании, если кэширование было включено в другой части конфигурации. *) Исправление: в директиве scgi_param при использовании составных параметров. *) Исправление: директивы add_header и expires не работали для ответов с кодом 206, если запрос проксировался. *) Исправление: в директиве "expires @time". *) Исправление: в модуле ngx_http_flv_module. Спасибо Piotr Sikora. *) Исправление: в модуле ngx_http_mp4_module. *) Исправление: nginx не собирался на FreeBSD 10. *) Исправление: nginx не собирался на AIX. Maxim Dounin From mdounin на mdounin.ru Thu Dec 15 15:03:56 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Dec 2011 19:03:56 +0400 Subject: limit_zone In-Reply-To: References: Message-ID: <20111215150355.GR67687@mdounin.ru> Hello! On Thu, Dec 15, 2011 at 06:41:00PM +0400, Anton Kiryushkin wrote: > У меня вопрос по документации. Вот тут: > http://nginx.org/ru/docs/http/ngx_http_limit_conn_module.html > Случаем опечатка не закралась? Почему-то у меня упорно nginx не хочет > принимать директиву limit_conn_zone. 1.1.8+ В более старых версиях, в т.ч. 1.0.x, ещё используется директива limit_zone. Maxim Dounin From sk на hlsrv.com Thu Dec 15 16:16:36 2011 From: sk на hlsrv.com (Sergej Kandyla) Date: Thu, 15 Dec 2011 18:16:36 +0200 Subject: php-fpm upstream pool In-Reply-To: <138581323939346@web67.yandex.ru> References: <20111201171227.GZ67687@mdounin.ru> <201112022002.48984.ne@vbart.ru> <201112022017.26541.ne@vbart.ru> <4ED900A4.2070103@csdoc.com> <20111202175128.GI67687@mdounin.ru> <4ED91E43.3020907@csdoc.com> <656771322855991@web115.yandex.ru> <4EE8D416.7050108@hlsrv.com> <138581323939346@web67.yandex.ru> Message-ID: <4EEA1D64.8010001@hlsrv.com> On 15.12.2011 10:55, Denis F. Latypoff wrote: > >> proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально. >> > О какой высокой нагрузке идет речь? У нас тут хайлоад так-то... > почему оперирование термином "типа хайлоад" должно что-то кардинально менять? Или использовать функционал, который имеется в nginx для балансировки запросов, защиты от перегрузки бекенда, проксирования статики и т.п. - уже стало зазорным? > > >> >> Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял бекенды >> на "дохлость" >> > И этим самым добил бекенда. > Почему? А так бекенд добивали юзеры, плюс явное ухудшение QoS. From postmaster на softsearch.ru Thu Dec 15 16:32:29 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 15 Dec 2011 20:32:29 +0400 Subject: sdch Message-ID: <145916647.20111215203229@softsearch.ru> Здравствуйте. Браузер во с таким юзер-агентов: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 предлагает сжать страничку вот такими методами: Accept-Encoding: gzip,deflate,sdch Последний метод новый: http://en.wikipedia.org/wiki/SDCH -- С уважением, Михаил mailto:postmaster на softsearch.ru From temotor на gmail.com Thu Dec 15 16:52:23 2011 From: temotor на gmail.com (Sergey Shepelev) Date: Thu, 15 Dec 2011 20:52:23 +0400 Subject: sdch In-Reply-To: <145916647.20111215203229@softsearch.ru> References: <145916647.20111215203229@softsearch.ru> Message-ID: 2011/12/15 Михаил Монашёв : > Здравствуйте. > > Браузер во с таким юзер-агентов: > Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 > предлагает сжать страничку вот такими методами: > Accept-Encoding: gzip,deflate,sdch > > Последний метод новый: http://en.wikipedia.org/wiki/SDCH > Chromium с каких-то первых версий поддерживает sdch, то есть уже далеко не первый год. А к чему вы клоните? :) From zzz на zzz.org.ua Thu Dec 15 19:10:18 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Thu, 15 Dec 2011 21:10:18 +0200 Subject: php-fpm upstream pool In-Reply-To: <4EE9B1F6.5010907@bestmx.ru> References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> <4EE9B1F6.5010907@bestmx.ru> Message-ID: On Thu, Dec 15, 2011 at 10:38 AM, Andrey N. Oktyabrski wrote: >> Да, и это нужно. Но посылать живого человека >> на нерабочий бэкенд, чтобы проверить - глупость. > > Нет, это не глупость, это нормально. Что же здесь нормального? Это проблема, которую с большой вероятностью заметят самые активные постоянные посетители. Если вы можете их игнорировать, то может вообще не стоит о фейловере заботиться, потерпят? From n.g.i.n.x.e.r на gmail.com Thu Dec 15 19:31:40 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Thu, 15 Dec 2011 22:31:40 +0300 Subject: nginx redis session Message-ID: Задача такая - хранить сессии в редисе. Возможно ли такое сделать и как? From zzz на zzz.org.ua Thu Dec 15 19:50:16 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Thu, 15 Dec 2011 21:50:16 +0200 Subject: nginx redis session In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 9:31 PM, Роман wrote: > Задача такая - хранить сессии в редисе. > Возможно ли такое сделать и как? Хранить в редисе конечно возможно. Но вы наверное имеете в виду проводить аутентификацию через nginx? Тогда нужно что-то стороннее. http://zzzcpan.github.com/nginx-perl/Nginx/Redis.html From n.g.i.n.x.e.r на gmail.com Thu Dec 15 20:08:23 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Thu, 15 Dec 2011 23:08:23 +0300 Subject: nginx redis session In-Reply-To: References: Message-ID: У меня стоит балансировщик, а он с сессий не дружит. ip-hash использовать не хочется т.к. убивается вся идея балансировки, вот и подумал о хранении сессий в памяти. Мемкеш использовать не хочется, т.к. развивается медленно и нужна репликация. 15 декабря 2011 г. 22:50 пользователь Alexandr Gomoliako написал: > On Thu, Dec 15, 2011 at 9:31 PM, Роман wrote: >> Задача такая - хранить сессии в редисе. >> Возможно ли такое сделать и как? > > Хранить в редисе конечно возможно. > Но вы наверное имеете в виду проводить аутентификацию > через nginx? Тогда нужно что-то стороннее. > > http://zzzcpan.github.com/nginx-perl/Nginx/Redis.html > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zzz на zzz.org.ua Thu Dec 15 20:16:34 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Thu, 15 Dec 2011 22:16:34 +0200 Subject: nginx redis session In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 10:08 PM, Роман wrote: > У меня стоит балансировщик, а он с сессий не дружит. > ip-hash использовать не хочется т.к. убивается вся идея балансировки, > вот и подумал о хранении сессий  в памяти. Лучше не хранить сессии у себя вообще. Самый примитивный способ отдавать сессию и подпись на сохранение клиенту и проверять при получении if ( hmac_sha1(session, global_secret_key) == session_signature ) { From zzz на zzz.org.ua Thu Dec 15 20:31:33 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Thu, 15 Dec 2011 22:31:33 +0200 Subject: nginx redis session In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 10:16 PM, Alexandr Gomoliako wrote: > Лучше не хранить сессии у себя вообще. Самый примитивный способ > отдавать сессию и подпись на сохранение клиенту и проверять > при получении >    if ( hmac_sha1(session, global_secret_key) == session_signature ) { Ошибка, вместо сессии конечно же имелся в виду пользователь. From n.g.i.n.x.e.r на gmail.com Thu Dec 15 20:38:54 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Thu, 15 Dec 2011 23:38:54 +0300 Subject: nginx redis session In-Reply-To: References: Message-ID: увы, сесси у себя нужны, т.к. если пользователь зарегистрирован, то идет сравнение кук с сессией. 15 декабря 2011 г. 23:31 пользователь Alexandr Gomoliako написал: > On Thu, Dec 15, 2011 at 10:16 PM, Alexandr Gomoliako wrote: >> Лучше не хранить сессии у себя вообще. Самый примитивный способ >> отдавать сессию и подпись на сохранение клиенту и проверять >> при получении >>    if ( hmac_sha1(session, global_secret_key) == session_signature ) { > > Ошибка, вместо сессии конечно же имелся в виду пользователь. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zzz на zzz.org.ua Thu Dec 15 20:48:21 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Thu, 15 Dec 2011 22:48:21 +0200 Subject: nginx redis session In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 10:38 PM, Роман wrote: > увы, сесси у себя нужны, т.к. если пользователь зарегистрирован, то > идет сравнение кук с сессией. Я плохо объяснил. Попробую подробнее: Когда приходит пользователь и логинится, мы вместо генерации случайной сессии отдаем ему в куки его же login/user_id, подписываем это с помощью секретного ключа и добавляем подпись. Т.е. отдаем ему: [ login, hmac_sha1(login, global_secret_key) ] На все следующие запросы мы проверяем его логин по подписи: if ( hmac_sha1(login, global_secret_key) == session_signature ) { Или отправляем логиниться. Дальше туда же можно добавлять время, когда сессия истекает, проверять его тоже, и т.д. From chmind на yandex.ru Thu Dec 15 21:10:37 2011 From: chmind на yandex.ru (Vadim) Date: Fri, 16 Dec 2011 01:10:37 +0400 Subject: nginx redis session In-Reply-To: References: Message-ID: <4EEA624D.9050605@yandex.ru> 16.12.2011 0:08, Роман пишет: > Мемкеш использовать не хочется, т.к. развивается медленно и нужна репликация. Сам не пробовал, но есть вот такая штука: http://repcached.sourceforge.net/ From n.g.i.n.x.e.r на gmail.com Thu Dec 15 21:11:36 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Fri, 16 Dec 2011 00:11:36 +0300 Subject: nginx redis session In-Reply-To: References: Message-ID: Алгоритм вроде понятен, но как это в nginx реализовать не совсем понял. Я так понимаю у вас такое уже в работе, можно пример location ? 15 декабря 2011 г. 23:48 пользователь Alexandr Gomoliako написал: > On Thu, Dec 15, 2011 at 10:38 PM, Роман wrote: >> увы, сесси у себя нужны, т.к. если пользователь зарегистрирован, то >> идет сравнение кук с сессией. > > Я плохо объяснил. Попробую подробнее: > > Когда приходит пользователь и логинится, мы вместо генерации > случайной сессии отдаем ему в куки его же login/user_id, подписываем > это с помощью секретного ключа и добавляем подпись. > > Т.е. отдаем ему: > >    [ login, hmac_sha1(login, global_secret_key) ] > > На все следующие запросы мы проверяем его логин по подписи: > >    if ( hmac_sha1(login, global_secret_key) == session_signature ) { > > Или отправляем логиниться. > > Дальше туда же можно добавлять время, когда сессия истекает, > проверять его тоже, и т.д. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zzz на zzz.org.ua Thu Dec 15 21:23:26 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Thu, 15 Dec 2011 23:23:26 +0200 Subject: nginx redis session In-Reply-To: References: Message-ID: On Thu, Dec 15, 2011 at 11:11 PM, Роман wrote: > Алгоритм вроде понятен, но как это в nginx реализовать не совсем понял. > Я так понимаю у вас такое уже в работе, можно пример location ? Это не привязано к nginx, это больше для бэкендов, т.е. чтобы каждый бэкенд знал, кто к нему пришел без общих сессий в редисе. Чтобы сделать это в nginx нужна возможность обработчика access фазы скриптом. Это только в сторонних модулях. From postmaster на softsearch.ru Thu Dec 15 23:05:54 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 16 Dec 2011 03:05:54 +0400 Subject: sdch In-Reply-To: References: <145916647.20111215203229@softsearch.ru> Message-ID: <587016995.20111216030554@softsearch.ru> Здравствуйте, Sergey. >> Браузер во с таким юзер-агентов: >> Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like >> Gecko) Chrome/15.0.874.121 Safari/535.2 >> предлагает сжать страничку вот такими методами: >> Accept-Encoding: gzip,deflate,sdch >> >> Последний метод новый: http://en.wikipedia.org/wiki/SDCH >> > Chromium с каких-то первых версий поддерживает sdch, то есть уже > далеко не первый год. А к чему вы клоните? :) Хотел обсудить востребованность этого способа сжатия. Сравнения их я не смог найти. Вот если б разница при сжатии текста была как между gzip и xz - в 2 раза при таком же потреблении памяти и процессора, то можно было бы задуматься... -- С уважением, Михаил mailto:postmaster на softsearch.ru From trent.clainor на gmail.com Fri Dec 16 06:16:33 2011 From: trent.clainor на gmail.com (Albert Mikhaylov) Date: Fri, 16 Dec 2011 10:16:33 +0400 Subject: sdch In-Reply-To: <587016995.20111216030554@softsearch.ru> References: <145916647.20111215203229@softsearch.ru> <587016995.20111216030554@softsearch.ru> Message-ID: > > Здравствуйте, Sergey. > > >> Браузер во с таким юзер-агентов: > >> Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like > >> Gecko) Chrome/15.0.874.121 Safari/535.2 > >> предлагает сжать страничку вот такими методами: > >> Accept-Encoding: gzip,deflate,sdch > >> > >> Последний метод новый: http://en.wikipedia.org/wiki/SDCH > >> > > > Chromium с каких-то первых версий поддерживает sdch, то есть уже > > далеко не первый год. А к чему вы клоните? :) > > Хотел обсудить востребованность этого способа сжатия. Сравнения их я > не смог найти. Вот если б разница при сжатии текста была как между > gzip и xz - в 2 раза при таком же потреблении памяти и процессора, то > можно было бы задуматься... нашел такое вот описание, думаю сравнения здесь неуместны ) sdch (Shared Dictionary Compression Over HTTP) ? относительно новый, предложенный компанией Google в сентябре 2008 года метод уменьшения избыточной информации в вебе. Основная идея ? не передавать дважды одинаковые куски документа (на- пример, шапку, ?подвал? страницы, общие CSS- и JavaScript-фай- лы). Метод построен на алгоритме VCDIFF (RFC3284), ответ допол- нительно может быть сжат любым другим поддерживаемым брау- зером методом сжатия (например, gzip)."" ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From hell-for-yahoo на umail.ru Fri Dec 16 07:42:28 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Fri, 16 Dec 2011 11:42:28 +0400 Subject: php-fpm upstream pool In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> <4EE9B1F6.5010907@bestmx.ru> Message-ID: <896702414.20111216114228@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Alexandr Gomoliako! >>> Да, и это нужно. Но посылать живого человека >>> на нерабочий бэкенд, чтобы проверить - глупость. >> >> Нет, это не глупость, это нормально. AG> Что же здесь нормального? AG> Это проблема, которую с большой вероятностью заметят самые активные AG> постоянные посетители. Если вы можете их игнорировать, то может вообще AG> не стоит о фейловере заботиться, потерпят? Если у вас бэкэнд отваливается каждые две минуты, проблема явно не в nginx. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) пятница, 16.12.2011, <11:41> From postmaster на softsearch.ru Fri Dec 16 08:34:10 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 16 Dec 2011 12:34:10 +0400 Subject: nginx redis session In-Reply-To: References: Message-ID: <106709897.20111216123410@softsearch.ru> Здравствуйте, Роман. > Мемкеш использовать не хочется, т.к. развивается медленно и нужна > репликация. Он уже давно развился. И было бы кстати очень здорово, если б его больше не развивали, а только ошибки исправляли. А то испортят только нормальную софтину. И у мемкешеда есть репликация: http://repcached.lab.klab.org/ -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Fri Dec 16 09:53:14 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Dec 2011 13:53:14 +0400 Subject: sdch In-Reply-To: <587016995.20111216030554@softsearch.ru> References: <145916647.20111215203229@softsearch.ru> <587016995.20111216030554@softsearch.ru> Message-ID: <20111216095313.GX67687@mdounin.ru> Hello! On Fri, Dec 16, 2011 at 03:05:54AM +0400, Михаил Монашёв wrote: > Здравствуйте, Sergey. > > >> Браузер во с таким юзер-агентов: > >> Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like > >> Gecko) Chrome/15.0.874.121 Safari/535.2 > >> предлагает сжать страничку вот такими методами: > >> Accept-Encoding: gzip,deflate,sdch > >> > >> Последний метод новый: http://en.wikipedia.org/wiki/SDCH > >> > > > Chromium с каких-то первых версий поддерживает sdch, то есть уже > > далеко не первый год. А к чему вы клоните? :) > > Хотел обсудить востребованность этого способа сжатия. Сравнения их я > не смог найти. Вот если б разница при сжатии текста была как между > gzip и xz - в 2 раза при таком же потреблении памяти и процессора, то > можно было бы задуматься... sdch - это не полноценый алгоритм сжатия, и расчитан скорее на применение совместно с gzip'ом. Вот тут почитай: http://groups.google.com/group/SDCH/msg/3010131ab1045b27 Maxim Dounin From postmaster на softsearch.ru Fri Dec 16 16:08:32 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 16 Dec 2011 20:08:32 +0400 Subject: =?UTF-8?B?UmVbMl06INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <20111215123854.GH67687@mdounin.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <201112142158.55236.ne@vbart.ru> <20111214182928.GD67687@mdounin.ru> <323471646.20111214225446@softsearch.ru> <20111215123854.GH67687@mdounin.ru> Message-ID: <1596898025.20111216200832@softsearch.ru> Здравствуйте, Maxim. >> Простите, что встреваю в Ваш разговор. Хочу заметить, что весьма >> возможно очень многим людям подойдут не идеальные варианты, когда >> при ограничении в 1000 запросов в минуту проскочит не ровно 1000, а >> 1001 или даже 1002. Или наоборот, заблокирует 998 или 998-ый >> запрос. Т.е. весьма вероятно, что исключительная точностью в >> подобном вопросе востребована очень немногими, и потому возможно >> сэкономить на блокировках и написать код, работающий не с >> абсолютной точностью, но зато хорошо заточенный под недалёкое >> будущее, когда количество ядер будет исчисляться сотнями. Саму же >> небрежность в работе описать в документации, снабдив причинами, >> почему выбрана именно такая реализация. > Совсем без блокировок - не обойтись, т.к. там обход дерева в > разделяемой памяти, и потом ещё и обновление нескольких значений. > Без блокировок будет не просто неточно, а в лучшем случае - просто > мусор, в худшем - segmentation fault. Это говорит о том, что используемый алгоритм плохо подходит. Как вариант его латания могу предложить сделать вместо одного дерева - тысячу деревьев. С однозначным отображением значения зоны в одно из деревьев. И блокировки соответственно ставить на каждое отдельное дерево, а не на весь лес. Тогда вероятность ожидания блокировки приблизится к нулю и их можно будет держать дольше, чем обычно. Число деревье фиксировано. Счётчик для каждого дерева находится в заранее известной ячейке памяти и потому менять его можно без блокировок. > Maxim Dounin > p.s. Ты вот лучше кейсов накидай - как ты будешь использовать > несколько одновременных limit_req, когда они будут? Накидал бы уже давно, если б использовал limit_req. От ботов отбиваюсь почти-realtime анализом логов. Ну может использовал бы для борьбы со спам-ботами, когда они через прокси или из левых страны лезут. Ещё, было б интересно блокировать тех, кто ходит по одним локейшнам, а по другим почему-то не ходит, хотя должен был бы. Или ходит по тем, по которым обычный юзер не может пойти. Или приходит по HTTP/1.0 и постоянно норовит зайти на страницу регистрации то с одного домена, то с другого. В итоге всё это выливается в то, что находятся и блокируются через ipfw подсети хостинг-провайдеров, где эти боты живут. Ограничивать количество запросов по нескольким признакам имеет смысл для доморощенных спамеров, которые с домашнего компа краулят или спамят сайт. Ибо их блокировать по ip нельзя, а вот замедлить их или ограничить количеством запросов хорошо бы. В том nginx, который из коробки, не хватает твоих патчей для поддержки директив memcached_gzip_flag 2; gunzip on; set $memcached_namespace beon; и в аптриме балансировщика memcached_hash; чтобы nginx с мемкешедом работал точно также как Perl. Ну и в перспективе comet из коробки хотелось бы. А если совсем помечтать, то DNS-сервер, аналог мемкешеда и простую БД аля-mysql. Ещё сейчас в голову пришла мысль сделать модуль для борьбы с мусорным трафиком. Очень приближённо схема такая. Задаётся так же переменная, как в limit_req_zone , которая состоит, например, из uri+ip+user_agent+coockies или из всех http-заголовков+ip. Задаётся зона, где будет храниться нейросеть. И две директивы: learn и protect. Первая занимается обучением нейросети правильными запросами, вторая дропает все запросы, похожие на мусор. Ну и хорошо бы периодически сохранять обученную нейросеть на диск, чтобы при рестарте nginx не учить её на трафике, который мог уже стать мусорным. Учить можно на тех запросах, на которых успевает учиться, а не на всех. Модуль этот можно и за деньги продавать, кстати. И саппорт к нему тоже за деньги, если человеку сложно самому всё настроить. Это выгоднее, чем постоянно платить сервисам защиты от DDOS. ИМХО, такой модуль вполне может убить DDOS, как средство влияния на сайты. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Fri Dec 16 16:20:08 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 16 Dec 2011 20:20:08 +0400 Subject: =?UTF-8?B?UmVbM106INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <1596898025.20111216200832@softsearch.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <201112142158.55236.ne@vbart.ru> <20111214182928.GD67687@mdounin.ru> <323471646.20111214225446@softsearch.ru> <20111215123854.GH67687@mdounin.ru> <1596898025.20111216200832@softsearch.ru> Message-ID: <985661177.20111216202008@softsearch.ru> Здравствуйте. Вдогонку... Если анти-ddos модуль до марта успеете сделать, то спрос на него будет большой. :-) А нас ведь войны нынче за умы людей и потому ведутся они всё больше в инете. При обострении ситуации в бой пойдёт тяжёлая артиллерия. Тут то модуль и пригодится... -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Fri Dec 16 17:04:31 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Dec 2011 21:04:31 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <1596898025.20111216200832@softsearch.ru> References: <201112141805.02107.ne@vbart.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <201112142158.55236.ne@vbart.ru> <20111214182928.GD67687@mdounin.ru> <323471646.20111214225446@softsearch.ru> <20111215123854.GH67687@mdounin.ru> <1596898025.20111216200832@softsearch.ru> Message-ID: <20111216170431.GH67687@mdounin.ru> Hello! On Fri, Dec 16, 2011 at 08:08:32PM +0400, Михаил Монашёв wrote: [...] > > Совсем без блокировок - не обойтись, т.к. там обход дерева в > > разделяемой памяти, и потом ещё и обновление нескольких значений. > > Без блокировок будет не просто неточно, а в лучшем случае - просто > > мусор, в худшем - segmentation fault. > > Это говорит о том, что используемый алгоритм плохо подходит. Как Нет, это лишь говорит о том, что без блокировок в этом месте не обойтись. > вариант его латания могу предложить сделать вместо одного дерева - > тысячу деревьев. С однозначным отображением значения зоны в одно из > деревьев. И блокировки соответственно ставить на каждое отдельное > дерево, а не на весь лес. Тогда вероятность ожидания блокировки > приблизится к нулю и их можно будет держать дольше, чем обычно. > > Число деревье фиксировано. Счётчик для каждого дерева находится в > заранее известной ячейке памяти и потому менять его можно без > блокировок. Для того, чтобы бороться с lock contention, нужно сначала чтобы там был оный lock contention. Тут под локом делается очень небольшое количество операций, и шансов на lock contention, особенно по сравнению с общей стоимостью запроса, практически никаких. > > p.s. Ты вот лучше кейсов накидай - как ты будешь использовать > > несколько одновременных limit_req, когда они будут? > > Накидал бы уже давно, если б использовал limit_req. От ботов отбиваюсь > почти-realtime анализом логов. Ну может использовал бы для борьбы со > спам-ботами, когда они через прокси или из левых страны лезут. Ещё, > было б интересно блокировать тех, кто ходит по одним локейшнам, а по [...] > Ещё сейчас в голову пришла мысль сделать модуль для борьбы с мусорным > трафиком. Очень приближённо схема такая. Задаётся так же переменная, [...] Ну вот limit_req - это один из простых модулей для борьбы с DoS'ом и всякими переборами паролей, расчитанный на то, чтобы работать "из коробки" с минимальными затратами на конфигурирование. Понятно, что "в идеале" нужна гораздо более сложная логика по детектированию и предотвращению мусорного трафика, но это a) за рамками задач этого модуля и б) в сложных случаях, боюсь, всё равно не поможет, т.к. до nginx'а просто не дойдёт трафик. Maxim Dounin From public-mail на alekciy.ru Fri Dec 16 17:22:13 2011 From: public-mail на alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Fri, 16 Dec 2011 21:22:13 +0400 Subject: =?UTF-8?B?UmU6INCe0L/RgNC10LTQtdC70LXQvdC40LUg0YDQsNC30LzQtdGA0LAga2V5c196?= =?UTF-8?B?b25l?= In-Reply-To: <4EE8FE2E.9090708@gmail.com> References: <4EE8FE2E.9090708@gmail.com> Message-ID: А не нужно лазить в error.log и смотреть. Нужно настроить мониторинг с чем, что бы при появлении сообщений в логе ошибок автоматически уходило уведомление админу. 14 декабря 2011 г. 23:51 пользователь Константин написал: > Здравствуйте! > > Подскажите, как правильно рассчитать правильный размер keys_zone? > > Был 64m, при размере кеша 675M и кол-ве элементов 494к память > закончилась :) Увеличил до 96m, посмотрим на сколько хватит. Просто не > хочется постоянно лазить в error.log и смотреть, все ли там нормально) > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From roman.vasilyev на yousendit.com Fri Dec 16 18:38:38 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 16 Dec 2011 10:38:38 -0800 Subject: =?UTF-8?Q?upload_module_=D0=B8_=40fallback?= Message-ID: <4EEB902E.7000804@yousendit.com> Пытаюсь отработать случай когда UWSGI процесс сдох, что бы не терять данные которые на этот момент уже были успешно залиты, подразумевается $request_body записать в fallback.log и потом их оттуда вынуть скриптом. есть следующая конфигурация: location /upload { upload_resumable on; upload_pass /uwsgi/upload.py; ......... } location ~ /uwsgi/(?P(.*))\.py$ { error_page 502 504 = @fallback; root html/uwsgi; uwsgi_pass 127.0.0.1:9001; include uwsgi_params; ......... } location @fallback { default_type text/plain; return 200 '$request_body'; } прибиваю процесс uwsgi, если шлю POST на /uwsgi/upload.py то вижу ожидаемы результат =========================================== ------WebKitFormBoundarySrDJ2gn2ydy6aS68 Content-Disposition: form-data; name="file"; filename="test.py" Content-Type: text/x-python test data ------WebKitFormBoundarySrDJ2gn2ydy6aS68-- =========================================== если же то же самое шлю на /upload то получаю некий обрубок исходных данных насколько я понимаю, вместо ожидаемого потока который поидее был отправлен на вход uwsgi процессу =========================================== ------WebKitFormBoundaryX7PyvqpoxiZwQxfr Content-Disposition: form-data; name=" =========================================== Вопрос, где моя ошибка если таковая имеется, если нет то как выходить из ситуации? From valery+nginx на grid.net.ru Fri Dec 16 19:25:38 2011 From: valery+nginx на grid.net.ru (Valery Kholodkov) Date: Fri, 16 Dec 2011 20:25:38 +0100 Subject: =?UTF-8?Q?Re=3A_upload_module_=D0=B8_=40fallback?= In-Reply-To: <4EEB902E.7000804@yousendit.com> References: <4EEB902E.7000804@yousendit.com> Message-ID: <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> Давным давно в 2006 году проходил патч, который это решал. Теперь я даже не помню, был ли это UWCGI или wsCGI, но суть в том, что он сливал последовательность буферов в один. -- Best regards, Valery Kholodkov On 16 Dec 2011, at 19:38, Roman Vasilyev wrote: > Пытаюсь отработать случай когда UWSGI процесс сдох, что бы не терять данные которые на этот момент уже были успешно залиты, подразумевается $request_body записать в fallback.log и потом их оттуда вынуть скриптом. > есть следующая конфигурация: > location /upload { > upload_resumable on; > upload_pass /uwsgi/upload.py; > ......... > } > > location ~ /uwsgi/(?P(.*))\.py$ { > error_page 502 504 = @fallback; > root html/uwsgi; > > uwsgi_pass 127.0.0.1:9001; > include uwsgi_params; > ......... > } > location @fallback { > default_type text/plain; > return 200 '$request_body'; > } > > прибиваю процесс uwsgi, если шлю POST на /uwsgi/upload.py то вижу ожидаемы результат > =========================================== > ------WebKitFormBoundarySrDJ2gn2ydy6aS68 > Content-Disposition: form-data; name="file"; filename="test.py" > Content-Type: text/x-python > > test data > > ------WebKitFormBoundarySrDJ2gn2ydy6aS68-- > =========================================== > > если же то же самое шлю на /upload то получаю некий обрубок исходных данных насколько я понимаю, вместо ожидаемого потока который поидее был отправлен на вход uwsgi процессу > =========================================== > ------WebKitFormBoundaryX7PyvqpoxiZwQxfr > Content-Disposition: form-data; name=" > =========================================== > > Вопрос, где моя ошибка если таковая имеется, если нет то как выходить из ситуации? From roman.vasilyev на yousendit.com Fri Dec 16 19:29:22 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 16 Dec 2011 11:29:22 -0800 Subject: =?UTF-8?Q?Re=3A_upload_module_=D0=B8_=40fallback?= In-Reply-To: <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> References: <4EEB902E.7000804@yousendit.com> <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> Message-ID: <4EEB9C12.9090401@yousendit.com> Хочу уточнить, что мне нужен результат который формирует ваш модуль, а не исходный поток. То есть на выходе, что бы была возможность просто знать откуда брать файл который уже сохранен модулем, если просто есть такая переменная это было бы прекрасно, тогда ненужен весь этот исходный body. On 12/16/2011 11:25 AM, Valery Kholodkov wrote: > Давным давно в 2006 году проходил патч, который это решал. Теперь я даже не помню, был ли это UWCGI или wsCGI, но суть в том, что он сливал последовательность буферов в один. > > From valery+nginxru на grid.net.ru Fri Dec 16 19:36:26 2011 From: valery+nginxru на grid.net.ru (Valery Kholodkov) Date: Fri, 16 Dec 2011 20:36:26 +0100 Subject: =?UTF-8?Q?Re=3A_upload_module_=D0=B8_=40fallback?= In-Reply-To: <4EEB9C12.9090401@yousendit.com> References: <4EEB902E.7000804@yousendit.com> <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> <4EEB9C12.9090401@yousendit.com> Message-ID: Если в uwCGI слить последовательность буферов в один, то Вы получите результат, который Вы хотите. -- Best regards, Valery Kholodkov On 16 Dec 2011, at 20:29, Roman Vasilyev wrote: > Хочу уточнить, что мне нужен результат который формирует ваш модуль, а не исходный поток. > То есть на выходе, что бы была возможность просто знать откуда брать файл который уже сохранен модулем, если просто есть такая переменная это было бы прекрасно, тогда ненужен весь этот исходный body. > > On 12/16/2011 11:25 AM, Valery Kholodkov wrote: >> Давным давно в 2006 году проходил патч, который это решал. Теперь я даже не помню, был ли это UWCGI или wsCGI, но суть в том, что он сливал последовательность буферов в один. >> >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From roman.vasilyev на yousendit.com Fri Dec 16 19:38:11 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 16 Dec 2011 11:38:11 -0800 Subject: =?UTF-8?Q?Re=3A_upload_module_=D0=B8_=40fallback?= In-Reply-To: References: <4EEB902E.7000804@yousendit.com> <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> <4EEB9C12.9090401@yousendit.com> Message-ID: <4EEB9E23.7060108@yousendit.com> uwsgi имеется в виду модуль NGINX а не сторонний процесс? On 12/16/2011 11:36 AM, Valery Kholodkov wrote: > Если в uwCGI слить последовательность буферов в один, то Вы получите результат, который Вы хотите. > > Насколько я понимаю мне нужно иметь возможность написать нечто вроде: location @fallback { log_format main '$upload_file_name|$upload_file_size'; if ( $app = 'upload' ) { access_log /var/log/nginx/lost.log main; } default_type text/plain; return 200 '$upload_file_name $upload_file_size'; } такое возможно? From hell-for-yahoo на umail.ru Fri Dec 16 19:41:15 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Fri, 16 Dec 2011 23:41:15 +0400 Subject: sdch In-Reply-To: <587016995.20111216030554@softsearch.ru> References: <145916647.20111215203229@softsearch.ru> <587016995.20111216030554@softsearch.ru> Message-ID: <73795128.20111216234115@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Михаил Монашёв! ММ> Хотел обсудить востребованность этого способа сжатия. Это не способ сжатия, это способ уменьшения количества передаваемой информации. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) пятница, 16.12.2011, <23:40> From roman.vasilyev на yousendit.com Fri Dec 16 20:05:13 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 16 Dec 2011 12:05:13 -0800 Subject: =?UTF-8?Q?Re=3A_upload_module_=D0=B8_=40fallback?= In-Reply-To: References: <4EEB902E.7000804@yousendit.com> <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> <4EEB9C12.9090401@yousendit.com> <4EEB9E23.7060108@yousendit.com> Message-ID: <4EEBA479.3070607@yousendit.com> On 12/16/2011 11:45 AM, Valery Kholodkov wrote: > Да, имеется в виду модуль nginx. Данная конфигурация не будет работать, так как большинство переменных модуля доступны только в процессе загрузки, а не во время записи в лог. > > А можно с вами скоординироваться и дописать возможность снимать это как простые переменные из модуля: a) в момент uwsgi_param; b) в момент записи в лог; ? ЗЫ: ОООООЧЕНЬ надо From roman.vasilyev на yousendit.com Fri Dec 16 23:18:52 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 16 Dec 2011 15:18:52 -0800 Subject: =?UTF-8?Q?Re=3A_upload_module_=D0=B8_=40fallback?= In-Reply-To: <4EEBA479.3070607@yousendit.com> References: <4EEB902E.7000804@yousendit.com> <4559BB94-BFA9-4D1A-B1AF-E6A2E1BCDE48@grid.net.ru> <4EEB9C12.9090401@yousendit.com> <4EEB9E23.7060108@yousendit.com> <4EEBA479.3070607@yousendit.com> Message-ID: <4EEBD1DC.8090901@yousendit.com> пока я тщетно пытаюсь какнибудь вынуть эти переменные из модуля, я добился хотябы что бы NGINX не валился когда передаешь эти переменные в лог, на всякий случай вышлю патч, скажите что думаете на эту тему. On 12/16/2011 12:05 PM, Roman Vasilyev wrote: > On 12/16/2011 11:45 AM, Valery Kholodkov wrote: >> Да, имеется в виду модуль nginx. Данная конфигурация не будет >> работать, так как большинство переменных модуля доступны только в >> процессе загрузки, а не во время записи в лог. >> > А можно с вами скоординироваться и дописать возможность снимать это > как простые переменные из модуля: > a) в момент uwsgi_param; > b) в момент записи в лог; > ? > > ЗЫ: ОООООЧЕНЬ надо > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: up.patch Type: text/x-diff Size: 2484 bytes Desc: отсутствует URL: From roman.vasilyev на yousendit.com Sat Dec 17 01:42:27 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Fri, 16 Dec 2011 17:42:27 -0800 Subject: =?UTF-8?B?dXBsb2FkIGJ1ZmZlciDQv9GA0Lgg0L7QsdC+0YDQstCw0L3QvdC+0LwgUE9TVA==?= Message-ID: <4EEBF383.1060802@yousendit.com> есть ли возможность, полученный не полностью, POST пропихнуть на backend? From neo.nix.lipetsk на gmail.com Sat Dec 17 11:05:07 2011 From: neo.nix.lipetsk на gmail.com (Turkin Maksim) Date: Sat, 17 Dec 2011 15:05:07 +0400 Subject: =?UTF-8?B?NTAyINC/0L7QutCwINC/0LXRgNC10LfQsNCz0YDRg9C20LDQtdGC0YHRjyBiYWNr?= =?UTF-8?B?ZW5k?= Message-ID: <4EEC7763.7040008@gmail.com> Дано: Сервер с панелью управления, которая перезагружает apache через некоторые промежутки времени, nginx в качестве frontend. Надо: Не выдавать 502 ошибку во время перезагрузок apache. Решение: limit_req_zone $server_addr zone=reload:10m rate=6r/m; server { location / { proxy_pass http://backend; error_page 502 = @reload; } location @reload { limit_req zone=reload burst=60; proxy_pass http://backend; } } Вопрос: Есть ли более правильный вариант решения кроме запуска еще одного backend'а? Если нет, то можно ли сделать так или я что-то не учел? Заранее спасибо. From voron на amhost.net Sat Dec 17 14:43:26 2011 From: voron на amhost.net (Alex Vorona) Date: Sat, 17 Dec 2011 16:43:26 +0200 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EEC7763.7040008@gmail.com> References: <4EEC7763.7040008@gmail.com> Message-ID: <4EECAA8E.5070204@amhost.net> 17.12.2011 13:05, Turkin Maksim wrote: > Дано: Сервер с панелью управления, которая перезагружает apache через некоторые > промежутки времени, nginx в качестве frontend. [...] > Вопрос: Есть ли более правильный вариант решения кроме запуска еще одного > backend'а? Если нет, то можно ли сделать так или я что-то не учел? А что вы хотите выдавать когда бекенд недоступен? Или хотите "попридержать" запросы пока бекенд не оживёт? From s на bykov.odessa.ua Sat Dec 17 15:13:04 2011 From: s на bykov.odessa.ua (s на bykov.odessa.ua) Date: Sat, 17 Dec 2011 17:13:04 +0200 Subject: =?UTF-8?B?UlBNLdC60Lggbmdpbng/?= Message-ID: <4EECB180.3070904@bykov.odessa.ua> Скажите, а сборки пакетов отсюда http://nginx.org/en/download.html - это что-то официальное или полагаться не стоит? И если да, почему на русской версии нет их ? From hell-for-yahoo на umail.ru Sat Dec 17 15:06:15 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Sat, 17 Dec 2011 19:06:15 +0400 Subject: upload buffer при оборванном POST In-Reply-To: <4EEBF383.1060802@yousendit.com> References: <4EEBF383.1060802@yousendit.com> Message-ID: <1785654243.20111217190615@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) Roman Vasilyev! RV> есть ли возможность, полученный не полностью, POST пропихнуть на backend? Смысл, если результаты некуда отправлять? И какой шанс, что этот обрубленный POST не нарушит работу вашего приложения? Это если приложение вообще его примет, а не завернёт за обрубленностью. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) суббота, 17.12.2011, <19:04> From neo.nix.lipetsk на gmail.com Sat Dec 17 15:49:07 2011 From: neo.nix.lipetsk на gmail.com (Turkin Maksim) Date: Sat, 17 Dec 2011 19:49:07 +0400 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EECAA8E.5070204@amhost.net> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> Message-ID: <4EECB9F3.1040408@gmail.com> 17.12.2011 18:43, Alex Vorona пишет: > 17.12.2011 13:05, Turkin Maksim wrote: >> Дано: Сервер с панелью управления, которая перезагружает apache через некоторые >> промежутки времени, nginx в качестве frontend. > [...] >> Вопрос: Есть ли более правильный вариант решения кроме запуска еще одного >> backend'а? Если нет, то можно ли сделать так или я что-то не учел? > А что вы хотите выдавать когда бекенд недоступен? Или хотите "попридержать" запросы пока > бекенд не оживёт? Попридержать пока не оживет. Там нужно не больше 5-7 секунд. В принципе вышеприведенный конфиг в тестовой среде с задачей справился, но вдруг есть более идеологически верное решение. From pavel2000 на ngs.ru Sat Dec 17 17:32:28 2011 From: pavel2000 на ngs.ru (Pavel V.) Date: Sun, 18 Dec 2011 00:32:28 +0700 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EECB9F3.1040408@gmail.com> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> Message-ID: <96578933.20111218003228@ngs.ru> Здравствуйте. Вы писали 17 декабря 2011 г., 22:49:07: > Попридержать пока не оживет. Там нужно не больше 5-7 секунд. В принципе > вышеприведенный конфиг в тестовой среде с задачей справился, но вдруг есть более > идеологически верное решение. Идеологически верное решение - не перезагружать backend. Предполагаю, что всего-лишь нужно использовать reload вместо restart. Разве этого нельзя сделать? -- С уважением, Pavel mailto:pavel2000 на ngs.ru From postmaster на softsearch.ru Sat Dec 17 18:24:14 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 17 Dec 2011 22:24:14 +0400 Subject: nginx-1.0.11 In-Reply-To: <20111215150222.GP67687@mdounin.ru> References: <20111215150222.GP67687@mdounin.ru> Message-ID: <1074837575.20111217222414@softsearch.ru> Здравствуйте, Maxim. После обновления с nginx-1.0.9 на nginx-1.0.11 у меня перестали течь сокеты. Они текли начиная с 0.8.х или 0.6.х версии. Судя по тому, что в ченж-логе ничего такого нет, то видимо исправление наведённое. Может дифф между nginx-1.0.9 и nginx-1.0.11 покажет, где скрывается ошибка. 2Максим и Игорь: если нужно, сервер для опытов с радостью предоставлю. -- С уважением, Михаил mailto:postmaster на softsearch.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: graph_image.png Type: application/octet-stream Size: 95645 bytes Desc: not available URL: From nginx-forum на nginx.us Sat Dec 17 23:01:36 2011 From: nginx-forum на nginx.us (adept) Date: Sat, 17 Dec 2011 18:01:36 -0500 Subject: location php-fpm Message-ID: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Дано: шлюз с nginx'om на борту --> тазик с сайтом На шлюзе, так-же установлен php-fpm для 1 пхп файла. Конфиг: server { listen IP:80; server_name site.ru www.site.ru; location /stat/ { fastcgi_pass 127.0.0.1:9000; fastcgi_index st.php; fastcgi_param script_FILENAME /var/www/other/stat/st.php include fastcgi_params; #root /var/www/other/stat/; } location / { proxy_pass http://ip_server2:80; proxy_redirect http://ip_server2:80/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } Собственно, site.ru/stat/st.php в итоге перенаправляет на тазик с сайтом. Где я накосячил? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220215#msg-220215 From neo.nix.lipetsk на gmail.com Sun Dec 18 00:46:23 2011 From: neo.nix.lipetsk на gmail.com (Turkin Maksim) Date: Sun, 18 Dec 2011 04:46:23 +0400 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <96578933.20111218003228@ngs.ru> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> Message-ID: <4EED37DF.7060004@gmail.com> 17.12.2011 21:32, Pavel V. пишет: > Здравствуйте. > > Вы писали 17 декабря 2011 г., 22:49:07: > >> Попридержать пока не оживет. Там нужно не больше 5-7 секунд. В принципе >> вышеприведенный конфиг в тестовой среде с задачей справился, но вдруг есть более >> идеологически верное решение. > > Идеологически верное решение - не перезагружать backend. > Предполагаю, что всего-лишь нужно использовать reload вместо restart. > > Разве этого нельзя сделать? Панель закрытая и возможность заменить restart на reload в ней не предусмотрена. From nefer05 на gmail.com Sun Dec 18 06:39:12 2011 From: nefer05 на gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Sun, 18 Dec 2011 10:39:12 +0400 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EED37DF.7060004@gmail.com> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> <4EED37DF.7060004@gmail.com> Message-ID: 2011/12/18 Turkin Maksim : > 17.12.2011 21:32, Pavel V. пишет: >> Здравствуйте. >> >> Вы писали 17 декабря 2011 г., 22:49:07: >> >>> Попридержать пока не оживет. Там нужно не больше 5-7 секунд. В принципе >>> вышеприведенный конфиг в тестовой среде с задачей справился, но вдруг есть более >>> идеологически верное решение. >> >> Идеологически верное решение - не перезагружать backend. >> Предполагаю, что всего-лишь нужно использовать reload вместо restart. >> >> Разве этого нельзя сделать? > > Панель закрытая и возможность заменить restart на reload в ней не предусмотрена. Зато можно заменить скрипт. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From neo.nix.lipetsk на gmail.com Sun Dec 18 07:22:28 2011 From: neo.nix.lipetsk на gmail.com (Turkin Maksim) Date: Sun, 18 Dec 2011 11:22:28 +0400 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> <4EED37DF.7060004@gmail.com> Message-ID: <4EED94B4.60901@gmail.com> 18.12.2011 10:39, Роман Москвитин пишет: > 2011/12/18 Turkin Maksim : >> 17.12.2011 21:32, Pavel V. пишет: >>> Идеологически верное решение - не перезагружать backend. >>> Предполагаю, что всего-лишь нужно использовать reload вместо restart. >>> >>> Разве этого нельзя сделать? >> >> Панель закрытая и возможность заменить restart на reload в ней не предусмотрена. > > Зато можно заменить скрипт. Этот вариант даже рассматривать не будем, пусть уж лучше работает как может. Своими руками создавать себе такую головную боль мне совсем не хочется. From maxim на nginx.com Sun Dec 18 08:35:15 2011 From: maxim на nginx.com (Maxim Konovalov) Date: Sun, 18 Dec 2011 12:35:15 +0400 Subject: =?UTF-8?B?UmU6IFJQTS3QutC4IG5naW54Pw==?= In-Reply-To: <4EECB180.3070904@bykov.odessa.ua> References: <4EECB180.3070904@bykov.odessa.ua> Message-ID: <4EEDA5C3.2080703@nginx.com> On 12/17/11 7:13 PM, s на bykov.odessa.ua wrote: > Скажите, а сборки пакетов отсюда http://nginx.org/en/download.html - > это что-то официальное или полагаться не стоит? > Да, эти пакеты мы собираем самостоятельно. На них можно жаловаться в trac.nginx.org (предпочтительно) или в мейллист. > И если да, почему на русской версии нет их ? > Если вы про отличия этой страницы с http://nginx.org/ru/download.html, то не дошли руки синхронизировать с англоязычным вариантом. Поправим. -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/ From s на bykov.odessa.ua Sun Dec 18 08:50:28 2011 From: s на bykov.odessa.ua (s на bykov.odessa.ua) Date: Sun, 18 Dec 2011 10:50:28 +0200 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EED94B4.60901@gmail.com> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> <4EED37DF.7060004@gmail.com> <4EED94B4.60901@gmail.com> Message-ID: <4EEDA954.1010906@bykov.odessa.ua> Это случайно не DirectAdmin или CPanel? > 18.12.2011 10:39, Роман Москвитин пишет: >> 2011/12/18 Turkin Maksim: >>> 17.12.2011 21:32, Pavel V. пишет: >>>> Идеологически верное решение - не перезагружать backend. >>>> Предполагаю, что всего-лишь нужно использовать reload вместо restart. >>>> >>>> Разве этого нельзя сделать? >>> Панель закрытая и возможность заменить restart на reload в ней не предусмотрена. >> Зато можно заменить скрипт. > Этот вариант даже рассматривать не будем, пусть уж лучше работает как может. > Своими руками создавать себе такую головную боль мне совсем не хочется. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From neo.nix.lipetsk на gmail.com Sun Dec 18 09:32:31 2011 From: neo.nix.lipetsk на gmail.com (Turkin Maksim) Date: Sun, 18 Dec 2011 13:32:31 +0400 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EEDA954.1010906@bykov.odessa.ua> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> <4EED37DF.7060004@gmail.com> <4EED94B4.60901@gmail.com> <4EEDA954.1010906@bykov.odessa.ua> Message-ID: <4EEDB32F.20906@gmail.com> 18.12.2011 12:50, s на bykov.odessa.ua пишет: > Это случайно не DirectAdmin или CPanel? В моем случае это Plesk, но я подозреваю, что почти все панели действуют примерно одинаково. From voron на amhost.net Sun Dec 18 10:05:34 2011 From: voron на amhost.net (Alex Vorona) Date: Sun, 18 Dec 2011 12:05:34 +0200 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EEDB32F.20906@gmail.com> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> <4EED37DF.7060004@gmail.com> <4EED94B4.60901@gmail.com> <4EEDA954.1010906@bykov.odessa.ua> <4EEDB32F.20906@gmail.com> Message-ID: <4EEDBAEE.4040305@amhost.net> 18.12.2011 11:32, Turkin Maksim wrote: > 18.12.2011 12:50, s на bykov.odessa.ua пишет: >> Это случайно не DirectAdmin или CPanel? > В моем случае это Plesk, http://kb.parallels.com/112020 не подходит? > но я подозреваю, что почти все панели действуют > примерно одинаково. Да, почти все дают включить graceful restart в apache. From neo.nix.lipetsk на gmail.com Sun Dec 18 10:50:17 2011 From: neo.nix.lipetsk на gmail.com (Turkin Maksim) Date: Sun, 18 Dec 2011 14:50:17 +0400 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EEDBAEE.4040305@amhost.net> References: <4EEC7763.7040008@gmail.com> <4EECAA8E.5070204@amhost.net> <4EECB9F3.1040408@gmail.com> <96578933.20111218003228@ngs.ru> <4EED37DF.7060004@gmail.com> <4EED94B4.60901@gmail.com> <4EEDA954.1010906@bykov.odessa.ua> <4EEDB32F.20906@gmail.com> <4EEDBAEE.4040305@amhost.net> Message-ID: <4EEDC569.9060201@gmail.com> 18.12.2011 14:05, Alex Vorona пишет: > 18.12.2011 11:32, Turkin Maksim wrote: >> 18.12.2011 12:50, s на bykov.odessa.ua пишет: >>> Это случайно не DirectAdmin или CPanel? >> В моем случае это Plesk, > http://kb.parallels.com/112020 не подходит? Я идиот. Спасибо. From nginx-forum на nginx.us Sun Dec 18 12:58:37 2011 From: nginx-forum на nginx.us (ast) Date: Sun, 18 Dec 2011 07:58:37 -0500 Subject: =?UTF-8?B?UmU6IDUwMiDQv9C+0LrQsCDQv9C10YDQtdC30LDQs9GA0YPQttCw0LXRgtGB0Y8g?= =?UTF-8?B?YmFja2VuZA==?= In-Reply-To: <4EEC7763.7040008@gmail.com> References: <4EEC7763.7040008@gmail.com> Message-ID: <45136b0ce6fcae700fa625f8425e6ca6.NginxMailingListRussian@forum.nginx.org> Ок, а если это джава бекенды, который так быстро не делаю рестарт? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220192,220226#msg-220226 From mdounin на mdounin.ru Sun Dec 18 13:11:36 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 18 Dec 2011 17:11:36 +0400 Subject: nginx-1.0.11 In-Reply-To: <1074837575.20111217222414@softsearch.ru> References: <20111215150222.GP67687@mdounin.ru> <1074837575.20111217222414@softsearch.ru> Message-ID: <20111218131136.GP67687@mdounin.ru> Hello! On Sat, Dec 17, 2011 at 10:24:14PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > После обновления с nginx-1.0.9 на nginx-1.0.11 у меня перестали течь > сокеты. Они текли начиная с 0.8.х или 0.6.х версии. Судя по тому, что > в ченж-логе ничего такого нет, то видимо исправление наведённое. Может > дифф между nginx-1.0.9 и nginx-1.0.11 покажет, где скрывается ошибка. > > 2Максим и Игорь: если нужно, сервер для опытов с радостью предоставлю. Workload? Конфиг? Сторонние модули? Ну и совсем простое - проверить 1.0.10. Maxim Dounin From chipitsine на gmail.com Sun Dec 18 18:45:20 2011 From: chipitsine на gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 19 Dec 2011 00:45:20 +0600 Subject: php-fpm upstream pool In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: > On Wed, Dec 14, 2011 at 9:54 PM, igor.goncharenko wrote: >> Тут я абсолютно согласен с Максимом - >> бывают ситуации когда alive чек говорит >> что все хорошо, но бэкенд тем не менее >> перекосило, и на самом деле он должен >> считаться нерабочим. Грамотно >> реализованный алгоритм выявления >> таких бэкендов лучше чем alive чеки. > > Да, и это нужно. Но посылать живого человека > на нерабочий бэкенд, чтобы проверить - глупость. почему глупость ? если вы делаете health check с 30-секундным интервалом, какая гарантия, что бекенд не скуксится до следуюшего health check? опять же кто вам мешает сделать очень маленький сonnect_timeout, чтобы факт неинсправности бекенда вас не напрягал? приложение достаточно быстрое - делаете маленький read_timeout приложение тормозное - делаете длинный fail_timeout (чтобы бекенд надолго прописывался в черный список) а теперь расскажите, почему это глупость посылать живого человека на нерабочий бекенд. > >> Если бы "в nginxе" так считали, им бы никто >> не пользовался. > > Если бы - не аргумент. Если бы не считали, > уже бы давно вытеснили апач. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zzz на zzz.org.ua Sun Dec 18 19:30:23 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Sun, 18 Dec 2011 21:30:23 +0200 Subject: php-fpm upstream pool In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: On Sun, Dec 18, 2011 at 8:45 PM, Илья Шипицин wrote: >> Да, и это нужно. Но посылать живого человека >> на нерабочий бэкенд, чтобы проверить - глупость. > почему глупость ? Потому что пользователи - это те, для кого это все делается. Меня вообще удивляет, когда разработчики ставят что-то в приоритет перед пользователями, типа экономить процессор, где только возможно. From gmm на csdoc.com Sun Dec 18 20:00:51 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 18 Dec 2011 22:00:51 +0200 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <20111214162424.GW67687@mdounin.ru> References: <201112141805.02107.ne@vbart.ru> <20111214142226.GU67687@mdounin.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> Message-ID: <4EEE4673.4010502@csdoc.com> On 14.12.2011 18:24, Maxim Dounin wrote: > E.g. типичная ситуация для хостинга, когда лимиты хочется на > каждый $host (чтобы один атакуемый сайт не мог съесть все > ресурсы), и на ip (чтобы с одного ip-адреса, вздремнув на ^R, > нельзя было съесть все ресурсы): > > limit_req; > limit_req; > > Если атакуют $host, то всё хорошо. > > Если ^R, то проблема: легко "выедается" лимит на $host (хотя > запросы реально не обслуживаются), и тем самым нужный хост > фактически блокируется. > > В данном конкретном случае - проблема легко решается сменой > порядка применения лимитов: сначала per-ip, потом per-host. > > Вопрос: есть ли в реальной жизни задачи, где проблема так *не* > решается? > > (С теоретической точки зрения - понятно, что такие задачи есть. > Интересуют сколько-нибудь относящиеся к реальной жизни примеры.) выше предполагается, что все запросы имеют примерно одинаковый вес. в рельной жизни - запросы к backend`у бывают как очень легкими, которые отрабатывают за десятые/сотые доли секунды, так и очень тяжелыми, обработка которых на backend`е занимает несколько секунд или даже несколько десятков секунд. в haproxy есть очень изящное решение: maxconn maxqueue это почти идеальное решение для выравнивания нагрузки на backend, так чтобы никакой $host не занял 100% ресурсов backend`а, и в то же время, чтобы не было 503 ошибок при небольшом и временном всплеске нагрузки на какой-то $host. например: maxconn 1 maxqueue 128 или maxconn 1 maxqueue 1024 с помощью limit_req; такого плавного выравнивания нагрузки получить нельзя, потому что backend или будет перегружен "тяжелыми" запросами, при слишком высоких лимитах или backend будет простаивать, а клиентов будет отсекать ограничение limit_req; если на $host идет большое количество "легких" запросов а лимиты limit_req; стоят слишком низкие. более идеальное решение - равномерно распределять запросы к backend`у из разных очередей, если количество виртуальных хостов больше, чем количество worker-процессов у backend`а. т.е. очереди proxy_maxconn/proxy_maxqueue на один и тот же backend из разных server{ ... } обрабатываются в виде round-robin и first_in-first_out с учетом лимита maxconn. (для случая если всплеск нагрузки идет на все/многие $host`ы) совсем идеальное решение - возможность управлять приоритетами очередей, примерно как в http://lartc.org/lartc.html или что-то похожее на maxconn / maxqueue между nginx и backend`ом можно сделать средствами netfilter, если подключение к backend`у идет по tcp/ip ? пока что народ ставит nginx <-> haproxy <-> backend а если подключение к backend`у идет через proxy_pass http://unix:/path/to/backend.socket:/uri/; uwsgi_pass unix:/var/run/example.com.sock; и т.п. ? -- Best regards, Gena From nginx-forum на nginx.us Sun Dec 18 20:34:34 2011 From: nginx-forum на nginx.us (hg_04) Date: Sun, 18 Dec 2011 15:34:34 -0500 Subject: location php-fpm In-Reply-To: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: после stat убери / или допиши .+ Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220238#msg-220238 From ne на vbart.ru Sun Dec 18 23:05:09 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 19 Dec 2011 03:05:09 +0400 Subject: location php-fpm In-Reply-To: References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112190305.09343.ne@vbart.ru> On Sunday 18 December 2011 03:01:36 adept wrote: [...] > > Собственно, site.ru/stat/st.php в итоге > перенаправляет на тазик с сайтом. > Где я накосячил? > Изменили конфигурацию и забыли перезапустить nginx? On Monday 19 December 2011 00:34:34 hg_04 wrote: > после stat убери / или допиши .+ > Не стоит давать вредных советов. -- Валентин Бартенев From chipitsine на gmail.com Mon Dec 19 02:38:54 2011 From: chipitsine на gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 19 Dec 2011 08:38:54 +0600 Subject: php-fpm upstream pool In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: разработчики - вообще удивительные люди. а расскажите тогда, зачем вы пользуетесь программным продуктом, который вас не удовлетворяет? вы заплатили за него? есть куча вариантов куда спрыгнуть, тот же haproxy, ну или самому написать, зачем связываться с непонятным продуктом каких-то непонятных разработчков, которые беспокоятся о процессоре, а а не о пользователях 19 декабря 2011 г. 1:30 пользователь Alexandr Gomoliako написал: > On Sun, Dec 18, 2011 at 8:45 PM, Илья Шипицин wrote: >>> Да, и это нужно. Но посылать живого человека >>> на нерабочий бэкенд, чтобы проверить - глупость. > >> почему глупость ? > > Потому что пользователи - это те, для кого это все делается. > > Меня вообще удивляет, когда разработчики ставят что-то > в приоритет перед пользователями, типа экономить процессор, > где только возможно. > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на nginx.us Mon Dec 19 06:22:12 2011 From: nginx-forum на nginx.us (Craken) Date: Mon, 19 Dec 2011 01:22:12 -0500 Subject: location php-fpm In-Reply-To: References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: hg_04 Пишет: ------------------------------------------------------- > после stat убери / или допиши > .+ location /stat/ - это не регулярное выражение! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220242#msg-220242 From mdounin на mdounin.ru Mon Dec 19 08:27:20 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 19 Dec 2011 12:27:20 +0400 Subject: =?UTF-8?B?UmU6INCg0LXQsNC70LjQt9Cw0YbQuNGPIG11bHRpcGxlIGxpbWl0X3JlcQ==?= In-Reply-To: <4EEE4673.4010502@csdoc.com> References: <201112141805.02107.ne@vbart.ru> <20111214142226.GU67687@mdounin.ru> <201112141939.19616.ne@vbart.ru> <20111214162424.GW67687@mdounin.ru> <4EEE4673.4010502@csdoc.com> Message-ID: <20111219082719.GR67687@mdounin.ru> Hello! On Sun, Dec 18, 2011 at 10:00:51PM +0200, Gena Makhomed wrote: > On 14.12.2011 18:24, Maxim Dounin wrote: > > >E.g. типичная ситуация для хостинга, когда лимиты хочется на > >каждый $host (чтобы один атакуемый сайт не мог съесть все > >ресурсы), и на ip (чтобы с одного ip-адреса, вздремнув на ^R, > >нельзя было съесть все ресурсы): > > > > limit_req; > > limit_req; > > > >Если атакуют $host, то всё хорошо. > > > >Если ^R, то проблема: легко "выедается" лимит на $host (хотя > >запросы реально не обслуживаются), и тем самым нужный хост > >фактически блокируется. > > > >В данном конкретном случае - проблема легко решается сменой > >порядка применения лимитов: сначала per-ip, потом per-host. > > > >Вопрос: есть ли в реальной жизни задачи, где проблема так *не* > >решается? > > > >(С теоретической точки зрения - понятно, что такие задачи есть. > >Интересуют сколько-нибудь относящиеся к реальной жизни примеры.) > > выше предполагается, что все запросы имеют примерно одинаковый вес. > в рельной жизни - запросы к backend`у бывают как очень легкими, > которые отрабатывают за десятые/сотые доли секунды, так и очень > тяжелыми, обработка которых на backend`е занимает несколько секунд > или даже несколько десятков секунд. > > в haproxy есть очень изящное решение: > > maxconn > maxqueue > > это почти идеальное решение для выравнивания нагрузки на backend, > так чтобы никакой $host не занял 100% ресурсов backend`а, > и в то же время, чтобы не было 503 ошибок при небольшом > и временном всплеске нагрузки на какой-то $host. > например: > > maxconn 1 > maxqueue 128 > > или > > maxconn 1 > maxqueue 1024 > > с помощью > > limit_req; > > такого плавного выравнивания нагрузки получить нельзя, > потому что backend или будет перегружен "тяжелыми" запросами, С помощью limit_req "такого плавного выравнивания получить нельзя", потому что он для этого не предназначен. А по теме есть что сказать? Maxim Dounin From nginx-forum на nginx.us Mon Dec 19 10:31:20 2011 From: nginx-forum на nginx.us (adept) Date: Mon, 19 Dec 2011 05:31:20 -0500 Subject: location php-fpm In-Reply-To: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <2cc9040c58c6a08775fbdf1eaa9e7f9e.NginxMailingListRussian@forum.nginx.org> nginx ессно перезапускал. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220247#msg-220247 From ne на vbart.ru Mon Dec 19 10:53:01 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 19 Dec 2011 14:53:01 +0400 Subject: location php-fpm In-Reply-To: <2cc9040c58c6a08775fbdf1eaa9e7f9e.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> <2cc9040c58c6a08775fbdf1eaa9e7f9e.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112191453.02158.ne@vbart.ru> On Monday 19 December 2011 14:31:20 adept wrote: > nginx ессно перезапускал. > Ещё кэш вашего браузера может быть виноват, иначе включайте и смотрите debug-лог. -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 19 11:11:42 2011 From: nginx-forum на nginx.us (Craken) Date: Mon, 19 Dec 2011 06:11:42 -0500 Subject: location php-fpm In-Reply-To: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <60decfadf95ba24e828fff08956f02c1.NginxMailingListRussian@forum.nginx.org> Чисто ради эксперимента можете попробовать переписать локейшн на: location ^~ /stat/ { Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220250#msg-220250 From nginx-forum на nginx.us Mon Dec 19 11:38:11 2011 From: nginx-forum на nginx.us (adept) Date: Mon, 19 Dec 2011 06:38:11 -0500 Subject: location php-fpm In-Reply-To: <60decfadf95ba24e828fff08956f02c1.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> <60decfadf95ba24e828fff08956f02c1.NginxMailingListRussian@forum.nginx.org> Message-ID: <2680ab5632850fa7efb2847dde14064e.NginxMailingListRussian@forum.nginx.org> Craken Wrote: ------------------------------------------------------- > Чисто ради эксперимента > можете попробовать > переписать локейшн на: > location ^~ /stat/ { На сайт уже не отправляет. Но получаю белую страницу. В логах: MY-IP - - [19/Dec/2011:19:28:27 +0300] "GET /stat/st.php HTTP/1.1" 200 5 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" site.ru Судя по всему, проблема в php, не обрабатывает даже простейший скрипт. И еще, переименовал st.php - никакой реакции. Так-же белая страница и такие-же логи. Процессы php висят. [root на nginx]# ps aux | grep php root 10685 0.0 0.0 222520 3732 ? Ss 19:30 0:00 php-fpm: master process (/etc/php-fpm.conf) nginx 10686 0.0 0.0 222520 3372 ? S 19:30 0:00 php-fpm: pool www nginx 10687 0.0 0.0 222520 3372 ? S 19:30 0:00 php-fpm: pool www nginx 10688 0.0 0.0 222520 3372 ? S 19:30 0:00 php-fpm: pool www Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220258#msg-220258 From nginx-forum на nginx.us Mon Dec 19 11:39:22 2011 From: nginx-forum на nginx.us (adept) Date: Mon, 19 Dec 2011 06:39:22 -0500 Subject: location php-fpm In-Reply-To: <2680ab5632850fa7efb2847dde14064e.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> <60decfadf95ba24e828fff08956f02c1.NginxMailingListRussian@forum.nginx.org> <2680ab5632850fa7efb2847dde14064e.NginxMailingListRussian@forum.nginx.org> Message-ID: <16ddf6e633d46174b94d0b1ce7ee207c.NginxMailingListRussian@forum.nginx.org> В логах php-fpm тишина. [19-Dec-2011 19:30:03] NOTICE: fpm is running, pid 10685 [19-Dec-2011 19:30:03] NOTICE: ready to handle connections Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220259#msg-220259 From nginx-forum на nginx.us Mon Dec 19 12:11:41 2011 From: nginx-forum на nginx.us (Craken) Date: Mon, 19 Dec 2011 07:11:41 -0500 Subject: location php-fpm In-Reply-To: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: Попробуйте так: server { listen IP:80; server_name site.ru www.site.ru; location ^~ /stat/ { return 403; } location / { proxy_pass http://ip_server2:80; proxy_redirect http://ip_server2:80/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } Если будет отдавать 403-ю ошибку при каждом запросе на /stat - то значит запрос попадает в локейшн, и проблема в пхп! >>В логах php-fpm тишина. >>[19-Dec-2011 19:30:03] NOTICE: fpm is running, pid 10685 >>[19-Dec-2011 19:30:03] NOTICE: ready to handle connections пхп не будет писать в лог о поступившем запросе! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220260#msg-220260 From ne на vbart.ru Mon Dec 19 12:54:05 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 19 Dec 2011 16:54:05 +0400 Subject: location php-fpm In-Reply-To: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112191654.06158.ne@vbart.ru> On Sunday 18 December 2011 03:01:36 adept wrote: > Дано: > шлюз с nginx'om на борту --> тазик с сайтом > На шлюзе, так-же установлен php-fpm для 1 > пхп файла. > > Конфиг: > server { > listen IP:80; > server_name site.ru www.site.ru; > > location /stat/ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index st.php; > fastcgi_param script_FILENAME > /var/www/other/stat/st.php > include fastcgi_params; > #root /var/www/other/stat/; > } > location / { > proxy_pass http://ip_server2:80; > proxy_redirect http://ip_server2:80/ /; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For > $proxy_add_x_forwarded_for; > proxy_set_header X-Real-IP $remote_addr; > } > > Собственно, site.ru/stat/st.php в итоге > перенаправляет на тазик с сайтом. > Где я накосячил? > Я так подозреваю, что конфиг вы нам не полностью показали или другой. Вот это работать не может: fastcgi_param script_FILENAME /var/www/other/stat/st.php И ";" на конце отсутствует, и script_FILENAME неправильно написано (регистр имеет значение). -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 19 15:04:54 2011 From: nginx-forum на nginx.us (adept) Date: Mon, 19 Dec 2011 10:04:54 -0500 Subject: location php-fpm In-Reply-To: References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <63a8daf47b7bc4d4281ecaf5b657ac86.NginxMailingListRussian@forum.nginx.org> > > Если будет отдавать 403-ю > ошибку при каждом запросе > на /stat - то значит запрос > попадает в локейшн, и > проблема в пхп! > Да, отдает 403. Полный код: location ^~ /stat/ { fastcgi_pass 127.0.0.1:9000; fastcgi_index st.php; fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name; include fastcgi_params; } php скрипт в /var/www/html/stat/ Видимо нужно в пхп копать, хотя php -v | -m все ок. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220269#msg-220269 From gmm на csdoc.com Mon Dec 19 17:10:58 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 19 Dec 2011 19:10:58 +0200 Subject: php-fpm upstream pool In-Reply-To: References: <8a2c9e0139bf418efe0864e0b82fbfe8.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EEF7022.2020800@csdoc.com> On 18.12.2011 21:30, Alexandr Gomoliako wrote: > ...пользователи - это те, для кого это все делается. > Меня вообще удивляет, когда разработчики ставят что-то > в приоритет перед пользователями, типа экономить процессор, > где только возможно. чем больше процессора сэкономили - тем больше запросов пользователей и тем быстрее сможет обслужить веб-сервер на том же ограниченном железе. так что экономия процессора - это и есть забота о пользователях. ситуация с неработающим backend`ом действительно достаточно редкая, и уменьшить негативные последствия от этого можно настройкой nginx. -- Best regards, Gena From nginx-forum на nginx.us Mon Dec 19 19:09:21 2011 From: nginx-forum на nginx.us (hg_04) Date: Mon, 19 Dec 2011 14:09:21 -0500 Subject: location php-fpm In-Reply-To: References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: Craken Wrote: > > location /stat/ - это не > регулярное выражение! и тем не мение /stat/(.+) вернет данные в $1 Валентин Бартенев Wrote: > Не стоит давать вредных советов. я ж не говорю в боевом режиме запускать, если сработает значит где-то локейшины перекрываются, здесь явно не весь конфиг предоставлен был. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220273#msg-220273 From ne на vbart.ru Mon Dec 19 19:34:46 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 19 Dec 2011 23:34:46 +0400 Subject: location php-fpm In-Reply-To: References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112192334.46664.ne@vbart.ru> On Monday 19 December 2011 23:09:21 hg_04 wrote: > Craken Wrote: > > location /stat/ - это не > > регулярное выражение! > > и тем не мение /stat/(.+) вернет данные в $1 > Не вернет. Ибо, как уже верно было замечено, локэйшн задан не регулярным выражением. Даже если его таковым сделать, всё равно это будет вредный совет. > я ж не говорю в боевом режиме запускать, > если сработает значит где-то локейшины > перекрываются, здесь явно не весь > конфиг предоставлен был. > Если где-то перекрываются, значит надо давать полный конфиг, а не рассчитывать на экстрасенсов. Метод тыка не уместен в любом случае. -- Валентин Бартенев From nginx-forum на nginx.us Mon Dec 19 22:49:09 2011 From: nginx-forum на nginx.us (adept) Date: Mon, 19 Dec 2011 17:49:09 -0500 Subject: location php-fpm In-Reply-To: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> References: <7c165a60e93e6364287867c47f21edb4.NginxMailingListRussian@forum.nginx.org> Message-ID: локейшены не перекрываются. Но на всякий, вот полный конфиг: server { listen 12.12.12.12:80; server_name site.ru www.site.ru; location ^~ /stat/ { fastcgi_pass 127.0.0.1:9000; fastcgi_index st.php; fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name; include fastcgi_params; } location / { proxy_pass http://24.24.24.24:80; proxy_redirect http://24.24.24.24:80/ /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|ico)$ { proxy_pass http://24.24.24.24:80; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220215,220278#msg-220278 From nginx-forum на nginx.us Mon Dec 19 23:43:40 2011 From: nginx-forum на nginx.us (Fixid) Date: Mon, 19 Dec 2011 18:43:40 -0500 Subject: =?UTF-8?B?0JjQt9C80LXQvdC10L3QuNC1IFVSTA==?= Message-ID: <541defc3e4e4fa5d536c99c6f6316d27.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Есть на сервере два сайта которые работают на localhost на разных портах, есть nginx 1.1.11. Мне надо чтобы в подпапках отображались разные сайты. Для этого добавил в конфиг: location ^~ /chat/ { proxy_redirect off; proxy_pass http://localhost:150/; } location ^~ /qwe/ { proxy_redirect off; proxy_pass http://localhost:151/; } Но к сожалению изменяет url, т.е. syte.com/chat/ после выполнения становится syte.com/(длинный урл) - что естественно не работает, но если написать syte.com/chat/(длинный урл), то все срабатывает. Как можно написать чтобы название подпапки не заменялось? Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220279,220279#msg-220279 From admin на tlvx.ru Tue Dec 20 02:17:28 2011 From: admin на tlvx.ru (=?KOI8-R?B?7M/QwdTJziD3zMHEyc3J0g==?=) Date: Tue, 20 Dec 2011 11:17:28 +0900 Subject: =?UTF-8?B?0J7Rh9C40YHRgtC40YLRjCDQutC70LjQtdC90YLRgdC60LjQuSDQutC10Yg=?= Message-ID: Приветствую всех, возможно ли как то очистить клиентский кеш, или может я что то не верно толкую, просто поменяли сайт, по старому адресу и без очистки кеша в браузере он не заходит на него. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From maxim на nginx.com Tue Dec 20 05:44:03 2011 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 20 Dec 2011 09:44:03 +0400 Subject: =?UTF-8?B?UmU6IFJQTS3QutC4IG5naW54Pw==?= In-Reply-To: <4EEDA5C3.2080703@nginx.com> References: <4EECB180.3070904@bykov.odessa.ua> <4EEDA5C3.2080703@nginx.com> Message-ID: <4EF020A3.6050707@nginx.com> On 12/18/11 12:35 PM, Maxim Konovalov wrote: > On 12/17/11 7:13 PM, s на bykov.odessa.ua wrote: >> Скажите, а сборки пакетов отсюда http://nginx.org/en/download.html - >> это что-то официальное или полагаться не стоит? >> > Да, эти пакеты мы собираем самостоятельно. На них можно жаловаться в > trac.nginx.org (предпочтительно) или в мейллист. > >> И если да, почему на русской версии нет их ? >> > Если вы про отличия этой страницы с > http://nginx.org/ru/download.html, то не дошли руки синхронизировать > с англоязычным вариантом. Поправим. > Just for the record: содержание синхронизировали. -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/ From s на bykov.odessa.ua Tue Dec 20 06:01:40 2011 From: s на bykov.odessa.ua (s на bykov.odessa.ua) Date: Tue, 20 Dec 2011 08:01:40 +0200 Subject: =?UTF-8?B?UmU6IFJQTS3QutC4IG5naW54Pw==?= In-Reply-To: <4EF020A3.6050707@nginx.com> References: <4EECB180.3070904@bykov.odessa.ua> <4EEDA5C3.2080703@nginx.com> <4EF020A3.6050707@nginx.com> Message-ID: <4EF024C4.1000803@bykov.odessa.ua> О, совсем другое дело. И любо и ладно стало. А то ж кручинушка была ранее коль земели, в машинописи кумекающие, вручную сборочку наладить должоны были, а бусурмане окаянные пакетами-самобранцами довольствовались > On 12/18/11 12:35 PM, Maxim Konovalov wrote: >> On 12/17/11 7:13 PM, s на bykov.odessa.ua wrote: >>> Скажите, а сборки пакетов отсюда http://nginx.org/en/download.html - >>> это что-то официальное или полагаться не стоит? >>> >> Да, эти пакеты мы собираем самостоятельно. На них можно жаловаться в >> trac.nginx.org (предпочтительно) или в мейллист. >> >>> И если да, почему на русской версии нет их ? >>> >> Если вы про отличия этой страницы с >> http://nginx.org/ru/download.html, то не дошли руки синхронизировать >> с англоязычным вариантом. Поправим. >> > Just for the record: содержание синхронизировали. > From nginx-forum на nginx.us Tue Dec 20 06:41:43 2011 From: nginx-forum на nginx.us (Craken) Date: Tue, 20 Dec 2011 01:41:43 -0500 Subject: =?UTF-8?B?UmU6INCe0YfQuNGB0YLQuNGC0Ywg0LrQu9C40LXQvdGC0YHQutC40Lkg0LrQtdGI?= In-Reply-To: References: Message-ID: можно попробовать передать браузеру запрет на кеширование! Честно скажу - не знаю или поможет! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220281,220287#msg-220287 From sytar.alex на gmail.com Tue Dec 20 07:01:40 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 20 Dec 2011 11:01:40 +0400 Subject: =?UTF-8?B?UmU6INCe0YfQuNGB0YLQuNGC0Ywg0LrQu9C40LXQvdGC0YHQutC40Lkg0LrQtdGI?= In-Reply-To: References: Message-ID: 20 декабря 2011 г. 6:17 пользователь Лопатин Владимир написал: > Приветствую всех, возможно ли как то очистить клиентский кеш, или может я > что то не верно толкую, просто поменяли сайт, по старому адресу и без > очистки кеша в браузере он не заходит на него. Можно, руками и каждому клиенту. А вообще почитайте - http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html From admin на tlvx.ru Tue Dec 20 07:32:26 2011 From: admin на tlvx.ru (=?KOI8-R?B?7M/QwdTJziD3zMHEyc3J0g==?=) Date: Tue, 20 Dec 2011 16:32:26 +0900 Subject: =?UTF-8?B?UmU6INCe0YfQuNGB0YLQuNGC0Ywg0LrQu9C40LXQvdGC0YHQutC40Lkg0LrQtdGI?= In-Reply-To: References: Message-ID: Почему то я так и думал :-D спасибо ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ne на vbart.ru Tue Dec 20 09:03:53 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 20 Dec 2011 13:03:53 +0400 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: <541defc3e4e4fa5d536c99c6f6316d27.NginxMailingListRussian@forum.nginx.org> References: <541defc3e4e4fa5d536c99c6f6316d27.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112201303.54114.ne@vbart.ru> On Tuesday 20 December 2011 03:43:40 Fixid wrote: > Здравствуйте. Есть на сервере два сайта > которые работают на localhost на разных > портах, есть nginx 1.1.11. > Мне надо чтобы в подпапках > отображались разные сайты. Для этого > добавил в конфиг: > > location ^~ /chat/ { > proxy_redirect off; > proxy_pass http://localhost:150/; > } > > location ^~ /qwe/ { > proxy_redirect off; > proxy_pass http://localhost:151/; > } > > Но к сожалению изменяет url, т.е. syte.com/chat/ > после выполнения становится > syte.com/(длинный урл) - что естественно не > работает, но если написать > syte.com/chat/(длинный урл), то все > срабатывает. Как можно написать чтобы > название подпапки не заменялось? > Если я правильно понял вашу проблему, убрать слэш из proxy_pass: location ^~ /chat/ { proxy_redirect off; proxy_pass http://localhost:150; } -- Валентин Бартенев From nginx-forum на nginx.us Tue Dec 20 09:10:19 2011 From: nginx-forum на nginx.us (Fixid) Date: Tue, 20 Dec 2011 04:10:19 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: <201112201303.54114.ne@vbart.ru> References: <201112201303.54114.ne@vbart.ru> Message-ID: <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Я наверное неправильно обьяснил. На localhost есть два сайта я хочу чтобы при заходе на syte.com/chat/ происходило проксирование с localhost:150 syte.com/qwe/ происходило проксирование с localhost:151 но у меня получается что слово chat удаляется после перехода на след страницу Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220279,220293#msg-220293 From nginx-forum на nginx.us Tue Dec 20 09:12:48 2011 From: nginx-forum на nginx.us (Fixid) Date: Tue, 20 Dec 2011 04:12:48 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: Если убрать слэш, на localhost передается url содержащий /chat/ в конце, и возникает ошибка Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220279,220294#msg-220294 From ne на vbart.ru Tue Dec 20 09:15:58 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 20 Dec 2011 13:15:58 +0400 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112201315.58800.ne@vbart.ru> On Tuesday 20 December 2011 13:10:19 Fixid wrote: [...] > На localhost есть два сайта > > я хочу чтобы при заходе на > syte.com/chat/ происходило проксирование с > localhost:150 > syte.com/qwe/ происходило проксирование с > localhost:151 > > но у меня получается что слово chat > удаляется после перехода на след > страницу > Вы попробовали изменить конфигурацию, как я написал, и у вас всё равно не заработало? -- Валентин Бартенев From ne на vbart.ru Tue Dec 20 09:17:50 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 20 Dec 2011 13:17:50 +0400 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112201317.50308.ne@vbart.ru> On Tuesday 20 December 2011 13:12:48 Fixid wrote: > Если убрать слэш, на localhost передается url > содержащий /chat/ в конце, и возникает > ошибка > Так значит проблема у вас на бэкенде. С /chat/ он у вас не работает, без /chat/ генерирует неверные ссылки. -- Валентин Бартенев From nginx-forum на nginx.us Tue Dec 20 09:33:09 2011 From: nginx-forum на nginx.us (Fixid) Date: Tue, 20 Dec 2011 04:33:09 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: бэкенд вобще не знает что его проксируют, по факту мне надо каждому сайту дать свою подпапку и он не должен знать о ней. Т.е на бэкенд передать запрос от клиента без /chat/, а возвращать результат с /chat/ Нашел что то похожее, но у меня не заработало. http://www.ruby-forum.com/topic/128598 Забыл сказать что все это на windows машине Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220279,220297#msg-220297 From sytar.alex на gmail.com Tue Dec 20 09:34:14 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 20 Dec 2011 13:34:14 +0400 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: 20 декабря 2011 г. 13:33 пользователь Fixid написал: > бэкенд вобще не знает что его > проксируют, по факту мне надо каждому > сайту дать свою подпапку и он не должен > знать о ней. Т.е на бэкенд передать > запрос от клиента без /chat/, а возвращать > результат с /chat/ > > Нашел что то похожее, но у меня не > заработало. > http://www.ruby-forum.com/topic/128598 > > > Забыл сказать что все это на windows машине А под каждый бэкенд свою секцию server не получается завести и не мучатся? From nginx-forum на nginx.us Tue Dec 20 09:37:29 2011 From: nginx-forum на nginx.us (Fixid) Date: Tue, 20 Dec 2011 04:37:29 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: Если я указываю слушать одинаковый порт в разных server, то 404 везде Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220279,220300#msg-220300 From nginx-forum на nginx.us Tue Dec 20 09:57:15 2011 From: nginx-forum на nginx.us (Fixid) Date: Tue, 20 Dec 2011 04:57:15 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> Message-ID: <08d7243e3d1099a5b0ddb3d14f84608b.NginxMailingListRussian@forum.nginx.org> Вы можете показать примерный конфиг? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220279,220302#msg-220302 From latypoff на yandex.ru Tue Dec 20 11:26:57 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Tue, 20 Dec 2011 18:26:57 +0700 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QtdC90LjQtSBVUkw=?= In-Reply-To: <08d7243e3d1099a5b0ddb3d14f84608b.NginxMailingListRussian@forum.nginx.org> References: <201112201303.54114.ne@vbart.ru> <49dcde66cfa6df2b85d3d13734c68879.NginxMailingListRussian@forum.nginx.org> <08d7243e3d1099a5b0ddb3d14f84608b.NginxMailingListRussian@forum.nginx.org> Message-ID: <64161324380417@web158.yandex.ru> 20.12.2011, 16:57, "Fixid" : > Вы можете показать примерный конфиг? > Да, в составе nginx идет. -- br, Denis F. Latypoff. From nginx-forum на nginx.us Tue Dec 20 14:59:00 2011 From: nginx-forum на nginx.us (winsov) Date: Tue, 20 Dec 2011 09:59:00 -0500 Subject: nginx redis session In-Reply-To: References: Message-ID: Вообще избавляться от хранения сессий в файлах нужно при большом кол-ве пользователей. Сессий хранить в мэмкэше ненадежно а в файлах тормознуто . А вот Редис вполне хороший вариант для хранения сессий т.к актуальные данные храняться в оперативной памяти но еще и копируются на жесткий диск для сохранности. ставим redis server В настройках php прописываем session.save_handler redis session.save_path 11.11.11.11:6379 где 11.11.11.11 - IP сервера где установлен redis (подключение по IP в случае использования редиса на отдельном сервере) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220121,220310#msg-220310 From nginx-forum на nginx.us Tue Dec 20 15:47:30 2011 From: nginx-forum на nginx.us (saken) Date: Tue, 20 Dec 2011 10:47:30 -0500 Subject: =?UTF-8?B?MS4xLjExINC90LUg0YHQvtCx0LjRgNCw0LXRgtGB0Y8g0L3QsCBTb2xhcmlzIDEw?= =?UTF-8?B?IFNQQVJD?= Message-ID: <9a178380219a269df522eb0fe1ba5c52.NginxMailingListRussian@forum.nginx.org> здравствуйте. пытаюсь собрать по Solaris 10 SPARC PCRE & OpenSSL установлены в /opt/local bash-3.2$ CC="cc" ./configure --prefix=/opt/local/nginx --with-cpu-opt="sparc64" --with-http_ssl_module --with-cc-opt="-I /opt/local/include" --with-ld-opt="-L /opt/local/lib -R /lib -R /usr/lib -R /opt/local/lib" checking for OS + SunOS 5.10 sun4u checking for C compiler ... found + using Sun C compiler + Sun C version: 5.12 SunOS_sparc 2011/11/16 checking for --with-ld-opt="-L /opt/local/lib -R /lib -R /usr/lib -R /opt/local/lib" ... found checking for gcc builtin atomic operations ... not found checking for C99 variadic macros ... found checking for gcc variadic macros ... found checking for unistd.h ... found checking for inttypes.h ... found checking for limits.h ... found checking for sys/filio.h ... found checking for sys/param.h ... found checking for sys/mount.h ... found checking for sys/statvfs.h ... found checking for crypt.h ... found checking for SunOS specific features checking for sendfilev() ... found checking for event ports ... found checking for nobody group ... found checking for poll() ... found checking for /dev/poll ... found checking for kqueue ... not found checking for crypt() ... found checking for F_READAHEAD ... not found checking for posix_fadvise() ... not found checking for O_DIRECT ... not found checking for F_NOCACHE ... not found checking for directio() ... found checking for statfs() ... not found checking for statvfs() ... found checking for dlopen() ... found checking for sched_yield() ... not found checking for sched_yield() in librt ... found checking for SO_SETFIB ... not found checking for SO_ACCEPTFILTER ... not found checking for TCP_DEFER_ACCEPT ... not found checking for TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT ... not found checking for accept4() ... not found checking for int size ... 4 bytes checking for long size ... 8 bytes checking for long long size ... 8 bytes checking for void * size ... 8 bytes checking for uint64_t ... found checking for sig_atomic_t ... found checking for sig_atomic_t size ... 4 bytes checking for socklen_t ... found checking for in_addr_t ... found checking for in_port_t ... found checking for rlim_t ... found checking for uintptr_t ... uintptr_t found checking for system endianess ... big endianess checking for size_t size ... 8 bytes checking for off_t size ... 8 bytes checking for time_t size ... 8 bytes checking for setproctitle() ... not found checking for pread() ... found checking for pwrite() ... found checking for sys_nerr ... not found checking for _sys_nerr ... not found checking for maximum errno ... found checking for localtime_r() ... found checking for posix_memalign() ... not found checking for memalign() ... found checking for mmap(MAP_ANON|MAP_SHARED) ... found checking for mmap("/dev/zero", MAP_SHARED) ... found checking for System V shared memory ... found checking for POSIX semaphores ... not found checking for POSIX semaphores in libpthread ... not found checking for POSIX semaphores in librt ... found checking for struct msghdr.msg_control ... not found checking for ioctl(FIONBIO) ... found checking for struct tm.tm_gmtoff ... not found checking for struct dirent.d_namlen ... not found checking for struct dirent.d_type ... not found checking for PCRE library ... found checking for OpenSSL library ... found checking for zlib library ... found creating objs/Makefile ./configure: test: argument expected bash-3.2$ make make: Fatal error: Don't know how to make target `build' bash-3.2$ make -f objs/Makefile "src/core/nginx.c", line 1034: undefined symbol: NGX_USER "src/core/nginx.c", line 1034: improper pointer/integer combination: arg #1 "src/core/nginx.c", line 1036: syntax error before or at: NGX_USER "src/core/nginx.c", line 1041: improper pointer/integer combination: op "=" "src/core/nginx.c", line 1045: undefined symbol: NGX_GROUP "src/core/nginx.c", line 1045: improper pointer/integer combination: arg #1 "src/core/nginx.c", line 1047: syntax error before or at: NGX_GROUP cc: acomp failed for src/core/nginx.c make: Fatal error: Command failed for target `objs/src/core/nginx.o' Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220311,220311#msg-220311 From sb на waeme.net Tue Dec 20 16:06:57 2011 From: sb на waeme.net (Sergey Budnevitch) Date: Tue, 20 Dec 2011 20:06:57 +0400 Subject: =?UTF-8?B?UmU6IDEuMS4xMSDQvdC1INGB0L7QsdC40YDQsNC10YLRgdGPINC90LAgU29sYXJp?= =?UTF-8?B?cyAxMCBTUEFSQw==?= In-Reply-To: <9a178380219a269df522eb0fe1ba5c52.NginxMailingListRussian@forum.nginx.org> References: <9a178380219a269df522eb0fe1ba5c52.NginxMailingListRussian@forum.nginx.org> Message-ID: <02848DD5-355F-4786-AC9D-8BC4F730C75E@waeme.net> On 20.12.2011, at 19:47, saken wrote: > здравствуйте. > > пытаюсь собрать по Solaris 10 SPARC > PCRE & OpenSSL установлены в /opt/local В Solaris /bin/sh старый и не posix-compliant, поэтому замените /bin/sh в первой строчке configure на /usr/xpg4/bin/sh > > bash-3.2$ CC="cc" ./configure --prefix=/opt/local/nginx > --with-cpu-opt="sparc64" --with-http_ssl_module --with-cc-opt="-I > /opt/local/include" --with-ld-opt="-L /opt/local/lib -R /lib -R /usr/lib > -R /opt/local/lib" > checking for OS > + SunOS 5.10 sun4u > checking for C compiler ... found > + using Sun C compiler > + Sun C version: 5.12 SunOS_sparc 2011/11/16 > checking for --with-ld-opt="-L /opt/local/lib -R /lib -R /usr/lib -R > /opt/local/lib" ... found > checking for gcc builtin atomic operations ... not found > checking for C99 variadic macros ... found > checking for gcc variadic macros ... found > checking for unistd.h ... found > checking for inttypes.h ... found > checking for limits.h ... found > checking for sys/filio.h ... found > checking for sys/param.h ... found > checking for sys/mount.h ... found > checking for sys/statvfs.h ... found > checking for crypt.h ... found > checking for SunOS specific features > checking for sendfilev() ... found > checking for event ports ... found > checking for nobody group ... found > checking for poll() ... found > checking for /dev/poll ... found > checking for kqueue ... not found > checking for crypt() ... found > checking for F_READAHEAD ... not found > checking for posix_fadvise() ... not found > checking for O_DIRECT ... not found > checking for F_NOCACHE ... not found > checking for directio() ... found > checking for statfs() ... not found > checking for statvfs() ... found > checking for dlopen() ... found > checking for sched_yield() ... not found > checking for sched_yield() in librt ... found > checking for SO_SETFIB ... not found > checking for SO_ACCEPTFILTER ... not found > checking for TCP_DEFER_ACCEPT ... not found > checking for TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT ... not found > checking for accept4() ... not found > checking for int size ... 4 bytes > checking for long size ... 8 bytes > checking for long long size ... 8 bytes > checking for void * size ... 8 bytes > checking for uint64_t ... found > checking for sig_atomic_t ... found > checking for sig_atomic_t size ... 4 bytes > checking for socklen_t ... found > checking for in_addr_t ... found > checking for in_port_t ... found > checking for rlim_t ... found > checking for uintptr_t ... uintptr_t found > checking for system endianess ... big endianess > checking for size_t size ... 8 bytes > checking for off_t size ... 8 bytes > checking for time_t size ... 8 bytes > checking for setproctitle() ... not found > checking for pread() ... found > checking for pwrite() ... found > checking for sys_nerr ... not found > checking for _sys_nerr ... not found > checking for maximum errno ... found > checking for localtime_r() ... found > checking for posix_memalign() ... not found > checking for memalign() ... found > checking for mmap(MAP_ANON|MAP_SHARED) ... found > checking for mmap("/dev/zero", MAP_SHARED) ... found > checking for System V shared memory ... found > checking for POSIX semaphores ... not found > checking for POSIX semaphores in libpthread ... not found > checking for POSIX semaphores in librt ... found > checking for struct msghdr.msg_control ... not found > checking for ioctl(FIONBIO) ... found > checking for struct tm.tm_gmtoff ... not found > checking for struct dirent.d_namlen ... not found > checking for struct dirent.d_type ... not found > checking for PCRE library ... found > checking for OpenSSL library ... found > checking for zlib library ... found > creating objs/Makefile > ./configure: test: argument expected > > bash-3.2$ make > make: Fatal error: Don't know how to make target `build' > > bash-3.2$ make -f objs/Makefile > "src/core/nginx.c", line 1034: undefined symbol: NGX_USER > "src/core/nginx.c", line 1034: improper pointer/integer combination: arg > #1 > "src/core/nginx.c", line 1036: syntax error before or at: NGX_USER > "src/core/nginx.c", line 1041: improper pointer/integer combination: op > "=" > "src/core/nginx.c", line 1045: undefined symbol: NGX_GROUP > "src/core/nginx.c", line 1045: improper pointer/integer combination: arg > #1 > "src/core/nginx.c", line 1047: syntax error before or at: NGX_GROUP > cc: acomp failed for src/core/nginx.c > make: Fatal error: Command failed for target `objs/src/core/nginx.o' > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220311,220311#msg-220311 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на nginx.us Tue Dec 20 16:29:15 2011 From: nginx-forum на nginx.us (saken) Date: Tue, 20 Dec 2011 11:29:15 -0500 Subject: =?UTF-8?B?UmU6IDEuMS4xMSDQvdC1INGB0L7QsdC40YDQsNC10YLRgdGPINC90LAgU29sYXJp?= =?UTF-8?B?cyAxMCBTUEFSQw==?= In-Reply-To: <9a178380219a269df522eb0fe1ba5c52.NginxMailingListRussian@forum.nginx.org> References: <9a178380219a269df522eb0fe1ba5c52.NginxMailingListRussian@forum.nginx.org> Message-ID: спасибо. попробую Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220311,220315#msg-220315 From maxim на nginx.com Tue Dec 20 16:32:21 2011 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 20 Dec 2011 20:32:21 +0400 Subject: =?UTF-8?B?UmU6IDEuMS4xMSDQvdC1INGB0L7QsdC40YDQsNC10YLRgdGPINC90LAgU29sYXJp?= =?UTF-8?B?cyAxMCBTUEFSQw==?= In-Reply-To: References: <9a178380219a269df522eb0fe1ba5c52.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EF0B895.7040602@nginx.com> On 12/20/11 8:29 PM, saken wrote: > спасибо. попробую > jfyi, Сергей закоммитил фикс: http://trac.nginx.org/nginx/changeset/4377/nginx -- Maxim Konovalov +7 (910) 4293178 http://nginx.com/ From nginx-forum на nginx.us Tue Dec 20 16:39:40 2011 From: nginx-forum на nginx.us (saken) Date: Tue, 20 Dec 2011 11:39:40 -0500 Subject: =?UTF-8?B?UmU6IDEuMS4xMSDQvdC1INGB0L7QsdC40YDQsNC10YLRgdGPINC90LAgU29sYXJp?= =?UTF-8?B?cyAxMCBTUEFSQw==?= In-Reply-To: <02848DD5-355F-4786-AC9D-8BC4F730C75E@waeme.net> References: <02848DD5-355F-4786-AC9D-8BC4F730C75E@waeme.net> Message-ID: <5534e85222e7f776208d6d758856484d.NginxMailingListRussian@forum.nginx.org> > В Solaris /bin/sh старый и не > posix-compliant, > поэтому замените /bin/sh в > первой строчке configure на > /usr/xpg4/bin/sh спасибо большое. Вы мне очень помогли Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220311,220317#msg-220317 From nginx-forum на nginx.us Tue Dec 20 17:44:52 2011 From: nginx-forum на nginx.us (alexch) Date: Tue, 20 Dec 2011 12:44:52 -0500 Subject: =?UTF-8?B?0LrQsNC6INC40YHQv9C+0LvRjNC30L7QstCw0YLRjCBtZW1jYWNoZSDRgSBuZ2lu?= =?UTF-8?B?eA==?= Message-ID: <5461d1ab3d8349793063377159290f39.NginxMailingListRussian@forum.nginx.org> freebsd 8/nginx последний чтото не могу понять почему он не берёт из мемкеша ??? 2011/12/20 19:37:13 [info] 23563#0: *396903 key: "css.php" was not found by memcached while reading response header from upstream, client: 91.198.116.5, server:xxxxxx.ua, request: "GET /css.php?13,css_print HTTP/1.1", upstream: "memcached://127.0.0.1:11211", host: "xxxxxxxx.ua", referrer: "http://xxxxxxxx.ua/read.php?13,839318" 2011/12/20 19:37:17 [info] 23563#0: *396903 key: "/templates/emerald/images/menu-background-highlight.png" was not found by memcached while reading response header from upstream, client: 91.198.116.5, server: xxxxxxx.ua, request: "GET /templates/emerald/images/menu-background-highlight.png HTTP/1.1", upstream: "memcached://127.0.0.1:11211", host: "xxxxxxxxx.ua", referrer: "http://xxxxxxxx.ua/read.php?13,839318" server { listen 80 default accept_filter=httpready; server_name xxxxxxx.ua; root /usr/home/xxxxxxxx.ua/www/; error_log /var/log/nginx/_error.log debug; #access_log /var/log/nginx/_access.log; location / { index index.html index.php; set $memcached_key $uri; memcached_pass 127.0.0.1:11211; default_type text/html; error_page 404 405 = @fallback; } location ~ \.php$ { default_type text/html; set $memcached_key $uri; memcached_pass 127.0.0.1:11211; error_page 404 405 = @fallback; } location @fallback { fastcgi_pass unix:/tmp/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /usr/home/xxxxxxx.ua/www$fastcgi_scr ipt_name; include fastcgi_params; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220318#msg-220318 From mdounin на mdounin.ru Tue Dec 20 17:52:13 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Dec 2011 21:52:13 +0400 Subject: =?UTF-8?Q?Re=3A_limit=5Frate_=D0=B8_sendfile=5Fmax=5Fchunk?= In-Reply-To: <201003091453.37122.alant@transtelecom.md> References: <201003091014.00232.alant@transtelecom.md> <20100309123436.GV76989@mdounin.ru> <201003091453.37122.alant@transtelecom.md> Message-ID: <20111220175213.GM67687@mdounin.ru> Hello! On Tue, Mar 09, 2010 at 02:53:36PM +0200, Alex Antropoff wrote: > В сообщении от Вторник 09 марта 2010 14:34:36 автор Maxim Dounin написал: > > Hello! > > > > On Tue, Mar 09, 2010 at 10:14:00AM +0200, Alex Antropoff wrote: > > > > > насколько видно в ngx_http_write_filter_module.c при > > > использовании limit_rate не используется sendfile_max_chunk. > > > Так как sendfile_max_chunk в теории позволяет уменьшить > > > блокирование при работе с нагруженной дисковой системой, может > > > быть дополнительно его использовать при вычислении limit ? > > > Особенно заметно при flv/mp4/etc streaming, когда limit_rate > > > нельзя задать ниже, чем битрейт, и после получаса просмотра > > > limit становится уже таким, что sendfile начинает блокироваться. > > > > Если limit при использовании limit_rate становится больше - значит > > либо клиент не выбирает выделенную ему полосу, либо сервер эту полосу > > отдать не в состоянии из-за прогруженности дисковой подсистемы. > > В первом случае sendfile блокировать так и так не будет (забъёт > > буфер и отвалится). Пытаемся лечить второй случай, я правильно > > понимаю? > Точно. Просто картина из первого случая плавно переходит во второй в чнн, > хотелось бы заранее знать поведение. > Я пока добавил пару строчек, но хотелось бы понять идеологию партии :-) Наконец дошли руки доделать это место. Патчи тут: http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001630.html http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001631.html Maxim Dounin From mdounin на mdounin.ru Tue Dec 20 17:57:13 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Dec 2011 21:57:13 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: <5461d1ab3d8349793063377159290f39.NginxMailingListRussian@forum.nginx.org> References: <5461d1ab3d8349793063377159290f39.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111220175713.GN67687@mdounin.ru> Hello! On Tue, Dec 20, 2011 at 12:44:52PM -0500, alexch wrote: > freebsd 8/nginx последний > > чтото не могу понять почему он не берёт > из мемкеша ??? А вы туда то, что пытаетесь брать, положили? Сам nginx ничего в memcached не кладёт. > 2011/12/20 19:37:13 [info] 23563#0: *396903 key: "css.php" was not found > by memcached while reading response header from upstream, client: > 91.198.116.5, server:xxxxxx.ua, request: "GET /css.php?13,css_print > HTTP/1.1", upstream: "memcached://127.0.0.1:11211", host: "xxxxxxxx.ua", > referrer: "http://xxxxxxxx.ua/read.php?13,839318" > 2011/12/20 19:37:17 [info] 23563#0: *396903 key: > "/templates/emerald/images/menu-background-highlight.png" was not found > by memcached while reading response header from upstream, client: > 91.198.116.5, server: xxxxxxx.ua, request: "GET > /templates/emerald/images/menu-background-highlight.png HTTP/1.1", > upstream: "memcached://127.0.0.1:11211", host: "xxxxxxxxx.ua", referrer: > "http://xxxxxxxx.ua/read.php?13,839318" [...] Maxim Dounin From nginx-forum на nginx.us Tue Dec 20 18:01:22 2011 From: nginx-forum на nginx.us (alexch) Date: Tue, 20 Dec 2011 13:01:22 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: <20111220175713.GN67687@mdounin.ru> References: <20111220175713.GN67687@mdounin.ru> Message-ID: <582d15d5968e8382da0896302e887483.NginxMailingListRussian@forum.nginx.org> сорри не уточнил phorum5/openx туда кладут по крайней мере так выставлено Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220324#msg-220324 From mdounin на mdounin.ru Tue Dec 20 18:05:15 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Dec 2011 22:05:15 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: <582d15d5968e8382da0896302e887483.NginxMailingListRussian@forum.nginx.org> References: <20111220175713.GN67687@mdounin.ru> <582d15d5968e8382da0896302e887483.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111220180515.GO67687@mdounin.ru> Hello! On Tue, Dec 20, 2011 at 01:01:22PM -0500, alexch wrote: > сорри не уточнил > phorum5/openx туда кладут > по крайней мере так выставлено Видимо, не кладут, или кладут как-то по другому. Смотрите им в душу. Maxim Dounin From nginx-forum на nginx.us Tue Dec 20 18:09:46 2011 From: nginx-forum на nginx.us (alexch) Date: Tue, 20 Dec 2011 13:09:46 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: <20111220180515.GO67687@mdounin.ru> References: <20111220180515.GO67687@mdounin.ru> Message-ID: жаль не смыслю в пхп а в конфиге всё верно?? или есть еще какието переменные, может чтото дописать в $memcached_key $uri ?? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220326#msg-220326 From nginx-forum на nginx.us Tue Dec 20 18:21:36 2011 From: nginx-forum на nginx.us (alexch) Date: Tue, 20 Dec 2011 13:21:36 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: References: <20111220180515.GO67687@mdounin.ru> Message-ID: в memcache.php форума5 нашел функцию котора кладет function phorum_cache_put($type,$key,$data,$ttl=PHORUM_CACHE_DEFAULT_TTL,$version=NULL) { if (empty($GLOBALS['PHORUM']['memcache_obj'])) return FALSE; return @$GLOBALS['PHORUM']['memcache_obj']->set( $type."_".$key, array($data,$version), 0, $ttl ); } подскажите какой должен быть set $memcached_key ??7 Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220327#msg-220327 From mdounin на mdounin.ru Tue Dec 20 18:24:55 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 20 Dec 2011 22:24:55 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: References: <20111220180515.GO67687@mdounin.ru> Message-ID: <20111220182455.GQ67687@mdounin.ru> Hello! On Tue, Dec 20, 2011 at 01:21:36PM -0500, alexch wrote: > в memcache.php форума5 нашел функцию котора > кладет > > > function > phorum_cache_put($type,$key,$data,$ttl=PHORUM_CACHE_DEFAULT_TTL,$version=NULL) > { > if (empty($GLOBALS['PHORUM']['memcache_obj'])) return FALSE; > return @$GLOBALS['PHORUM']['memcache_obj']->set( > $type."_".$key, array($data,$version), 0, $ttl > ); > } > > подскажите какой должен быть set > $memcached_key > ??7 Судя по приведённому коду - оно кладёт внутренние данные phorum'а, а не готовую страницу для клиента. Отдавать это nginx'ом не получится. Maxim Dounin From sytar.alex на gmail.com Tue Dec 20 19:10:16 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 20 Dec 2011 23:10:16 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: References: <20111220180515.GO67687@mdounin.ru> Message-ID: вторник, 20 декабря 2011 г. пользователь alexch писал: > в memcache.php форума5 нашел функцию котора > кладет > > > function > phorum_cache_put($type,$key,$data,$ttl=PHORUM_CACHE_DEFAULT_TTL,$version=NULL) > { > if (empty($GLOBALS['PHORUM']['memcache_obj'])) return FALSE; > return @$GLOBALS['PHORUM']['memcache_obj']->set( > $type."_".$key, array($data,$version), 0, $ttl > ); > } > > подскажите какой должен быть set > $memcached_key > ??7 > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220327#msg-220327 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sytar.alex на gmail.com Tue Dec 20 19:12:21 2011 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 20 Dec 2011 23:12:21 +0400 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: References: <20111220180515.GO67687@mdounin.ru> Message-ID: вторник, 20 декабря 2011 г. пользователь alexch писал: > в memcache.php форума5 нашел функцию котора > кладет > > > function > phorum_cache_put($type,$key,$data,$ttl=PHORUM_CACHE_DEFAULT_TTL,$version=NULL) > { > if (empty($GLOBALS['PHORUM']['memcache_obj'])) return FALSE; > return @$GLOBALS['PHORUM']['memcache_obj']->set( > $type."_".$key, array($data,$version), 0, $ttl > ); > } > > подскажите какой должен быть set > $memcached_key > ??7 > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220327#msg-220327 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Сорри, предыдущее случайно ушло. К мемкешу есть куча админок смотреть статы. Либо через любую проверьте либо телнетом. Там текстовые команды. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From swood на fotofor.biz Tue Dec 20 19:18:17 2011 From: swood на fotofor.biz (Anton Kiryushkin) Date: Tue, 20 Dec 2011 23:18:17 +0400 Subject: proxy_cache_key $http_user_agent Message-ID: Всем доброго времени суток. Возникла задача кэшировать сайт, который существует в трех версиях для разных юзер-агентов. Собственно вопрос в том, можно ли в директиву proxy_cache_key засунуть некую собственную переменную, например $agent, которая может меняться в зависимости от непосредственно юзер-агента и тем самым пользуясь одним и тем же proxy_cache cache_folder, делать в него разные по своей сути кэш? -- Best regards, Anton Kiryushkin, From wangsamp на gmail.com Tue Dec 20 19:26:24 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Tue, 20 Dec 2011 21:26:24 +0200 (EET) Subject: proxy_cache_key $http_user_agent In-Reply-To: References: Message-ID: Today Dec 20, 2011 at 23:18 Anton Kiryushkin wrote: > > Возникла задача кэшировать сайт, который существует в трех версиях для > разных юзер-агентов. Собственно вопрос в том, можно ли в директиву > proxy_cache_key засунуть некую собственную переменную, например > $agent, которая может меняться в зависимости от непосредственно > юзер-агента и тем самым пользуясь одним и тем же proxy_cache > cache_folder, делать в него разные по своей сути кэш? Можно. А значение её удобнее всего будет задавать через map: http://wiki.nginx.org/HttpMapModule#map -- WNGS-RIPE From swood на fotofor.biz Tue Dec 20 19:45:34 2011 From: swood на fotofor.biz (Anton Kiryushkin) Date: Tue, 20 Dec 2011 23:45:34 +0400 Subject: proxy_cache_key $http_user_agent In-Reply-To: References: Message-ID: Ну как задавать в общем-то на вкус и цвет...А вот насчет proxy_cache_key, может ли кто-нибудь подсказать с примером такого использования. К сожалению пока что мои эксперименты результата не дали.. 20 декабря 2011 г. 23:26 пользователь Oleksandr V. Typlyns'kyi написал: > Today Dec 20, 2011 at 23:18 Anton Kiryushkin wrote: > >> >> Возникла задача кэшировать сайт, который существует в трех версиях для >> разных юзер-агентов. Собственно вопрос в том, можно ли в директиву >> proxy_cache_key засунуть некую собственную переменную, например >> $agent, которая может меняться в зависимости от непосредственно >> юзер-агента  и тем самым пользуясь одним и тем же proxy_cache >> cache_folder, делать в него разные по своей сути кэш? > >  Можно. >  А значение её удобнее всего будет задавать через map: >  http://wiki.nginx.org/HttpMapModule#map > > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin, From wangsamp на gmail.com Tue Dec 20 20:03:58 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Tue, 20 Dec 2011 22:03:58 +0200 (EET) Subject: proxy_cache_key $http_user_agent In-Reply-To: References: Message-ID: Today Dec 20, 2011 at 23:45 Anton Kiryushkin wrote: > Ну как задавать в общем-то на вкус и цвет...А вот насчет > proxy_cache_key, может ли кто-нибудь подсказать с примером такого > использования. К сожалению пока что мои эксперименты результата не > дали.. Просто добавить вместе с другими переменными: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_key proxy_cache_key $scheme$proxy_host$request_uri$agent; -- WNGS-RIPE From nginx-forum на nginx.us Wed Dec 21 05:02:11 2011 From: nginx-forum на nginx.us (sourse) Date: Wed, 21 Dec 2011 00:02:11 -0500 Subject: =?UTF-8?B?0J/RgNC+0LLQtdGA0LrQsCAkdXJpINC90LAg0LLQsNC70LjQtNC90L7RgdGC0Yw=?= Message-ID: Здравствуйте, Подскажите, как в nginx правильно сделать проверку uri на валидность Сейчас в конфиге есть: if ($request_uri != $uri) { #return 403; rewrite ^(.*) http://$server_name$uri permanent; } Но если uri не верный получается зацикливание 301, как исправить? # В uri могут быть только: буквы, цифры, точки, слэши, тире, подчеркивания Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220339,220339#msg-220339 From nginx-forum на nginx.us Wed Dec 21 07:34:55 2011 From: nginx-forum на nginx.us (alexch) Date: Wed, 21 Dec 2011 02:34:55 -0500 Subject: =?UTF-8?B?UmU6INC60LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0YwgbWVtY2FjaGUg0YEg?= =?UTF-8?B?bmdpbng=?= In-Reply-To: <20111220182455.GQ67687@mdounin.ru> References: <20111220182455.GQ67687@mdounin.ru> Message-ID: <6446ae183b7bc3aa8fec9a5224e6d396.NginxMailingListRussian@forum.nginx.org> таки да, проверил стороним memcache.php Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220318,220341#msg-220341 From ru на nginx.com Wed Dec 21 07:57:56 2011 From: ru на nginx.com (Ruslan Ermilov) Date: Wed, 21 Dec 2011 07:57:56 +0000 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: References: Message-ID: <20111221075756.GB95602@lo0.su> On Wed, Dec 21, 2011 at 12:02:11AM -0500, sourse wrote: > Здравствуйте, > > Подскажите, как в nginx правильно сделать > проверку uri на валидность > > Сейчас в конфиге есть: > > if ($request_uri != $uri) { > #return 403; > rewrite ^(.*) http://$server_name$uri permanent; > } > > Но если uri не верный получается > зацикливание 301, как исправить? > > # В uri могут быть только: буквы, цифры, > точки, слэши, тире, подчеркивания Попробуйте написать location с подходящим регулярным выражением: http://nginx.org/ru/docs/http/ngx_http_core_module.html#location Также см. http://nginx.org/en/docs/http/converting_rewrite_rules.html From nginx-forum на nginx.us Wed Dec 21 08:55:31 2011 From: nginx-forum на nginx.us (sourse) Date: Wed, 21 Dec 2011 03:55:31 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: References: Message-ID: <8e4e611e1a892bfde8bd70275c877fb9.NginxMailingListRussian@forum.nginx.org> это и есть location, только общий для всех, т.е. /, еще есть @fallback и один в котором нужен $request_uri , а не $uri Хочу сделать так, чтобы по неправильному URL выдавалась либо 404, либо 301 на правильный URL. В URL нет параметров, поэтому справедливо ******* if ($request_uri != $uri) rewrite ^(.*) http://$server_name$uri permanent; ******* редирект сделан для того, чтобы с /folder/word_1.html?query перекидывать на /folder/word_1.html, т.к. раньше по /folder/word_1.html?query открывалась /folder/word_1.html страница, а это не правильно. если сделать ошибку, скажем в /folder/wordERROR_1.html то будет 404. все работало, пока не попробовал пробелы и квадратные скобки [ ] в uri, из-за них получается цикл, и как его можно вылечить не могу придумать. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220339,220347#msg-220347 From wangsamp на gmail.com Wed Dec 21 11:39:52 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 21 Dec 2011 13:39:52 +0200 (EET) Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: <8e4e611e1a892bfde8bd70275c877fb9.NginxMailingListRussian@forum.nginx.org> References: <8e4e611e1a892bfde8bd70275c877fb9.NginxMailingListRussian@forum.nginx.org> Message-ID: Today Dec 21, 2011 at 03:55 sourse wrote: > ******* > > if ($request_uri != $uri) > rewrite ^(.*) http://$server_name$uri permanent; > > ******* > > редирект сделан для того, чтобы с > /folder/word_1.html?query перекидывать на > /folder/word_1.html, > т.к. раньше по /folder/word_1.html?query > открывалась /folder/word_1.html страница, а это > не правильно. Тоесть на самом деле Вы хотите убрать $args? http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables if ($args) {return 404;} или if ($args) {return 301 http://$server_name$uri;} -- WNGS-RIPE From ne на vbart.ru Wed Dec 21 12:01:58 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 21 Dec 2011 16:01:58 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: References: <8e4e611e1a892bfde8bd70275c877fb9.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112211601.59019.ne@vbart.ru> On Wednesday 21 December 2011 15:39:52 Oleksandr V. Typlyns'kyi wrote: > Today Dec 21, 2011 at 03:55 sourse wrote: > > ******* > > > > if ($request_uri != $uri) > > rewrite ^(.*) http://$server_name$uri permanent; > > > > ******* > > > > редирект сделан для того, чтобы с > > /folder/word_1.html?query перекидывать на > > /folder/word_1.html, > > т.к. раньше по /folder/word_1.html?query > > открывалась /folder/word_1.html страница, а это > > не правильно. > > Тоесть на самом деле Вы хотите убрать $args? > http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables > if ($args) {return 404;} или if ($args) {return 301 > http://$server_name$uri;} Лучше использовать $is_args. -- Валентин Бартенев From nginx-forum на nginx.us Wed Dec 21 12:13:45 2011 From: nginx-forum на nginx.us (sourse) Date: Wed, 21 Dec 2011 07:13:45 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: References: Message-ID: Oleksandr V. Typlyns'kyi Wrote: ------------------------------------------------------- > Today Dec 21, 2011 at 03:55 sourse wrote: > > > ******* > > > > if ($request_uri != $uri) > > rewrite ^(.*) http://$server_name$uri permanent; > > > > ******* > > > > редирект сделан для того, > чтобы с > > /folder/word_1.html?query > перекидывать на > > /folder/word_1.html, > > т.к. раньше по > /folder/word_1.html?query > > открывалась /folder/word_1.html > страница, а это > > не правильно. > > Тоесть на самом деле Вы > хотите убрать $args? > > http://nginx.org/ru/docs/http/ngx_http_core_module > .html#variables > if ($args) {return 404;} или if ($args) > {return 301 http://$server_name$uri;} > > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru так тоже пробовал, способ не решает проблему с $is_args в конце URL, т.е. аргументов нет, есть только знак "?" nginx отъедает знак вопроса в uri и передает его на backend, backend отвечает на правильный uri, и в итоге получаются две одинаковые страницы по разным адресам. site.com/folder/word_1.html? И site.com/folder/word_1.html Поэтому я сравниваю $request_uri с $uri чтобы отсеять $is_args. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220339,220354#msg-220354 From wangsamp на gmail.com Wed Dec 21 12:19:15 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 21 Dec 2011 14:19:15 +0200 (EET) Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: <201112211601.59019.ne@vbart.ru> References: <8e4e611e1a892bfde8bd70275c877fb9.NginxMailingListRussian@forum.nginx.org> <201112211601.59019.ne@vbart.ru> Message-ID: Today Dec 21, 2011 at 16:01 Валентин Бартенев wrote: > > > редирект сделан для того, чтобы с > > > /folder/word_1.html?query перекидывать на > > > /folder/word_1.html, > > > т.к. раньше по /folder/word_1.html?query > > > открывалась /folder/word_1.html страница, а это > > > не правильно. > > > > Тоесть на самом деле Вы хотите убрать $args? > > http://nginx.org/ru/docs/http/ngx_http_core_module.html#variables > > if ($args) {return 404;} или if ($args) {return 301 http://$server_name$uri;} > > Лучше использовать $is_args. Тут зависит от её значения в случае запроса "/folder/word_1.html?" и как его обрабатывать -- WNGS-RIPE From nginx-forum на nginx.us Wed Dec 21 12:19:31 2011 From: nginx-forum на nginx.us (sourse) Date: Wed, 21 Dec 2011 07:19:31 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCy0LXRgNC60LAgJHVyaSDQvdCwINCy0LDQu9C40LTQvdC+0YE=?= =?UTF-8?B?0YLRjA==?= In-Reply-To: <201112211601.59019.ne@vbart.ru> References: <201112211601.59019.ne@vbart.ru> Message-ID: <681c90beba5aeb0081a1dfc6edaeab47.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: > > Лучше использовать $is_args. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru if ($is_args) {return 301 http://$server_name$uri;} Не работает, т.к. не задуманно Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220339,220355#msg-220355 From swood на fotofor.biz Wed Dec 21 15:33:28 2011 From: swood на fotofor.biz (Anton Kiryushkin) Date: Wed, 21 Dec 2011 19:33:28 +0400 Subject: proxy_cache_key $http_user_agent In-Reply-To: References: Message-ID: Да, так и получилось, спасибо! Теперь вторая часть. Допустим в URL есть сессия, то есть урл выглядит примерно так: http://site.com/page.html;session=29387492387492837 Можно ли как-то при кэшировании этот параметр сессии отбрасывать, а потом при доставании из кэша игнорировать? 21 декабря 2011 г. 0:03 пользователь Oleksandr V. Typlyns'kyi написал: > Today Dec 20, 2011 at 23:45 Anton Kiryushkin wrote: > >> Ну как задавать в общем-то на вкус и цвет...А вот насчет >> proxy_cache_key, может ли кто-нибудь подсказать с примером такого >> использования. К сожалению пока что мои эксперименты результата не >> дали.. > >  Просто добавить вместе с другими переменными: >  http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_key >  proxy_cache_key $scheme$proxy_host$request_uri$agent; > > -- > WNGS-RIPE > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin, From fry.kun на gmail.com Thu Dec 22 05:58:29 2011 From: fry.kun на gmail.com (Konstantin Svist) Date: Wed, 21 Dec 2011 21:58:29 -0800 Subject: gzip error Message-ID: <4EF2C705.8030407@gmail.com> Кажется нашёл глюку в 1.1.11 Бэкенд CherryPy подаёт jquery-1.7.1.min.js как application/javascript без компрессии. Nginx не трогает Content-Type но компрессирует ответ. Браузер конечно-же висит ожидая байтов которые никогда не придут... Простой тест без CherryPy: gzip_comp_level 3; gzip_proxied any; gzip_types text/javascript text/xml application/x-javascript; server { location /js { # Симулируем cherrypy бэкенд gzip off; add_header Content-Type application/javascript; root /tmp; } location /foo { gzip on; proxy_pass http://localhost/js; } } Если добавить application/javascript в gzip_types, то всё работает как положено. From nginx-forum на nginx.us Thu Dec 22 10:07:42 2011 From: nginx-forum на nginx.us (mathead) Date: Thu, 22 Dec 2011 05:07:42 -0500 Subject: php-fpm upstream pool In-Reply-To: References: Message-ID: <10064ecf82ce35ac14c6fb22cb47f20d.NginxMailingListRussian@forum.nginx.org> Доброе время суток! Помогите решить такую проблему! Есть зеркало сайта, расположенное в директории /var/www/htdocs/mirrors/project1/ и vnStat PHP расположенный в директории /var/www/htdocs/vnstat/ пытаюсь заставить одновременно работать php в этих директориях, но пока не получается.Немогу правильно подобрать синтаксис location. по отдельности они у меня работают, так работает php в директории vnstat: location ~* \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME /var/www/htdocs/$fastcgi_script_name; , а так в mirrors location ~* \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME /var/www/htdocs/mirrors/$fastcgi_script_name; Перенести все в одну директорию нельзя, вот тут и начинаются грабли! :( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,219032,220380#msg-220380 From nginx-forum на nginx.us Thu Dec 22 10:27:44 2011 From: nginx-forum на nginx.us (egoryich) Date: Thu, 22 Dec 2011 05:27:44 -0500 Subject: =?UTF-8?B?0KjQsNCx0LvQvtC90Ysg0L7RiNC40LHQvtC6IEhUVFA=?= Message-ID: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> Всем привет. Существуют где-нибудь шаблоны состояний HTTP? Если да, то где? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220382,220382#msg-220382 From citrin на citrin.ru Thu Dec 22 10:31:50 2011 From: citrin на citrin.ru (Anton Yuzhaninov) Date: Thu, 22 Dec 2011 14:31:50 +0400 Subject: gzip error In-Reply-To: <4EF2C705.8030407@gmail.com> References: <4EF2C705.8030407@gmail.com> Message-ID: <4EF30716.8050100@citrin.ru> On 12/22/11 09:58, Konstantin Svist wrote: > > Бэкенд CherryPy подаёт jquery-1.7.1.min.js как application/javascript без > компрессии. > Nginx не трогает Content-Type но компрессирует ответ. Браузер конечно-же висит > ожидая байтов которые никогда не придут... 1. В вашем вопрос не указано с каким URI вы делаете запрос и поэтому не известно в какой location он должен попасть. 2. nginx при сжатии ответа не должен менять Content-Type. Для сжатого ответа указывается Content-Encoding. 3. из приведенного выше непонято каковы заголовки запроса и какие заголовки ответа, и в чем их несоответствие. Приведите пример запроса с заголовки. -- Anton Yuzhaninov From ekruglov на gmail.com Thu Dec 22 12:20:08 2011 From: ekruglov на gmail.com (Kruglov Eugenie) Date: Thu, 22 Dec 2011 15:20:08 +0300 Subject: =?UTF-8?B?UmU6INCo0LDQsdC70L7QvdGLINC+0YjQuNCx0L7QuiBIVFRQ?= In-Reply-To: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> References: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> Message-ID: 2011/12/22 egoryich > Всем привет. > > Существуют где-нибудь шаблоны > состояний HTTP? Если да, то где? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,220382,220382#msg-220382 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru В исходниках. -- Faithfully yours, Eugenie ICQ #701217 GTalk ekruglov на gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum на nginx.us Thu Dec 22 12:52:09 2011 From: nginx-forum на nginx.us (egoryich) Date: Thu, 22 Dec 2011 07:52:09 -0500 Subject: =?UTF-8?B?UmU6INCo0LDQsdC70L7QvdGLINC+0YjQuNCx0L7QuiBIVFRQ?= In-Reply-To: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> References: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> Message-ID: я понимаю что они где-то есть, если не сложно подсказать где в исходниках? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220382,220391#msg-220391 From lvm на citylink-rk.ru Thu Dec 22 13:12:10 2011 From: lvm на citylink-rk.ru (=?KOI8-R?Q?=F7=C1=C4=C9=CD_=EC=C1=DA=CF=D7=D3=CB=C9=CA?=) Date: Thu, 22 Dec 2011 17:12:10 +0400 Subject: =?UTF-8?B?UmU6INCo0LDQsdC70L7QvdGLINC+0YjQuNCx0L7QuiBIVFRQ?= In-Reply-To: References: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> Message-ID: <4EF32CAA.9040807@citylink-rk.ru> 22.12.2011 16:52, egoryich пишет: > я понимаю что они где-то есть, если не > сложно подсказать где в исходниках? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220382,220391#msg-220391 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru А, простите, зачем? Переопределите нужные ошибки при помощи директивы error_page. А хоть на уровне http. http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page From swood на fotofor.biz Thu Dec 22 14:34:51 2011 From: swood на fotofor.biz (Anton Kiryushkin) Date: Thu, 22 Dec 2011 18:34:51 +0400 Subject: proxy_cache_key $http_user_agent In-Reply-To: References: Message-ID: Не найдя других решений сделал lua-вставку. Работает на УРА :) 21 декабря 2011 г. 19:33 пользователь Anton Kiryushkin написал: > Да, так и получилось, спасибо! > > Теперь вторая часть. Допустим в URL есть сессия, то есть урл выглядит > примерно так: > http://site.com/page.html;session=29387492387492837 > Можно ли как-то при кэшировании этот параметр сессии отбрасывать, а > потом при доставании из кэша игнорировать? > > 21 декабря 2011 г. 0:03 пользователь Oleksandr V. Typlyns'kyi > написал: >> Today Dec 20, 2011 at 23:45 Anton Kiryushkin wrote: >> >>> Ну как задавать в общем-то на вкус и цвет...А вот насчет >>> proxy_cache_key, может ли кто-нибудь подсказать с примером такого >>> использования. К сожалению пока что мои эксперименты результата не >>> дали.. >> >>  Просто добавить вместе с другими переменными: >>  http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_key >>  proxy_cache_key $scheme$proxy_host$request_uri$agent; >> >> -- >> WNGS-RIPE >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > Best regards, > Anton Kiryushkin, -- Best regards, Anton Kiryushkin, From fry.kun на gmail.com Thu Dec 22 18:50:30 2011 From: fry.kun на gmail.com (Konstantin Svist) Date: Thu, 22 Dec 2011 10:50:30 -0800 Subject: gzip error In-Reply-To: <4EF30716.8050100@citrin.ru> References: <4EF2C705.8030407@gmail.com> <4EF30716.8050100@citrin.ru> Message-ID: <4EF37BF6.1070608@gmail.com> On 12/22/2011 02:31 AM, Anton Yuzhaninov wrote: > On 12/22/11 09:58, Konstantin Svist wrote: >> >> Бэкенд CherryPy подаёт jquery-1.7.1.min.js как application/javascript >> без >> компрессии. >> Nginx не трогает Content-Type но компрессирует ответ. Браузер >> конечно-же висит >> ожидая байтов которые никогда не придут... > > 1. В вашем вопрос не указано с каким URI вы делаете запрос и поэтому > не известно в какой location он должен попасть. > > 2. nginx при сжатии ответа не должен менять Content-Type. > Для сжатого ответа указывается Content-Encoding. > > 3. из приведенного выше непонято каковы заголовки запроса и какие > заголовки ответа, и в чем их несоответствие. Приведите пример запроса > с заголовки. > Имел ввиду Content-Length и /foo.. но что-то не воспроизводится на другом хосте. Буду искать дальше. From nginx-forum на nginx.us Fri Dec 23 05:46:07 2011 From: nginx-forum на nginx.us (egoryich) Date: Fri, 23 Dec 2011 00:46:07 -0500 Subject: =?UTF-8?B?UmU6INCo0LDQsdC70L7QvdGLINC+0YjQuNCx0L7QuiBIVFRQ?= In-Reply-To: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> References: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> Message-ID: Спасибо всем за ответы. Но все таки, если кто знает где шаблоны ошибок, пусть напишет) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220382,220411#msg-220411 From dedukhin на mail.ru Fri Dec 23 06:16:29 2011 From: dedukhin на mail.ru (Dmitry Dedukhin) Date: Fri, 23 Dec 2011 10:16:29 +0400 Subject: =?UTF-8?B?bmd4X2h0dHBfbGltaXRfY29ubl9tb2R1bGU6INC20YPRh9C+0Log0L/RgNC4INC+?= =?UTF-8?B?0LPRgNCw0L3QuNGH0LXQvdC40Lgg0YHQvtC10LTQuNC90LXQvdC40Lk/?= Message-ID: <4EF41CBD.4000508@mail.ru> Добрый день. CentOS 5. /usr/sbin/nginx -V nginx: nginx version: nginx/1.0.9 nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46) nginx: TLS SNI support disabled nginx: configure arguments: --prefix= --with-poll_module --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin --error-log-path=/var/log/nginx/nginx.error.log --http-log-path=/var/log/nginx/nginx.log --http-client-body-temp-path=/var/spool/nginx/tmp/client --http-proxy-temp-path=/var/spool/nginx/tmp/proxy --http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --user=mail --group=mail --with-http_ssl_module --with-select_module --with-poll_module --with-http_ssl_module --with-md5=YES --with-http_realip_module --with-http_stub_status_module --with-http_sub_module --with-http_addition_module --with-http_dav_module --add-module=./vkholodkov-nginx-upload-module-8d271b1 --add-module=./evanmiller-mod_zip-2657fc8 --add-module=./vkholodkov-nginx-eval-module-125fa2e Кусочек конфига: limit_zone dnl $binary_remote_addr 5m; location /d2/ { ... limit_conn dnl 3; ... } Аптайм nginx'а около месяца: Active connections: 1728 server accepts handled requests 12730717 12730717 12684554 Reading: 28 Writing: 1700 Waiting: 0 Несмотря на заданное в конфиге ограничение в 3 соединения, по крайней мере для одного IP-адреса nginx позволяет только 1 соединение, если больше - возвращает 503 ошибку. Вполне вероятно, что неверное ограничение может действовать и на ряд других IP-адресов, в то время как для большей части ограничение работает корректно. С чем это может быть связано и куда копать? Может ли это быть связано с коллизиями crc32 ? Может ли при каких-то условиях "залипнуть" счетчик lz->conn ? Например, не произошел вызов функции ngx_http_limit_zone_cleanup и, соответственно, декрементирование счетчика, либо наоборот, произошел "лишний" вызов ngx_http_limit_zone_cleanup и счетчик стал равен максимальному u_short ? PS: nginx на этом сервере пока не рестартован, поэтому могу что-то посмотреть, прицепившись через gdb From ne на vbart.ru Fri Dec 23 08:37:23 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 23 Dec 2011 12:37:23 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiAg0LbRg9GH0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <4EF41CBD.4000508@mail.ru> References: <4EF41CBD.4000508@mail.ru> Message-ID: <201112231237.24147.ne@vbart.ru> On Friday 23 December 2011 10:16:29 Dmitry Dedukhin wrote: [...] > > Несмотря на заданное в конфиге ограничение в 3 соединения, по крайней > мере для одного IP-адреса nginx позволяет только 1 соединение, если > больше - возвращает 503 ошибку. [...] Как вы это проверяли? -- Валентин Бартенев From nginx-forum на nginx.us Fri Dec 23 09:31:22 2011 From: nginx-forum на nginx.us (igor.goncharenko) Date: Fri, 23 Dec 2011 04:31:22 -0500 Subject: =?UTF-8?B?dHJ5IGZpbGVzINCy0LzQtdGB0YLQviBpZiAtZg==?= Message-ID: Hi! Прошу прощения, если было уже. Как сделать try_files вместо if -f. Мне нужно выдавать ошибку, если файл _существует_. Сейчас сделал так: location /interface/ { if ( -f /var/nginx/locks/interface.lock ) { return 403; } proxy_pass http://interface_backend; } пробовал вместо if делать: root /var/nginx/locks/; try_files /interface.lock =403; но, соответственно, получил 403 ошибку когда файла не существует. --- Igor Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220414,220414#msg-220414 From dedukhin на mail.ru Fri Dec 23 10:03:00 2011 From: dedukhin на mail.ru (Dmitry Dedukhin) Date: Fri, 23 Dec 2011 14:03:00 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiAg0LbRg9GH0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <201112231237.24147.ne@vbart.ru> References: <4EF41CBD.4000508@mail.ru> <201112231237.24147.ne@vbart.ru> Message-ID: <4EF451D4.4030202@mail.ru> 23.12.2011 12:37, Валентин Бартенев пишет: > On Friday 23 December 2011 10:16:29 Dmitry Dedukhin wrote: > [...] >> Несмотря на заданное в конфиге ограничение в 3 соединения, по крайней >> мере для одного IP-адреса nginx позволяет только 1 соединение, если >> больше - возвращает 503 ошибку. > [...] > > Как вы это проверяли? Пользователь в DownloadMaster'е запускал скачивание файла (в один поток), при попытке запустить еще одно скачивание получал в ответ ошибку (html-страницу вместо файла). По факту, при срабатывании ограничения вместо 503 кода отдается 200 код и html-страница, т.к. в конфиге на уровне server стоит обработчик: error_page 503 = /503.html; location = /503.html { alias /path/to/error503.html; } From ne на vbart.ru Fri Dec 23 10:34:10 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 23 Dec 2011 14:34:10 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiAg0LbRg9GH0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <4EF451D4.4030202@mail.ru> References: <4EF41CBD.4000508@mail.ru> <201112231237.24147.ne@vbart.ru> <4EF451D4.4030202@mail.ru> Message-ID: <201112231434.10626.ne@vbart.ru> On Friday 23 December 2011 14:03:00 Dmitry Dedukhin wrote: > 23.12.2011 12:37, Валентин Бартенев пишет: > > On Friday 23 December 2011 10:16:29 Dmitry Dedukhin wrote: > > [...] > > > >> Несмотря на заданное в конфиге ограничение в 3 соединения, по крайней > >> мере для одного IP-адреса nginx позволяет только 1 соединение, если > >> больше - возвращает 503 ошибку. > > > > [...] > > > > Как вы это проверяли? > > Пользователь в DownloadMaster'е запускал скачивание файла (в один > поток), при попытке запустить еще одно скачивание получал в ответ ошибку > (html-страницу вместо файла). > По факту, при срабатывании ограничения вместо 503 кода отдается 200 код > и html-страница, т.к. в конфиге на уровне server стоит обработчик: > [...] К сожалению, это не может служить индикатором наличия какой-либо проблемы. DownloadMaster - сложная проприетарная качалка, с закрытыми исходниками. Сколько она реально делает запросов и почему сработало ограничения мог бы показать debug log. По факту, у меня большие сомнения, что для старта закачки она делает всего один запрос, а не сразу несколько. В её настройках можно обнаружить такие опции, как "Получать размер файла при добавлении закачки", "Вывести содержание ZIP архива". Плюс, неизвестно какие там могут ещё скрываться баги. К тому же, вы сами усугубили ситуацию тем, что выдаете 200-ый код и качалка не имеет никакой возможности узнать о том, что запрос закончился неудачно. -- Валентин Бартенев From dedukhin на mail.ru Fri Dec 23 10:45:19 2011 From: dedukhin на mail.ru (Dmitry Dedukhin) Date: Fri, 23 Dec 2011 14:45:19 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiAg0LbRg9GH0L7QuiDQv9GA?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <201112231434.10626.ne@vbart.ru> References: <4EF41CBD.4000508@mail.ru> <201112231237.24147.ne@vbart.ru> <4EF451D4.4030202@mail.ru> <201112231434.10626.ne@vbart.ru> Message-ID: <4EF45BBF.4080600@mail.ru> 23.12.2011 14:34, Валентин Бартенев пишет: > On Friday 23 December 2011 14:03:00 Dmitry Dedukhin wrote: >> 23.12.2011 12:37, Валентин Бартенев пишет: >>> On Friday 23 December 2011 10:16:29 Dmitry Dedukhin wrote: >>> [...] >>> >>>> Несмотря на заданное в конфиге ограничение в 3 соединения, по крайней >>>> мере для одного IP-адреса nginx позволяет только 1 соединение, если >>>> больше - возвращает 503 ошибку. >>> [...] >>> >>> Как вы это проверяли? >> Пользователь в DownloadMaster'е запускал скачивание файла (в один >> поток), при попытке запустить еще одно скачивание получал в ответ ошибку >> (html-страницу вместо файла). >> По факту, при срабатывании ограничения вместо 503 кода отдается 200 код >> и html-страница, т.к. в конфиге на уровне server стоит обработчик: >> > [...] > > К сожалению, это не может служить индикатором наличия какой-либо проблемы. > > DownloadMaster - сложная проприетарная качалка, с закрытыми исходниками. > Сколько она реально делает запросов и почему сработало ограничения мог > бы показать debug log. По факту, у меня большие сомнения, что для старта > закачки она делает всего один запрос, а не сразу несколько. В её настройках > можно обнаружить такие опции, как "Получать размер файла при добавлении > закачки", "Вывести содержание ZIP архива". Плюс, неизвестно какие там могут > ещё скрываться баги. > > К тому же, вы сами усугубили ситуацию тем, что выдаете 200-ый код и качалка > не имеет никакой возможности узнать о том, что запрос закончился неудачно. Я грепал этот IP по access-логу nginx'а в тот же день, и поэтому могу с уверенностью сказать, что лишних запросов не было. К сожалению, в данный момент не располагаю дебаг-логом, но попробую его получить. From ekruglov на gmail.com Fri Dec 23 11:57:56 2011 From: ekruglov на gmail.com (Kruglov Eugenie) Date: Fri, 23 Dec 2011 14:57:56 +0300 Subject: =?UTF-8?B?UmU6IHRyeSBmaWxlcyDQstC80LXRgdGC0L4gaWYgLWY=?= In-Reply-To: References: Message-ID: Сделай error_page 200 2011/12/23 igor.goncharenko > Hi! > > Прошу прощения, если было уже. Как > сделать try_files вместо if -f. Мне нужно > выдавать ошибку, если файл _существует_. > Сейчас сделал так: > > location /interface/ > { > if ( -f /var/nginx/locks/interface.lock ) { return 403; } > proxy_pass http://interface_backend; > } > > пробовал вместо if делать: > root /var/nginx/locks/; > try_files /interface.lock =403; > > но, соответственно, получил 403 ошибку > когда файла не существует. > > > --- > Igor > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,220414,220414#msg-220414 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Faithfully yours, Eugenie ICQ #701217 GTalk ekruglov на gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Fri Dec 23 12:05:30 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 23 Dec 2011 16:05:30 +0400 Subject: =?UTF-8?B?UmU6INCo0LDQsdC70L7QvdGLINC+0YjQuNCx0L7QuiBIVFRQ?= In-Reply-To: References: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> Message-ID: <20111223120530.GJ67687@mdounin.ru> Hello! On Fri, Dec 23, 2011 at 12:46:07AM -0500, egoryich wrote: > Спасибо всем за ответы. > Но все таки, если кто знает где шаблоны > ошибок, пусть напишет) Вот тут хорошие: http://www.flickr.com/photos/apelad/sets/72157594388426362/ ;) Maxim Dounin From mdounin на mdounin.ru Fri Dec 23 12:23:37 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 23 Dec 2011 16:23:37 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiDQttGD0YfQvtC6INC/0YA=?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <4EF41CBD.4000508@mail.ru> References: <4EF41CBD.4000508@mail.ru> Message-ID: <20111223122337.GL67687@mdounin.ru> Hello! On Fri, Dec 23, 2011 at 10:16:29AM +0400, Dmitry Dedukhin wrote: > Добрый день. > > CentOS 5. > > /usr/sbin/nginx -V > > nginx: nginx version: nginx/1.0.9 > nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46) > nginx: TLS SNI support disabled > nginx: configure arguments: --prefix= --with-poll_module > --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin > --error-log-path=/var/log/nginx/nginx.error.log > --http-log-path=/var/log/nginx/nginx.log > --http-client-body-temp-path=/var/spool/nginx/tmp/client > --http-proxy-temp-path=/var/spool/nginx/tmp/proxy > --http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi > --pid-path=/var/run/nginx.pid --user=mail --group=mail > --with-http_ssl_module --with-select_module --with-poll_module > --with-http_ssl_module --with-md5=YES --with-http_realip_module > --with-http_stub_status_module --with-http_sub_module > --with-http_addition_module --with-http_dav_module > --add-module=./vkholodkov-nginx-upload-module-8d271b1 > --add-module=./evanmiller-mod_zip-2657fc8 > --add-module=./vkholodkov-nginx-eval-module-125fa2e > > Кусочек конфига: > > limit_zone dnl $binary_remote_addr 5m; > location /d2/ { > ... > limit_conn dnl 3; > ... > } > > Аптайм nginx'а около месяца: > > Active connections: 1728 > server accepts handled requests > 12730717 12730717 12684554 > Reading: 28 Writing: 1700 Waiting: 0 > > Несмотря на заданное в конфиге ограничение в 3 соединения, по > крайней мере для одного IP-адреса nginx позволяет только 1 > соединение, если больше - возвращает 503 ошибку. > Вполне вероятно, что неверное ограничение может действовать и на ряд > других IP-адресов, в то время как для большей части ограничение > работает корректно. > > С чем это может быть связано и куда копать? > Может ли это быть связано с коллизиями crc32 ? > Может ли при каких-то условиях "залипнуть" счетчик lz->conn ? > Например, не произошел вызов функции ngx_http_limit_zone_cleanup и, > соответственно, декрементирование счетчика, либо наоборот, произошел > "лишний" вызов ngx_http_limit_zone_cleanup и счетчик стал равен > максимальному u_short ? > > PS: nginx на этом сервере пока не рестартован, поэтому могу что-то > посмотреть, прицепившись через gdb grep -f '[alert]' /path/to/error/logs Скорее всего за прошедший месяц рабочие процессы падали и/или их некорректно убивали, в результате в зоне не были уменьшены счётчики соединений. Очистить счётчики можно с помощью процедуры обновления исполняемого файла на лету. Maxim Dounin From gmm на csdoc.com Fri Dec 23 12:25:49 2011 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 23 Dec 2011 14:25:49 +0200 Subject: =?UTF-8?B?UmU6INCo0LDQsdC70L7QvdGLINC+0YjQuNCx0L7QuiBIVFRQ?= In-Reply-To: <20111223120530.GJ67687@mdounin.ru> References: <313f61d9c01ff0f9b4322a5d56c6bbc1.NginxMailingListRussian@forum.nginx.org> <20111223120530.GJ67687@mdounin.ru> Message-ID: <4EF4734D.1030500@csdoc.com> On 23.12.2011 14:05, Maxim Dounin wrote: >> Спасибо всем за ответы. >> Но все таки, если кто знает где шаблоны >> ошибок, пусть напишет) > Вот тут хорошие: > http://www.flickr.com/photos/apelad/sets/72157594388426362/ вот тут тоже неплохие: http://miumau.livejournal.com/901636.html -- Best regards, Gena From dedukhin на mail.ru Fri Dec 23 12:39:12 2011 From: dedukhin на mail.ru (Dmitry Dedukhin) Date: Fri, 23 Dec 2011 16:39:12 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiDQttGD0YfQvtC6INC/0YA=?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <20111223122337.GL67687@mdounin.ru> References: <4EF41CBD.4000508@mail.ru> <20111223122337.GL67687@mdounin.ru> Message-ID: <4EF47670.8010409@mail.ru> 23.12.2011 16:23, Maxim Dounin пишет: > Hello! > > On Fri, Dec 23, 2011 at 10:16:29AM +0400, Dmitry Dedukhin wrote: > >> Добрый день. >> >> CentOS 5. >> >> /usr/sbin/nginx -V >> >> nginx: nginx version: nginx/1.0.9 >> nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46) >> nginx: TLS SNI support disabled >> nginx: configure arguments: --prefix= --with-poll_module >> --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin >> --error-log-path=/var/log/nginx/nginx.error.log >> --http-log-path=/var/log/nginx/nginx.log >> --http-client-body-temp-path=/var/spool/nginx/tmp/client >> --http-proxy-temp-path=/var/spool/nginx/tmp/proxy >> --http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi >> --pid-path=/var/run/nginx.pid --user=mail --group=mail >> --with-http_ssl_module --with-select_module --with-poll_module >> --with-http_ssl_module --with-md5=YES --with-http_realip_module >> --with-http_stub_status_module --with-http_sub_module >> --with-http_addition_module --with-http_dav_module >> --add-module=./vkholodkov-nginx-upload-module-8d271b1 >> --add-module=./evanmiller-mod_zip-2657fc8 >> --add-module=./vkholodkov-nginx-eval-module-125fa2e >> >> Кусочек конфига: >> >> limit_zone dnl $binary_remote_addr 5m; >> location /d2/ { >> ... >> limit_conn dnl 3; >> ... >> } >> >> Аптайм nginx'а около месяца: >> >> Active connections: 1728 >> server accepts handled requests >> 12730717 12730717 12684554 >> Reading: 28 Writing: 1700 Waiting: 0 >> >> Несмотря на заданное в конфиге ограничение в 3 соединения, по >> крайней мере для одного IP-адреса nginx позволяет только 1 >> соединение, если больше - возвращает 503 ошибку. >> Вполне вероятно, что неверное ограничение может действовать и на ряд >> других IP-адресов, в то время как для большей части ограничение >> работает корректно. >> >> С чем это может быть связано и куда копать? >> Может ли это быть связано с коллизиями crc32 ? >> Может ли при каких-то условиях "залипнуть" счетчик lz->conn ? >> Например, не произошел вызов функции ngx_http_limit_zone_cleanup и, >> соответственно, декрементирование счетчика, либо наоборот, произошел >> "лишний" вызов ngx_http_limit_zone_cleanup и счетчик стал равен >> максимальному u_short ? >> >> PS: nginx на этом сервере пока не рестартован, поэтому могу что-то >> посмотреть, прицепившись через gdb > grep -f '[alert]' /path/to/error/logs > > Скорее всего за прошедший месяц рабочие процессы падали и/или их > некорректно убивали, в результате в зоне не были уменьшены > счётчики соединений. > > Очистить счётчики можно с помощью процедуры обновления > исполняемого файла на лету. В логе куча записей вида: 2011/12/23 00:00:41 [error] 2734#0: *22996338 limiting connections by zone "dnl" while sending to client ... может что-то конкретное надо искать? Кстати, почему директива limit_conn_log_level warn; не подавляет эти записи в еррор-логе? Или я не так понял её? error_log /path/to/error.log error; server { ... limit_conn_log_level warn; location /d2/ { ... limit_conn dnl 3; ... } } From mdounin на mdounin.ru Fri Dec 23 13:33:49 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 23 Dec 2011 17:33:49 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiDQttGD0YfQvtC6INC/0YA=?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: <4EF47670.8010409@mail.ru> References: <4EF41CBD.4000508@mail.ru> <20111223122337.GL67687@mdounin.ru> <4EF47670.8010409@mail.ru> Message-ID: <20111223133348.GO67687@mdounin.ru> Hello! On Fri, Dec 23, 2011 at 04:39:12PM +0400, Dmitry Dedukhin wrote: > 23.12.2011 16:23, Maxim Dounin пишет: > >Hello! > > > >On Fri, Dec 23, 2011 at 10:16:29AM +0400, Dmitry Dedukhin wrote: > > > >>Добрый день. > >> > >>CentOS 5. > >> > >>/usr/sbin/nginx -V > >> > >>nginx: nginx version: nginx/1.0.9 > >>nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46) > >>nginx: TLS SNI support disabled > >>nginx: configure arguments: --prefix= --with-poll_module > >>--conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin > >>--error-log-path=/var/log/nginx/nginx.error.log > >>--http-log-path=/var/log/nginx/nginx.log > >>--http-client-body-temp-path=/var/spool/nginx/tmp/client > >>--http-proxy-temp-path=/var/spool/nginx/tmp/proxy > >>--http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi > >>--pid-path=/var/run/nginx.pid --user=mail --group=mail > >>--with-http_ssl_module --with-select_module --with-poll_module > >>--with-http_ssl_module --with-md5=YES --with-http_realip_module > >>--with-http_stub_status_module --with-http_sub_module > >>--with-http_addition_module --with-http_dav_module > >>--add-module=./vkholodkov-nginx-upload-module-8d271b1 > >>--add-module=./evanmiller-mod_zip-2657fc8 > >>--add-module=./vkholodkov-nginx-eval-module-125fa2e > >> > >>Кусочек конфига: > >> > >>limit_zone dnl $binary_remote_addr 5m; > >>location /d2/ { > >> ... > >> limit_conn dnl 3; > >> ... > >>} > >> > >>Аптайм nginx'а около месяца: > >> > >>Active connections: 1728 > >>server accepts handled requests > >> 12730717 12730717 12684554 > >>Reading: 28 Writing: 1700 Waiting: 0 > >> > >>Несмотря на заданное в конфиге ограничение в 3 соединения, по > >>крайней мере для одного IP-адреса nginx позволяет только 1 > >>соединение, если больше - возвращает 503 ошибку. > >>Вполне вероятно, что неверное ограничение может действовать и на ряд > >>других IP-адресов, в то время как для большей части ограничение > >>работает корректно. > >> > >>С чем это может быть связано и куда копать? > >>Может ли это быть связано с коллизиями crc32 ? > >>Может ли при каких-то условиях "залипнуть" счетчик lz->conn ? > >>Например, не произошел вызов функции ngx_http_limit_zone_cleanup и, > >>соответственно, декрементирование счетчика, либо наоборот, произошел > >>"лишний" вызов ngx_http_limit_zone_cleanup и счетчик стал равен > >>максимальному u_short ? > >> > >>PS: nginx на этом сервере пока не рестартован, поэтому могу что-то > >>посмотреть, прицепившись через gdb > >grep -f '[alert]' /path/to/error/logs s/-f/-F/ > >Скорее всего за прошедший месяц рабочие процессы падали и/или их > >некорректно убивали, в результате в зоне не были уменьшены > >счётчики соединений. > > > >Очистить счётчики можно с помощью процедуры обновления > >исполняемого файла на лету. > > В логе куча записей вида: > > 2011/12/23 00:00:41 [error] 2734#0: *22996338 limiting connections > by zone "dnl" while sending to client ... > > может что-то конкретное надо искать? Нужно искать alert'ы. Если я прав - должно быть про 'worker process N exited on signal M'. > Кстати, почему директива limit_conn_log_level warn; не подавляет эти > записи в еррор-логе? Или я не так понял её? > > error_log /path/to/error.log error; > server { > ... > limit_conn_log_level warn; > location /d2/ { > ... > limit_conn dnl 3; > ... > } > } Это ошибка, директива limit_conn_log_level сейчас работает только если указана на уровне http или вместе с директивой limit_conn. Где-то у Валентина есть патч, в ближайшее время закоммитим. Maxim Dounin From xinu на list.ru Fri Dec 23 15:03:13 2011 From: xinu на list.ru (=?UTF-8?B?eGludQ==?=) Date: Fri, 23 Dec 2011 19:03:13 +0400 Subject: =?UTF-8?B?0LjQt9C80LXQvdC10L3QuNC1IGxvZ19mb3JtYXQgKyAnLXMgcmVsb2FkIC8gcmVv?= =?UTF-8?B?cGVuJyAg0L3QtSDQv9GA0LjQstC+0LTQuNGCINC6INC40LfQvNC10L3QtdC9?= =?UTF-8?B?0LjRjiDQu9C+0LPQsA==?= Message-ID: добрый день, изменение log_format + '-s reload / reopen' не приводит к изменению лога, после stop / start - лог в новом формате. ето фитча или я чего то не дочитал в документации? спасибо. ps: log_format - задекларирован на уровне http access_log - стоит на уровне server nginx -V nginx version: nginx/1.1.11 TLS SNI support disabled configure arguments: --prefix=xxxxx --with-http_ssl_module --with-http_realip_module --with-http_gzip_static_module --with-http_perl_module --with-pcre --with-debug ?? From citrin на citrin.ru Fri Dec 23 15:05:37 2011 From: citrin на citrin.ru (Anton Yuzhaninov) Date: Fri, 23 Dec 2011 19:05:37 +0400 Subject: =?UTF-8?B?UmU6INC40LfQvNC10L3QtdC90LjQtSBsb2dfZm9ybWF0ICsgJy1zIHJlbG9hZCAv?= =?UTF-8?B?IHJlb3BlbicgINC90LUg0L/RgNC40LLQvtC00LjRgiDQuiDQuNC30LzQtdC9?= =?UTF-8?B?0LXQvdC40Y4g0LvQvtCz0LA=?= In-Reply-To: References: Message-ID: <4EF498C1.3010105@citrin.ru> On 12/23/11 19:03, xinu wrote: > изменение log_format + '-s reload / reopen' не приводит к изменению лога, после stop / start - лог в новом формате. > ето фитча или я чего то не дочитал в документации? смотрите что пишется в error_log в момент reload -- Anton Yuzhaninov From xinu на list.ru Fri Dec 23 16:44:08 2011 From: xinu на list.ru (=?UTF-8?B?eGludQ==?=) Date: Fri, 23 Dec 2011 20:44:08 +0400 Subject: =?UTF-8?B?UmVbMl06INC40LfQvNC10L3QtdC90LjQtSBsb2dfZm9ybWF0ICsgJy1zIHJlbG9h?= =?UTF-8?B?ZCAvIHJlb3BlbicgINC90LUg0L/RgNC40LLQvtC00LjRgiDQuiDQuNC30Lw=?= =?UTF-8?B?0LXQvdC10L3QuNGOINC70L7Qs9Cw?= In-Reply-To: <4EF498C1.3010105@citrin.ru> References: <4EF498C1.3010105@citrin.ru> Message-ID: спасибо, да - вы правы, reload, очевидно не происходит вообще. ++++ # /хх/nginx -s reload Enter PEM pass phrase: # fg tail -f /хх/logs/error.log 2011/12/23 17:42:10 [notice] 21242#0: signal process started Enter PEM pass phrase: 2011/12/23 17:42:11 [emerg] 21180#0: SSL_CTX_use_PrivateKey_file("/хххх.key") failed (SSL: error:0906406D:PEM routines:PEM_def_callback:problems getting password error:0906A068:PEM routines:PEM_do_header:bad password read error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib) ++++ start / stop / reopen - (с той же passphrasе) проходят без проблем: +++ # /xx/sbin/nginx -s stop Enter PEM pass phrase: Enter PEM pass phrase: # fg tail -f /xx/logs/error.log 2011/12/23 17:24:40 [notice] 20923#0: signal process started [5]+ Stopped tail -f /xx/logs/error.log # /xx/sbin/nginx Enter PEM pass phrase: Enter PEM pass phrase: # fg tail -f /xxx/logs/error.log [5]+ Stopped tail -f /xx/logs/error.log +++ что мешает reload'у ? спасибо, Сергей > смотрите что пишется в error_log в момент reload > > -- > Anton Yuzhaninov > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From marck на rinet.ru Fri Dec 23 21:13:18 2011 From: marck на rinet.ru (Dmitry Morozovsky) Date: Sat, 24 Dec 2011 01:13:18 +0400 (MSK) Subject: =?UTF-8?B?UmVbMl06INC40LfQvNC10L3QtdC90LjQtSBsb2dfZm9ybWF0ICsgJy1zIHJlbG9h?= =?UTF-8?B?ZCAvIHJlb3BlbicgINC90LUg0L/RgNC40LLQvtC00LjRgiDQuiDQuNC30Lw=?= =?UTF-8?B?0LXQvdC10L3QuNGOINC70L7Qs9Cw?= In-Reply-To: References: <4EF498C1.3010105@citrin.ru> Message-ID: On Fri, 23 Dec 2011, xinu wrote: > спасибо, > да - вы правы, reload, очевидно не происходит вообще. > > 2011/12/23 17:42:10 [notice] 21242#0: signal process started Enter PEM pass > phrase: 2011/12/23 17:42:11 [emerg] 21180#0: > SSL_CTX_use_PrivateKey_file("/хххх.key") failed (SSL: error:0906406D:PEM > routines:PEM_def_callback:problems getting password error:0906A068:PEM > routines:PEM_do_header:bad password read error:140B0009:SSL > routines:SSL_CTX_use_PrivateKey_file:PEM lib) ++++ > > что мешает reload'у ? отсутствие терминала у главного процесса, а стало быть, невозможность прочитать пассфразу для ключа (неоткуда) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck на FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck на rinet.ru *** ------------------------------------------------------------------------ From dedukhin на mail.ru Sat Dec 24 06:48:47 2011 From: dedukhin на mail.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JTQtdC00Y7RhdC40L0=?=) Date: Sat, 24 Dec 2011 10:48:47 +0400 Subject: =?UTF-8?B?UmVbMl06IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiDQttGD0YfQvtC6INC/?= =?UTF-8?B?0YDQuCDQvtCz0YDQsNC90LjRh9C10L3QuNC4INGB0L7QtdC00LjQvdC10L0=?= =?UTF-8?B?0LjQuT8=?= In-Reply-To: <20111223133348.GO67687@mdounin.ru> References: <4EF41CBD.4000508@mail.ru> <4EF47670.8010409@mail.ru> <20111223133348.GO67687@mdounin.ru> Message-ID: 23 декабря 2011, 17:34 от Maxim Dounin : > Hello! > > On Fri, Dec 23, 2011 at 04:39:12PM +0400, Dmitry Dedukhin wrote: > > > 23.12.2011 16:23, Maxim Dounin пишет: > > >Hello! > > > > > >On Fri, Dec 23, 2011 at 10:16:29AM +0400, Dmitry Dedukhin wrote: > > > > > >>Добрый день. > > >> > > >>CentOS 5. > > >> > > >>/usr/sbin/nginx -V > > >> > > >>nginx: nginx version: nginx/1.0.9 > > >>nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46) > > >>nginx: TLS SNI support disabled > > >>nginx: configure arguments: --prefix= --with-poll_module > > >>--conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin > > >>--error-log-path=/var/log/nginx/nginx.error.log > > >>--http-log-path=/var/log/nginx/nginx.log > > >>--http-client-body-temp-path=/var/spool/nginx/tmp/client > > >>--http-proxy-temp-path=/var/spool/nginx/tmp/proxy > > >>--http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi > > >>--pid-path=/var/run/nginx.pid --user=mail --group=mail > > >>--with-http_ssl_module --with-select_module --with-poll_module > > >>--with-http_ssl_module --with-md5=YES --with-http_realip_module > > >>--with-http_stub_status_module --with-http_sub_module > > >>--with-http_addition_module --with-http_dav_module > > >>--add-module=./vkholodkov-nginx-upload-module-8d271b1 > > >>--add-module=./evanmiller-mod_zip-2657fc8 > > >>--add-module=./vkholodkov-nginx-eval-module-125fa2e > > >> > > >>Кусочек конфига: > > >> > > >>limit_zone dnl $binary_remote_addr 5m; > > >>location /d2/ { > > >> ... > > >> limit_conn dnl 3; > > >> ... > > >>} > > >> > > >>Аптайм nginx'а около месяца: > > >> > > >>Active connections: 1728 > > >>server accepts handled requests > > >> 12730717 12730717 12684554 > > >>Reading: 28 Writing: 1700 Waiting: 0 > > >> > > >>Несмотря на заданное в конфиге ограничение в 3 соединения, по > > >>крайней мере для одного IP-адреса nginx позволяет только 1 > > >>соединение, если больше - возвращает 503 ошибку. > > >>Вполне вероятно, что неверное ограничение может действовать и на ряд > > >>других IP-адресов, в то время как для большей части ограничение > > >>работает корректно. > > >> > > >>С чем это может быть связано и куда копать? > > >>Может ли это быть связано с коллизиями crc32 ? > > >>Может ли при каких-то условиях "залипнуть" счетчик lz->conn ? > > >>Например, не произошел вызов функции ngx_http_limit_zone_cleanup и, > > >>соответственно, декрементирование счетчика, либо наоборот, произошел > > >>"лишний" вызов ngx_http_limit_zone_cleanup и счетчик стал равен > > >>максимальному u_short ? > > >> > > >>PS: nginx на этом сервере пока не рестартован, поэтому могу что-то > > >>посмотреть, прицепившись через gdb > > >grep -f '[alert]' /path/to/error/logs > > s/-f/-F/ > > > >Скорее всего за прошедший месяц рабочие процессы падали и/или их > > >некорректно убивали, в результате в зоне не были уменьшены > > >счётчики соединений. > > > > > >Очистить счётчики можно с помощью процедуры обновления > > >исполняемого файла на лету. > > > > В логе куча записей вида: > > > > 2011/12/23 00:00:41 [error] 2734#0: *22996338 limiting connections > > by zone "dnl" while sending to client ... > > > > может что-то конкретное надо искать? > > Нужно искать alert'ы. Если я прав - должно быть про 'worker > process N exited on signal M'. > > > Кстати, почему директива limit_conn_log_level warn; не подавляет эти > > записи в еррор-логе? Или я не так понял её? > > > > error_log /path/to/error.log error; > > server { > > ... > > limit_conn_log_level warn; > > location /d2/ { > > ... > > limit_conn dnl 3; > > ... > > } > > } > > Это ошибка, директива limit_conn_log_level сейчас работает только > если указана на уровне http или вместе с директивой limit_conn. > Где-то у Валентина есть патч, в ближайшее время закоммитим. > Прошу прощения, в первый раз не заметил, что грепал не то, что нужно. Максим, похоже вы правы, за декабрь в логе этого сервера есть 33 сообщения вида: 2011/12/23 16:30:12 [alert] 11692#0: worker process 9711 exited on signal 11 From ne на vbart.ru Sat Dec 24 13:14:46 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 24 Dec 2011 17:14:46 +0400 Subject: php-fpm upstream pool In-Reply-To: <10064ecf82ce35ac14c6fb22cb47f20d.NginxMailingListRussian@forum.nginx.org> References: <10064ecf82ce35ac14c6fb22cb47f20d.NginxMailingListRussian@forum.nginx.org> Message-ID: <201112241714.46486.ne@vbart.ru> On Thursday 22 December 2011 14:07:42 mathead wrote: > Доброе время суток! > Помогите решить такую проблему! > Есть зеркало сайта, расположенное в > директории > /var/www/htdocs/mirrors/project1/ > и vnStat PHP расположенный в директории > /var/www/htdocs/vnstat/ > пытаюсь заставить одновременно > работать php в этих директориях, но пока > не получается.Немогу правильно > подобрать синтаксис location. > > по отдельности они у меня работают, > так работает php в директории vnstat: > location ~* \.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME > /var/www/htdocs/$fastcgi_script_name; > , а так в mirrors > location ~* \.php$ { > fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > include fastcgi_params; > fastcgi_param SCRIPT_FILENAME > /var/www/htdocs/mirrors/$fastcgi_script_name; > > Перенести все в одну директорию нельзя, > вот тут и начинаются грабли! :( > location ~* \.php$ { root /var/www/htdocs; try_files $uri /mirrors$uri =404; fastcgi_pass 127.0.0.1:9000; include fastcgi.conf; } -- Валентин Бартенев From mdounin на mdounin.ru Sun Dec 25 05:45:03 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 25 Dec 2011 09:45:03 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX2xpbWl0X2Nvbm5fbW9kdWxlOiDQttGD0YfQvtC6INC/0YA=?= =?UTF-8?B?0Lgg0L7Qs9GA0LDQvdC40YfQtdC90LjQuCDRgdC+0LXQtNC40L3QtdC90Lg=?= =?UTF-8?B?0Lk/?= In-Reply-To: References: <4EF41CBD.4000508@mail.ru> <4EF47670.8010409@mail.ru> <20111223133348.GO67687@mdounin.ru> Message-ID: <20111225054503.GA67687@mdounin.ru> Hello! On Sat, Dec 24, 2011 at 10:48:47AM +0400, Дмитрий Дедюхин wrote: > 23 декабря 2011, 17:34 от Maxim Dounin : > > Hello! > > > > On Fri, Dec 23, 2011 at 04:39:12PM +0400, Dmitry Dedukhin wrote: > > > > > 23.12.2011 16:23, Maxim Dounin пишет: > > > >Hello! > > > > > > > >On Fri, Dec 23, 2011 at 10:16:29AM +0400, Dmitry Dedukhin wrote: > > > > > > > >>Добрый день. > > > >> > > > >>CentOS 5. > > > >> > > > >>/usr/sbin/nginx -V > > > >> > > > >>nginx: nginx version: nginx/1.0.9 > > > >>nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46) > > > >>nginx: TLS SNI support disabled > > > >>nginx: configure arguments: --prefix= --with-poll_module > > > >>--conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin > > > >>--error-log-path=/var/log/nginx/nginx.error.log > > > >>--http-log-path=/var/log/nginx/nginx.log > > > >>--http-client-body-temp-path=/var/spool/nginx/tmp/client > > > >>--http-proxy-temp-path=/var/spool/nginx/tmp/proxy > > > >>--http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi > > > >>--pid-path=/var/run/nginx.pid --user=mail --group=mail > > > >>--with-http_ssl_module --with-select_module --with-poll_module > > > >>--with-http_ssl_module --with-md5=YES --with-http_realip_module > > > >>--with-http_stub_status_module --with-http_sub_module > > > >>--with-http_addition_module --with-http_dav_module > > > >>--add-module=./vkholodkov-nginx-upload-module-8d271b1 > > > >>--add-module=./evanmiller-mod_zip-2657fc8 > > > >>--add-module=./vkholodkov-nginx-eval-module-125fa2e [...] > Максим, похоже вы правы, за декабрь в логе этого сервера есть 33 сообщения вида: > 2011/12/23 16:30:12 [alert] 11692#0: worker process 9711 exited on signal 11 Обновиться до 1.0.11 (а лучше - до 1.1.11), если не поможет - получать корку и присылать backtrace. Желательно без сторониих модулей. Подробности тут: http://wiki.nginx.org/Debugging Maxim Dounin From nginx-forum на nginx.us Sun Dec 25 10:15:32 2011 From: nginx-forum на nginx.us (kuchumovn) Date: Sun, 25 Dec 2011 05:15:32 -0500 Subject: =?UTF-8?B?W9Cf0YDQtdC00LvQvtC20LXQvdC40LVdINCc0L7QttC10YIg0LHRi9GC0Ywg0YE=?= =?UTF-8?B?0YLQvtC40YIg0YHQtNC10LvQsNGC0Ywg0LLRi9Cy0L7QtCBVUkwn0L7QsiA=?= =?UTF-8?B?0LIgYWNjZXNzIGxvZyDQv9GA0LXQtNCy0LDRgNC40YLQtdC70YzQvdC+INC0?= =?UTF-8?B?0LXQutC+0LTQuNGA0L7QstCw0L3QvdGL0LzQuD8=?= Message-ID: <389500f5cb5b12ad67582862e0c61124.NginxMailingListRussian@forum.nginx.org> Пример. Я пишу сайт с русскими человеко-понятными УРЛами. В частности, есть вот такой запрос: http://localhost:8081/приложение/люди?с=1&сколько=8 Который отображается в access_log'е в таком виде: 127.0.0.1 - - [25/Dec/2011:14:09:03 +0400] "GET /%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5/%D0%BB%D1%8E%D0%B4%D0%B8?%D1%81=1&%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE=8 HTTP/1.1" 200 474 "http://localhost:8081/%D0%BB%D1%8E%D0%B4%D0%B8" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1" Моё предложение: может быть стоит, перед выводом этого УРЛа в access_log, предварительно его пропускать через что-то наподобие decodeURI в яваскрипте? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220458,220458#msg-220458 From nginx-forum на nginx.us Sun Dec 25 11:59:48 2011 From: nginx-forum на nginx.us (next40) Date: Sun, 25 Dec 2011 06:59:48 -0500 Subject: nginx+upload progress Message-ID: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Добрый день, помогите пожалуйста разобраться с настройкой данной связки...... вопросы: файл загружает и сохраняет скрипт(php) или сам nginx? не пойму как правильно настроить..... OS Gentoo Linux nginx/1.0.10(собран с поддержкой upload module и uploadprogress module)+php5.3(c поддержкой pecl-uploadprogress) использую скрипт на ajax для теста, вот форма:
 
Конфиг nginx: server { listen *:80 default; server_name uploads; access_log /var/log/nginx/localhost.access_log main; error_log /var/log/nginx/localhost.error_log info; root /var/www/localhost/htdocs; charset windows-1251; location ~ \.php$ { fastcgi_connect_timeout 90; fastcgi_send_timeout 60; fastcgi_read_timeout 120; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } upload_store /tmp 1; upload_set_form_field "${upload_field_name}_name" "$upload_file_name"; upload_set_form_field "${upload_field_name}_content_type" "$upload_content_type"; upload_set_form_field "${upload_field_name}_path" "$upload_tmp_path"; upload_pass_form_field "^submit$"; location = /upload { upload_pass /internal_upload; track_uploads proxied 30s; } location ^~ /progress { # report uploads tracked in the 'proxied' zone report_uploads proxied; } } } Результат: 405 Not Allowed В логах: 2011/12/25 16:16:49 [error] 28776#0: *59 failed to create output file "/tmp/0/0000000010" for "FW_TEW-652BRP_V1(1.10b08).zip" (2: No such file or directory), client: 192.168.91.190, server: uploads, request: "POST /upload?X-Progress-ID=e23800c2a6644532b847d983f6adfb2d HTTP/1.0", host: "10.77.88.243", referrer: "http://10.77.88.243/upload.html" 2011/12/25 16:17:05 [info] 28776#0: *61 client closed prematurely connection while reading client request line, client: 192.168.91.190, server: uploads Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220460#msg-220460 From nefer05 на gmail.com Sun Dec 25 12:04:47 2011 From: nefer05 на gmail.com (=?KOI8-R?B?8s/Nwc4g7c/Ty9fJ1MnO?=) Date: Sun, 25 Dec 2011 16:04:47 +0400 Subject: =?UTF-8?B?UmU6IFvQn9GA0LXQtNC70L7QttC10L3QuNC1XSDQnNC+0LbQtdGCINCx0YvRgtGM?= =?UTF-8?B?INGB0YLQvtC40YIg0YHQtNC10LvQsNGC0Ywg0LLRi9Cy0L7QtCBVUkwn0L4=?= =?UTF-8?B?0LIg0LIgYWNjZXNzIGxvZyDQv9GA0LXQtNCy0LDRgNC40YLQtdC70YzQvdC+?= =?UTF-8?B?INC00LXQutC+0LTQuNGA0L7QstCw0L3QvdGL0LzQuD8=?= In-Reply-To: <389500f5cb5b12ad67582862e0c61124.NginxMailingListRussian@forum.nginx.org> References: <389500f5cb5b12ad67582862e0c61124.NginxMailingListRussian@forum.nginx.org> Message-ID: 2011/12/25 kuchumovn : > Пример. > Я пишу сайт с русскими > человеко-понятными УРЛами. > В частности, есть вот такой запрос: > > http://localhost:8081/приложение/люди?с=1&сколько=8 > > Который отображается в access_log'е в таком > виде: > > 127.0.0.1 - - [25/Dec/2011:14:09:03 +0400] "GET > /%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5/%D0%BB%D1%8E%D0%B4%D0%B8?%D1%81=1&%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE=8 > HTTP/1.1" 200 474 "http://localhost:8081/%D0%BB%D1%8E%D0%B4%D0%B8" > "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 > Firefox/8.0.1" > > Моё предложение: может быть стоит, > перед выводом этого УРЛа в access_log, > предварительно его пропускать через > что-то наподобие decodeURI в яваскрипте? Вам не встречались в URL переводы строк? А юникод? А бинарные данные? Что тогда с логом то будет? Если уж так хочется - можете в лог ротатор добавить скрипт, который вам будет декодировать, а в основной код пихать такое нельзя. From nginx-forum на nginx.us Sun Dec 25 12:05:08 2011 From: nginx-forum на nginx.us (next40) Date: Sun, 25 Dec 2011 07:05:08 -0500 Subject: nginx+upload progress In-Reply-To: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: <446ce85a67528f3f21d645c36e2fb391.NginxMailingListRussian@forum.nginx.org> nginx стоит как основной сервер, backend отсутствует непонятное еще как правильно использовать опцию upload_pass или proxy_pass если у меня только один сервер и нет backed'a несколько дней уже бьюсь так и не получилось настроить..... (( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220461#msg-220461 From a.vasilishin на kpi.ua Sun Dec 25 19:20:16 2011 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Sun, 25 Dec 2011 21:20:16 +0200 Subject: =?UTF-8?Q?ionice_=D0=B8_nginx?= Message-ID: <4EF77770.2040504@kpi.ua> Здравствуйте! Всех католиков с Рождеством :) В общем пытался выполнить # ionice -c 3 nginx и получил: nginx: [emerg] bind() to x.x.x.x:80 failed (98: Address already in use) nginx: [emerg] bind() to x.x.x.x:80 failed (98: Address already in use) nginx: [emerg] bind() to x.x.x.x:80 failed (98: Address already in use) nginx: [emerg] bind() to x.x.x.x:80 failed (98: Address already in use) nginx: [emerg] bind() to x.x.x.x:80 failed (98: Address already in use) nginx: [emerg] still could not bind() в связи с чем возникает несколько вопросов: Имеет ли смысл ionice понижать приоритет работы с дисками? Если да, то как удобнее это сделать, не перечислять же все PID в ionice -c 3 -p ? Может имеет смысл сделать директиву наподобие worker_priority, только для io, обозвав ее типа worker_io_priority? -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE From hell-for-yahoo на umail.ru Sun Dec 25 22:24:25 2011 From: hell-for-yahoo на umail.ru (Andrey Repin) Date: Mon, 26 Dec 2011 02:24:25 +0400 Subject: nginx+upload progress In-Reply-To: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: <1511136178.20111226022425@mtu-net.ru> Здравствуйте, Уважаемый(-ая, -ое) next40! n> Добрый день, помогите пожалуйста n> разобраться с настройкой данной n> связки...... n> вопросы: файл загружает и сохраняет "Кто убил Кеннеди и Распутина?" n> скрипт(php) или сам nginx? Загружает файлы пользователь (клиент). Сохраняет - PHP. -- С уважением Andrey Repin (hell-for-yahoo на umail.ru) понедельник, 26.12.2011, <02:21> From nginx-forum на nginx.us Mon Dec 26 03:53:24 2011 From: nginx-forum на nginx.us (next40) Date: Sun, 25 Dec 2011 22:53:24 -0500 Subject: nginx+upload progress In-Reply-To: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: хорошо, со скриптом аплоада ясно....... а что я делаю не так ? uploadprogress нет индикации загрузки =( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220478#msg-220478 From i.lobahin на nikitaonline.ru Mon Dec 26 13:26:51 2011 From: i.lobahin на nikitaonline.ru (Ilya Lobahin) Date: Mon, 26 Dec 2011 17:26:51 +0400 Subject: =?UTF-8?B?0J3QsNGD0YfQuNGC0LUg0L/RgNCw0LLQuNC70YzQvdC+INC/0LjRgdCw0YLRjCA=?= =?UTF-8?B?0LvQvtC60LXQudGI0LXQvdGL?= Message-ID: <1072819477.20111226172651@nikitaonline.ru> Здравствуйте, коллеги. Есть сайт с php. На сайте хочется закрыть папу папок по IP от всех кроме себя. Делаю так: ------------------------------------------ root /var/www/site/htdocs/; index index.php index.html; location /(path1|path2)/ { allow 1.1.1.1; deny all } location ~ \.php$ { include /etc/nginx/fastcgi.conf; } ------------------------------------------ В результате site/path1 открывается. Но если сделать так: --------------------------- root /var/www/site/htdocs/; index index.php index.html; location /path1/ { allow 1.1.1.1; deny all } location /path2/ { allow 1.1.1.1; deny all } location ~ \.php$ { include /etc/nginx/fastcgi.conf; } --------------------------- То все работает как и задумано. Как делать правильнее? -- С уважением, Лобахин Илья From latypoff на yandex.ru Mon Dec 26 13:33:15 2011 From: latypoff на yandex.ru (Denis F. Latypoff) Date: Mon, 26 Dec 2011 20:33:15 +0700 Subject: =?UTF-8?B?UmU6INCd0LDRg9GH0LjRgtC1INC/0YDQsNCy0LjQu9GM0L3QviDQv9C40YHQsNGC?= =?UTF-8?B?0Ywg0LvQvtC60LXQudGI0LXQvdGL?= In-Reply-To: <1072819477.20111226172651@nikitaonline.ru> References: <1072819477.20111226172651@nikitaonline.ru> Message-ID: <70231324906395@web98.yandex.ru> 26.12.2011, 20:26, "Ilya Lobahin" : > Здравствуйте, коллеги. > > Есть сайт с php. На сайте хочется закрыть папу папок по IP от всех кроме себя. > > Делаю так: > ------------------------------------------ >     root   /var/www/site/htdocs/; >     index  index.php index.html; А какой логике следовали тут? >     location /(path1|path2)/ { Не буду мучать - выше не регулярное выражение, про локейшены читать тут http://nginx.org/ru/docs/http/ngx_http_core_module.html#location >              allow 1.1.1.1; >              deny all >     } >     location ~ \.php$ { >              include /etc/nginx/fastcgi.conf; >     } > ------------------------------------------ > В результате site/path1 открывается. > > Но если сделать так: > --------------------------- >     root   /var/www/site/htdocs/; >     index  index.php index.html; >     location /path1/ { >              allow 1.1.1.1; >              deny all >     } >     location /path2/ { >              allow 1.1.1.1; >              deny all >     } >     location ~ \.php$ { >              include /etc/nginx/fastcgi.conf; >     } > --------------------------- > То все работает как и задумано. > > Как делать правильнее? > > -- > С уважением, > Лобахин Илья > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- br, Denis F. Latypoff. From mdounin на mdounin.ru Mon Dec 26 15:48:51 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 26 Dec 2011 19:48:51 +0400 Subject: nginx-1.1.12 Message-ID: <20111226154851.GL67687@mdounin.ru> Изменения в nginx 1.1.12 26.12.2011 *) Изменение: после перенаправления запроса с помощью директивы error_page директива proxy_pass без URI теперь использует изменённый URI. Спасибо Lanshun Zhou. *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. *) Добавление: директива pcre_jit. *) Добавление: SSI команда if поддерживает выделения в регулярных выражениях. *) Исправление: SSI команда if не работала внутри команды block. *) Исправление: директивы limit_conn_log_level и limit_req_log_level могли не работать. *) Исправление: директива limit_rate не позволяла передавать на полной скорости, даже если был указан очень большой лимит. *) Исправление: директива sendfile_max_chunk не работала, если использовалась директива limit_rate. *) Исправление: если в директиве proxy_pass использовались переменные и не был указан URI, всегда использовался URI исходного запроса. *) Исправление: после перенаправления запроса с помощью директивы try_files директива proxy_pass без URI могла использовать URI исходного запроса. Спасибо Lanshun Zhou. *) Исправление: в модуле ngx_http_scgi_module. *) Исправление: в модуле ngx_http_mp4_module. *) Исправление: nginx не собирался на Solaris; ошибка появилась в 1.1.9. Maxim Dounin From savefrom на gmail.com Mon Dec 26 18:16:51 2011 From: savefrom на gmail.com (SaveFrom.net) Date: Tue, 27 Dec 2011 02:16:51 +0800 Subject: =?UTF-8?B?0JHQsNCzINGBINC30LDQs9C+0LvQvtCy0LrQvtC8IENvbnRlbnQtVHlwZSDQv9GA?= =?UTF-8?B?0LggWC1BY2NlbC1SZWRpcmVjdA==?= Message-ID: Здравствуйте. Отловил следующий баг: при проксировании не удается заменить заголовок Content-Type, если был внутренний редирект (x-accel-redirect). Конфиг: location = /foo/ { #types { } #default_type application/octet-stream; директивы не вляют proxy_pass http://pushnoy.ru/resource/_audio/Pushnoy-ru_OOO_DuTaxi.mp3; proxy_hide_header Content-Type; add_header Content-Type 'application/octet-stream'; } location = /x-accel/ { proxy_pass http://return-x-accel-redirect-to-foo; } Дергаем /x-accel/ > HTTP/1.1 200 OK > Server: nginx > Date: Mon, 26 Dec 2011 18:04:14 GMT > *Content-Type: text/html; charset=UTF-8* > Connection: keep-alive > Vary: Accept-Encoding > Last-Modified: Thu, 15 Apr 2010 09:32:45 GMT > ETag: "3e0122-5a6c41-4bc6dd3d" > Accept-Ranges: bytes > Content-Length: 5925953 > *Content-Type: application/octet-stream* > А если дернуть /foo/ - Ок. Директивы срабатыват ожидаемым образом. > HTTP/1.1 200 OK > Server: nginx > Date: Mon, 26 Dec 2011 18:04:24 GMT > Connection: keep-alive > Last-Modified: Thu, 15 Apr 2010 09:32:45 GMT > ETag: "3e0122-5a6c41-4bc6dd3d" > Accept-Ranges: bytes > Content-Length: 5925953 > *Content-Type: application/octet-stream** > * * * До кучи заголовки проксируемого файла ( http://pushnoy.ru/resource/_audio/Pushnoy-ru_OOO_DuTaxi.mp3) > HTTP/1.1 200 OK > Date: Mon, 26 Dec 2011 18:07:48 GMT > Server: Apache > Last-Modified: Thu, 15 Apr 2010 09:32:45 GMT > ETag: "3e0122-5a6c41-4bc6dd3d" > Accept-Ranges: bytes > Content-Length: 5925953 > Keep-Alive: timeout=15, max=800 > Connection: Keep-Alive > Content-Type: audio/mpeg > nginx -V nginx: nginx version: nginx/1.1.2 nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50) nginx: TLS SNI support disabled nginx: configure arguments: --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/sbin/nginx --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/spool/nginx/tmp/client --http-proxy-temp-path=/var/spool/nginx/tmp/proxy --http-fastcgi-temp-path=/var/spool/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --user=nginx --group=nginx --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module -- С уважением, Антон -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster на softsearch.ru Mon Dec 26 21:12:13 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 27 Dec 2011 01:12:13 +0400 Subject: nginx-1.1.12 In-Reply-To: <20111226154851.GL67687@mdounin.ru> References: <20111226154851.GL67687@mdounin.ru> Message-ID: <186426009.20111227011213@softsearch.ru> Здравствуйте, Maxim. > *) Изменение: после перенаправления запроса с помощью директивы > error_page директива proxy_pass без URI теперь использует изменённый > URI. > Спасибо Lanshun Zhou. Изменённый чем именно? Если error_page перенаправляет запрос в именованный локейшн, то что-то изменяется в URI? -- С уважением, Михаил mailto:postmaster на softsearch.ru From ne на vbart.ru Mon Dec 26 21:25:34 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 27 Dec 2011 01:25:34 +0400 Subject: nginx-1.1.12 In-Reply-To: <186426009.20111227011213@softsearch.ru> References: <20111226154851.GL67687@mdounin.ru> <186426009.20111227011213@softsearch.ru> Message-ID: <201112270125.34821.ne@vbart.ru> On Tuesday 27 December 2011 01:12:13 Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Изменение: после перенаправления запроса с помощью директивы > > > > error_page директива proxy_pass без URI теперь использует > > изменённый URI. > > Спасибо Lanshun Zhou. > > Изменённый чем именно? Директивой error_page, вестимо. > Если error_page перенаправляет запрос в именованный локейшн, то что-то > изменяется в URI? http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page "Если при перенаправлении не нужно менять URI, то можно перенаправить обработку ошибки в именованный location" -- Валентин Бартенев From mdounin на mdounin.ru Tue Dec 27 07:01:27 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Dec 2011 11:01:27 +0400 Subject: nginx-1.1.12 In-Reply-To: <186426009.20111227011213@softsearch.ru> References: <20111226154851.GL67687@mdounin.ru> <186426009.20111227011213@softsearch.ru> Message-ID: <20111227070127.GQ67687@mdounin.ru> Hello! On Tue, Dec 27, 2011 at 01:12:13AM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Изменение: после перенаправления запроса с помощью директивы > > error_page директива proxy_pass без URI теперь использует изменённый > > URI. > > Спасибо Lanshun Zhou. > > Изменённый чем именно? > > Если error_page перенаправляет запрос в именованный локейшн, то что-то > изменяется в URI? Изменённый директивой error_page. При перенаправлении в именованный location URI не меняется. Речь идет о конструкции вида location / { error_page 502 = /retry; proxy_pass http://backend1; } location /retry { proxy_pass http://backend2; } Подобная конструкция ещё до появления именованных location'ов позволяла обратится к другому бекенду без изменения URI. Теперь такая конструкция работать перестанет, вместо неё следует использовать именованные location'ы. Maxim Dounin From nginx-forum на nginx.us Tue Dec 27 07:04:37 2011 From: nginx-forum на nginx.us (next40) Date: Tue, 27 Dec 2011 02:04:37 -0500 Subject: nginx+upload progress In-Reply-To: References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: Переделал конфиг: server { listen *:80 default; server_name portal.nit-energo.ru; access_log /var/log/nginx/localhost.access_log main; error_log /var/log/nginx/localhost.error_log debug; root /var/www/localhost/htdocs; charset windows-1251; location ~ \.php$ { fastcgi_connect_timeout 90; fastcgi_send_timeout 60; fastcgi_read_timeout 120; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location @script { rewrite ^ /upload.php last; } location ^~ /progress { #upload_progress_json_output; report_uploads uploads; } location /upload { # Pass altered request body to this location upload_pass @script; # Store files to this directory # The directory is hashed, subdirectories 0 1 2 3 4 5 6 7 8 9 should exist upload_store /tmp 1; # Allow uploaded files to be read only by user upload_store_access user:rw group:rw all:rw; # Set specified fields in request body upload_set_form_field $upload_field_name.name "$upload_file_name"; upload_set_form_field $upload_field_name.path "$upload_tmp_path"; # Inform backend about hash and size of a file upload_aggregate_form_field "$upload_field_name.sha1" "$upload_file_sha1"; upload_aggregate_form_field "$upload_field_name.size" "$upload_file_size"; # This directive specifies any extra POST fields which should be passed along. #upload_pass_form_field "^fallback$|^login$|^usession$"; upload_pass_form_field "^X-Progress-ID$|^submit$|^email$"; upload_cleanup 400 404 499 500-505; track_uploads uploads 5s; } location /status { stub_status on; access_log off; #allow xx.xx.xx.xx; #deny all; } } access_log: 192.168.91.192 - - [27/Dec/2011:00:42:40 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:41 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:42 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:43 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:44 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:45 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:46 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:47 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:48 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:49 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:50 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:51 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:52 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:53 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:54 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:55 +0400] "POST /progress?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 405 778 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 192.168.91.192 - - [27/Dec/2011:00:42:56 +0400] "POST /upload?X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0" 200 144 "http://10.77.88.243/upl.html" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7" "-" 405 not allowed =((( Лог ошибок(debug) 2011/12/27 00:42:39 [debug] 8984#0: *1 test location: "/status" 2011/12/27 00:42:39 [debug] 8984#0: *1 test location: "/upload" 2011/12/27 00:42:39 [debug] 8984#0: *1 test location: ~ "\.php$" 2011/12/27 00:42:39 [debug] 8984#0: *1 using configuration "/upload" 2011/12/27 00:42:39 [debug] 8984#0: *1 http cl:3866844 max:104857600 2011/12/27 00:42:39 [debug] 8984#0: *1 rewrite phase: 3 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: get_tracking_id 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: get_tracking_id no header found 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: get_tracking_id no header found, args found 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: get_tracking_id found args: X-Progress-ID=a16a7888c2526e8337af74f39d69b340 HTTP/1.0 Host 2011/12/27 00:42:39 [debug] 8984#0: *1 malloc: 08129160:8 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: get_tracking_id found args: a16a7888c2526e8337af74f39d69b340 2011/12/27 00:42:39 [debug] 8984#0: *1 trackuploads id found: a16a7888c2526e8337af74f39d69b340 2011/12/27 00:42:39 [debug] 8984#0: *1 trackuploads hash 8DEAE83C for id: a16a7888c2526e8337af74f39d69b340 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: find_node a16a7888c2526e8337af74f39d69b340 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: can't find node 2011/12/27 00:42:39 [debug] 8984#0: *1 add cleanup: 080FFB0C 2011/12/27 00:42:39 [debug] 8984#0: *1 trackuploads: 8DEAE83C inserted in rbtree 2011/12/27 00:42:39 [debug] 8984#0: *1 rewrite phase: 4 2011/12/27 00:42:39 [debug] 8984#0: *1 post rewrite phase: 5 2011/12/27 00:42:39 [debug] 8984#0: *1 generic phase: 6 2011/12/27 00:42:39 [debug] 8984#0: *1 generic phase: 7 2011/12/27 00:42:39 [debug] 8984#0: *1 generic phase: 8 2011/12/27 00:42:39 [debug] 8984#0: *1 access phase: 9 2011/12/27 00:42:39 [debug] 8984#0: *1 access phase: 10 2011/12/27 00:42:39 [debug] 8984#0: *1 post access phase: 11 2011/12/27 00:42:39 [debug] 8984#0: *1 upload-progress: ngx_http_uploadprogress_content_handler 2011/12/27 00:42:39 [debug] 8984#0: *1 malloc: 08158AC8:4096 2011/12/27 00:42:39 [debug] 8984#0: *1 http client request body preread 203 2011/12/27 00:42:39 [debug] 8984#0: *1 malloc: 08100528:8192 2011/12/27 00:42:39 [debug] 8984#0: *1 http read client request body 2011/12/27 00:42:39 [debug] 8984#0: *1 recv: fd:8 316 of 8192 2011/12/27 00:42:39 [debug] 8984#0: *1 http client request body recv 316 2011/12/27 00:42:39 [debug] 8984#0: *1 http client request body rest 3866325 2011/12/27 00:42:39 [debug] 8984#0: *1 recv: fd:8 -1 of 7876 2011/12/27 00:42:39 [debug] 8984#0: *1 recv() not ready (11: Resource temporarily unavailable) 1. файл нормально загружаетс в /tmp/x/ 2. php не перемещает файл в нужную директорию 3. нет индикации нагрузки В чем может быть проблема.....??? незнаю даже куда копать Может что-то не так настроил Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220516#msg-220516 From swood на fotofor.biz Tue Dec 27 08:47:03 2011 From: swood на fotofor.biz (Anton Kiryushkin) Date: Tue, 27 Dec 2011 12:47:03 +0400 Subject: nginx-1.1.12 In-Reply-To: <20111226154851.GL67687@mdounin.ru> References: <20111226154851.GL67687@mdounin.ru> Message-ID: Подскажите пожалуйста, а о чем директива pcre_jit? 26 декабря 2011 г. 19:48 пользователь Maxim Dounin написал: > Изменения в nginx 1.1.12                                          26.12.2011 > >    *) Изменение: после перенаправления запроса с помощью директивы >       error_page директива proxy_pass без URI теперь использует изменённый >       URI. >       Спасибо Lanshun Zhou. > >    *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, >       proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. > >    *) Добавление: директива pcre_jit. > >    *) Добавление: SSI команда if поддерживает выделения в регулярных >       выражениях. > >    *) Исправление: SSI команда if не работала внутри команды block. > >    *) Исправление: директивы limit_conn_log_level и limit_req_log_level >       могли не работать. > >    *) Исправление: директива limit_rate не позволяла передавать на полной >       скорости, даже если был указан очень большой лимит. > >    *) Исправление: директива sendfile_max_chunk не работала, если >       использовалась директива limit_rate. > >    *) Исправление: если в директиве proxy_pass использовались переменные и >       не был указан URI, всегда использовался URI исходного запроса. > >    *) Исправление: после перенаправления запроса с помощью директивы >       try_files директива proxy_pass без URI могла использовать URI >       исходного запроса. >       Спасибо Lanshun Zhou. > >    *) Исправление: в модуле ngx_http_scgi_module. > >    *) Исправление: в модуле ngx_http_mp4_module. > >    *) Исправление: nginx не собирался на Solaris; ошибка появилась в 1.1.9. > > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin, From ne на vbart.ru Tue Dec 27 09:06:14 2011 From: ne на vbart.ru (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Tue, 27 Dec 2011 13:06:14 +0400 Subject: nginx-1.1.12 In-Reply-To: References: <20111226154851.GL67687@mdounin.ru> Message-ID: <201112271306.15346.ne@vbart.ru> On Tuesday 27 December 2011 12:47:03 Anton Kiryushkin wrote: > Подскажите пожалуйста, а о чем директива pcre_jit? Включает just-in-time компиляцию регулярных выражений, компилируемых на этапе конфигурации, т. е. в location, map, rewrite, if и т. д., действует на все регулярные выражения прописанные в конфиге. Для работы опции nginx должен быть собран с PCRE 8.20 и выше. PCRE должна быть собрана с флагом --enable-jit. Если PCRE конфигурируется вместе с nginx, т.е. используется опция --with-pcre=path/to/source, то для сборки с JIT-компиляцией необходимо также указать configure флаг: --with-pcre-jit JIT компиляция ускоряет выполнение регулярных выражений (особенно сложных) в 1-10 раз: http://sljit.sourceforge.net/pcre.html Опция pcre_jit on/off указывается на глобальном уровне (контекст: main). По-умолчанию off. Соответственно для включения надо указать on. Документация вскоре будет обновлена. -- Валентин Бартенев From nginx-forum на nginx.us Tue Dec 27 09:42:11 2011 From: nginx-forum на nginx.us (valet) Date: Tue, 27 Dec 2011 04:42:11 -0500 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4gSHR0cFNlY3VyZUxpbmtNb2R1bGU=?= Message-ID: Помогите пожалуйста разобраться с HttpSecureLinkModule. Делаю все по инструкции http://wiki.nginx.org/HttpSecureLinkModule, но почему-то не получается. Задача: отдавать по разным ссылкам видео в зависимости от IP юзера. Создаю локейшен: location /video/ { ## This must match the URI part related to the MD5 hash and expiration time. secure_link $arg_st; ## This is how the MD5 hash is built from a secret token, an URI and an ## expiration time. secure_link_md5 qp3mc84ha0m46c$uri$remote_addr; ## If the hash is incorrect then $secure_link is a null string. if ($secure_link = "") { return 403; } ## The current local time is greater than the specified expiration time. if ($secure_link = "0") { return 403; } ## If everything is ok $secure_link is 1. } Делаю /etc/init.d/nginx reload чтобы подхватить новый конфиг. Создаю в каталоге qp3mc84ha0m46c/video/files/ файл top_secret.pdf Для проверки генерю вручную нужную ссылку, по которой он должен отдаваться: php -r 'print str_replace("=", "", strtr(base64_encode(md5("qp3mc84ha0m46c/video/files/top_secret.pdf46.185.43.130", TRUE)), "+/", "-_")) . "\n";' где 46.185.43.130 - мой IP. Получается: 1aucwvhDHWfwAaDJuw1QrQ Потом пробую получить файл: http://site.ru/video/files/top_secret.pdf?st=1aucwvhDHWfwAaDJuw1QrQ В результате 404 Not Found nginx/1.0.6 А так http://site.ru/qp3mc84ha0m46c/video/files/top_secret.pdf - все нормально - 200 с отдачей файла. Что я делаю не так? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220529,220529#msg-220529 From xinu на list.ru Tue Dec 27 11:04:04 2011 From: xinu на list.ru (=?UTF-8?B?eGludQ==?=) Date: Tue, 27 Dec 2011 15:04:04 +0400 Subject: =?UTF-8?B?UmVbM106INC40LfQvNC10L3QtdC90LjQtSBsb2dfZm9ybWF0ICsgJy1zIHJlbG9h?= =?UTF-8?B?ZCAvIHJlb3BlbicgINC90LUg0L/RgNC40LLQvtC00LjRgiDQuiDQuNC30Lw=?= =?UTF-8?B?0LXQvdC10L3QuNGOINC70L7Qs9Cw?= In-Reply-To: References: Message-ID: > отсутствие терминала у главного процесса, а стало быть, невозможность прочитать > пассфразу для ключа (неоткуда) > т.е. пассфразу, которуу я ввожу, я передау новому мастер-процессу, а он - передает старому (работаущему) мастер процессу только сигнал reload без пассфразы и завержает работу. я правильно Вас понял? спасибо. From nginx-forum на nginx.us Tue Dec 27 11:04:48 2011 From: nginx-forum на nginx.us (valet) Date: Tue, 27 Dec 2011 06:04:48 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IEh0dHBTZWN1cmVMaW5rTW9kdWxl?= In-Reply-To: References: Message-ID: Разобрался уже сам. В моем случае нужно было добавить в location root /var/www/site.ru/qp3mc84ha0m46c; И все сразу заработало. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220529,220532#msg-220532 From johnbat26 на gmail.com Tue Dec 27 11:11:41 2011 From: johnbat26 на gmail.com (Eugene Batogov) Date: Tue, 27 Dec 2011 14:11:41 +0300 Subject: =?UTF-8?B?bmd4X2h0dHBfeHNsdF9tb2R1bGU6INGD0LHRgNCw0YLRjCDQt9Cw0LPQvtC70L4=?= =?UTF-8?B?0LLQvtC6IHhtbA==?= Message-ID: Привет. Столкнулся с проблемой. Мне необходимо преобразовать xml в JavaScript, для этого использую ngx_http_xslt_module. Конфигурация nginx: location portal-facade-ytraffic-jsonpp { proxy_pass http://op.yandex.ru/; proxy_set_header Host op.yandex.ru; add_header Content-Type application/x-javascript; xslt_stylesheet /var/spool/nginx/tve-jsonpp/yandex-traffic.xsl; break; } XSLT-преобразование: Оно преобразовывает XML с сайта Яндекс.Пробки в JavaScript: fw.core.RequestManager.response({ rate: 7 }); Проблема в том, что в ответе первой строкой выдается XML-заголовок: fw.core.RequestManager.response({ rate: 7 }); Вот именно этот заголовок мне надо убрать, и оставить только чистый JavaScript. Как это можно сделать? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Tue Dec 27 11:34:36 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Dec 2011 15:34:36 +0400 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX3hzbHRfbW9kdWxlOiDRg9Cx0YDQsNGC0Ywg0LfQsNCz0L4=?= =?UTF-8?B?0LvQvtCy0L7QuiB4bWw=?= In-Reply-To: References: Message-ID: <20111227113436.GY67687@mdounin.ru> Hello! On Tue, Dec 27, 2011 at 02:11:41PM +0300, Eugene Batogov wrote: > Привет. > > Столкнулся с проблемой. Мне необходимо преобразовать xml в JavaScript, > для этого использую ngx_http_xslt_module. > > Конфигурация nginx: > > location portal-facade-ytraffic-jsonpp { > proxy_pass http://op.yandex.ru/; > proxy_set_header Host op.yandex.ru; > add_header Content-Type application/x-javascript; > xslt_stylesheet /var/spool/nginx/tve-jsonpp/yandex-traffic.xsl; > break; > } > > XSLT-преобразование: > > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> > > > > > > > > Оно преобразовывает XML с сайта Яндекс.Пробки в JavaScript: > > fw.core.RequestManager.response({ rate: 7 }); > > Проблема в том, что в ответе первой строкой выдается XML-заголовок: > > > fw.core.RequestManager.response({ rate: 7 }); > > Вот именно этот заголовок мне надо убрать, и оставить только чистый > JavaScript. Как это можно сделать? Добавить в xslt шаблон: И убрать add_header. Maxim Dounin From johnbat26 на gmail.com Tue Dec 27 12:06:28 2011 From: johnbat26 на gmail.com (Eugene Batogov) Date: Tue, 27 Dec 2011 15:06:28 +0300 Subject: =?UTF-8?B?UmU6IG5neF9odHRwX3hzbHRfbW9kdWxlOiDRg9Cx0YDQsNGC0Ywg0LfQsNCz0L4=?= =?UTF-8?B?0LvQvtCy0L7QuiB4bWw=?= In-Reply-To: <20111227113436.GY67687@mdounin.ru> References: <20111227113436.GY67687@mdounin.ru> Message-ID: Большое спасибо. Все работает ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.g.i.n.x.e.r на gmail.com Tue Dec 27 12:08:21 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 27 Dec 2011 16:08:21 +0400 Subject: =?UTF-8?B?0JTQvtGB0YLRg9C/INC/0L4g0L/RgNCw0LLQuNC70YM=?= Message-ID: Те, кто настраивал bind, знают, что там можно указать блок подсетей для доступа. Возник вопрос- а можно ли так же сделать в nginx? Бывают ситуации когда нужно закрыть доступ к нескольким местам в проекте. Копировать каждый раз блок разрешенных адресов парит. А потом его еще и менять (. From mdounin на mdounin.ru Tue Dec 27 12:11:17 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Dec 2011 16:11:17 +0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+INC/0YDQsNCy0LjQu9GD?= In-Reply-To: References: Message-ID: <20111227121117.GB67687@mdounin.ru> Hello! On Tue, Dec 27, 2011 at 04:08:21PM +0400, Роман wrote: > Те, кто настраивал bind, знают, что там можно указать блок подсетей для доступа. > > Возник вопрос- а можно ли так же сделать в nginx? > > Бывают ситуации когда нужно закрыть доступ к нескольким местам в > проекте. Копировать каждый раз блок разрешенных адресов парит. > А потом его еще и менять (. include mynetworks; Maxim Dounin From n.g.i.n.x.e.r на gmail.com Tue Dec 27 12:13:08 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 27 Dec 2011 16:13:08 +0400 Subject: nginx redis session In-Reply-To: References: Message-ID: Сессии не единственные данные которые я бы хотел хранить в редисе. Меня интересует взаимосвязь nginx+redis, а не php+redis И memcache тоже умеет реплицироваться и бекапитсья на диск, но я хотел для разнообразия попробовать redis, т.к. он умеет хранить не только строки. 20 декабря 2011 г. 18:59 пользователь winsov написал: > Вообще избавляться от хранения сессий > в файлах нужно при большом кол-ве > пользователей. Сессий хранить в > мэмкэше ненадежно а в файлах > тормознуто . А вот Редис вполне хороший > вариант для хранения сессий т.к > актуальные данные храняться в > оперативной памяти но еще и копируются > на жесткий диск для сохранности. > ставим redis server > В настройках php прописываем > > > session.save_handler    redis > session.save_path       11.11.11.11:6379 > > > где 11.11.11.11 - IP сервера где установлен redis > (подключение по IP в случае > использования редиса на отдельном > сервере) > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220121,220310#msg-220310 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From n.g.i.n.x.e.r на gmail.com Tue Dec 27 12:15:24 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 27 Dec 2011 16:15:24 +0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+INC/0YDQsNCy0LjQu9GD?= In-Reply-To: <20111227121117.GB67687@mdounin.ru> References: <20111227121117.GB67687@mdounin.ru> Message-ID: А как сделать проверку: если не в этой сети то что то иначе что то 27 декабря 2011 г. 16:11 пользователь Maxim Dounin написал: > Hello! > > On Tue, Dec 27, 2011 at 04:08:21PM +0400, Роман wrote: > >> Те, кто настраивал bind, знают, что там можно указать блок подсетей для доступа. >> >> Возник вопрос- а можно ли так же сделать в nginx? >> >> Бывают ситуации когда нужно закрыть доступ к нескольким местам в >> проекте. Копировать каждый раз блок разрешенных адресов парит. >> А потом его еще и менять (. > > include mynetworks; > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin на mdounin.ru Tue Dec 27 12:25:27 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Dec 2011 16:25:27 +0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+INC/0YDQsNCy0LjQu9GD?= In-Reply-To: References: <20111227121117.GB67687@mdounin.ru> Message-ID: <20111227122527.GC67687@mdounin.ru> Hello! On Tue, Dec 27, 2011 at 04:15:24PM +0400, Роман wrote: > А как сделать проверку: > > если не в этой сети то > что то > иначе > что то Как-то так: geo $mynetwork { ... } И дальше проверять значение переменной $mynetwork. Только иметь в виду, что в if'ах внутри location'а крайне не рекомендуется использовать что-либо, кроме return и безусловного rewrite. Подробности на http://wiki.nginx.org/IfIsEvil. Maxim Dounin > > > 27 декабря 2011 г. 16:11 пользователь Maxim Dounin написал: > > Hello! > > > > On Tue, Dec 27, 2011 at 04:08:21PM +0400, Роман wrote: > > > >> Те, кто настраивал bind, знают, что там можно указать блок подсетей для доступа. > >> > >> Возник вопрос- а можно ли так же сделать в nginx? > >> > >> Бывают ситуации когда нужно закрыть доступ к нескольким местам в > >> проекте. Копировать каждый раз блок разрешенных адресов парит. > >> А потом его еще и менять (. > > > > include mynetworks; > > > > Maxim Dounin > > > > _______________________________________________ > > 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 n.g.i.n.x.e.r на gmail.com Tue Dec 27 12:49:02 2011 From: n.g.i.n.x.e.r на gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Tue, 27 Dec 2011 16:49:02 +0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGC0YPQvyDQv9C+INC/0YDQsNCy0LjQu9GD?= In-Reply-To: <20111227122527.GC67687@mdounin.ru> References: <20111227121117.GB67687@mdounin.ru> <20111227122527.GC67687@mdounin.ru> Message-ID: не, мне надо сделать проверку дял внешней сети, а для внутренней ее убрать. 27 декабря 2011 г. 16:25 пользователь Maxim Dounin написал: > Hello! > > On Tue, Dec 27, 2011 at 04:15:24PM +0400, Роман wrote: > >> А как сделать проверку: >> >> если не в этой сети то >>     что то >> иначе >>     что то > > Как-то так: > >    geo $mynetwork { >       ... >    } > > И дальше проверять значение переменной $mynetwork. > > Только иметь в виду, что в if'ах внутри location'а крайне не > рекомендуется использовать что-либо, кроме return и безусловного > rewrite.  Подробности на http://wiki.nginx.org/IfIsEvil. > > Maxim Dounin > >> >> >> 27 декабря 2011 г. 16:11 пользователь Maxim Dounin написал: >> > Hello! >> > >> > On Tue, Dec 27, 2011 at 04:08:21PM +0400, Роман wrote: >> > >> >> Те, кто настраивал bind, знают, что там можно указать блок подсетей для доступа. >> >> >> >> Возник вопрос- а можно ли так же сделать в nginx? >> >> >> >> Бывают ситуации когда нужно закрыть доступ к нескольким местам в >> >> проекте. Копировать каждый раз блок разрешенных адресов парит. >> >> А потом его еще и менять (. >> > >> > include mynetworks; >> > >> > Maxim Dounin >> > >> > _______________________________________________ >> > 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 From mdounin на mdounin.ru Tue Dec 27 13:50:59 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 27 Dec 2011 17:50:59 +0400 Subject: =?UTF-8?B?UmU6INCR0LDQsyDRgSDQt9Cw0LPQvtC70L7QstC60L7QvCBDb250ZW50LVR5cGUg?= =?UTF-8?B?0L/RgNC4IFgtQWNjZWwtUmVkaXJlY3Q=?= In-Reply-To: References: Message-ID: <20111227135059.GE67687@mdounin.ru> Hello! On Tue, Dec 27, 2011 at 02:16:51AM +0800, SaveFrom.net wrote: > Здравствуйте. > Отловил следующий баг: при проксировании не удается заменить заголовок > Content-Type, если был внутренний редирект (x-accel-redirect). > > Конфиг: > > > location = /foo/ { > #types { } > #default_type application/octet-stream; директивы не вляют > proxy_pass http://pushnoy.ru/resource/_audio/Pushnoy-ru_OOO_DuTaxi.mp3; > proxy_hide_header Content-Type; > add_header Content-Type 'application/octet-stream'; > } > location = /x-accel/ { > proxy_pass http://return-x-accel-redirect-to-foo; > } При X-Accel-Redirect заголовок Content-Type берётся из ответа, вернувшего X-Accel-Redirect. Соответственно там он должен быть либо правильный, либо отсутствовать. Директива add_header заменять заголовки сейчас не умеет, так что поведение ожидаемо. Maxim Dounin From nginx-forum на nginx.us Wed Dec 28 01:42:01 2011 From: nginx-forum на nginx.us (locojohn) Date: Tue, 27 Dec 2011 20:42:01 -0500 Subject: nginx+upload progress In-Reply-To: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: <8153d1558d0b920e6aaea408461b784f.NginxMailingListRussian@forum.nginx.org> 405 = Method not allowed Вполне вероятно, что вы пытаетесь считать информацию о прогрессе загрузки через POST. Это не работает и об этом написано в документации к данному модулю. Попробуйте передавать X-Progress-ID через GET. Удачи! Андрей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220567#msg-220567 From nginx-forum на nginx.us Wed Dec 28 05:58:18 2011 From: nginx-forum на nginx.us (Nestap) Date: Wed, 28 Dec 2011 00:58:18 -0500 Subject: Nginx+SSL, Authentification based on certificate Message-ID: privet vsem, vot takoi vapros mojet ktota stolknulsea s etoi problemi: Mne nado nastroiti Nginx server tak stob authentificatia na servere https(ssl) pri pomashiu client certificata no stob server prinimal certificati ot nescoliko CA authority. Ia nastroil dlya odnova CA center i vseo rabotaet otlichino no haciu dabaviti 2 ca center. vot kak ya nastroil dlya odnovo CA: ssl_certificate /etc/nginx/ssl/server.cer; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_client_certificate /etc/nginx/ssl/ca.cer; ssl_verify_client on; ssl_verify_depth 2; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220571,220571#msg-220571 From nginx-forum на nginx.us Wed Dec 28 06:19:44 2011 From: nginx-forum на nginx.us (next40) Date: Wed, 28 Dec 2011 01:19:44 -0500 Subject: nginx+upload progress In-Reply-To: References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: <702aabb003800e41859231163e898c40.NginxMailingListRussian@forum.nginx.org> Да действительно в скрипте передавалось через POST, исправил на GET Проблема не ушла, ошибки теже что и в логе выше =( Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220573#msg-220573 From daniel на quietsupport.net Wed Dec 28 12:14:49 2011 From: daniel на quietsupport.net (Daniel Yavorovich) Date: Wed, 28 Dec 2011 14:14:49 +0200 Subject: =?UTF-8?B?cHJveHlfc3RvcmUg0Lgg0LjQt9C80LXQvdC10L3QuNGPINGE0LDQudC70L7Qsi4=?= Message-ID: <4EFB0839.2010406@quietsupport.net> Доброго времени суток, коллеги. Сейчас я использую proxy_store для сохранения статических файлов на фронтенде, но возникла необходимость изменять эти файлы со стороны бекендов, и, соответственно, обновлять их на front-end'ах. Исходя из документации: > Директиву можно использовать для создания локальных копий статических неизменяемых файлов я понимаю, что proxy_store в нынешней конфигурации мне не подходит. При запросе front-end получает Last Modified Time. Возможно ли при его изменении (или каким либо другим способом) обновлять realtime статические файлы на front-end'ах при изменеии их со стороны back-end'ов? ---- Часть конфига одного из front-end'ов: # Static files location location / { expires 3d; root /home/user/st; try_files $uri @front-static; } location @front-static{ internal; proxy_pass http://static; proxy_set_header Host st001.int; proxy_store on; proxy_store_access user:rw group:rw all:r; proxy_temp_path /home/user/tmp; root /home/user/st; access_log off; } ---- Часть конфига одного из back-end'ов: # Static files location location / { root /home/user/st/; access_log off; } Спасибо. -- С уважением, Даниэль Яворович From nginx-forum на nginx.us Wed Dec 28 12:26:41 2011 From: nginx-forum на nginx.us (locojohn) Date: Wed, 28 Dec 2011 07:26:41 -0500 Subject: nginx+upload progress In-Reply-To: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: И до сих пор 405??? 405 = Method not alllowed, и в таком случае, если вы передаёте X-Progress-ID через "GET", то это вряд ли уже связано с upload progress. Ищите в других настройках. Может у вас какие-нибудь "deny all" стоят где-то. Андрей Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220588#msg-220588 From nginx-forum на nginx.us Wed Dec 28 12:46:45 2011 From: nginx-forum на nginx.us (next40) Date: Wed, 28 Dec 2011 07:46:45 -0500 Subject: nginx+upload progress In-Reply-To: References: <62306a321006c3fe3857cf68cf33967a.NginxMailingListRussian@forum.nginx.org> Message-ID: <752c29c01c67b3b6c32b47a89ecbac3d.NginxMailingListRussian@forum.nginx.org> теперь уже 200 в логе(сорри некорректно написал ответил) но в error_log тоже самое и нет индикации загрузки файла Posted at Nginx Forum: http://forum.nginx.org/read.php?21,220460,220589#msg-220589 From postmaster на softsearch.ru Wed Dec 28 12:53:27 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 28 Dec 2011 16:53:27 +0400 Subject: nginx-1.1.12 In-Reply-To: <20111226154851.GL67687@mdounin.ru> References: <20111226154851.GL67687@mdounin.ru> Message-ID: <1952835407.20111228165327@softsearch.ru> Здравствуйте, Maxim. > *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. А где можно почитать по эти новые директивы? > *) Добавление: директива pcre_jit. А почему бы эту директиву по дефолту не включать? -- С уважением, Михаил mailto:postmaster на softsearch.ru From wangsamp на gmail.com Wed Dec 28 12:58:47 2011 From: wangsamp на gmail.com (Oleksandr V. Typlyns'kyi) Date: Wed, 28 Dec 2011 14:58:47 +0200 (EET) Subject: nginx-1.1.12 In-Reply-To: <1952835407.20111228165327@softsearch.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> Message-ID: Today Dec 28, 2011 at 16:53 Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, > > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. > > А где можно почитать по эти новые директивы? http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html -- WNGS-RIPE From mdounin на mdounin.ru Wed Dec 28 13:19:06 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 28 Dec 2011 17:19:06 +0400 Subject: nginx-1.1.12 In-Reply-To: <1952835407.20111228165327@softsearch.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> Message-ID: <20111228131906.GR67687@mdounin.ru> Hello! On Wed, Dec 28, 2011 at 04:53:27PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > > *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, > > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. > > А где можно почитать по эти новые директивы? Пока тут: http://trac.nginx.org/nginx/changeset/4386/nginx Скоро опишем в документации. In short: если включена директива proxy_cache_lock on; то при наличии нескольких запросов к конкретному незакешированному ресурсу - на бекенд пойдёт только первый, остальные будут ждать вплоть до proxy_cache_lock_timeout каждый. > > *) Добавление: директива pcre_jit. > > А почему бы эту директиву по дефолту не включать? В основном из соображений безопасности. JIT - относительно новая фича PCRE, и нет желания получить проблемы, если там что-то работает не так, как хотелось бы. Вероятно, в будущем значение по умолчанию будет пересмотрено. Maxim Dounin From postmaster на softsearch.ru Wed Dec 28 14:04:28 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 28 Dec 2011 18:04:28 +0400 Subject: nginx-1.1.12 In-Reply-To: <20111228131906.GR67687@mdounin.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> <20111228131906.GR67687@mdounin.ru> Message-ID: <882038476.20111228180428@softsearch.ru> Здравствуйте, Maxim. >> > *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, >> > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. >> >> А где можно почитать по эти новые директивы? > Пока тут: > http://trac.nginx.org/nginx/changeset/4386/nginx > Скоро опишем в документации. In short: если включена директива > proxy_cache_lock on; > то при наличии нескольких запросов к конкретному незакешированному > ресурсу - на бекенд пойдёт только первый, остальные будут ждать > вплоть до proxy_cache_lock_timeout каждый. Полезная вещь. Почитал http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html Странная реализация. Зачем на каждый ожидающий запрос вешать отдельный таймаут, если достаточно одного на первый запрос, пошедший к бэкенду? -- С уважением, Михаил mailto:postmaster на softsearch.ru From unera на uvw.ru Wed Dec 28 14:06:45 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Wed, 28 Dec 2011 18:06:45 +0400 Subject: Perl: Nginx Message-ID: <20111228140645.GK29996@apache.rbscorp.ru> Смотрю примеры использования сабж. Интересуют вопросы, вот например: ngx_timer 5, 5, sub { ngx_log_notice 0, "5 seconds gone"; }; А как сделать например чтобы таймер повторился 5 раз? То есть в AnyEvent например мы делаем нечто вроде my $timer; my $counter = 0; $timer = AE::timer 5, 5, sub { log_notice "5 seconds gone"; return if ++$counter < 5; undef $timer; # тут мы останавливаем timer }; А в nginx такая возможность есть? Так же интересуют вопросы остановки работы с сокетами. -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From postmaster на softsearch.ru Wed Dec 28 14:20:01 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 28 Dec 2011 18:20:01 +0400 Subject: Perl: Nginx In-Reply-To: <20111228140645.GK29996@apache.rbscorp.ru> References: <20111228140645.GK29996@apache.rbscorp.ru> Message-ID: <1648058640.20111228182001@softsearch.ru> Здравствуйте, Dmitry. http://zzzcpan.github.com/nginx-perl/ -- С уважением, Михаил mailto:postmaster на softsearch.ru From unera на uvw.ru Wed Dec 28 14:22:52 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Wed, 28 Dec 2011 18:22:52 +0400 Subject: Perl: Nginx In-Reply-To: <20111228140645.GK29996@apache.rbscorp.ru> References: <20111228140645.GK29996@apache.rbscorp.ru> Message-ID: <20111228142252.GL29996@apache.rbscorp.ru> > Смотрю примеры использования сабж. > Интересуют вопросы, вот например: > ngx_timer 5, 5, sub { > ngx_log_notice 0, "5 seconds gone"; > }; > А как сделать например чтобы таймер повторился 5 раз? > То есть в AnyEvent например мы делаем нечто вроде > my $timer; > my $counter = 0; > $timer = AE::timer 5, 5, sub { > log_notice "5 seconds gone"; > return if ++$counter < 5; > undef $timer; # тут мы останавливаем timer > }; > А в nginx такая возможность есть? > Так же интересуют вопросы остановки работы с сокетами. Я к чему. Имеются туева хуча наработок на Perl для работы event-машинами. В частности AnyEvent. На базе него есть разные вещи вроде событийной обработки, парсинга итп. Но там работа основана на том что когда ты вешаешь свой саб на обработку некоего повторяющегося события (например что данные появились в сокете), то ты всегда этот ватчер можешь убрать/заменить другим. И на этом можно крутить очень сложную логику в довольно простом режиме. То есть например первый ватчер читает заголовок какого-нибудь протокола, затем удаляется и заменяется другим, который что-то дочитывает итп. и эта вся фигатень в перле развивается: всякие коннекторы к БД асинхронные делают (например к постгрису есть коннектор), итп итд. Вот и хочется для AnyEvent написать имплементатор Nginx и все это хозяйтство автоматом станет работать на nginx. -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From unera на uvw.ru Wed Dec 28 14:37:31 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Wed, 28 Dec 2011 18:37:31 +0400 Subject: Perl: Nginx In-Reply-To: <1648058640.20111228182001@softsearch.ru> References: <20111228140645.GK29996@apache.rbscorp.ru> <1648058640.20111228182001@softsearch.ru> Message-ID: <20111228143731.GM29996@apache.rbscorp.ru> > Здравствуйте, Dmitry. > http://zzzcpan.github.com/nginx-perl/ Ну да это то же самое что я смотрю. Тут и вопросы: например мы делаем запрос на сразу три сайта. ngx_connector "1.2.3.4", 80, 15, sub { }; ngx_connector "1.2.3.3", 80, 15, sub { }; ngx_connector "1.2.3.5", 80, 15, sub { }; в одном из них выясняется что два других нам уже не нужны (если они еще не выполнились). Вопрос как остановить процесс установления коннекта? Или удалить процесс ngx_reader с сокета (и возможно заменить его другим)? и что такое $c? обычный handler? то есть можно ли этим функциям подсовывать сокеты, которые открыты из perl'ового кода? Этот вопрос как-то не раскрыт остался -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From zzz на zzz.org.ua Wed Dec 28 15:16:52 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Wed, 28 Dec 2011 17:16:52 +0200 Subject: Perl: Nginx In-Reply-To: <20111228143731.GM29996@apache.rbscorp.ru> References: <20111228140645.GK29996@apache.rbscorp.ru> <1648058640.20111228182001@softsearch.ru> <20111228143731.GM29996@apache.rbscorp.ru> Message-ID: On 12/28/11, Dmitry E. Oboukhov wrote: > ngx_connector "1.2.3.4", 80, 15, sub { > > }; > ngx_connector "1.2.3.3", 80, 15, sub { > > }; > ngx_connector "1.2.3.5", 80, 15, sub { > > }; > в одном из них выясняется что два других нам уже не нужны (если они > еще не выполнились). Вопрос как остановить процесс установления > коннекта? Внутри: ngx_connector "1.2.3.5", 80, 15, sub { return NGX_CLOSE if $someone_already_responded; ... }; Этого должно быть достаточно, подключение может происходить успешно, но возвращать ошибку сразу при попытке отправить данные или получить. Т.е. все равно нужно ждать дольше. http://zzzcpan.github.com/nginx-perl/Nginx.html#FLOW_CONTROL > Или удалить процесс ngx_reader с сокета (и возможно заменить его > другим)? Можно переопределять сколько угодно раз, но только явно: ngx_reader $c, .. sub { ... ngx_reader $c, .. sub { ... }; return NGX_READ; }; Т.е. весь flow будет выстроен в лесенку. Но лесенка будет маленькая, т.к. ими можно управлять: my $min = 10; my $max = 10; my $timeout = 15; my $buf; ngx_reader $c, $buf, $min, $max, $timeout, sub { if ($something) { $min = 50; $max = 100; $timeout = 5; return NGX_READ; } ... }; > и что такое $c? обычный handler? то есть можно ли этим функциям > подсовывать сокеты, которые открыты из perl'ового кода? Этот вопрос > как-то не раскрыт остался Это не сокет, это указатель на ngx_connection_t, который хранит в себе все остальное. From unera на uvw.ru Wed Dec 28 15:30:22 2011 From: unera на uvw.ru (Dmitry E. Oboukhov) Date: Wed, 28 Dec 2011 19:30:22 +0400 Subject: Perl: Nginx In-Reply-To: References: <20111228140645.GK29996@apache.rbscorp.ru> <1648058640.20111228182001@softsearch.ru> <20111228143731.GM29996@apache.rbscorp.ru> Message-ID: <20111228153022.GN29996@apache.rbscorp.ru> >> и что такое $c? обычный handler? то есть можно ли этим функциям >> подсовывать сокеты, которые открыты из perl'ового кода? Этот вопрос >> как-то не раскрыт остался > Это не сокет, это указатель на ngx_connection_t, который хранит в себе > все остальное. то есть если сокет получен другим способом нежели ngx_connect то способа ожидать на нем события в nginx нет? -- . ''`. Dmitry E. Oboukhov : :? : email: unera на debian.org jabber://UNera на uvw.ru `. `~? GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From zzz на zzz.org.ua Wed Dec 28 15:35:54 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Wed, 28 Dec 2011 17:35:54 +0200 Subject: Perl: Nginx In-Reply-To: <20111228153022.GN29996@apache.rbscorp.ru> References: <20111228140645.GK29996@apache.rbscorp.ru> <1648058640.20111228182001@softsearch.ru> <20111228143731.GM29996@apache.rbscorp.ru> <20111228153022.GN29996@apache.rbscorp.ru> Message-ID: On 12/28/11, Dmitry E. Oboukhov wrote: >>> и что такое $c? обычный handler? то есть можно ли этим функциям >>> подсовывать сокеты, которые открыты из perl'ового кода? Этот вопрос >>> как-то не раскрыт остался > >> Это не сокет, это указатель на ngx_connection_t, который хранит в себе >> все остальное. > > то есть если сокет получен другим способом нежели ngx_connect то > способа ожидать на нем события в nginx нет? Да, пока нет. Есть мысль сделать что-то типа $c = ngx_new_connection_from_fh $fh; From mdounin на mdounin.ru Wed Dec 28 16:21:27 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 28 Dec 2011 20:21:27 +0400 Subject: nginx-1.1.12 In-Reply-To: <882038476.20111228180428@softsearch.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> <20111228131906.GR67687@mdounin.ru> <882038476.20111228180428@softsearch.ru> Message-ID: <20111228162127.GU67687@mdounin.ru> Hello! On Wed, Dec 28, 2011 at 06:04:28PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> > *) Добавление: директивы proxy/fastcgi/scgi/uwsgi_cache_lock, > >> > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. > >> > >> А где можно почитать по эти новые директивы? > > > Пока тут: > > > http://trac.nginx.org/nginx/changeset/4386/nginx > > > Скоро опишем в документации. In short: если включена директива > > > proxy_cache_lock on; > > > то при наличии нескольких запросов к конкретному незакешированному > > ресурсу - на бекенд пойдёт только первый, остальные будут ждать > > вплоть до proxy_cache_lock_timeout каждый. > > Полезная вещь. > > Почитал http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html > Странная реализация. Зачем на каждый ожидающий запрос вешать отдельный > таймаут, если достаточно одного на первый запрос, пошедший к бэкенду? Таймаута - одного недостаточно, т.к. proxy_cache_lock_timeout ограничивает время, которое *один конкретный запрос* может провести в ожидании лока (т.е. дополнительное время ожидания, которое увидит клиент). У каждого запроса начальное время ожидания своё (да и сам таймаут теоретически может быть не таким, как у других). Если ты про таймер, который сейчас зовётся раз в 500ms, то по хорошему его там вообще не должно быть: запросы должны подниматься из очереди по снятию лока. Но сейчас этого нормально сделать нельзя, т.к. рабочих процессов может быть много, а лок - общий. И нет механизмов, чтобы сообщить в другой рабочий процесс о том, что вот такие запросы можно поднимать. Так что для начала было выбрано максимально простое решение. В дальнейшем оно, вероятно, будет усовершенствовано. Maxim Dounin From postmaster на softsearch.ru Wed Dec 28 18:52:51 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 28 Dec 2011 22:52:51 +0400 Subject: =?UTF-8?B?0J7Rh9C10L3RjCDQtNC70LjQvdC90YvQtSDRg9GA0LvRiy4=?= Message-ID: <1407322813.20111228225251@softsearch.ru> Здравствуйте. Можно как-то ограничить в nginx-е длину url-ей , передаваемых на бэкенд? А то апач выдаёт 403 на длинные урлы [Wed Dec 28 22:47:07 2011] [error] [client 81.200.127.6] (63)File name too long: access to /interests/%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e\xc8\xd5 \xce\xd7\xc5\xcd\xdc \xcc\xcd\xce\xc3\xce%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e/ failed и я не знаю как изменить его поведение, например, на выдачу редиректа на /interests/ или на / . Ну или может в апаче 1.3 есть способ, как управлять ответом на длинные урлы. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Wed Dec 28 18:57:02 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 28 Dec 2011 22:57:02 +0400 Subject: nginx-1.1.12 In-Reply-To: <20111228162127.GU67687@mdounin.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> <20111228131906.GR67687@mdounin.ru> <882038476.20111228180428@softsearch.ru> <20111228162127.GU67687@mdounin.ru> Message-ID: <66186103.20111228225702@softsearch.ru> Здравствуйте, Maxim. >> >> > *) Добавление: директивы >> proxy/fastcgi/scgi/uwsgi_cache_lock, >> >> > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. >> >> >> >> А где можно почитать по эти новые директивы? >> >> > Пока тут: >> >> > http://trac.nginx.org/nginx/changeset/4386/nginx >> >> > Скоро опишем в документации. In short: если включена директива >> >> > proxy_cache_lock on; >> >> > то при наличии нескольких запросов к конкретному незакешированному >> > ресурсу - на бекенд пойдёт только первый, остальные будут ждать >> > вплоть до proxy_cache_lock_timeout каждый. >> >> Полезная вещь. >> >> Почитал >> http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html >> Странная реализация. Зачем на каждый ожидающий запрос вешать отдельный >> таймаут, если достаточно одного на первый запрос, пошедший к бэкенду? > Таймаута - одного недостаточно, т.к. proxy_cache_lock_timeout > ограничивает время, которое *один конкретный запрос* может провести > в ожидании лока (т.е. дополнительное время ожидания, которое увидит > клиент). У каждого запроса начальное время ожидания своё (да и сам > таймаут теоретически может быть не таким, как у других). А зачем снова долбиться на бэкенд, который не смог ответить? Почему бы всем запросам в очереди не выдать тот же ответ, что получил первый запрос? Они ведь не зря в очередь выстроились и ждут. -- С уважением, Михаил mailto:postmaster на softsearch.ru From zzz на zzz.org.ua Wed Dec 28 19:10:10 2011 From: zzz на zzz.org.ua (Alexandr Gomoliako) Date: Wed, 28 Dec 2011 21:10:10 +0200 Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LTQu9C40L3QvdGL0LUg0YPRgNC70Ysu?= In-Reply-To: <1407322813.20111228225251@softsearch.ru> References: <1407322813.20111228225251@softsearch.ru> Message-ID: On Wed, Dec 28, 2011 at 8:52 PM, Михаил Монашёв wrote: > Можно  как-то  ограничить  в  nginx-е  длину  url-ей , передаваемых на > бэкенд? А то апач выдаёт 403 на длинные урлы Обработать урл перлом :), установить в переменную и использовать ее в proxy_pass. From igor на sysoev.ru Wed Dec 28 19:22:07 2011 From: igor на sysoev.ru (Igor Sysoev) Date: Wed, 28 Dec 2011 23:22:07 +0400 Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LTQu9C40L3QvdGL0LUg0YPRgNC70Ysu?= In-Reply-To: <1407322813.20111228225251@softsearch.ru> References: <1407322813.20111228225251@softsearch.ru> Message-ID: <20111228192207.GB55610@nginx.com> On Wed, Dec 28, 2011 at 10:52:51PM +0400, Михаил Монашёв wrote: > Здравствуйте. > > Можно как-то ограничить в nginx-е длину url-ей , передаваемых на > бэкенд? А то апач выдаёт 403 на длинные урлы > [Wed Dec 28 22:47:07 2011] [error] [client 81.200.127.6] (63)File name too long: access to /interests/%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e\xc8\xd5 \xce\xd7\xc5\xcd\xdc \xcc\xcd\xce\xc3\xce%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e/ failed > и я не знаю как изменить его поведение, например, на выдачу редиректа > на /interests/ или на / . Ну или может в апаче 1.3 есть способ, как > управлять ответом на длинные урлы. location ~ ^/.{1024,} { return http://$host/; } -- Igor Sysoev From daniel на quietsupport.net Wed Dec 28 23:03:33 2011 From: daniel на quietsupport.net (Daniel Yavorovich) Date: Thu, 29 Dec 2011 01:03:33 +0200 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC4INC40LfQvNC10L3QtdC90LjRjyDRhNCw0LnQu9C+?= =?UTF-8?B?0LIu?= In-Reply-To: <4EFB0839.2010406@quietsupport.net> References: <4EFB0839.2010406@quietsupport.net> Message-ID: <4EFBA045.4090406@quietsupport.net> Для моей задачи есть готовое решения, что я не нашёл в документации? 28.12.2011 14:14, Daniel Yavorovich пишет: > Доброго времени суток, коллеги. > > > Сейчас я использую proxy_store для сохранения статических файлов на > фронтенде, но возникла необходимость изменять эти файлы со стороны > бекендов, и, соответственно, обновлять их на front-end'ах. > > Исходя из документации: > > > Директиву можно использовать для создания локальных копий статических > неизменяемых файлов > > я понимаю, что proxy_store в нынешней конфигурации мне не подходит. > > При запросе front-end получает Last Modified Time. Возможно ли при его > изменении (или каким либо другим способом) обновлять realtime > статические файлы на front-end'ах при изменеии их со стороны back-end'ов? > > ---- > Часть конфига одного из front-end'ов: > > # Static files location > location / { > expires 3d; > root /home/user/st; > try_files $uri @front-static; > } > > location @front-static{ > internal; > > proxy_pass http://static; > proxy_set_header Host st001.int; > proxy_store on; > proxy_store_access user:rw group:rw all:r; > proxy_temp_path /home/user/tmp; > > root /home/user/st; > access_log off; > } > > ---- > Часть конфига одного из back-end'ов: > > # Static files location > location / { > root /home/user/st/; > access_log off; > } > > Спасибо. From fry.kun на gmail.com Wed Dec 28 23:26:48 2011 From: fry.kun на gmail.com (Konstantin Svist) Date: Wed, 28 Dec 2011 15:26:48 -0800 Subject: proxy_read_timeout Message-ID: <4EFBA5B8.9020109@gmail.com> Здравствуйте. Можно ли как нибудь установить proxy_read_timeout на лету? Может быть с помощью lua? -- С уважением, Константин From roman.vasilyev на yousendit.com Wed Dec 28 23:32:12 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Wed, 28 Dec 2011 15:32:12 -0800 Subject: =?UTF-8?Q?ngx=5Fhttp=5Finternal=5Fredirect/ngx=5Fhttp=5Fnamed=5Flocation_?= =?UTF-8?Q?=D0=B8_/*_clear_the_modules_contexts_*/?= Message-ID: <4EFBA6FC.8020304@yousendit.com> Я отрабатываю ситуацию когда backend лег и мне нужно просто сохранить некие переменные в лог, который потом распарсить и пропихнуть дальше. Рассчитывал я это сделать как: location ~ /uwsgi/(?P(.*))\.py$ { error_page 502 504 = @fallback; root html/uwsgi; uwsgi_pass 127.0.0.1:9001; include uwsgi_params; ......... } location @fallback { log_format main '$my_important_var'; if ( $app = 'upload' ) { access_log /var/log/nginx/lost.log main; } default_type text/plain; return 200 'AAAAAAAAAAAAAAAAAAA SAVE'; } но когда дело доходило до лога то туда писались только "чисто" Я понимаю, что при внутренних редиректах читсятся контексты модулей. Вопрос, возможно ли такое осуществить? Есть ли варианты обхода? Или есть более простой и надежный механизм сохранения неких кусков в момент сбоя бэкенда? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From roman.vasilyev на yousendit.com Wed Dec 28 23:44:24 2011 From: roman.vasilyev на yousendit.com (Roman Vasilyev) Date: Wed, 28 Dec 2011 15:44:24 -0800 Subject: proxy_read_timeout In-Reply-To: <4EFBA5B8.9020109@gmail.com> References: <4EFBA5B8.9020109@gmail.com> Message-ID: <4EFBA9D8.80008@yousendit.com> On 12/28/2011 03:26 PM, Konstantin Svist wrote: > Здравствуйте. > > Можно ли как нибудь установить proxy_read_timeout на лету? > Может быть с помощью lua? > похоже, что нет разве что с помощью location что то типа if ($a=='123') {rewrite ^ /a1 last;} if ($a=='321') {rewrite ^ /a2 last;} location /a1 { proxy_read_timeout 10; .... } location /a2 { proxy_read_timeout 20; .... } From postmaster на softsearch.ru Thu Dec 29 07:16:50 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 29 Dec 2011 11:16:50 +0400 Subject: =?UTF-8?B?UmVbMl06INCe0YfQtdC90Ywg0LTQu9C40L3QvdGL0LUg0YPRgNC70Ysu?= In-Reply-To: <20111228192207.GB55610@nginx.com> References: <1407322813.20111228225251@softsearch.ru> <20111228192207.GB55610@nginx.com> Message-ID: <276903778.20111229111650@softsearch.ru> Здравствуйте, Igor. >> Можно как-то ограничить в nginx-е длину url-ей , передаваемых на >> бэкенд? А то апач выдаёт 403 на длинные урлы >> [Wed Dec 28 22:47:07 2011] [error] [client 81.200.127.6] >> (63)File name too long: access to >> /interests/%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e\xc8\xd5 >> \xce\xd7\xc5\xcd\xdc >> \xcc\xcd\xce\xc3\xce%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e/ >> failed >> и я не знаю как изменить его поведение, например, на выдачу редиректа >> на /interests/ или на / . Ну или может в апаче 1.3 есть способ, как >> управлять ответом на длинные урлы. > location ~ ^/.{1024,} { > return http://$host/; > } Спасибо. А апач 1.3 имеет ограничение в 1024 символов в урле? Приведённый выше урл короче 1024 символов. -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Thu Dec 29 08:11:45 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Dec 2011 12:11:45 +0400 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC4INC40LfQvNC10L3QtdC90LjRjyDRhNCw0LnQu9C+?= =?UTF-8?B?0LIu?= In-Reply-To: <4EFBA045.4090406@quietsupport.net> References: <4EFB0839.2010406@quietsupport.net> <4EFBA045.4090406@quietsupport.net> Message-ID: <20111229081145.GW67687@mdounin.ru> Hello! On Thu, Dec 29, 2011 at 01:03:33AM +0200, Daniel Yavorovich wrote: > Для моей задачи есть готовое решения, что я не нашёл в документации? Директива proxy_store не предоставляет каких-либо средств для обработки обновления файлов. Если вам нужно обновлять сохранённые файлы - предполагается, что вы будете делать это сами с помощью внешних средств, e.g. удалять сохранённые файлы через ssh/dav/whatever. Maxim Dounin > > 28.12.2011 14:14, Daniel Yavorovich пишет: > >Доброго времени суток, коллеги. > > > > > >Сейчас я использую proxy_store для сохранения статических файлов на > >фронтенде, но возникла необходимость изменять эти файлы со стороны > >бекендов, и, соответственно, обновлять их на front-end'ах. > > > >Исходя из документации: > > > > > Директиву можно использовать для создания локальных копий статических > >неизменяемых файлов > > > >я понимаю, что proxy_store в нынешней конфигурации мне не подходит. > > > >При запросе front-end получает Last Modified Time. Возможно ли при его > >изменении (или каким либо другим способом) обновлять realtime > >статические файлы на front-end'ах при изменеии их со стороны back-end'ов? > > > >---- > >Часть конфига одного из front-end'ов: > > > ># Static files location > >location / { > >expires 3d; > >root /home/user/st; > >try_files $uri @front-static; > >} > > > >location @front-static{ > >internal; > > > >proxy_pass http://static; > >proxy_set_header Host st001.int; > >proxy_store on; > >proxy_store_access user:rw group:rw all:r; > >proxy_temp_path /home/user/tmp; > > > >root /home/user/st; > >access_log off; > >} > > > >---- > >Часть конфига одного из back-end'ов: > > > ># Static files location > >location / { > >root /home/user/st/; > >access_log off; > >} > > > >Спасибо. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From igor на sysoev.ru Thu Dec 29 08:16:01 2011 From: igor на sysoev.ru (Igor Sysoev) Date: Thu, 29 Dec 2011 12:16:01 +0400 Subject: =?UTF-8?B?UmU6INCe0YfQtdC90Ywg0LTQu9C40L3QvdGL0LUg0YPRgNC70Ysu?= In-Reply-To: <276903778.20111229111650@softsearch.ru> References: <1407322813.20111228225251@softsearch.ru> <20111228192207.GB55610@nginx.com> <276903778.20111229111650@softsearch.ru> Message-ID: <20111229081601.GA71359@nginx.com> On Thu, Dec 29, 2011 at 11:16:50AM +0400, Михаил Монашёв wrote: > Здравствуйте, Igor. > > >> Можно как-то ограничить в nginx-е длину url-ей , передаваемых на > >> бэкенд? А то апач выдаёт 403 на длинные урлы > >> [Wed Dec 28 22:47:07 2011] [error] [client 81.200.127.6] > >> (63)File name too long: access to > >> /interests/%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e\xc8\xd5 > >> \xce\xd7\xc5\xcd\xdc > >> \xcc\xcd\xce\xc3\xce%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e/ > >> failed > >> и я не знаю как изменить его поведение, например, на выдачу редиректа > >> на /interests/ или на / . Ну или может в апаче 1.3 есть способ, как > >> управлять ответом на длинные урлы. > > > location ~ ^/.{1024,} { > > return http://$host/; > > } > > Спасибо. > А апач 1.3 имеет ограничение в 1024 символов в урле? Нет, у него 8K. "File name too long" - это ошибка ядра. > Приведённый выше > урл короче 1024 символов. [ENAMETOOLONG] A component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters. location ~ ^/.{1024,} { return http://$host/; } location ~ /[^/]{256,}/ { return http://$host/; } -- Igor Sysoev From postmaster на softsearch.ru Thu Dec 29 08:31:18 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 29 Dec 2011 12:31:18 +0400 Subject: =?UTF-8?B?UmVbMl06INCe0YfQtdC90Ywg0LTQu9C40L3QvdGL0LUg0YPRgNC70Ysu?= In-Reply-To: <20111229081601.GA71359@nginx.com> References: <1407322813.20111228225251@softsearch.ru> <20111228192207.GB55610@nginx.com> <276903778.20111229111650@softsearch.ru> <20111229081601.GA71359@nginx.com> Message-ID: <510101305.20111229123118@softsearch.ru> Здравствуйте, Igor. >> >> Можно как-то ограничить в nginx-е длину url-ей , передаваемых на >> >> бэкенд? А то апач выдаёт 403 на длинные урлы >> >> [Wed Dec 28 22:47:07 2011] [error] [client 81.200.127.6] >> >> (63)File name too long: access to >> >> >> /interests/%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e\xc8\xd5 >> >> \xce\xd7\xc5\xcd\xdc >> >> >> \xcc\xcd\xce\xc3\xce%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e%2e/ >> >> failed >> >> и я не знаю как изменить его поведение, например, на выдачу редиректа >> >> на /interests/ или на / . Ну или может в апаче 1.3 есть способ, как >> >> управлять ответом на длинные урлы. >> >> > location ~ ^/.{1024,} { >> > return http://$host/; >> > } >> >> Спасибо. >> А апач 1.3 имеет ограничение в 1024 символов в урле? > Нет, у него 8K. "File name too long" - это ошибка ядра. >> Приведённый выше >> урл короче 1024 символов. > [ENAMETOOLONG] A component of a pathname exceeded 255 characters, or > an entire path name exceeded 1023 characters. > location ~ ^/.{1024,} { > return http://$host/; > } > location ~ /[^/]{256,}/ { > return http://$host/; > } Ясно. Заодно видимо в Апаче надо будет постепенно переходить с ... на ... Дабы обращения к диску минимизировать. -- С уважением, Михаил mailto:postmaster на softsearch.ru From daniel на quietsupport.net Thu Dec 29 08:50:22 2011 From: daniel на quietsupport.net (Daniel Yavorovich) Date: Thu, 29 Dec 2011 10:50:22 +0200 Subject: =?UTF-8?B?UmU6IHByb3h5X3N0b3JlINC4INC40LfQvNC10L3QtdC90LjRjyDRhNCw0LnQu9C+?= =?UTF-8?B?0LIu?= In-Reply-To: <20111229081145.GW67687@mdounin.ru> References: <4EFB0839.2010406@quietsupport.net> <4EFBA045.4090406@quietsupport.net> <20111229081145.GW67687@mdounin.ru> Message-ID: <4EFC29CE.50807@quietsupport.net> В итоге пришёл к 2 вариантам решения проблемы: * Ври изменении изображений давать ему новое уникальное имя, и раз в n дней чистить файлы старше, чем n+1 дней. * Всё же использовать дополнительные инструменты в коде для взаимодействия с файлами на front-end'ах. Спасибо. 29.12.2011 10:11, Maxim Dounin пишет: > Hello! > > On Thu, Dec 29, 2011 at 01:03:33AM +0200, Daniel Yavorovich wrote: > >> Для моей задачи есть готовое решения, что я не нашёл в документации? > > Директива proxy_store не предоставляет каких-либо средств для > обработки обновления файлов. Если вам нужно обновлять сохранённые > файлы - предполагается, что вы будете делать это сами с помощью > внешних средств, e.g. удалять сохранённые файлы через > ssh/dav/whatever. > > Maxim Dounin > >> >> 28.12.2011 14:14, Daniel Yavorovich пишет: >>> Доброго времени суток, коллеги. >>> >>> >>> Сейчас я использую proxy_store для сохранения статических файлов на >>> фронтенде, но возникла необходимость изменять эти файлы со стороны >>> бекендов, и, соответственно, обновлять их на front-end'ах. >>> >>> Исходя из документации: >>> >>>> Директиву можно использовать для создания локальных копий статических >>> неизменяемых файлов >>> >>> я понимаю, что proxy_store в нынешней конфигурации мне не подходит. >>> >>> При запросе front-end получает Last Modified Time. Возможно ли при его >>> изменении (или каким либо другим способом) обновлять realtime >>> статические файлы на front-end'ах при изменеии их со стороны back-end'ов? >>> >>> ---- >>> Часть конфига одного из front-end'ов: >>> >>> # Static files location >>> location / { >>> expires 3d; >>> root /home/user/st; >>> try_files $uri @front-static; >>> } >>> >>> location @front-static{ >>> internal; >>> >>> proxy_pass http://static; >>> proxy_set_header Host st001.int; >>> proxy_store on; >>> proxy_store_access user:rw group:rw all:r; >>> proxy_temp_path /home/user/tmp; >>> >>> root /home/user/st; >>> access_log off; >>> } >>> >>> ---- >>> Часть конфига одного из back-end'ов: >>> >>> # Static files location >>> location / { >>> root /home/user/st/; >>> access_log off; >>> } >>> >>> Спасибо. >> >> _______________________________________________ >> 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 serp256 на gmail.com Thu Dec 29 08:49:05 2011 From: serp256 на gmail.com (SerP) Date: Thu, 29 Dec 2011 11:49:05 +0300 Subject: half-closed socket Message-ID: Столкнулись с проблемой при использовании nginx. Отдаем статические файлы, и после жалоб пользвателей, нашли в логах странные строчки, когда размер файла не совпадает с $body_bytes_sent, причем статус ответа 200. После анализа пришли к выводу, что клиенты иногда посылают запрос и вызывают команду shutdown send на сокете, nginx это расценивает как закрытие сокета и не досылает файл до конца. Другие сервера себя так не ведут, apache, lighttpd. В документации не нашел ничего что могло бы исправить такое поведение nginx. Может быть есть средство? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Dec 29 10:08:07 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Dec 2011 14:08:07 +0400 Subject: nginx-1.1.12 In-Reply-To: <66186103.20111228225702@softsearch.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> <20111228131906.GR67687@mdounin.ru> <882038476.20111228180428@softsearch.ru> <20111228162127.GU67687@mdounin.ru> <66186103.20111228225702@softsearch.ru> Message-ID: <20111229100807.GY67687@mdounin.ru> Hello! On Wed, Dec 28, 2011 at 10:57:02PM +0400, Михаил Монашёв wrote: > Здравствуйте, Maxim. > > >> >> > *) Добавление: директивы > >> proxy/fastcgi/scgi/uwsgi_cache_lock, > >> >> > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. > >> >> > >> >> А где можно почитать по эти новые директивы? > >> > >> > Пока тут: > >> > >> > http://trac.nginx.org/nginx/changeset/4386/nginx > >> > >> > Скоро опишем в документации. In short: если включена директива > >> > >> > proxy_cache_lock on; > >> > >> > то при наличии нескольких запросов к конкретному незакешированному > >> > ресурсу - на бекенд пойдёт только первый, остальные будут ждать > >> > вплоть до proxy_cache_lock_timeout каждый. > >> > >> Полезная вещь. > >> > >> Почитал > >> http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html > >> Странная реализация. Зачем на каждый ожидающий запрос вешать отдельный > >> таймаут, если достаточно одного на первый запрос, пошедший к бэкенду? > > > Таймаута - одного недостаточно, т.к. proxy_cache_lock_timeout > > ограничивает время, которое *один конкретный запрос* может провести > > в ожидании лока (т.е. дополнительное время ожидания, которое увидит > > клиент). У каждого запроса начальное время ожидания своё (да и сам > > таймаут теоретически может быть не таким, как у других). > > А зачем снова долбиться на бэкенд, который не смог ответить? Почему бы > всем запросам в очереди не выдать тот же ответ, что получил первый > запрос? Они ведь не зря в очередь выстроились и ждут. В общем случае мы не знаем, смог бекенд ответить или нет. Ответ может занять существенно большее время, чем время proxy_cache_lock_timeout. В худшем случае - ответ будет через заметное время, и при этом его нельзя будет кешировать (и соответственно отдать другим ожидающим клиентам). Если таймаутов не будет - то в такой ситуации все запросы будут отправляться на бекенд по одному, и с большой вероятностью части ответов клиенты просто не дождутся. Директива proxy_cache_lock_timeout позволяет ограничить время, проводимое запросом в ожидании лока, и соотвтетственно определяет максимально возможную задержку, вносимую этим механизмом. Т.е. в худшем случае время ответа будет <как было> + _cache_lock_timeout. Maxim Dounin From s на bykov.odessa.ua Thu Dec 29 13:34:52 2011 From: s на bykov.odessa.ua (s на bykov.odessa.ua) Date: Thu, 29 Dec 2011 15:34:52 +0200 Subject: =?UTF-8?B?0JLRi9C90YPQttC00LXQvSDRgdC+0L7QsdGJ0LjRgtGMINC+0LEg0Y3RgtC+0Lwg?= =?UTF-8?B?0YHQtdC50YfQsNGB?= Message-ID: <4EFC6C7C.40005@bykov.odessa.ua> Всем привет. Праздновать мы уже начали и, к сожалению, сегодня последний шанс сделать это в здравом уме. С наступающим новым годом! С рождеством! И (тем кто доживет до этого дня) со Старым Новым Годом! From igor на sysoev.ru Thu Dec 29 13:55:34 2011 From: igor на sysoev.ru (Igor Sysoev) Date: Thu, 29 Dec 2011 17:55:34 +0400 Subject: half-closed socket In-Reply-To: References: Message-ID: <20111229135533.GA78522@nginx.com> On Thu, Dec 29, 2011 at 11:49:05AM +0300, SerP wrote: > Столкнулись с проблемой при использовании nginx. Отдаем статические файлы, > и после жалоб пользвателей, нашли в логах странные строчки, когда размер > файла не совпадает с $body_bytes_sent, причем статус ответа 200. После > анализа пришли к выводу, что клиенты иногда посылают запрос и вызывают > команду shutdown send на сокете, nginx это расценивает как закрытие сокета > и не досылает файл до конца. Какой у них User-Agent ? > Другие сервера себя так не ведут, apache, lighttpd. В документации не нашел > ничего что могло бы исправить такое поведение nginx. Может быть есть > средство? На данный момент - нет. -- Igor Sysoev From mdounin на mdounin.ru Thu Dec 29 13:55:54 2011 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 29 Dec 2011 17:55:54 +0400 Subject: half-closed socket In-Reply-To: References: Message-ID: <20111229135554.GG67687@mdounin.ru> Hello! On Thu, Dec 29, 2011 at 11:49:05AM +0300, SerP wrote: > Столкнулись с проблемой при использовании nginx. Отдаем статические файлы, > и после жалоб пользвателей, нашли в логах странные строчки, когда размер > файла не совпадает с $body_bytes_sent, причем статус ответа 200. После > анализа пришли к выводу, что клиенты иногда посылают запрос и вызывают > команду shutdown send на сокете, nginx это расценивает как закрытие сокета > и не досылает файл до конца. > Другие сервера себя так не ведут, apache, lighttpd. В документации не нашел > ничего что могло бы исправить такое поведение nginx. Может быть есть > средство? Э... Инструкция "не делайте так" в данном случае помогает лучше всего, но вообще говоря при раздаче статики этого наблюдаться не должно. Точно при раздаче статики? Вообще такое обычно наблюдается при проксировании, помогает proxy_ignore_client_abort on; http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort Maxim Dounin From postmaster на softsearch.ru Thu Dec 29 15:24:46 2011 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 29 Dec 2011 19:24:46 +0400 Subject: nginx-1.1.12 In-Reply-To: <20111229100807.GY67687@mdounin.ru> References: <20111226154851.GL67687@mdounin.ru> <1952835407.20111228165327@softsearch.ru> <20111228131906.GR67687@mdounin.ru> <882038476.20111228180428@softsearch.ru> <20111228162127.GU67687@mdounin.ru> <66186103.20111228225702@softsearch.ru> <20111229100807.GY67687@mdounin.ru> Message-ID: <1263952075.20111229192446@softsearch.ru> Здравствуйте, Maxim. >> >> >> > *) Добавление: директивы >> >> proxy/fastcgi/scgi/uwsgi_cache_lock, >> >> >> > proxy/fastcgi/scgi/uwsgi_cache_lock_timeout. >> >> >> >> >> >> А где можно почитать по эти новые директивы? >> >> >> >> > Пока тут: >> >> >> >> > http://trac.nginx.org/nginx/changeset/4386/nginx >> >> >> >> > Скоро опишем в документации. In short: если включена директива >> >> >> >> > proxy_cache_lock on; >> >> >> >> > то при наличии нескольких запросов к конкретному незакешированному >> >> > ресурсу - на бекенд пойдёт только первый, остальные будут ждать >> >> > вплоть до proxy_cache_lock_timeout каждый. >> >> >> >> Полезная вещь. >> >> >> >> Почитал >> >> >> http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html >> >> Странная реализация. Зачем на каждый ожидающий запрос вешать отдельный >> >> таймаут, если достаточно одного на первый запрос, пошедший к бэкенду? >> >> > Таймаута - одного недостаточно, т.к. proxy_cache_lock_timeout >> > ограничивает время, которое *один конкретный запрос* может провести >> > в ожидании лока (т.е. дополнительное время ожидания, которое увидит >> > клиент). У каждого запроса начальное время ожидания своё (да и сам >> > таймаут теоретически может быть не таким, как у других). >> >> А зачем снова долбиться на бэкенд, который не смог ответить? Почему бы >> всем запросам в очереди не выдать тот же ответ, что получил первый >> запрос? Они ведь не зря в очередь выстроились и ждут. > В общем случае мы не знаем, смог бекенд ответить или нет. Ответ > может занять существенно большее время, чем время > proxy_cache_lock_timeout. В худшем случае - ответ будет через > заметное время, и при этом его нельзя будет кешировать (и > соответственно отдать другим ожидающим клиентам). Если таймаутов > не будет - то в такой ситуации все запросы будут отправляться на > бекенд по одному, и с большой вероятностью части ответов клиенты > просто не дождутся. > Директива proxy_cache_lock_timeout позволяет ограничить время, > проводимое запросом в ожидании лока, и соотвтетственно определяет > максимально возможную задержку, вносимую этим механизмом. Т.е. в > худшем случае время ответа будет <как было> + _cache_lock_timeout. Идею понял. Она даже лучше, чем изначально казалась :-) -- С уважением, Михаил mailto:postmaster на softsearch.ru From admin на tlvx.ru Thu Dec 29 22:40:10 2011 From: admin на tlvx.ru (=?KOI8-R?B?7M/QwdTJziD3zMHEyc3J0g==?=) Date: Fri, 30 Dec 2011 07:40:10 +0900 Subject: =?UTF-8?B?UmU6INCS0YvQvdGD0LbQtNC10L0g0YHQvtC+0LHRidC40YLRjCDQvtCxINGN0YI=?= =?UTF-8?B?0L7QvCDRgdC10LnRh9Cw0YE=?= In-Reply-To: <4EFC6C7C.40005@bykov.odessa.ua> References: <4EFC6C7C.40005@bykov.odessa.ua> Message-ID: 29 декабря 2011 г. 23:34 пользователь s на bykov.odessa.ua написал: > Всем привет. Праздновать мы уже начали и, к сожалению, сегодня последний > шанс сделать это в здравом уме. > > С наступающим новым годом! С рождеством! И (тем кто доживет до этого дня) > со Старым Новым Годом! > > Присоеденяюсь к поздравлению, всех с наступающим новым годом удачно отметить и не падающих серверов =) ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From serp256 на gmail.com Fri Dec 30 07:31:04 2011 From: serp256 на gmail.com (SerP) Date: Fri, 30 Dec 2011 10:31:04 +0300 Subject: half-closed socket In-Reply-To: <20111229135554.GG67687@mdounin.ru> References: <20111229135554.GG67687@mdounin.ru> Message-ID: Мы протестировали это, и если клиент вызывает shutdown то именно так и происходит, просто не понятно почему "не должно". Здесь можно только рассчитывать что ни один клиент (ни один из браузеров) так делать не будет. 2011/12/29 Maxim Dounin > Hello! > > On Thu, Dec 29, 2011 at 11:49:05AM +0300, SerP wrote: > > > Столкнулись с проблемой при использовании nginx. Отдаем статические > файлы, > > и после жалоб пользвателей, нашли в логах странные строчки, когда размер > > файла не совпадает с $body_bytes_sent, причем статус ответа 200. После > > анализа пришли к выводу, что клиенты иногда посылают запрос и вызывают > > команду shutdown send на сокете, nginx это расценивает как закрытие > сокета > > и не досылает файл до конца. > > Другие сервера себя так не ведут, apache, lighttpd. В документации не > нашел > > ничего что могло бы исправить такое поведение nginx. Может быть есть > > средство? > > Э... Инструкция "не делайте так" в данном случае помогает лучше > всего, но вообще говоря при раздаче статики этого наблюдаться не > должно. Точно при раздаче статики? > > Вообще такое обычно наблюдается при проксировании, помогает > > proxy_ignore_client_abort on; > > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort > > Maxim Dounin > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From serp256 на gmail.com Fri Dec 30 07:37:25 2011 From: serp256 на gmail.com (SerP) Date: Fri, 30 Dec 2011 10:37:25 +0300 Subject: half-closed socket In-Reply-To: <20111229135533.GA78522@nginx.com> References: <20111229135533.GA78522@nginx.com> Message-ID: User-Agent совершенно различный. Но здесь же не понятно, был это нормальный close или таки shutdown, на стороне сервера нет различий, судя по strace, nginx шлет файл, потом получает от epoll (система linux) EPOLLIN, делает recvfrom - получает 0 и закрывает сокет, здесь таки корректней было дождаться EPIPE при записи, тогда уже четно понятно что клиенту не нужны наши данные, разве нет? 2011/12/29 Igor Sysoev > On Thu, Dec 29, 2011 at 11:49:05AM +0300, SerP wrote: > > Столкнулись с проблемой при использовании nginx. Отдаем статические > файлы, > > и после жалоб пользвателей, нашли в логах странные строчки, когда размер > > файла не совпадает с $body_bytes_sent, причем статус ответа 200. После > > анализа пришли к выводу, что клиенты иногда посылают запрос и вызывают > > команду shutdown send на сокете, nginx это расценивает как закрытие > сокета > > и не досылает файл до конца. > > Какой у них User-Agent ? > > > Другие сервера себя так не ведут, apache, lighttpd. В документации не > нашел > > ничего что могло бы исправить такое поведение nginx. Может быть есть > > средство? > > На данный момент - нет. > > > -- > Igor Sysoev > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From igor на sysoev.ru Fri Dec 30 08:10:57 2011 From: igor на sysoev.ru (Igor Sysoev) Date: Fri, 30 Dec 2011 12:10:57 +0400 Subject: half-closed socket In-Reply-To: References: <20111229135554.GG67687@mdounin.ru> Message-ID: <20111230081057.GA152@nginx.com> On Fri, Dec 30, 2011 at 10:31:04AM +0300, SerP wrote: > Мы протестировали это, и если клиент вызывает shutdown то именно так и > происходит, просто не понятно почему "не должно". Здесь можно только > рассчитывать что ни один клиент (ни один из браузеров) так делать не будет. Ни один из бразуеров так и не делает. > 2011/12/29 Maxim Dounin > > > Hello! > > > > On Thu, Dec 29, 2011 at 11:49:05AM +0300, SerP wrote: > > > > > Столкнулись с проблемой при использовании nginx. Отдаем статические > > файлы, > > > и после жалоб пользвателей, нашли в логах странные строчки, когда размер > > > файла не совпадает с $body_bytes_sent, причем статус ответа 200. После > > > анализа пришли к выводу, что клиенты иногда посылают запрос и вызывают > > > команду shutdown send на сокете, nginx это расценивает как закрытие > > сокета > > > и не досылает файл до конца. > > > Другие сервера себя так не ведут, apache, lighttpd. В документации не > > нашел > > > ничего что могло бы исправить такое поведение nginx. Может быть есть > > > средство? > > > > Э... Инструкция "не делайте так" в данном случае помогает лучше > > всего, но вообще говоря при раздаче статики этого наблюдаться не > > должно. Точно при раздаче статики? > > > > Вообще такое обычно наблюдается при проксировании, помогает > > > > proxy_ignore_client_abort on; > > > > > > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort -- Igor Sysoev From me на kemko.ru Fri Dec 30 08:19:33 2011 From: me на kemko.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdC00YDQtdC10LI=?=) Date: Fri, 30 Dec 2011 12:19:33 +0400 Subject: half-closed socket In-Reply-To: <20111230081057.GA152@nginx.com> References: <20111229135554.GG67687@mdounin.ru> <20111230081057.GA152@nginx.com> Message-ID: Эти пользователи не могли оказаться за прокси-серверами?