From differentlocal at gmail.com Fri Nov 1 07:12:12 2013 From: differentlocal at gmail.com (Nikita A Kardashin) Date: Fri, 1 Nov 2013 13:12:12 +0600 Subject: =?UTF-8?B?0KHQtdGA0LLQtdGAINC/0L4t0YPQvNC+0LvRh9Cw0L3QuNGOINC00LvRjyDQutC+?= =?UTF-8?B?0L3QutGA0LXRgtC90L7Qs9C+INC00L7QvNC10L3QsA==?= Message-ID: Всем привет, Возникла задача: - На один nginx ссылаются >1 домена, при этом, для каждого из них должен быть доступен SSL (есть сертификаты). - Все запросы к несуществующим на сервере хостам должны попадать в некий хост по-умолчанию (и редиректиться оттуда rewrite-ом, но это частности). Т.е, поступает запрос. Если есть сервер, для которого запрошенный хост прописан в server_name - отправляем его туда. Если нет - в сервер по-умолчанию для domain.tld, откуда его регулярка отправляет "по адресу" (на главный сайт в зависимости от запрошенного домена). Классическая схема (сервера + один сервер с опцией default) прекрасно работала до тех пор, пока домен был один, а сейчас - не вариант, т.к. мы не можем прописать в сервере больше, чем 1 SSL-сертификат (в результате чего пользователь при обращении к несуществующему серверу по домену, отличному от первого вместо ожидаемого редиректа получает неожиданный FailedCertificateAlert от браузера и блокировку дальнейшего редиректа). Если же создать сервер с server_name = *.domain.tld для каждого домена, то туда попадают все запросы, даже те, для которых есть отдельные server-ы. Есть какой-то нормальный путь это обойти? Например, задавать приоритет серверу (тогда можно поставить минимальный умолчальному серверу и запрос таки будет улетать туда только тогда, когда более подходящих серверов нет). Или выбирать сертификат в зависимости от домена (по IF-у)? -- With best regards, differentlocal (www.differentlocal.ru | differentlocal at gmail.com), System administrator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor at sysoev.ru Fri Nov 1 08:56:22 2013 From: igor at sysoev.ru (Igor Sysoev) Date: Fri, 1 Nov 2013 12:56:22 +0400 Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+LdGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?= =?UTF-8?B?0LrQvtC90LrRgNC10YLQvdC+0LPQviDQtNC+0LzQtdC90LA=?= In-Reply-To: References: Message-ID: http://nginx.org/ru/docs/http/configuring_https_servers.html#name_based_https_servers -- Igor Sysoev http://nginx.com On Nov 1, 2013, at 11:12 , Nikita A Kardashin wrote: > Всем привет, > > Возникла задача: > > - На один nginx ссылаются >1 домена, при этом, для каждого из них должен быть доступен SSL (есть сертификаты). > - Все запросы к несуществующим на сервере хостам должны попадать в некий хост по-умолчанию (и редиректиться оттуда rewrite-ом, но это частности). > > Т.е, поступает запрос. Если есть сервер, для которого запрошенный хост прописан в server_name - отправляем его туда. Если нет - в сервер по-умолчанию для domain.tld, откуда его регулярка отправляет "по адресу" (на главный сайт в зависимости от запрошенного домена). > > Классическая схема (сервера + один сервер с опцией default) прекрасно работала до тех пор, пока домен был один, а сейчас - не вариант, т.к. мы не можем прописать в сервере больше, чем 1 SSL-сертификат (в результате чего пользователь при обращении к несуществующему серверу по домену, отличному от первого вместо ожидаемого редиректа получает неожиданный FailedCertificateAlert от браузера и блокировку дальнейшего редиректа). > > Если же создать сервер с server_name = *.domain.tld для каждого домена, то туда попадают все запросы, даже те, для которых есть отдельные server-ы. > > Есть какой-то нормальный путь это обойти? Например, задавать приоритет серверу (тогда можно поставить минимальный умолчальному серверу и запрос таки будет улетать туда только тогда, когда более подходящих серверов нет). Или выбирать сертификат в зависимости от домена (по IF-у)? > > -- > With best regards, > differentlocal (www.differentlocal.ru | differentlocal at gmail.com), > System administrator. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at skubriev.ru Fri Nov 1 09:04:02 2013 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Fri, 01 Nov 2013 13:04:02 +0400 Subject: upstream prematurely closed connection while reading response header from upstream Message-ID: <52736E82.4010807@skubriev.ru> Вопрос, если в логе nginx появляется сообщение (раз в 10-20 обновлений страницы) upstream prematurely closed connection while reading response header from upstream и при этом на бэкенде в логах конкретно об этом запросе ни чего нет но предыдущие запросы и последующие запросы нормально логируются. Зачит куда нужно копать ? Я понимаю, что дело в бэкенде, тем более, что я менял бэкенд - со старым все работает нормально. Проверял работу через HTTPS поднятом на nginx c валидными сертификатами. Использовать для тестов 443 порт не могу, т.к. через него сейчас работают люди со старым сервером. Другой backend - очень старая версия redmine под apache и из старой ubuntu 10.04 Новый backend - lxc контейнер с новой версией redmine и новым apache из ubuntu 12.04 на том же же серевере где стоит прокси nginx. Спасибо. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru From megalin2 at gmail.com Fri Nov 1 10:07:16 2013 From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=) Date: Fri, 1 Nov 2013 16:07:16 +0600 Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+LdGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?= =?UTF-8?B?0LrQvtC90LrRgNC10YLQvdC+0LPQviDQtNC+0LzQtdC90LA=?= In-Reply-To: References: Message-ID: Так, я, видимо, не очень правильно описал проблему. Попробую еще раз: - Есть домены: domain1.tld domain2.tld domain3.tld Сами главные домены хостятся где-то в другом, отличном от нашего сервера, месте. Для каждого из них есть wildcard SSL-сертификат. На нашем сервере хостятся приложения, доступные по поддоменам этих доменов (app1.domain2.tld, app10.domain3.tld, etc). Для каждого приложения создан конфиг в sites-enabled с описанием сервера (где задается и нужный SSL-сертификат, в зависимости от того, в каком домене находится приложение). Доступны они только по SSL (по сертификату *.domain.tld). Но иногда приложения удаляются, а ссылки на них где-то живут. Мне нужно каким-то образом реализовать возможность редиректить все запросы к адресам а-ля https://appX.domainX.tld/, в случае, если приложение уже не существует (т.е. сервер appX.domainX.tld не описан в конфиге nginx). Пока домен был один - я эту проблему решал просто, определил в конфиге один сервер с признаком default и там уже в location / осуществлял редирект на нужный сайт. Все прекрасно работало. А теперь сайтов стало три. В описании default-сервера я могу задать только одну пару сертификат:ключ, соответственно, те, кто придет по appX.domainX.tld (в случае, если домен отличается от того, чей сертификат прописан) в default-сервер получат в браузере ошибку (и не получат редирект). Прописать для каждого из доменов сервер с server_name *.domainX.tld я тоже не могу, т.к. тогда туда пойдут не только запросы к несуществующим приложениям, а вообще ВСЕ запросы (т.е. в приложение никто не попадет). Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов на одном IP (это-то прекрасно работает, тут проблем нет), а в том, что мне нужно каким-то образом иметь несколько default-серверов с поддержкой SSL (либо иметь возможность задавать приоритеты серверам, чтобы запрос всегда попадал в более точный сервер (appX.domainX.tld), а не в wildcard *.domainX.tld). Как мне из этой ситуации выйти? 1 ноября 2013 г., 14:56 пользователь Igor Sysoev написал: > > http://nginx.org/ru/docs/http/configuring_https_servers.html#name_based_https_servers > > > -- > Igor Sysoev > http://nginx.com > > On Nov 1, 2013, at 11:12 , Nikita A Kardashin wrote: > > Всем привет, > > Возникла задача: > > - На один nginx ссылаются >1 домена, при этом, для каждого из них должен > быть доступен SSL (есть сертификаты). > - Все запросы к несуществующим на сервере хостам должны попадать в некий > хост по-умолчанию (и редиректиться оттуда rewrite-ом, но это частности). > > Т.е, поступает запрос. Если есть сервер, для которого запрошенный хост > прописан в server_name - отправляем его туда. Если нет - в сервер > по-умолчанию для domain.tld, откуда его регулярка отправляет "по адресу" > (на главный сайт в зависимости от запрошенного домена). > > Классическая схема (сервера + один сервер с опцией default) прекрасно > работала до тех пор, пока домен был один, а сейчас - не вариант, т.к. мы не > можем прописать в сервере больше, чем 1 SSL-сертификат (в результате чего > пользователь при обращении к несуществующему серверу по домену, отличному > от первого вместо ожидаемого редиректа получает неожиданный > FailedCertificateAlert от браузера и блокировку дальнейшего редиректа). > > Если же создать сервер с server_name = *.domain.tld для каждого домена, то > туда попадают все запросы, даже те, для которых есть отдельные server-ы. > > Есть какой-то нормальный путь это обойти? Например, задавать приоритет > серверу (тогда можно поставить минимальный умолчальному серверу и запрос > таки будет улетать туда только тогда, когда более подходящих серверов нет). > Или выбирать сертификат в зависимости от домена (по IF-у)? > > -- > With best regards, > differentlocal (www.differentlocal.ru | differentlocal at gmail.com), > System administrator. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- With best regards, differentlocal (www.differentlocal.ru | differentlocal at gmail.com), System administrator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at skubriev.ru Fri Nov 1 10:14:45 2013 From: vladimir at skubriev.ru (Vladimir Skubriev) Date: Fri, 01 Nov 2013 14:14:45 +0400 Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+LdGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?= =?UTF-8?B?0LrQvtC90LrRgNC10YLQvdC+0LPQviDQtNC+0LzQtdC90LA=?= In-Reply-To: References: Message-ID: <52737F15.4040007@skubriev.ru> 01.11.2013 14:07, Никита Кардашин пишет: > Так, я, видимо, не очень правильно описал проблему. Попробую еще раз: > > - Есть домены: > domain1.tld > domain2.tld > domain3.tld > > Сами главные домены хостятся где-то в другом, отличном от нашего > сервера, месте. Для каждого из них есть wildcard SSL-сертификат. > > На нашем сервере хостятся приложения, доступные по поддоменам этих > доменов (app1.domain2.tld, app10.domain3.tld, etc). Для каждого > приложения создан конфиг в sites-enabled с описанием сервера (где > задается и нужный SSL-сертификат, в зависимости от того, в каком > домене находится приложение). Доступны они только по SSL (по > сертификату *.domain.tld). Но иногда приложения удаляются, а ссылки на > них где-то живут. > > Мне нужно каким-то образом реализовать возможность редиректить все > запросы к адресам а-ля https://appX.domainX.tld/, в случае, если > приложение уже не существует (т.е. сервер appX.domainX.tld не описан в > конфиге nginx). > > Пока домен был один - я эту проблему решал просто, определил в конфиге > один сервер с признаком default и там уже в location / осуществлял > редирект на нужный сайт. Все прекрасно работало. > > А теперь сайтов стало три. В описании default-сервера я могу задать > только одну пару сертификат:ключ, соответственно, те, кто придет по > appX.domainX.tld (в случае, если домен отличается от того, чей > сертификат прописан) в default-сервер получат в браузере ошибку (и не > получат редирект). > > Прописать для каждого из доменов сервер с server_name *.domainX.tld я > тоже не могу, т.к. тогда туда пойдут не только запросы к > несуществующим приложениям, а вообще ВСЕ запросы (т.е. в приложение > никто не попадет). > > Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов > на одном IP (это-то прекрасно работает, тут проблем нет), а в том, что > мне нужно каким-то образом иметь несколько default-серверов с > поддержкой SSL (либо иметь возможность задавать приоритеты серверам, > чтобы запрос всегда попадал в более точный сервер (appX.domainX.tld), > а не в wildcard *.domainX.tld). > > Как мне из этой ситуации выйти? Из документации Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе ---расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Однако, поддержка SNI браузерами ограничена. Сейчас это поддерживается браузерами начиная со следующих версий: Другим способом является использование wildcard-сертификата, например|*.example.org|. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. Под такой сертификат подходит|www.example.org|, но не подходят|example.org|и|www.sub.example.org|. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле SubjectAltName, например|example.org|и|*.example.org|. Боюсь что это не может быть, т.к. не могу все клиенты поддерживать SNI. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From megalin2 at gmail.com Fri Nov 1 12:07:53 2013 From: megalin2 at gmail.com (=?KOI8-R?B?7snLydTBIOvB0sTB28nO?=) Date: Fri, 1 Nov 2013 18:07:53 +0600 Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+LdGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?= =?UTF-8?B?0LrQvtC90LrRgNC10YLQvdC+0LPQviDQtNC+0LzQtdC90LA=?= In-Reply-To: <52737F15.4040007@skubriev.ru> References: <52737F15.4040007@skubriev.ru> Message-ID: Не смог найти в документации, как мне в _одном_ server{} настроить более 1 сертификата (SNI). Это возможно? 1 ноября 2013 г., 16:14 пользователь Vladimir Skubriev написал: > 01.11.2013 14:07, Никита Кардашин пишет: > > Так, я, видимо, не очень правильно описал проблему. Попробую еще раз: > > - Есть домены: > domain1.tld > domain2.tld > domain3.tld > > Сами главные домены хостятся где-то в другом, отличном от нашего > сервера, месте. Для каждого из них есть wildcard SSL-сертификат. > > На нашем сервере хостятся приложения, доступные по поддоменам этих > доменов (app1.domain2.tld, app10.domain3.tld, etc). Для каждого приложения > создан конфиг в sites-enabled с описанием сервера (где задается и нужный > SSL-сертификат, в зависимости от того, в каком домене находится > приложение). Доступны они только по SSL (по сертификату *.domain.tld). Но > иногда приложения удаляются, а ссылки на них где-то живут. > > Мне нужно каким-то образом реализовать возможность редиректить все > запросы к адресам а-ля https://appX.domainX.tld/, в случае, если > приложение уже не существует (т.е. сервер appX.domainX.tld не описан в > конфиге nginx). > > Пока домен был один - я эту проблему решал просто, определил в конфиге > один сервер с признаком default и там уже в location / осуществлял редирект > на нужный сайт. Все прекрасно работало. > > А теперь сайтов стало три. В описании default-сервера я могу задать > только одну пару сертификат:ключ, соответственно, те, кто придет по > appX.domainX.tld (в случае, если домен отличается от того, чей сертификат > прописан) в default-сервер получат в браузере ошибку (и не получат > редирект). > > Прописать для каждого из доменов сервер с server_name *.domainX.tld я > тоже не могу, т.к. тогда туда пойдут не только запросы к несуществующим > приложениям, а вообще ВСЕ запросы (т.е. в приложение никто не попадет). > > Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов > на одном IP (это-то прекрасно работает, тут проблем нет), а в том, что мне > нужно каким-то образом иметь несколько default-серверов с поддержкой SSL > (либо иметь возможность задавать приоритеты серверам, чтобы запрос всегда > попадал в более точный сервер (appX.domainX.tld), а не в wildcard > *.domainX.tld). > > Как мне из этой ситуации выйти? > > Из документации > > Более общее решение для работы нескольких HTTPS-серверов на одном > IP-адресе -- расширение Server Name Indication протокола TLS > (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя > сервера во время SSL handshake, а значит сервер будет знать, какой > сертификат ему следует использовать для соединения. Однако, поддержка SNI > браузерами ограничена. Сейчас это поддерживается браузерами начиная со > следующих версий: > > Другим способом является использование wildcard-сертификата, например *. > example.org. Такой сертификат защищает все поддомены указанного домена, > но только на заданном уровне. Под такой сертификат подходит > www.example.org, но не подходят example.org и www.sub.example.org. Два > вышеуказанных способа можно комбинировать. Сертификат может одновременно > содержать и точное, и wildcard имена в поле SubjectAltName, например > example.org и *.example.org. > Боюсь что это не может быть, т.к. не могу все клиенты поддерживать SNI. > > > > -- > С Уважением, > специалист по техническому и программному обеспечению, > системный администратор > > Скубриев Владимир > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Россия, Ростовская область, г. Таганрог > > тел. моб: +7 (918) 504 38 20 > skype: v.skubriev > icq: 214-800-502 > www: skubriev.ru > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- With best regards, differentlocal (www.differentlocal.ru | differentlocal at gmail.com), System administrator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kobzar at itcraft.org Fri Nov 1 12:23:32 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 14:23:32 +0200 Subject: =?UTF-8?B?0KPQv9GA0LDQstC70LXQvdC40LUg0LHRjdC60LXQvdC00LDQvNC4?= Message-ID: <52739D44.20508@itcraft.org> Приветсвую Nginx стоит как frontend. За ним находится несколько десятков или более бэкендов (разные servername). Необходимо динамически управлять на какой бэкенд запрос упадет. Править nginx.conf и перечитывает его не вариант, т.к. это может происходить ежесекундно. Думал хранить соответствие servername -> backend в memcached, но nginx похоже только умеет доставать http response и memcached. Остается только Nginx -> Perl -> Memcached. Или есть еще варинаты? lua? From wangsamp at gmail.com Fri Nov 1 12:25:17 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Fri, 1 Nov 2013 14:25:17 +0200 (EET) Subject: =?UTF-8?B?UmU6INCh0LXRgNCy0LXRgCDQv9C+LdGD0LzQvtC70YfQsNC90LjRjiDQtNC70Y8g?= =?UTF-8?B?0LrQvtC90LrRgNC10YLQvdC+0LPQviDQtNC+0LzQtdC90LA=?= In-Reply-To: References: Message-ID: Today Nov 1, 2013 at 16:07 Никита Кардашин wrote: > Прописать для каждого из доменов сервер с server_name *.domainX.tld я тоже > не могу, т.к. тогда туда пойдут не только запросы к несуществующим > приложениям, а вообще ВСЕ запросы (т.е. в приложение никто не попадет). http://nginx.org/r/server_name/ru При поиске виртуального сервера по имени, если имени соответствует несколько из указанных вариантов, например, одновременно подходят и имя с маской, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета: 1. точное имя 2. самое длинное имя с маской в начале, например .*.example.com. 3. самое длинное имя с маской в конце, например .mail.*. 4. первое подходящее регулярное выражение (в порядке следования в конфигурационном файле) Используйте точные имена в server_name для приложений или проследите дабы они были выше по конфигу чем с перенаправлением. -- WNGS-RIPE From vbart at nginx.com Fri Nov 1 12:26:21 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 1 Nov 2013 16:26:21 +0400 Subject: =?UTF-8?B?UmU6ICDQodC10YDQstC10YAg0L/Qvi3Rg9C80L7Qu9GH0LDQvdC40Y4g0LTQu9GP?= =?UTF-8?B?INC60L7QvdC60YDQtdGC0L3QvtCz0L4g0LTQvtC80LXQvdCw?= In-Reply-To: References: Message-ID: <201311011626.21230.vbart@nginx.com> On Friday 01 November 2013 14:07:16 Никита Кардашин wrote: [..] > Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов на > одном IP (это-то прекрасно работает, тут проблем нет), а в том, что мне > нужно каким-то образом иметь несколько default-серверов с поддержкой SSL > (либо иметь возможность задавать приоритеты серверам, чтобы запрос всегда > попадал в более точный сервер (appX.domainX.tld), а не в wildcard > *.domainX.tld). > Запрос всегда попадает "в более точный сервер". См. документацию: http://nginx.org/r/server_name/ru со строк "При поиске виртуального сервера по имени...". Если у вас не так, то либо просто не работает SNI, либо вы что-то перемудрили. -- Валентин Бартенев From wangsamp at gmail.com Fri Nov 1 12:28:15 2013 From: wangsamp at gmail.com (Oleksandr V. Typlyns'kyi) Date: Fri, 1 Nov 2013 14:28:15 +0200 (EET) Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <52739D44.20508@itcraft.org> References: <52739D44.20508@itcraft.org> Message-ID: Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: > Приветсвую > > Nginx стоит как frontend. За ним находится несколько десятков или более > бэкендов (разные servername). Необходимо динамически управлять на какой > бэкенд запрос упадет. > > Править nginx.conf и перечитывает его не вариант, т.к. это может > происходить ежесекундно. http://nginx.org/r/upstream_conf Одно но: This directive is available as part of our commercial subscription only. -- WNGS-RIPE From vbart at nginx.com Fri Nov 1 12:32:08 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Nov 2013 16:32:08 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <52739D44.20508@itcraft.org> References: <52739D44.20508@itcraft.org> Message-ID: <201311011632.08456.vbart@nginx.com> On Friday 01 November 2013 16:23:32 Sergey Kobzar wrote: > Приветсвую > > Nginx стоит как frontend. За ним находится несколько десятков или более > бэкендов (разные servername). Необходимо динамически управлять на какой > бэкенд запрос упадет. > > Править nginx.conf и перечитывает его не вариант, т.к. это может > происходить ежесекундно. > > Думал хранить соответствие servername -> backend в memcached, но nginx > похоже только умеет доставать http response и memcached. > > Остается только Nginx -> Perl -> Memcached. Или есть еще варинаты? lua? > Самый лучший вариант - X-Accel-Redirect, смотрите например в описании директивы proxy_ignore_headers. http://nginx.org/r/proxy_ignore_headers/ru -- Валентин Бартенев From sergey.kobzar at itcraft.org Fri Nov 1 12:35:57 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 14:35:57 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: References: <52739D44.20508@itcraft.org> Message-ID: <5273A02D.1000503@itcraft.org> On 11/01/13 14:28, Oleksandr V. Typlyns'kyi wrote: > Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: > >> Приветсвую >> >> Nginx стоит как frontend. За ним находится несколько десятков или более >> бэкендов (разные servername). Необходимо динамически управлять на какой >> бэкенд запрос упадет. >> >> Править nginx.conf и перечитывает его не вариант, т.к. это может >> происходить ежесекундно. > > http://nginx.org/r/upstream_conf > Одно но: > This directive is available as part of our commercial subscription only. Как вариант конечно... Вопрос к разработчикам: сколько стоит commercial subscription? Вот еще нашел то, что мне нужно: http://sosedoff.com/2012/06/11/dynamic-nginx-upstreams-with-lua-and-redis.html Но насколько lua модуль стабильный и выдерживает ли он high load. From vbart at nginx.com Fri Nov 1 12:41:03 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Nov 2013 16:41:03 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <5273A02D.1000503@itcraft.org> References: <52739D44.20508@itcraft.org> <5273A02D.1000503@itcraft.org> Message-ID: <201311011641.03627.vbart@nginx.com> On Friday 01 November 2013 16:35:57 Sergey Kobzar wrote: > On 11/01/13 14:28, Oleksandr V. Typlyns'kyi wrote: > > Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: > >> Приветсвую > >> > >> Nginx стоит как frontend. За ним находится несколько десятков или более > >> бэкендов (разные servername). Необходимо динамически управлять на какой > >> бэкенд запрос упадет. > >> > >> Править nginx.conf и перечитывает его не вариант, т.к. это может > >> происходить ежесекундно. > >> > > http://nginx.org/r/upstream_conf > > Одно но: > > This directive is available as part of our commercial subscription > > only. > > Как вариант конечно... > Вопрос к разработчикам: сколько стоит commercial subscription? > [..] На сайте есть прайс: http://nginx.com/products/ и заказ онлайн https://cs.nginx.com/cart При желании, можно попросить trial. -- Валентин Бартенев From sergey.kobzar at itcraft.org Fri Nov 1 12:41:47 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 14:41:47 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011632.08456.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <201311011632.08456.vbart@nginx.com> Message-ID: <5273A18B.6090005@itcraft.org> On 11/01/13 14:32, Валентин Бартенев wrote: > On Friday 01 November 2013 16:23:32 Sergey Kobzar wrote: >> Приветсвую >> >> Nginx стоит как frontend. За ним находится несколько десятков или более >> бэкендов (разные servername). Необходимо динамически управлять на какой >> бэкенд запрос упадет. >> >> Править nginx.conf и перечитывает его не вариант, т.к. это может >> происходить ежесекундно. >> >> Думал хранить соответствие servername -> backend в memcached, но nginx >> похоже только умеет доставать http response и memcached. >> >> Остается только Nginx -> Perl -> Memcached. Или есть еще варинаты? lua? >> > > Самый лучший вариант - X-Accel-Redirect, смотрите например в описании > директивы proxy_ignore_headers. > > http://nginx.org/r/proxy_ignore_headers/ru Валентин, спасибо. Не совсем понял как это применить на практике. Т.е. мне все-равно нужно как-то динамически управлять на какой backend перенапрявлять запрос. P.S. Состоянием бэкендов управляет дополнительный сервер. На нем можно выдавать или состояние бэкенда или на какой бэкенд запрос перенаправить. Но что-то я не соображу как это дело применить... > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From sergey.kobzar at itcraft.org Fri Nov 1 12:44:09 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 14:44:09 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011641.03627.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <5273A02D.1000503@itcraft.org> <201311011641.03627.vbart@nginx.com> Message-ID: <5273A219.1010508@itcraft.org> On 11/01/13 14:41, Валентин Бартенев wrote: > On Friday 01 November 2013 16:35:57 Sergey Kobzar wrote: >> On 11/01/13 14:28, Oleksandr V. Typlyns'kyi wrote: >>> Today Nov 1, 2013 at 14:23 Sergey Kobzar wrote: >>>> Приветсвую >>>> >>>> Nginx стоит как frontend. За ним находится несколько десятков или более >>>> бэкендов (разные servername). Необходимо динамически управлять на какой >>>> бэкенд запрос упадет. >>>> >>>> Править nginx.conf и перечитывает его не вариант, т.к. это может >>>> происходить ежесекундно. >>>> >>> http://nginx.org/r/upstream_conf >>> Одно но: >>> This directive is available as part of our commercial subscription >>> only. >> >> Как вариант конечно... >> Вопрос к разработчикам: сколько стоит commercial subscription? >> > [..] > > На сайте есть прайс: http://nginx.com/products/ > и заказ онлайн https://cs.nginx.com/cart > > При желании, можно попросить trial. Спасибо. Сейчас у себя обсудим. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From vbart at nginx.com Fri Nov 1 12:47:32 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Nov 2013 16:47:32 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <5273A18B.6090005@itcraft.org> References: <52739D44.20508@itcraft.org> <201311011632.08456.vbart@nginx.com> <5273A18B.6090005@itcraft.org> Message-ID: <201311011647.32730.vbart@nginx.com> On Friday 01 November 2013 16:41:47 Sergey Kobzar wrote: > On 11/01/13 14:32, Валентин Бартенев wrote: > > On Friday 01 November 2013 16:23:32 Sergey Kobzar wrote: > >> Приветсвую > >> > >> Nginx стоит как frontend. За ним находится несколько десятков или более > >> бэкендов (разные servername). Необходимо динамически управлять на какой > >> бэкенд запрос упадет. > >> > >> Править nginx.conf и перечитывает его не вариант, т.к. это может > >> происходить ежесекундно. > >> > >> Думал хранить соответствие servername -> backend в memcached, но nginx > >> похоже только умеет доставать http response и memcached. > >> > >> Остается только Nginx -> Perl -> Memcached. Или есть еще варинаты? lua? > > > > Самый лучший вариант - X-Accel-Redirect, смотрите например в описании > > директивы proxy_ignore_headers. > > > > http://nginx.org/r/proxy_ignore_headers/ru > > Валентин, спасибо. > Не совсем понял как это применить на практике. Т.е. мне все-равно нужно > как-то динамически управлять на какой backend перенапрявлять запрос. > > P.S. Состоянием бэкендов управляет дополнительный сервер. На нем можно > выдавать или состояние бэкенда или на какой бэкенд запрос перенаправить. > Но что-то я не соображу как это дело применить... > Зависит от того, что вам требуется. Как я первоначально понял ваш вопрос, требуется на каждый запрос решать на какой сервер он пойдет. В этом случае вы сначала с помощью proxy_pass/fastcgi_pass направляете запрос на скрипт/сервер/приложение/базу - который решает на какой бэкенд его отправить и возвращает в заголовках X-Accel-Redirect с указанием бэкенда. Далее у вас есть internal location, в котором тот же proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный сервер. -- Валентин Бартенев From sergey.kobzar at itcraft.org Fri Nov 1 12:54:43 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 14:54:43 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011647.32730.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <201311011632.08456.vbart@nginx.com> <5273A18B.6090005@itcraft.org> <201311011647.32730.vbart@nginx.com> Message-ID: <5273A493.70705@itcraft.org> On 11/01/13 14:47, Валентин Бартенев wrote: > Зависит от того, что вам требуется. Как я первоначально понял ваш вопрос, > требуется на каждый запрос решать на какой сервер он пойдет. Да - так и есть. > В этом случае вы сначала с помощью proxy_pass/fastcgi_pass направляете > запрос на скрипт/сервер/приложение/базу - который решает на какой бэкенд > его отправить и возвращает в заголовках X-Accel-Redirect с указанием > бэкенда. Тут понял. > Далее у вас есть internal location, в котором тот же proxy_pass/fastcgi_pass > с переменной и запрос отправляется на нужный сервер. А переменную как выковырять из ответа? > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Fri Nov 1 13:02:43 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Nov 2013 17:02:43 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <5273A493.70705@itcraft.org> References: <52739D44.20508@itcraft.org> <201311011647.32730.vbart@nginx.com> <5273A493.70705@itcraft.org> Message-ID: <201311011702.43603.vbart@nginx.com> On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote: [..] > > Далее у вас есть internal location, в котором тот же > > proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный > > сервер. > > А переменную как выковырять из ответа? > Например так: возвращаете "X-Accel-Redirect: /redirect_to/198.51.100.1" и он попадает в такой location: location ~ ^/redirect_to/(?.+)$ { internal; proxy_pass http://$backend; } Если нужно сохранить оригинальный URI запроса, то это делается с помощью set: set $original_uri $request_uri; и proxy_pass в этом случает будет выглядеть так: proxy_pass http://$backend$original_uri; -- Валентин Бартенев From vbart at nginx.com Fri Nov 1 13:09:42 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Nov 2013 17:09:42 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011702.43603.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <5273A493.70705@itcraft.org> <201311011702.43603.vbart@nginx.com> Message-ID: <201311011709.42051.vbart@nginx.com> On Friday 01 November 2013 17:02:43 Валентин Бартенев wrote: > On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote: > [..] > > > > Далее у вас есть internal location, в котором тот же > > > proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный > > > сервер. > > > > А переменную как выковырять из ответа? > > Например так: возвращаете "X-Accel-Redirect: /redirect_to/198.51.100.1" > и он попадает в такой location: > > location ~ ^/redirect_to/(?.+)$ { > internal; > proxy_pass http://$backend; > } > > Если нужно сохранить оригинальный URI запроса, то это делается с помощью > set: > > set $original_uri $request_uri; > > и proxy_pass в этом случает будет выглядеть так: > > proxy_pass http://$backend$original_uri; > Альтернативный, и даже наверное лучший и более простой вариант всего этого: использовать аналогичным образом модуль ngx_http_auth_request. http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html -- Валентин Бартенев From sergey.kobzar at itcraft.org Fri Nov 1 13:13:27 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 15:13:27 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011702.43603.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <201311011647.32730.vbart@nginx.com> <5273A493.70705@itcraft.org> <201311011702.43603.vbart@nginx.com> Message-ID: <5273A8F7.2030801@itcraft.org> On 11/01/13 15:02, Валентин Бартенев wrote: > On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote: > [..] >>> Далее у вас есть internal location, в котором тот же >>> proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный >>> сервер. >> >> А переменную как выковырять из ответа? >> > > Например так: возвращаете "X-Accel-Redirect: /redirect_to/198.51.100.1" > и он попадает в такой location: > > location ~ ^/redirect_to/(?.+)$ { > internal; > proxy_pass http://$backend; > } > > Если нужно сохранить оригинальный URI запроса, то это делается с помощью set: > > set $original_uri $request_uri; > > и proxy_pass в этом случает будет выглядеть так: > > proxy_pass http://$backend$original_uri; Теперь все понятно. Спасибо! > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From sergey.kobzar at itcraft.org Fri Nov 1 13:50:51 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 15:50:51 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011709.42051.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <5273A493.70705@itcraft.org> <201311011702.43603.vbart@nginx.com> <201311011709.42051.vbart@nginx.com> Message-ID: <5273B1BB.70404@itcraft.org> On 11/01/13 15:09, Валентин Бартенев wrote: > On Friday 01 November 2013 17:02:43 Валентин Бартенев wrote: >> On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote: >> [..] >> >>>> Далее у вас есть internal location, в котором тот же >>>> proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный >>>> сервер. >>> >>> А переменную как выковырять из ответа? >> >> Например так: возвращаете "X-Accel-Redirect: /redirect_to/198.51.100.1" >> и он попадает в такой location: >> >> location ~ ^/redirect_to/(?.+)$ { >> internal; >> proxy_pass http://$backend; >> } >> >> Если нужно сохранить оригинальный URI запроса, то это делается с помощью >> set: >> >> set $original_uri $request_uri; >> >> и proxy_pass в этом случает будет выглядеть так: >> >> proxy_pass http://$backend$original_uri; >> > > Альтернативный, и даже наверное лучший и более простой вариант всего этого: > использовать аналогичным образом модуль ngx_http_auth_request. > > http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html Хм. А этот модуль при чем? Мне не нужно авторизовывать пользователей. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From vbart at nginx.com Fri Nov 1 15:02:01 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 1 Nov 2013 19:02:01 +0400 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <5273B1BB.70404@itcraft.org> References: <52739D44.20508@itcraft.org> <201311011709.42051.vbart@nginx.com> <5273B1BB.70404@itcraft.org> Message-ID: <201311011902.01418.vbart@nginx.com> On Friday 01 November 2013 17:50:51 Sergey Kobzar wrote: > On 11/01/13 15:09, Валентин Бартенев wrote: > > On Friday 01 November 2013 17:02:43 Валентин Бартенев wrote: > >> On Friday 01 November 2013 16:54:43 Sergey Kobzar wrote: > >> [..] > >> > >>>> Далее у вас есть internal location, в котором тот же > >>>> proxy_pass/fastcgi_pass с переменной и запрос отправляется на нужный > >>>> сервер. > >>> > >>> А переменную как выковырять из ответа? > >> > >> Например так: возвращаете "X-Accel-Redirect: /redirect_to/198.51.100.1" > >> > >> и он попадает в такой location: > >> location ~ ^/redirect_to/(?.+)$ { > >> > >> internal; > >> proxy_pass http://$backend; > >> > >> } > >> > >> Если нужно сохранить оригинальный URI запроса, то это делается с помощью > >> > >> set: > >> set $original_uri $request_uri; > >> > >> и proxy_pass в этом случает будет выглядеть так: > >> proxy_pass http://$backend$original_uri; > > > > Альтернативный, и даже наверное лучший и более простой вариант всего > > этого: использовать аналогичным образом модуль ngx_http_auth_request. > > > > http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html > > Хм. А этот модуль при чем? Мне не нужно авторизовывать пользователей. > Авторизация - лишь одно из применений. В каком-то смысле ваша задача тоже авторизация, вы авторизуете пользовательский запрос быть переданным на определенный бэкенд. Для вас важно, что модуль отправляет запрос на access-фазе на указанный сервер и позволяет из его ответа извлечь адрес бэкенда, на который потом запрос будет передан. Основной плюс тут в том, что на конечный бэкенд будет уходить оригинальный запрос, а не перенаправленный, как в предложенном мной ранее решении с X-Accel-Redirect. Не потребуется хака с сохранением $request_uri. -- Валентин Бартенев From sergey.kobzar at itcraft.org Fri Nov 1 20:04:16 2013 From: sergey.kobzar at itcraft.org (Sergey Kobzar) Date: Fri, 01 Nov 2013 22:04:16 +0200 Subject: =?UTF-8?B?UmU6INCj0L/RgNCw0LLQu9C10L3QuNC1INCx0Y3QutC10L3QtNCw0LzQuA==?= In-Reply-To: <201311011902.01418.vbart@nginx.com> References: <52739D44.20508@itcraft.org> <201311011709.42051.vbart@nginx.com> <5273B1BB.70404@itcraft.org> <201311011902.01418.vbart@nginx.com> Message-ID: <52740940.4060703@itcraft.org> On 11/01/13 17:02, Валентин Бартенев wrote: >>> Альтернативный, и даже наверное лучший и более простой вариант всего >>> этого: использовать аналогичным образом модуль ngx_http_auth_request. >>> >>> http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html >> >> Хм. А этот модуль при чем? Мне не нужно авторизовывать пользователей. >> > > Авторизация - лишь одно из применений. В каком-то смысле ваша задача тоже > авторизация, вы авторизуете пользовательский запрос быть переданным на > определенный бэкенд. > > Для вас важно, что модуль отправляет запрос на access-фазе на указанный > сервер и позволяет из его ответа извлечь адрес бэкенда, на который потом > запрос будет передан. > > Основной плюс тут в том, что на конечный бэкенд будет уходить оригинальный > запрос, а не перенаправленный, как в предложенном мной ранее решении с > X-Accel-Redirect. Не потребуется хака с сохранением $request_uri. Что-то я не совсем понял если честно. Ладно, сперва доку про модуль почитаю. Спасибо за наводку. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From nginx-forum at nginx.us Sat Nov 2 14:46:51 2013 From: nginx-forum at nginx.us (Bdfy) Date: Sat, 02 Nov 2013 10:46:51 -0400 Subject: =?UTF-8?B?0JzQvtC20L3QviDQu9C4INC+0L/RgNC10LTQtdC70LjRgtGMINC00LXQu9C40Lw=?= =?UTF-8?B?0L7RgdGC0Ywg0YfQuNGB0LvQsCA/?= Message-ID: Можно ли в nginx без использования сторонних модулей ( в перле или в lua это можно сделать ) определить делимость числа на какое-либо число, например 10 ? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244370,244370#msg-244370 From postmaster at softsearch.ru Sat Nov 2 15:42:39 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sat, 2 Nov 2013 19:42:39 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: References: Message-ID: <1453997418.20131102194239@softsearch.ru> Здравствуйте, Bdfy. > Можно ли в nginx без использования сторонних модулей ( в перле или в lua это > можно сделать ) определить делимость числа на какое-либо число, например 10 Если на 10, 8, 5, 4 или 2, то регэкспом можно. -- С уважением, Михаил mailto:postmaster at softsearch.ru From andrei.nigmatulin at gmail.com Sat Nov 2 16:53:55 2013 From: andrei.nigmatulin at gmail.com (Andrei Nigmatulin) Date: Sat, 2 Nov 2013 16:53:55 +0000 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: <1453997418.20131102194239@softsearch.ru> References: <1453997418.20131102194239@softsearch.ru> Message-ID: На любое можно регеспом. Другое дело, что не каждый регексп получится коротким. 2013/11/2 Михаил Монашёв > Здравствуйте, Bdfy. > > > Можно ли в nginx без использования сторонних модулей ( в перле или в lua > это > > можно сделать ) определить делимость числа на какое-либо число, например > 10 > > Если на 10, 8, 5, 4 или 2, то регэкспом можно. > > -- > С уважением, > Михаил mailto:postmaster at softsearch.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Andrei Nigmatulin GPG PUB KEY 6449830D Now I lay me down to sleep(3) Pray the OS my core to keep If I die before I wake Pray the Disk my core to take -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.goryainov at gmail.com Sat Nov 2 18:02:39 2013 From: dmitry.goryainov at gmail.com (Dmitry) Date: Sat, 2 Nov 2013 22:02:39 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: References: <1453997418.20131102194239@softsearch.ru> Message-ID: А зачем это нужно на стороне веб-сервера? 02.11.2013 20:54 пользователь "Andrei Nigmatulin" < andrei.nigmatulin at gmail.com> написал: > На любое можно регеспом. Другое дело, что не каждый регексп получится > коротким. > > > 2013/11/2 Михаил Монашёв > >> Здравствуйте, Bdfy. >> >> > Можно ли в nginx без использования сторонних модулей ( в перле или в >> lua это >> > можно сделать ) определить делимость числа на какое-либо число, >> например 10 >> >> Если на 10, 8, 5, 4 или 2, то регэкспом можно. >> >> -- >> С уважением, >> Михаил mailto:postmaster at softsearch.ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > Andrei Nigmatulin > GPG PUB KEY 6449830D > > Now I lay me down to sleep(3) > Pray the OS my core to keep > If I die before I wake > Pray the Disk my core to take > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood at fotofor.biz Sat Nov 2 18:11:46 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sat, 2 Nov 2013 22:11:46 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: References: <1453997418.20131102194239@softsearch.ru> Message-ID: Например, чтобы распределять нагрузку? 2 ноября 2013 г., 22:02 пользователь Dmitry написал: > А зачем это нужно на стороне веб-сервера? > 02.11.2013 20:54 пользователь "Andrei Nigmatulin" < > andrei.nigmatulin at gmail.com> написал: > > На любое можно регеспом. Другое дело, что не каждый регексп получится >> коротким. >> >> >> 2013/11/2 Михаил Монашёв >> >>> Здравствуйте, Bdfy. >>> >>> > Можно ли в nginx без использования сторонних модулей ( в перле или в >>> lua это >>> > можно сделать ) определить делимость числа на какое-либо число, >>> например 10 >>> >>> Если на 10, 8, 5, 4 или 2, то регэкспом можно. >>> >>> -- >>> С уважением, >>> Михаил mailto:postmaster at softsearch.ru >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> >> -- >> Andrei Nigmatulin >> GPG PUB KEY 6449830D >> >> Now I lay me down to sleep(3) >> Pray the OS my core to keep >> If I die before I wake >> Pray the Disk my core to take >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitroko at gmail.com Sat Nov 2 18:21:39 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Sat, 2 Nov 2013 22:21:39 +0400 Subject: =?UTF-8?B?0KPRgtC+0YfQvdC10L3QuNC1INC70L7Qs9C40LrQuCDRgNCw0LHQvtGC0Ysgbmd4?= =?UTF-8?B?X2h0dHBfYXV0aF9yZXF1ZXN0X21vZHVsZQ==?= Message-ID: Здравствуйте. Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module) Настройку этого модуля производил по README от модуля. Сам вебсервер собрал с такими параметрами в дебиане: nginx version: nginx/1.3.14 built by gcc 4.4.5 (Debian 4.4.5-8) TLS SNI support enabled configure arguments: --with-openssl=/usr/build/openssl-1.0.1e --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-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-ipv6 --with-mail --with-mail_ssl_module --add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module --add-module=/usr/build/ngx_http_auth_request_module Предисловие для понимания возможности проявления архитектурной ошибки у меня. Я разработал модуль авторизации по pin+token поверх google authenticator http://sourceforge.net/projects/simsim/ Он работает хорошо. Возвращает по локейшну /auth/ или 200 или 401 в разных случаях. Алгоритм проекта прост. 1) Клиент приходит в локейшн /auth/ без кук или с просроченными/неверными и получает 401, предлагает перейти на /gauth/ 2) /gauth/ выдаёт запрос basic auth на ввод данных. Данные обрабатывает моим модулем. Если пара пин-токен подходящая, то клиенту выдаются куки и его редиректят на /auth/ снова. 3) /auth/ получает куки и возвращает 200. 4) В последующие запросы браузер вставляет куки и прохождение /auth/ просиходит по их наличию без переходов на /gauth/ Проверка куки происходит совместно с обращением в редис, который их хранит.. Чтобы удалённо пользоваться своими проектами, я на фронте сделал reverse proxy средствами nginx. Запрос приходит на https://ssl.stremki.net/project_name/ Пример обработки локейшна: location /nagios { auth_request /auth/; proxy_pass http://192.168.125.47; proxy_buffering on; proxy_set_header SSL NO; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 1800; proxy_redirect off; } /auth/ локейшн описан по докумментации от Максима методом проксирования. location /auth/ { proxy_pass http://192.168.125.35/auth/; proxy_pass_request_body off; proxy_buffering off; proxy_cache off; proxy_set_header Content-Length ""; proxy_set_header Host 192.168.125.35; } Я пытался делать без проксирования, указывая URI auth_request http://192.168.125.35/auth/ Но это не работало и я в логах nginx видел ошибку 2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp:// 192.168.125.35/auth/index.html" is not found (2: No such file or directory), client: 192.168.125.47, server: ssl.stremki.net, request: "GET /mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/", host: " ssl.stremki.net" Было бы здорово, если бы я смог работать без проксирования /auth/. Просто, пока не понял, как прописать внутренний бекенд для обработки и сейчас пользуюсь локейшном /auth/ в режиме проксирования. Для наджиоса всё работает отлично. Однако, есть точно такие же локейшны для ownCloud и RoundCube Во время захода на https://ssl.stremki.net/mail/ nginx обрабатывает auth_request Поскольку, cookie достаточную для прохождения /auth/ я посылаю, то я получаю страницу логина в RoundCube. Страница прогружается вся (все элементы: js скрипты, картинки). Затем, когда я ввожу логин и пароль к RoundCube, браузер впадает в ожидание ответа от nginx В tcpdump на бэкенде, отвечающем за /auth/ я не вижу запросов в этот момент. Для дополнительного тестирования, я поставил на клиентскую часть Burp Proxy и пошагово прошёл весь процесс авторизации От получения кук для /auth/ до попадания в вебинтерфейс уже самого ящика в RoundCube. И был удивлён. Так, как Burp запрашивает разрешение на каждый шаг (каждый запрос), как дебаггер, то это даёт временные промежутки между запросами браузера к nginx. Если браузер делает запросы не моментально, а через промежутки 1-2 секунды, то авторизация RoundCube отрабатывает и я попадаю в почтовый ящик. Я пока не очень хорошо знаю, как работает nginx во время проксирования вкупе с модулем Максима и предполагаю, что он не делает запрос к бекенду, отвечающему за локейшн /auth/ при большом количестве запросов. Возможно, я что-то не так настроил. Помогите, пожалуйста, разобраться. Спасибо. --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.goryainov at gmail.com Sat Nov 2 19:38:21 2013 From: dmitry.goryainov at gmail.com (Dmitry) Date: Sat, 2 Nov 2013 23:38:21 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: References: <1453997418.20131102194239@softsearch.ru> Message-ID: И чем не устраивает штатный способ настройки? 02.11.2013 22:12 пользователь "Anton Kiryushkin" написал: > Например, чтобы распределять нагрузку? > > > 2 ноября 2013 г., 22:02 пользователь Dmitry написал: > >> А зачем это нужно на стороне веб-сервера? >> 02.11.2013 20:54 пользователь "Andrei Nigmatulin" < >> andrei.nigmatulin at gmail.com> написал: >> >> На любое можно регеспом. Другое дело, что не каждый регексп получится >>> коротким. >>> >>> >>> 2013/11/2 Михаил Монашёв >>> >>>> Здравствуйте, Bdfy. >>>> >>>> > Можно ли в nginx без использования сторонних модулей ( в перле или в >>>> lua это >>>> > можно сделать ) определить делимость числа на какое-либо число, >>>> например 10 >>>> >>>> Если на 10, 8, 5, 4 или 2, то регэкспом можно. >>>> >>>> -- >>>> С уважением, >>>> Михаил mailto:postmaster at softsearch.ru >>>> >>>> _______________________________________________ >>>> nginx-ru mailing list >>>> nginx-ru at nginx.org >>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>>> >>> >>> >>> >>> -- >>> Andrei Nigmatulin >>> GPG PUB KEY 6449830D >>> >>> Now I lay me down to sleep(3) >>> Pray the OS my core to keep >>> If I die before I wake >>> Pray the Disk my core to take >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.goryainov at gmail.com Sat Nov 2 19:54:11 2013 From: dmitry.goryainov at gmail.com (Dmitry) Date: Sat, 2 Nov 2013 23:54:11 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: References: <1453997418.20131102194239@softsearch.ru> Message-ID: На вскидку, ибо с телефона, http://www.ashep.org/2011/nginx-balansirovka-nagruzki/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Nov 2 20:02:46 2013 From: nginx-forum at nginx.us (Romano) Date: Sat, 02 Nov 2013 16:02:46 -0400 Subject: =?UTF-8?B?0JTQvtGB0YDQvtGH0L3QvtC1INC30LDQutGA0YvRgtC40LUg0YHQvtC10LTQuNC9?= =?UTF-8?B?0LXQvdC40Y8g0L/QviDQt9Cw0LPQvtC70L7QstC60LDQvCDQsdGA0LDRg9C3?= =?UTF-8?B?0LXRgNCw?= Message-ID: В PHP под управлением Apache можно досрочно закрыть соединение, а затем продолжить выполнение скрипта в "фоновом" режиме, освободив при этом браузер пользователя: http://stackoverflow.com/questions/4806637/continue-processing-after-closing-connection. Но если использовать Nginx между посетителем и Apache (кэширование не настроено), то такая схема не работает. Возможно что-то сделать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244383,244383#msg-244383 From hunter at comsys.com.ua Sat Nov 2 20:40:53 2013 From: hunter at comsys.com.ua (Sergey Smitienko) Date: Sat, 02 Nov 2013 22:40:53 +0200 Subject: =?UTF-8?B?UmU6INCU0L7RgdGA0L7Rh9C90L7QtSDQt9Cw0LrRgNGL0YLQuNC1INGB0L7QtdC0?= =?UTF-8?B?0LjQvdC10L3QuNGPINC/0L4g0LfQsNCz0L7Qu9C+0LLQutCw0Lwg0LHRgNCw?= =?UTF-8?B?0YPQt9C10YDQsA==?= In-Reply-To: References: Message-ID: <52756355.1070100@comsys.com.ua> Используйте http://pear.php.net/package/System_Daemon On 11/2/2013 10:02 PM, Romano wrote: > В PHP под управлением Apache можно досрочно закрыть соединение, а затем > продолжить выполнение скрипта в "фоновом" режиме, освободив при этом браузер > пользователя: > http://stackoverflow.com/questions/4806637/continue-processing-after-closing-connection. > From nginx-forum at nginx.us Sat Nov 2 20:59:38 2013 From: nginx-forum at nginx.us (Romano) Date: Sat, 02 Nov 2013 16:59:38 -0400 Subject: =?UTF-8?B?UmU6INCU0L7RgdGA0L7Rh9C90L7QtSDQt9Cw0LrRgNGL0YLQuNC1INGB0L7QtdC0?= =?UTF-8?B?0LjQvdC10L3QuNGPINC/0L4g0LfQsNCz0L7Qu9C+0LLQutCw0Lwg0LHRgNCw?= =?UTF-8?B?0YPQt9C10YDQsA==?= In-Reply-To: <52756355.1070100@comsys.com.ua> References: <52756355.1070100@comsys.com.ua> Message-ID: <0bdf4182ca5440a54aa73e274cc41608.NginxMailingListRussian@forum.nginx.org> Спасибо, к сожалению нет возможности использовать System_Daemon, ограничения хостинга. Другого не дано? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244383,244385#msg-244385 From hunter at comsys.com.ua Sat Nov 2 21:07:52 2013 From: hunter at comsys.com.ua (Sergey Smitienko) Date: Sat, 02 Nov 2013 23:07:52 +0200 Subject: =?UTF-8?B?UmU6INCU0L7RgdGA0L7Rh9C90L7QtSDQt9Cw0LrRgNGL0YLQuNC1INGB0L7QtdC0?= =?UTF-8?B?0LjQvdC10L3QuNGPINC/0L4g0LfQsNCz0L7Qu9C+0LLQutCw0Lwg0LHRgNCw?= =?UTF-8?B?0YPQt9C10YDQsA==?= In-Reply-To: <0bdf4182ca5440a54aa73e274cc41608.NginxMailingListRussian@forum.nginx.org> References: <52756355.1070100@comsys.com.ua> <0bdf4182ca5440a54aa73e274cc41608.NginxMailingListRussian@forum.nginx.org> Message-ID: <527569A8.9080900@comsys.com.ua> http://php.net/manual/ru/function.pcntl-fork.php - смотрите пример index() > Спасибо, к сожалению нет возможности использовать System_Daemon, ограничения > хостинга. Другого не дано? -- Sergey Smitienko From swood at fotofor.biz Sun Nov 3 10:17:44 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 3 Nov 2013 14:17:44 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QttC90L4g0LvQuCDQvtC/0YDQtdC00LXQu9C40YLRjCDQtNC10Ls=?= =?UTF-8?B?0LjQvNC+0YHRgtGMINGH0LjRgdC70LAgPw==?= In-Reply-To: References: <1453997418.20131102194239@softsearch.ru> Message-ID: Ну всякие бывают извращения. Например, бывает несколько апстримов, между которыми нужно распределять запросы, в зависимости от некого числа. 2013/11/2 Dmitry > На вскидку, ибо с телефона, > http://www.ashep.org/2011/nginx-balansirovka-nagruzki/ > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kav at karagodov.name Sun Nov 3 12:45:21 2013 From: kav at karagodov.name (Alexey V. Karagodov) Date: Sun, 3 Nov 2013 16:45:21 +0400 Subject: =?UTF-8?B?UmU6IFtTUEFNXVJlOiDQlNC+0YHRgNC+0YfQvdC+0LUg0LfQsNC60YDRi9GC0Lg=?= =?UTF-8?B?0LUg0YHQvtC10LTQuNC90LXQvdC40Y8g0L/QviDQt9Cw0LPQvtC70L7QstC6?= =?UTF-8?B?0LDQvCDQsdGA0LDRg9C30LXRgNCw?= In-Reply-To: <52756355.1070100@comsys.com.ua> References: <52756355.1070100@comsys.com.ua> Message-ID: <55370474-1701-4F6A-8FFD-B20D688EC822@karagodov.name> тут случаем не про PHP-FPM спрашивают? On 03 нояб. 2013 г., at 0:40, Sergey Smitienko wrote: > Используйте http://pear.php.net/package/System_Daemon > > On 11/2/2013 10:02 PM, Romano wrote: >> В PHP под управлением Apache можно досрочно закрыть соединение, а затем >> продолжить выполнение скрипта в "фоновом" режиме, освободив при этом браузер >> пользователя: >> http://stackoverflow.com/questions/4806637/continue-processing-after-closing-connection. >> > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From dmitry.goryainov at gmail.com Sun Nov 3 13:16:59 2013 From: dmitry.goryainov at gmail.com (Dmitry) Date: Sun, 3 Nov 2013 17:16:59 +0400 Subject: =?UTF-8?B?UmU6IFtTUEFNXVJlOiDQlNC+0YHRgNC+0YfQvdC+0LUg0LfQsNC60YDRi9GC0Lg=?= =?UTF-8?B?0LUg0YHQvtC10LTQuNC90LXQvdC40Y8g0L/QviDQt9Cw0LPQvtC70L7QstC6?= =?UTF-8?B?0LDQvCDQsdGA0LDRg9C30LXRgNCw?= In-Reply-To: <55370474-1701-4F6A-8FFD-B20D688EC822@karagodov.name> References: <52756355.1070100@comsys.com.ua> <55370474-1701-4F6A-8FFD-B20D688EC822@karagodov.name> Message-ID: вряд ли... Пишут про Апач, Вряд ли речь о fastcgi_finish_request 2013/11/3 Alexey V. Karagodov > тут случаем не про PHP-FPM спрашивают? > > On 03 нояб. 2013 г., at 0:40, Sergey Smitienko > wrote: > > > Используйте http://pear.php.net/package/System_Daemon > > > > On 11/2/2013 10:02 PM, Romano wrote: > >> В PHP под управлением Apache можно досрочно закрыть соединение, а затем > >> продолжить выполнение скрипта в "фоновом" режиме, освободив при этом > браузер > >> пользователя: > >> > http://stackoverflow.com/questions/4806637/continue-processing-after-closing-connection > . > >> > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Dmitry Goryainov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sun Nov 3 15:48:57 2013 From: nginx-forum at nginx.us (atemirov) Date: Sun, 03 Nov 2013 10:48:57 -0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQt9Cw0LPRgNGD0LfQutC+0Lkg0YTQsNC50Ls=?= =?UTF-8?B?0L7QsiDQvdCwINGB0LXRgNCy0LXRgA==?= Message-ID: <727fa4b93b88412fc8b5fc312545c71b.NginxMailingListRussian@forum.nginx.org> Дано: 1. VPS-сервер 2. Настройки PHP ? max_execution_time = 600 ? max_input_time = 600 ? memory_limit = 256M ? post_max_size = 100M ? upload_max_filesize = 100M ? max_file_uploads = 40 3. Настройки ngnix ? client_max_body_size 100M в настройках ngnix При загрузке любых файлов (минимальный объем ? 354 КБ) на сервер происходит следующее: загружаются примерно до 30%, после этого состояние загрузки сбрасывается на 0%, файл снова загружается примерно на 30% и браузер (Chrome) выдаёт следующую ошибку: Ошибка 101 (net::ERR_CONNECTION_RESET): Соединение сброшено. В других браузерах аналогичная ситуация. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244391,244391#msg-244391 From sytar.alex at gmail.com Sun Nov 3 17:22:59 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Sun, 3 Nov 2013 21:22:59 +0400 Subject: malloc(270336) failed Message-ID: Сегодня столкнулся со следующей проблемой: 2013/11/03 17:24:54 [emerg] 4532#1564: *1875523 malloc(270336) failed (8: Not enough storage is available to process this command) while sending to client, client: 5.10.83.57, server: ___.ru, request: "GET /6032/33621/ HTTP/1.1", upstream: "http://127.0.0.1:8081/6032/33621/", host: "____.ru" Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. c:\nginx>nginx -V nginx version: nginx/1.4.2 TLS SNI support enabled configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug --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-te mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp --http-fast cgi-temp-path=temp/fastcgi_temp --http-scgi-temp-path=temp/scgi_temp --http-uwsg i-temp-path=temp/uwsgi_temp --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs.msv c8/lib/pcre-8.32 --with-zlib=objs.msvc8/lib/zlib-1.2.8 --with-select_module --wi th-http_realip_module --with-http_addition_module --with-http_sub_module --with- http_dav_module --with-http_stub_status_module --with-http_flv_module --with-htt p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-htt p_random_index_module --with-http_secure_link_module --with-mail --with-openssl= objs.msvc8/lib/openssl-1.0.1e --with-openssl-opt=enable-tlsext --with-http_ssl_m odule --with-mail_ssl_module --with-ipv6 Что это было и как этого избегать в дальнейшем? -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood at fotofor.biz Sun Nov 3 18:48:47 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 3 Nov 2013 22:48:47 +0400 Subject: malloc(270336) failed In-Reply-To: References: Message-ID: Не запускать nginx в windows. А вообще, у вас закончилась память. Без конфига сложно понять для чего, но, возможно, для какого-нибудь буфера. 2013/11/3 Aleksandr Sytar > Сегодня столкнулся со следующей проблемой: > > 2013/11/03 17:24:54 [emerg] 4532#1564: *1875523 malloc(270336) failed (8: > Not enough storage is available to process this command) while sending to > client, client: 5.10.83.57, server: ___.ru, request: "GET /6032/33621/ > HTTP/1.1", upstream: "http://127.0.0.1:8081/6032/33621/", host: "____.ru" > > > Microsoft Windows [Version 5.2.3790] > (C) Copyright 1985-2003 Microsoft Corp. > > c:\nginx>nginx -V > nginx version: nginx/1.4.2 > TLS SNI support enabled > configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug > --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-te > mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp > --http-fast > cgi-temp-path=temp/fastcgi_temp --http-scgi-temp-path=temp/scgi_temp > --http-uwsg > i-temp-path=temp/uwsgi_temp --with-cc-opt=-DFD_SETSIZE=1024 > --with-pcre=objs.msv > c8/lib/pcre-8.32 --with-zlib=objs.msvc8/lib/zlib-1.2.8 > --with-select_module --wi > th-http_realip_module --with-http_addition_module --with-http_sub_module > --with- > http_dav_module --with-http_stub_status_module --with-http_flv_module > --with-htt > p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module > --with-htt > p_random_index_module --with-http_secure_link_module --with-mail > --with-openssl= > objs.msvc8/lib/openssl-1.0.1e --with-openssl-opt=enable-tlsext > --with-http_ssl_m > odule --with-mail_ssl_module --with-ipv6 > > > Что это было и как этого избегать в дальнейшем? > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sytar.alex at gmail.com Sun Nov 3 19:05:02 2013 From: sytar.alex at gmail.com (Aleksandr Sytar) Date: Sun, 3 Nov 2013 23:05:02 +0400 Subject: malloc(270336) failed In-Reply-To: References: Message-ID: 2013/11/3 Anton Kiryushkin > Не запускать nginx в windows. А вообще, у вас закончилась память. Без > конфига сложно понять для чего, но, возможно, для какого-нибудь буфера. > > Это слишком очевидное объяснение понятное из описания ошибки. Если бы память реально кончилась на сервер нельзя было бы залогиниться. При этом stub_status отлично отрабатывал. Конфиг: #user nobody; worker_processes 1; error_log logs/error.log; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; client_max_body_size 20m; #для загрузки больших картинок log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log off; msie_padding on; ignore_invalid_headers on; gzip on; gzip_static on; gzip_vary on; gzip_min_length 2048; gzip_comp_level 1; gzip_buffers 16 8k; gzip_types text/plain text/css text/xml text/javascript application/x-javascript; directio 4m; sendfile on; sendfile_max_chunk 256k; tcp_nopush on; tcp_nodelay on; reset_timedout_connection on; output_buffers 16 512k; postpone_output 1460; keepalive_timeout 30 15; server_name_in_redirect off; proxy_connect_timeout 120s; proxy_http_version 1.1; proxy_ignore_client_abort off; proxy_read_timeout 120s; proxy_send_timeout 120s; server_tokens off; include conf.d/*.conf; } server { listen 80; server_name example.com; error_log logs/error.log; access_log off; root some_path; index index.php; proxy_intercept_errors on; error_page 500 502 503 504 /503.html; location =/503.html { } location / { try_files $uri @apache; } location @apache { proxy_pass http://backend_babypages; proxy_set_header Host $host; proxy_set_header http_referer $http_referer; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location =/nginx_status { stub_status on; allow 86.62.121.100; allow 109.252.246.98; deny all; } location ~* \.php$ { proxy_pass http://backend_babypages; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header http_referer $http_referer; } } > 2013/11/3 Aleksandr Sytar > >> Сегодня столкнулся со следующей проблемой: >> >> 2013/11/03 17:24:54 [emerg] 4532#1564: *1875523 malloc(270336) failed (8: >> Not enough storage is available to process this command) while sending to >> client, client: 5.10.83.57, server: ___.ru, request: "GET /6032/33621/ >> HTTP/1.1", upstream: "http://127.0.0.1:8081/6032/33621/", host: "____.ru" >> >> >> Microsoft Windows [Version 5.2.3790] >> (C) Copyright 1985-2003 Microsoft Corp. >> >> c:\nginx>nginx -V >> nginx version: nginx/1.4.2 >> TLS SNI support enabled >> configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug >> --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-te >> mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp >> --http-fast >> cgi-temp-path=temp/fastcgi_temp --http-scgi-temp-path=temp/scgi_temp >> --http-uwsg >> i-temp-path=temp/uwsgi_temp --with-cc-opt=-DFD_SETSIZE=1024 >> --with-pcre=objs.msv >> c8/lib/pcre-8.32 --with-zlib=objs.msvc8/lib/zlib-1.2.8 >> --with-select_module --wi >> th-http_realip_module --with-http_addition_module --with-http_sub_module >> --with- >> http_dav_module --with-http_stub_status_module --with-http_flv_module >> --with-htt >> p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module >> --with-htt >> p_random_index_module --with-http_secure_link_module --with-mail >> --with-openssl= >> objs.msvc8/lib/openssl-1.0.1e --with-openssl-opt=enable-tlsext >> --with-http_ssl_m >> odule --with-mail_ssl_module --with-ipv6 >> >> >> Что это было и как этого избегать в дальнейшем? >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- > Best regards, > Anton Kiryushkin > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swood at fotofor.biz Sun Nov 3 19:22:16 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Sun, 3 Nov 2013 23:22:16 +0400 Subject: malloc(270336) failed In-Reply-To: References: Message-ID: Предположу, что стоит посмотреть в сторону действительно большого output_buffers, а так же взаимоисключающих друг друга directio и sendfile. К тому же, если я правильно понимаю, вы запускаете nginx под windows, где этих методов вообще, вроде бы, нет. 2013/11/3 Aleksandr Sytar > > > > 2013/11/3 Anton Kiryushkin > >> Не запускать nginx в windows. А вообще, у вас закончилась память. Без >> конфига сложно понять для чего, но, возможно, для какого-нибудь буфера. >> >> > Это слишком очевидное объяснение понятное из описания ошибки. > > Если бы память реально кончилась на сервер нельзя было бы залогиниться. > При этом stub_status отлично отрабатывал. > > Конфиг: > > > #user nobody; > worker_processes 1; > > error_log logs/error.log; > > events { > worker_connections 1024; > } > > > http { > include mime.types; > default_type application/octet-stream; > client_max_body_size 20m; #для загрузки больших картинок > > log_format main '$remote_addr - $remote_user [$time_local] > "$request" ' > '$status $body_bytes_sent "$http_referer" ' > '"$http_user_agent" "$http_x_forwarded_for"'; > > access_log off; > > > msie_padding on; > ignore_invalid_headers on; > > gzip on; > gzip_static on; > gzip_vary on; > gzip_min_length 2048; > gzip_comp_level 1; > gzip_buffers 16 8k; > gzip_types text/plain text/css text/xml > text/javascript application/x-javascript; > > directio 4m; > sendfile on; > sendfile_max_chunk 256k; > tcp_nopush on; > tcp_nodelay on; > reset_timedout_connection on; > > output_buffers 16 512k; > postpone_output 1460; > > keepalive_timeout 30 15; > server_name_in_redirect off; > proxy_connect_timeout 120s; > proxy_http_version 1.1; > proxy_ignore_client_abort off; > proxy_read_timeout 120s; > proxy_send_timeout 120s; > > server_tokens off; > include conf.d/*.conf; > } > > server { > listen 80; > server_name example.com; > error_log logs/error.log; > access_log off; > > root some_path; > index index.php; > proxy_intercept_errors on; > error_page 500 502 503 504 /503.html; > location =/503.html { > } > location / { > try_files $uri @apache; > } > > location @apache { > proxy_pass http://backend_babypages; > proxy_set_header Host $host; > proxy_set_header http_referer $http_referer; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > } > location =/nginx_status { > stub_status on; > allow 86.62.121.100; > allow 109.252.246.98; > deny all; > } > > location ~* \.php$ { > proxy_pass http://backend_babypages; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header http_referer $http_referer; > } > > } > > > > >> 2013/11/3 Aleksandr Sytar >> >>> Сегодня столкнулся со следующей проблемой: >>> >>> 2013/11/03 17:24:54 [emerg] 4532#1564: *1875523 malloc(270336) failed >>> (8: Not enough storage is available to process this command) while sending >>> to client, client: 5.10.83.57, server: ___.ru, request: "GET /6032/33621/ >>> HTTP/1.1", upstream: "http://127.0.0.1:8081/6032/33621/", host: >>> "____.ru" >>> >>> >>> Microsoft Windows [Version 5.2.3790] >>> (C) Copyright 1985-2003 Microsoft Corp. >>> >>> c:\nginx>nginx -V >>> nginx version: nginx/1.4.2 >>> TLS SNI support enabled >>> configure arguments: --with-cc=cl --builddir=objs.msvc8 --with-debug >>> --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-te >>> mp-path=temp/client_body_temp --http-proxy-temp-path=temp/proxy_temp >>> --http-fast >>> cgi-temp-path=temp/fastcgi_temp --http-scgi-temp-path=temp/scgi_temp >>> --http-uwsg >>> i-temp-path=temp/uwsgi_temp --with-cc-opt=-DFD_SETSIZE=1024 >>> --with-pcre=objs.msv >>> c8/lib/pcre-8.32 --with-zlib=objs.msvc8/lib/zlib-1.2.8 >>> --with-select_module --wi >>> th-http_realip_module --with-http_addition_module --with-http_sub_module >>> --with- >>> http_dav_module --with-http_stub_status_module --with-http_flv_module >>> --with-htt >>> p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module >>> --with-htt >>> p_random_index_module --with-http_secure_link_module --with-mail >>> --with-openssl= >>> objs.msvc8/lib/openssl-1.0.1e --with-openssl-opt=enable-tlsext >>> --with-http_ssl_m >>> odule --with-mail_ssl_module --with-ipv6 >>> >>> >>> Что это было и как этого избегать в дальнейшем? >>> >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru at nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >>> >> >> >> >> -- >> Best regards, >> Anton Kiryushkin >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From studentikus at ya.ru Sun Nov 3 20:26:41 2013 From: studentikus at ya.ru (studentikus at ya.ru) Date: Mon, 04 Nov 2013 00:26:41 +0400 Subject: =?UTF-8?B?0JrQsNC6INGB0LTQtdC70LDRgtGMINGA0LXQtNC40YDQtdC60YI/?= Message-ID: <69081383510401@web6g.yandex.ru> An HTML attachment was scrubbed... URL: From dmitry.goryainov at gmail.com Sun Nov 3 20:33:39 2013 From: dmitry.goryainov at gmail.com (Dmitry) Date: Mon, 4 Nov 2013 00:33:39 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDRgNC10LTQuNGA0LXQutGCPw==?= In-Reply-To: <69081383510401@web6g.yandex.ru> References: <69081383510401@web6g.yandex.ru> Message-ID: http://wiki.nginx.org/HttpRewriteModule#rewrite 2013/11/4 > Подскажите, как сделать "сео"-редирект? > Это должно выглядеть примерно так, но... Чего-то я не понимаю. > > 1. > 2. location /goto/ { > 3. rewrite ^/goto/(.*)$ $1 redirect; > 4. } > 5. > > > > Т.е. что бы при переходе на site.ru/goto/ya.ru был 302 редирект на ya.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Dmitry Goryainov -------------- next part -------------- An HTML attachment was scrubbed... URL: From shadow at ekb-lug.ru Mon Nov 4 00:49:34 2013 From: shadow at ekb-lug.ru (Shadow) Date: Mon, 4 Nov 2013 06:49:34 +0600 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDRgNC10LTQuNGA0LXQutGCPw==?= In-Reply-To: References: <69081383510401@web6g.yandex.ru> Message-ID: location /goto/ { location ~ ^/goto/(.*)$ { return http://$1$is_args$args; } } 4 ноября 2013 г., 2:33 пользователь Dmitry написал: > http://wiki.nginx.org/HttpRewriteModule#rewrite > > > 2013/11/4 >> >> Подскажите, как сделать "сео"-редирект? >> Это должно выглядеть примерно так, но... Чего-то я не понимаю. >> >> >> location /goto/ { >> rewrite ^/goto/(.*)$ $1 redirect; >> } >> >> >> >> >> Т.е. что бы при переходе на site.ru/goto/ya.ru был 302 редирект на ya.ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > > -- > Dmitry Goryainov > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Mon Nov 4 10:03:50 2013 From: nginx-forum at nginx.us (vulgast) Date: Mon, 04 Nov 2013 05:03:50 -0500 Subject: =?UTF-8?B?0J/RgNC4INCy0LrQu9GO0YfQtdC90LjQuCBnemlwINC90LUg0YDQsNCx0L7RgtCw?= =?UTF-8?B?0LXRgiBjaHVuay1lbmNvZGluZw==?= Message-ID: Добрый день. Версии: nginx - 1.2.1 + php-fpm Нужен совет. При включении gzip-а перестает работать chunk-encoding. В заголовке ответа chunked содержится, но по-факту с включенным gzip страница не отдается частями. Connection:keep-alive Content-Encoding:gzip Content-Type:text/html; charset=UTF-8 Date:Mon, 04 Nov 2013 09:57:07 GMT Server:nginx Transfer-Encoding:chunked Vary:Accept-Encoding X-Powered-By:PHP/5.4.4-14+deb7u5 Конфиги: gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 5; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; .............. upstream ********* { server unix:/var/run/*******-fpm.sock weight=5; server *.*.*.*:9010 weight=5; keepalive 5; } ..................... server { server_name www.***.ua; return 301 $scheme://********.ua$request_uri; } server { server_name ********.ua; root /home/*********.ua/www; chunkin on; access_log /home/******.ua/logs/access.log; error_log /home/***********.ua/logs/error.log; charset utf-8; include /etc/nginx/access.rules; error_page 411 = @my_411_error; location @my_411_error { chunkin_resume; } location / { try_files $uri @yii; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { log_not_found off; access_log off; } location ~ \.php$ { return 404; } location @yii { include fastcgi_params; set $memcached_key $uri; #memcached_pass ******.ua; fastcgi_param SCRIPT_FILENAME $document_root/index.php; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_connect_timeout 300; fastcgi_send_timeout 600; fastcgi_read_timeout 600; fastcgi_pass 127.0.0.1:9000; #proxy_buffering off; fastcgi_keep_conn on; chunkin_keepalive on; proxy_http_version 1.1; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244400,244400#msg-244400 From nginx-forum at nginx.us Mon Nov 4 10:10:14 2013 From: nginx-forum at nginx.us (vulgast) Date: Mon, 04 Nov 2013 05:10:14 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggZ3ppcCDQvdC1INGA0LDQsdC+?= =?UTF-8?B?0YLQsNC10YIgY2h1bmstZW5jb2Rpbmc=?= In-Reply-To: References: Message-ID: Такое впечетление, что есть какой-то буфер 4096+, который нужно заполнить, иначе чанк просто не отдается даже при сбросе буффера в php. Может это какой-то буфер в пхп или нжинксе? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244400,244401#msg-244401 From xolodit at gmail.com Mon Nov 4 11:43:37 2013 From: xolodit at gmail.com (XIT) Date: Mon, 4 Nov 2013 15:43:37 +0400 Subject: =?UTF-8?B?0L3QsNGB0YLRgNC+0LnQutCwIG5naW54INC00LvRjyDRh9Cw0LnQvdC40LrQsA==?= Message-ID: Доброго времени. Просьба не кидаться тухлыми помидорами, гугл использовал, wiki читал - но мозаика так и не сложилась. Решил давеча переехать на буржуйский vps, т.к. наши шареды больно падучи или везло так, не суть. Стал читать как nginx + php5-fpm поставить и все вроде бы срослось. Осталось дело за малым, просто понять само устройство, вероятно это настолько очевидно, что нигде не пишут о нем в целом, а я что-то торможу по всей видимости. Итак: 1. Есть файл в папке /etc/nginx/nginx.conf. Этот файл для примера лежит, или используется или его надо переместить в какое-то специальное место? 2. Для чего нужны папки: - sites-available - здесь лежит некий конфиг default, с таким вот содержимым http://pastebin.com/MPX0ii0g, которое позволяет работать только сайту site1.ru, но вот при входе на сайт site2.ru, открывается первый. - Как сделать, чтобы для каждого сайта был свой конфиг? Куда его класть и где до него прописывать инклюд, в nginx.conf? - sites-enabled - симлинк default на sites-available/default. Что в этой папке должно быть, её назначение? - conf.d - пустая, что в ней должно быть и её назначение? Буду безмерно благодарен, если ответите или дадите ссылку на мануал и простите за нубство. -- Relax, take it easy! -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Mon Nov 4 12:16:33 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Mon, 4 Nov 2013 16:16:33 +0400 Subject: =?UTF-8?B?UmU6INC90LDRgdGC0YDQvtC50LrQsCBuZ2lueCDQtNC70Y8g0YfQsNC50L3QuNC6?= =?UTF-8?B?0LA=?= In-Reply-To: References: Message-ID: > 1. Есть файл в папке /etc/nginx/nginx.conf. Этот файл для примера лежит, или > используется или его надо переместить в какое-то специальное место? Используется. Для тривиального случая там сделаны подходящие настройки, для нетривиального - возможно, его прийдется править. Вообще - его имеет смысл почитать, особо обращая внимание на директивы include. Многое станет понятным :) > sites-available - здесь лежит некий конфиг default, с таким вот содержимым > http://pastebin.com/MPX0ii0g, которое позволяет работать только сайту > site1.ru, но вот при входе на сайт site2.ru, открывается первый. Это debian-way конфиги. В этой папке лежат собственно конфиги сайтов. Но к работающей конфигурации могут быть подключены совсем не все, лежащие здесь. > Как сделать, чтобы для каждого сайта был свой конфиг? Куда его класть и где > до него прописывать инклюд, в nginx.conf? Класть в sites-available, прописывать симлинк в sites-enabled. Все, что есть в sites-enabled, инклюдится автоматически (это в штатном /etc/nginx/nginx.conf прописано) в секцию http. > sites-enabled - симлинк default на sites-available/default. Что в этой папке > должно быть, её назначение? см. выше. > conf.d - пустая, что в ней должно быть и её назначение? Сюда класть дополнения к стандартной конфигурации, которые должны быть за пределами секции http. Почитайте, повторюсь, /etc/nginx/nginx.conf - станет яснее. Для тривиальной конфигурации сюда ничего класть не прийдется. From xolodit at gmail.com Mon Nov 4 13:24:33 2013 From: xolodit at gmail.com (XIT) Date: Mon, 4 Nov 2013 17:24:33 +0400 Subject: =?UTF-8?B?UmU6INC90LDRgdGC0YDQvtC50LrQsCBuZ2lueCDQtNC70Y8g0YfQsNC50L3QuNC6?= =?UTF-8?B?0LA=?= In-Reply-To: References: Message-ID: Daniel, благодарю, теперь логика понятна. 04.11.2013 16:16 пользователь "Daniel Podolsky" написал: > > 1. Есть файл в папке /etc/nginx/nginx.conf. Этот файл для примера лежит, > или > > используется или его надо переместить в какое-то специальное место? > Используется. Для тривиального случая там сделаны подходящие > настройки, для нетривиального - возможно, его прийдется править. > Вообще - его имеет смысл почитать, особо обращая внимание на директивы > include. Многое станет понятным :) > > > sites-available - здесь лежит некий конфиг default, с таким вот > содержимым > > http://pastebin.com/MPX0ii0g, которое позволяет работать только сайту > > site1.ru, но вот при входе на сайт site2.ru, открывается первый. > Это debian-way конфиги. В этой папке лежат собственно конфиги сайтов. > Но к работающей конфигурации могут быть подключены совсем не все, > лежащие здесь. > > > Как сделать, чтобы для каждого сайта был свой конфиг? Куда его класть и > где > > до него прописывать инклюд, в nginx.conf? > Класть в sites-available, прописывать симлинк в sites-enabled. Все, > что есть в sites-enabled, инклюдится автоматически (это в штатном > /etc/nginx/nginx.conf прописано) в секцию http. > > > sites-enabled - симлинк default на sites-available/default. Что в этой > папке > > должно быть, её назначение? > см. выше. > > > conf.d - пустая, что в ней должно быть и её назначение? > Сюда класть дополнения к стандартной конфигурации, которые должны быть > за пределами секции http. Почитайте, повторюсь, /etc/nginx/nginx.conf > - станет яснее. > Для тривиальной конфигурации сюда ничего класть не прийдется. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From tetsio.nainn at gmail.com Mon Nov 4 17:24:27 2013 From: tetsio.nainn at gmail.com (=?UTF-8?B?0Jwu0JAuINCc0L7RhdC90LDRh9C10LLRgdC60LjQuQ==?=) Date: Tue, 5 Nov 2013 03:24:27 +1000 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LfQsNCz0YDRg9C30LrQvtC5INGE0LA=?= =?UTF-8?B?0LnQu9C+0LIg0L3QsCDRgdC10YDQstC10YA=?= In-Reply-To: <727fa4b93b88412fc8b5fc312545c71b.NginxMailingListRussian@forum.nginx.org> References: <727fa4b93b88412fc8b5fc312545c71b.NginxMailingListRussian@forum.nginx.org> Message-ID: PHP через mod_fcgid? 4 ноября 2013 г., 1:48 пользователь atemirov написал: > Дано: > > 1. VPS-сервер > > 2. Настройки PHP > ? max_execution_time = 600 > ? max_input_time = 600 > ? memory_limit = 256M > ? post_max_size = 100M > ? upload_max_filesize = 100M > ? max_file_uploads = 40 > > 3. Настройки ngnix > ? client_max_body_size 100M в настройках ngnix > > При загрузке любых файлов (минимальный объем ? 354 КБ) на сервер происходит > следующее: > загружаются примерно до 30%, после этого состояние загрузки сбрасывается на > 0%, файл снова загружается примерно на 30% и браузер (Chrome) выдаёт > следующую ошибку: Ошибка 101 (net::ERR_CONNECTION_RESET): Соединение > сброшено. > > В других браузерах аналогичная ситуация. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244391,244391#msg-244391 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С ув. М.А. Мохначевский Отдел системного администрирования ООО "Компания "СахаИнтернет НТ" к.т. (4112)219711 доб. 927 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Mon Nov 4 18:09:57 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 4 Nov 2013 18:09:57 +0000 Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90LDRjyDQvtGC0LTQsNGH0LAg0YHRgtCw0YLQuNC6?= =?UTF-8?B?0Lg=?= In-Reply-To: <20131030120849.GD84761@mdounin.ru> References: <20131030120849.GD84761@mdounin.ru> Message-ID: On 30 Oct 2013, at 12:08, Maxim Dounin wrote: > Hello! > > On Mon, Oct 28, 2013 at 12:34:33PM -0400, buddha wrote: > >> Привет всем. >> Знаю что вопрос уже обсуждался - почитал, попробовал - не выходит. >> >> Есть проблема с медленной отдачей статики. Что это значит: >> >> Отдача файла(js) ~40kb за 300-400ms >> на drive.ru или ya 40kb за 70-90ms >> >> Т.е. разница в разы. и она ощутима. >> >> ping до сервера ~70ms >> до drive и ya ~ 20-30ms >> >> отдает Nginx, config: >> >> location / { >> sendfile on; >> access_log off; >> expires 4M; >> >> root /var/www/static >> } >> >> сервер находится у хетцнера. >> >> Подскажите как можно приблизить скорость отдачи к drive или ya. >> Если сервер, диск(хотя iowait 0.01-0.05), то подскажите на что его можно >> заменить > > Судя по цифрам, то, что у вас получается - это в первую очередь > результат большого RTT + работы механизмов Congestion Control > протокола TCP. > > Можно пытаться походить в сторону тюнинга initial congestion > window size. Но, строго говоря, много это всё равно не даст - > где-то пару round trip'ов можно сэкономить при использовании > сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем > больше ответ - тем меньше разница). Ну и на всякий случай > напомню, что с тюнингом таких вещей следует быть осторожным, т.к. > подобные действия отражаются на всех в сети. Прежде, чем > ковыряться - лучше как минимум ознакомиться с теоретической > стороной вопроса. Максим, разве Google не провел исследования, по результатам которых они подняли icwnd до 10 на своих серверах? В последних версиях Linux kernel icwnd уже 10 по умолчанию и может дать обратный эффект только в очень редких случаях на сегодняшний день. TCP fast open в kernel 3.6+ следующей шаг, в который Google вкладывает силы и деньги. > > Вообще, IMHO, в первую очередь имеет смысл смотреть за тем, чтобы > с клиентами обеспечивались постоянные соединения. В nginx'е они > по умолчанию включены, но лишний раз проверить не помешает. В > частности - посмотреть на директиву keepalive_timeout и убедиться, > что там никто не написал 0 в попытке поэкономить соединения. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From anatoly at sonru.com Mon Nov 4 18:16:45 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 4 Nov 2013 18:16:45 +0000 Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90LDRjyDQvtGC0LTQsNGH0LAg0YHRgtCw0YLQuNC6?= =?UTF-8?B?0Lg=?= In-Reply-To: References: <20131030120849.GD84761@mdounin.ru> Message-ID: <65455BE1-C905-467E-B08D-F5803276B69E@sonru.com> On 04 Nov 2013, at 18:09, Anatoly Mikhailov wrote: > > On 30 Oct 2013, at 12:08, Maxim Dounin wrote: > >> Hello! >> >> On Mon, Oct 28, 2013 at 12:34:33PM -0400, buddha wrote: >> >>> Привет всем. >>> Знаю что вопрос уже обсуждался - почитал, попробовал - не выходит. >>> >>> Есть проблема с медленной отдачей статики. Что это значит: >>> >>> Отдача файла(js) ~40kb за 300-400ms >>> на drive.ru или ya 40kb за 70-90ms >>> >>> Т.е. разница в разы. и она ощутима. >>> >>> ping до сервера ~70ms >>> до drive и ya ~ 20-30ms >>> >>> отдает Nginx, config: >>> >>> location / { >>> sendfile on; >>> access_log off; >>> expires 4M; >>> >>> root /var/www/static >>> } >>> >>> сервер находится у хетцнера. >>> >>> Подскажите как можно приблизить скорость отдачи к drive или ya. >>> Если сервер, диск(хотя iowait 0.01-0.05), то подскажите на что его можно >>> заменить >> >> Судя по цифрам, то, что у вас получается - это в первую очередь >> результат большого RTT + работы механизмов Congestion Control >> протокола TCP. >> >> Можно пытаться походить в сторону тюнинга initial congestion >> window size. Но, строго говоря, много это всё равно не даст - >> где-то пару round trip'ов можно сэкономить при использовании >> сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем >> больше ответ - тем меньше разница). Ну и на всякий случай >> напомню, что с тюнингом таких вещей следует быть осторожным, т.к. >> подобные действия отражаются на всех в сети. Прежде, чем >> ковыряться - лучше как минимум ознакомиться с теоретической >> стороной вопроса. > > Максим, разве Google не провел исследования, по результатам > которых они подняли icwnd до 10 на своих серверах? > > В последних версиях Linux kernel icwnd уже 10 по умолчанию > и может дать обратный эффект только в очень редких случаях > на сегодняшний день. > > TCP fast open в kernel 3.6+ следующей шаг, в который Google > вкладывает силы и деньги. Насколько мне известно, TCP Congestion window имеет смысл при согласовании окон получателя и отправителя. ICWND 2/3 были установлены по умолчанию много лет назад во времена dial-up. TCP Slow Start обязательно иметь включенным, но start after idle нет смысла оставлять 1 сек, как и размер окна 2/3. Мы уделяли большое внимание оптимизации TCP/IP стэка, результаты ниже. В течение длительного времени я не заметил побочных эффектов, возможно они и есть. Ваше мнение? net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_timestamps = 0 net.core.wmem_max = 256960 net.core.rmem_max = 256960 net.core.wmem_default = 256960 net.core.rmem_default = 256960 net.ipv4.tcp_wmem = 4096 87380 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 > >> >> Вообще, IMHO, в первую очередь имеет смысл смотреть за тем, чтобы >> с клиентами обеспечивались постоянные соединения. В nginx'е они >> по умолчанию включены, но лишний раз проверить не помешает. В >> частности - посмотреть на директиву keepalive_timeout и убедиться, >> что там никто не написал 0 в попытке поэкономить соединения. >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Mon Nov 4 20:03:14 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Tue, 5 Nov 2013 00:03:14 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgdC00LXQu9Cw0YLRjCDRgNC10LTQuNGA0LXQutGCPw==?= In-Reply-To: <69081383510401@web6g.yandex.ru> References: <69081383510401@web6g.yandex.ru> Message-ID: <201311050003.14773.vbart@nginx.com> On Monday 04 November 2013 00:26:41 studentikus at ya.ru wrote: > Подскажите, как сделать "сео"-редирект? > Это должно выглядеть примерно так, но... Чего-то я не понимаю. > > location /goto/ { > rewrite ^/goto/(.*)$ $1 redirect; > } > > > Т.е. что бы при переходе на site.ru/goto/ya.ru был 302 редирект на ya.ru rewrite ^/goto/(.*)$ http://$1 redirect; -- Валентин Бартенев From mdounin at mdounin.ru Mon Nov 4 20:19:59 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 Nov 2013 00:19:59 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: Message-ID: <20131104201959.GL95765@mdounin.ru> Hello! On Sat, Nov 02, 2013 at 10:21:39PM +0400, Dzmitry Stremkouski wrote: > Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module) > Настройку этого модуля производил по README от модуля. > Сам вебсервер собрал с такими параметрами в дебиане: > > nginx version: nginx/1.3.14 Порекомендую начать с простого. Не надо использовать 1.3.14, это старая и неподдерживаемая версия. Надо взять 1.5.6, где соответствующий модуль в коробке. [...] > Я пытался делать без проксирования, указывая URI > auth_request http://192.168.125.35/auth/ > Но это не работало и я в логах nginx видел ошибку > 2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp:// > 192.168.125.35/auth/index.html" is not found (2: No such file or > directory), client: 192.168.125.47, server: ssl.stremki.net, request: "GET > /mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/", host: " > ssl.stremki.net" > > Было бы здорово, если бы я смог работать без проксирования /auth/. > Просто, пока не понял, как прописать внутренний бекенд для обработки и > сейчас > пользуюсь локейшном /auth/ в режиме проксирования. Модуль auth_request не пытается реализовывать каких-либо протколов сам, он просто делает подзапрос. Точно так же, как это делает SSI или модуль addition. Настроить необходимую обработку для соответствующего URI, который вы используете в auth_request - ваша задача, будь то проксирование или что-либо ещё. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Mon Nov 4 21:05:40 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 4 Nov 2013 21:05:40 +0000 Subject: =?UTF-8?B?UmU6INCa0LDQuiDRg9GB0YLQsNC90L7QstC40YLRjCDQvNC+0LTRg9C70YwgaHR0?= =?UTF-8?B?cCBnemlwIHN0YXRpYyBtb2R1bGU/?= In-Reply-To: <1119325074.20131024214359@sadok.spb.ru> References: <1119325074.20131024214359@sadok.spb.ru> Message-ID: <7807E69B-E218-45E8-AAC5-212B2CE6AD4B@sonru.com> On 24 Oct 2013, at 18:43, Dmitry Ivanov wrote: > Здравствуйте, tfox. > > Вы писали 24 октября 2013 г., 21:38:10: > >> Здравствуйте. >> Мне необходимо установить модуль http_gzip_static_module >> FreeBSD 9.1 >> Nginx/1.4.2 > >> Как это сделать? Читал, что нужно как то пересобирать/перекомпилировать из >> портов, но не понял. Я новичок. Помогите пожалуйста. > > cd /usr/ports/www/nginx > make config (там всякие чекбокссы понажимать) > make > make deinstall && make reinstall && /usr/local/etc/rc.d/nginx restart не надо чекбоксы нажимать, собирайте с одноименными ключами, например: ./configure --with-http_gzip_static_module? чтобы совсем наглядно - немного устаревший пример, но суть та же: https://gist.github.com/mikhailov/3052776 > > > -- > С уважением, > Dmitry mailto:nginx-ru at sadok.spb.ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Nov 4 21:52:48 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 Nov 2013 01:52:48 +0400 Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90LDRjyDQvtGC0LTQsNGH0LAg0YHRgtCw0YLQuNC6?= =?UTF-8?B?0Lg=?= In-Reply-To: References: <20131030120849.GD84761@mdounin.ru> Message-ID: <20131104215248.GN95765@mdounin.ru> Hello! On Mon, Nov 04, 2013 at 06:09:57PM +0000, Anatoly Mikhailov wrote: [...] > > Судя по цифрам, то, что у вас получается - это в первую очередь > > результат большого RTT + работы механизмов Congestion Control > > протокола TCP. > > > > Можно пытаться походить в сторону тюнинга initial congestion > > window size. Но, строго говоря, много это всё равно не даст - > > где-то пару round trip'ов можно сэкономить при использовании > > сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем > > больше ответ - тем меньше разница). Ну и на всякий случай > > напомню, что с тюнингом таких вещей следует быть осторожным, т.к. > > подобные действия отражаются на всех в сети. Прежде, чем > > ковыряться - лучше как минимум ознакомиться с теоретической > > стороной вопроса. > > Максим, разве Google не провел исследования, по результатам > которых они подняли icwnd до 10 на своих серверах? Исследования Google отличаются, к сожалению, несколько однобоким подходом к проблеме. Вот тут, например, не рекомендуют: http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 Я, впрочем, ничего против icwnd 10 не имею. Но наблюдал людей, бездумно ставящих icwnd 100000, и призываю думать, прежде чем лезть в подобные вещи грязными руками. -- Maxim Dounin http://nginx.org/en/donation.html From anatoly at sonru.com Mon Nov 4 22:07:16 2013 From: anatoly at sonru.com (Anatoly Mikhailov) Date: Mon, 4 Nov 2013 22:07:16 +0000 Subject: =?UTF-8?B?UmU6INCc0LXQtNC70LXQvdC90LDRjyDQvtGC0LTQsNGH0LAg0YHRgtCw0YLQuNC6?= =?UTF-8?B?0Lg=?= In-Reply-To: <20131104215248.GN95765@mdounin.ru> References: <20131030120849.GD84761@mdounin.ru> <20131104215248.GN95765@mdounin.ru> Message-ID: <5249BB91-0CFB-454B-95E6-0F2C28C9902F@sonru.com> On 04 Nov 2013, at 21:52, Maxim Dounin wrote: > Hello! > > On Mon, Nov 04, 2013 at 06:09:57PM +0000, Anatoly Mikhailov wrote: > > [...] > >>> Судя по цифрам, то, что у вас получается - это в первую очередь >>> результат большого RTT + работы механизмов Congestion Control >>> протокола TCP. >>> >>> Можно пытаться походить в сторону тюнинга initial congestion >>> window size. Но, строго говоря, много это всё равно не даст - >>> где-то пару round trip'ов можно сэкономить при использовании >>> сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем >>> больше ответ - тем меньше разница). Ну и на всякий случай >>> напомню, что с тюнингом таких вещей следует быть осторожным, т.к. >>> подобные действия отражаются на всех в сети. Прежде, чем >>> ковыряться - лучше как минимум ознакомиться с теоретической >>> стороной вопроса. >> >> Максим, разве Google не провел исследования, по результатам >> которых они подняли icwnd до 10 на своих серверах? > > Исследования Google отличаются, к сожалению, несколько однобоким > подходом к проблеме. Вот тут, например, не рекомендуют: > > http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00 > > Я, впрочем, ничего против icwnd 10 не имею. Но наблюдал людей, > бездумно ставящих icwnd 100000, и призываю думать, прежде чем > лезть в подобные вещи грязными руками. Разумеется, значения окон icwnd/rwnd больше 10-16 редко имеют смысл, а 100000 - так вообще глупо. Google разработали SPDY и установка размера окон - это одна из важных их рекомендаций к использованию SPDY на стороне сервера, ровно как и увеличение/отключение таймаута на сужение окна tcp_slow_start_after_idle: http://dev.chromium.org/spdy/spdy-best-practices > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Nov 5 08:51:42 2013 From: nginx-forum at nginx.us (romkins514) Date: Tue, 05 Nov 2013 03:51:42 -0500 Subject: =?UTF-8?B?0LLQuNC00LjQvNC+IHJld3JpdGUg0LggbG9jYXRpb24=?= Message-ID: <9a5bb165fdd081bd80c4f1d03220542b.NginxMailingListRussian@forum.nginx.org> день добрый. перечитал форум, перепробовал кучу вариантов, но не правильно мыслю видимо совершенно. есть задача из редиректов апача, перевести в синтаксис нгикса. например. RewriteRule ^/pro/neon/?n1=1&n2=2&n3=3$ /pro/neon/ [L,R=301] сначала шёл простым путём, пробовал конвертерами, код получается не правильный. позже читал форум, варианты шли примерно вот такие: location = /pro/neon/ { rewrite ^/pro/neon/?n1=1&n2=2&n3=3$ http://xxx.ru/pro/neon/? redirect; } или location = /pro/neon/ { if ($args ~ ^n1){return 301 http://xxx.ru/pro/neon/;} } в общем-то практически все варианты возвращают 404 и в логах "/usr/local/etc/nginx/html/pro/neon/index.html" is not found (2: No such file or directory) спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244447,244447#msg-244447 From mitroko at gmail.com Tue Nov 5 10:40:17 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Tue, 5 Nov 2013 14:40:17 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131104201959.GL95765@mdounin.ru> References: <20131104201959.GL95765@mdounin.ru> Message-ID: Максим, спасибо за ваш ответ. Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить область поиска ошибки. На данный момент у меня сборка следующая: nginx version: nginx/1.5.6 built by gcc 4.4.5 (Debian 4.4.5-8) TLS SNI support enabled configure arguments: --with-openssl=/usr/build/openssl-1.0.1e --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-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-mail --with-mail_ssl_module --add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module --with-http_auth_request_module Все симптомы остались прежними. CGI скрипты нагиоса работают через такую связку отлично, как и ранее. однако, другие приложения (owncloud, roundcube) требуют "медленного" прохода. Ещё сделал различие, что нагиос работает везде GET запросами, в то время, как owncloud, jenkins, roundcube делают периодически POST Возможно, это неверно как-то обрабатывается. Дополнительно, я попытался смягчить условия для мониторинга, прописал в http секцию geo $ip_range { default 0; 192.168.125.0/24 1; } и в секциях server/location set $auth_location /auth/; if ( $ip_range = 1 ) { set $auth_location /always_ok; } location = /always_ok { return 200; } location /jenkins { auth_request $auth_location; proxy_pass http://192.168.125.37:8080; proxy_buffering on; proxy_set_header SSL NO; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 1800; } такая связка не работает. Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а не делает подзапрос в локейшн возращаемый переменной. 2013/11/05 13:17:13 [error] 32126#0: *1243 open() "/usr/local/nginx/html$auth_location" failed (2: No such file or directory), client: 185.6.244.255, server: ssl.stremki.net, request: "GET /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest: "$auth_location", host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/" 2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected status: 404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/" Я включил дебаг для своего адреса. Вот, его вывод. http://pastebin.com/aKDG4gYk Буду благодарен за помощь. 2013/11/5 Maxim Dounin > Hello! > > On Sat, Nov 02, 2013 at 10:21:39PM +0400, Dzmitry Stremkouski wrote: > > > Я установил nginx и модуль Максима Дунина (ngx_http_auth_request_module) > > Настройку этого модуля производил по README от модуля. > > Сам вебсервер собрал с такими параметрами в дебиане: > > > > nginx version: nginx/1.3.14 > > Порекомендую начать с простого. Не надо использовать 1.3.14, это > старая и неподдерживаемая версия. Надо взять 1.5.6, где > соответствующий модуль в коробке. > > [...] > > > Я пытался делать без проксирования, указывая URI > > auth_request http://192.168.125.35/auth/ > > Но это не работало и я в логах nginx видел ошибку > > 2013/11/01 23:31:51 [error] 10938#0: *245 "/usr/local/nginx/htmlhttp:// > > 192.168.125.35/auth/index.html" is not found (2: No such file or > > directory), client: 192.168.125.47, server: ssl.stremki.net, request: > "GET > > /mail/ HTTP/1.1", subrequest: "http://192.168.125.35/auth/", host: " > > ssl.stremki.net" > > > > Было бы здорово, если бы я смог работать без проксирования /auth/. > > Просто, пока не понял, как прописать внутренний бекенд для обработки и > > сейчас > > пользуюсь локейшном /auth/ в режиме проксирования. > > Модуль auth_request не пытается реализовывать каких-либо > протколов сам, он просто делает подзапрос. Точно так же, как это > делает SSI или модуль addition. > > Настроить необходимую обработку для соответствующего URI, который > вы используете в auth_request - ваша задача, будь то проксирование > или что-либо ещё. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy at gmail.com Tue Nov 5 11:13:00 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Tue, 5 Nov 2013 15:13:00 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> Message-ID: Здравствуйте. location /jenkins { auth_request /auth; ... } location = /auth { internal; if ($ip_range) { return 200; } proxy_pass http://your_authentication_backend; ... } ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitroko at gmail.com Tue Nov 5 11:14:50 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Tue, 5 Nov 2013 15:14:50 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> Message-ID: Вадим, здравствуйте! Я могу сделать его internal, но мне этот локейшн нужен извне, также. Или от этого ломается логика модуля Максима? On Tue, Nov 5, 2013 at 3:13 PM, Vadim Lazovskiy wrote: > Здравствуйте. > > location /jenkins { > auth_request /auth; > > ... > } > > location = /auth { > internal; > > if ($ip_range) { > return 200; > } > > proxy_pass http://your_authentication_backend; > ... > } > > ? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.lazovskiy at gmail.com Tue Nov 5 11:21:54 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Tue, 5 Nov 2013 15:21:54 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> Message-ID: Должно работать и без internal 5 ноября 2013 г., 15:14 пользователь Dzmitry Stremkouski написал: > Вадим, здравствуйте! > Я могу сделать его internal, но мне этот локейшн нужен извне, также. > Или от этого ломается логика модуля Максима? > > > On Tue, Nov 5, 2013 at 3:13 PM, Vadim Lazovskiy > wrote: > >> Здравствуйте. >> >> location /jenkins { >> auth_request /auth; >> >> ... >> } >> >> location = /auth { >> internal; >> >> if ($ip_range) { >> return 200; >> } >> >> proxy_pass http://your_authentication_backend; >> ... >> } >> >> ? >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- >
> (o_ - Dzmitry Stremkouski.
> //\ - cel: +7 (916) 090-85-68
> V_/_- web: http://mitroko.com
> 
> > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitroko at gmail.com Tue Nov 5 11:22:27 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Tue, 5 Nov 2013 15:22:27 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> Message-ID: Хотя, ваша конструкция if ($ip_range) { return 200; } помогла решить проблему мониторинга. RoundCube пока не работает через /auth/. Спасибо! 2013/11/5 Dzmitry Stremkouski > Вадим, здравствуйте! > Я могу сделать его internal, но мне этот локейшн нужен извне, также. > Или от этого ломается логика модуля Максима? > > > On Tue, Nov 5, 2013 at 3:13 PM, Vadim Lazovskiy > wrote: > >> Здравствуйте. >> >> location /jenkins { >> auth_request /auth; >> >> ... >> } >> >> location = /auth { >> internal; >> >> if ($ip_range) { >> return 200; >> } >> >> proxy_pass http://your_authentication_backend; >> ... >> } >> >> ? >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- >
> (o_ - Dzmitry Stremkouski.
> //\ - cel: +7 (916) 090-85-68
> V_/_- web: http://mitroko.com
> 
> --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Nov 5 14:08:41 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 Nov 2013 18:08:41 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> Message-ID: <20131105140841.GU95765@mdounin.ru> Hello! On Tue, Nov 05, 2013 at 02:40:17PM +0400, Dzmitry Stremkouski wrote: > Максим, спасибо за ваш ответ. > Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить > область поиска ошибки. > > На данный момент у меня сборка следующая: > nginx version: nginx/1.5.6 > built by gcc 4.4.5 (Debian 4.4.5-8) > TLS SNI support enabled > configure arguments: --with-openssl=/usr/build/openssl-1.0.1e > --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-http_flv_module --with-http_geoip_module > --with-http_gzip_static_module --with-http_realip_module > --with-http_stub_status_module --with-http_ssl_module > --with-http_sub_module --with-mail --with-mail_ssl_module > --add-module=/usr/build/nginx-upstream-fair-master --with-http_spdy_module > --with-http_auth_request_module > > Все симптомы остались прежними. > CGI скрипты нагиоса работают через такую связку отлично, как и ранее. > однако, другие приложения (owncloud, roundcube) требуют "медленного" > прохода. > Ещё сделал различие, что нагиос работает везде GET запросами, в то время, > как owncloud, jenkins, roundcube делают периодически POST > Возможно, это неверно как-то обрабатывается. > > Дополнительно, я попытался смягчить условия для мониторинга, прописал в > http секцию > > geo $ip_range { > default 0; > 192.168.125.0/24 1; > } > > и в секциях server/location > > set $auth_location /auth/; > if ( $ip_range = 1 ) { > set $auth_location /always_ok; > } > > location = /always_ok { > return 200; > } > > location /jenkins { > auth_request $auth_location; > proxy_pass http://192.168.125.37:8080; > proxy_buffering on; > proxy_set_header SSL NO; > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_read_timeout 1800; > } > > такая связка не работает. > Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а > не делает подзапрос в локейшн возращаемый переменной. > > 2013/11/05 13:17:13 [error] 32126#0: *1243 open() > "/usr/local/nginx/html$auth_location" failed (2: No such file or > directory), client: 185.6.244.255, server: ssl.stremki.net, request: "GET > /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest: "$auth_location", > host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/" > 2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected status: > 404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET > /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net", > referrer: "https://ssl.stremki.net/jenkins/" > > Я включил дебаг для своего адреса. Вот, его вывод. > http://pastebin.com/aKDG4gYk Директива auth_request не понимает переменных, и ваша конфигурация ожидаемо пытается обратиться к файлу, которого не существует. Правильное решение исходной задачи "разрешить свою сеть, для остальных - требовать авторизацию" - написать что-нибудь вроде: location / { satisfy any; auth_request /auth; allow 192.168.125.0/24; deny all; ... } http://nginx.org/r/satisfy Что конкретно у вас происходит в случае, когда конфигурация работоспособна и помогает "замедление" - надо смотреть, но скорее всего просто авторизационный бекенд не справляется с нагрузкой. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Nov 5 14:30:54 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 Nov 2013 18:30:54 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggZ3ppcCDQvdC1INGA0LDQsdC+?= =?UTF-8?B?0YLQsNC10YIgY2h1bmstZW5jb2Rpbmc=?= In-Reply-To: References: Message-ID: <20131105143053.GV95765@mdounin.ru> Hello! On Mon, Nov 04, 2013 at 05:10:14AM -0500, vulgast wrote: > Такое впечетление, что есть какой-то буфер 4096+, который нужно заполнить, > иначе чанк просто не отдается даже при сбросе буффера в php. Может это > какой-то буфер в пхп или нжинксе? Для эффективного сжатия данных - их надо сначала накопить хоть сколько-то, что и делает библиотека zlib, которую nginx использует для реализации gzip-сжатия. Чтобы данные по возможности не буферизировались nginx'ом при обработки ответов fastcgi-бекенда, а сразу отправлялись клиенту (в случае gzip'а - ценой худшего сжатия) - существует директива fastcgi_buffering, документация тут: http://nginx.org/r/fastcgi_buffering/ru Директива fastcgi_buffering появилась в nginx 1.5.6. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Tue Nov 5 16:02:15 2013 From: nginx-forum at nginx.us (Bionicman) Date: Tue, 05 Nov 2013 11:02:15 -0500 Subject: Nginx + Crome: part header is too long (400) Message-ID: Используеся nginx + flash uploader для загузки файлов в медиахранилище. В целом, конфигурация стандартная. Возникла проблема с ответом от сервера кода 400 при попытке загрузки файлов через crome (при этом неисправность плавающая и не зависит от самого файла). Этот же файл в следующий раз загружается нормально, а какой-нибудь другой отдаёт 400. Увеличение буферов не особо помогает. Тестировалось также в FF, Opera, Safari: проблема не проявляется. Читал о схожей проблеме тут: http://forum.nginx.org/read.php?2,214924,214926 Но не понял, какие из этого делать выводы. Вот момент возникновения ошибки: 2013/11/05 19:17:45 [debug] 44995#0: *204201812 hashed path: /home/web/tmp_storage/0038896449 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".name" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".content_type" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "application/octet-stream" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 posix_memalign: 0000000803CA8000:4096 @16 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".path" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "/home/web/tmp_storage/0038896449" 2013/11/05 19:17:45 [info] 44995#0: *204201812 started uploading file "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" to "/home/web/tmp_storage/0038896449" (field "Filedata", content type "application/octet-stream"), client: 83.220.58.78, server: test.org, request: "POST /uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160 HTTP/1.1", host: "test.org", referrer: "http://test.org/" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 write: 32, 0000000803CA7000, 4096, 0 2013/11/05 19:17:45 [debug] 44995#0: *204201812 recv: eof:0, avail:5530, err:0 2013/11/05 19:17:45 [debug] 44995#0: *204201812 recv: fd:30 8192 of 8192 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http client request body recv 8192 2013/11/05 19:17:45 [debug] 44995#0: *204201812 write: 32, 0000000803CA7000, 4096, 4096 2013/11/05 19:17:45 [debug] 44995#0: *204201812 write: 32, 0000000803CA7000, 69, 8192 2013/11/05 19:17:45 [info] 44995#0: *204201812 finished uploading file "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" to "/home/web/tmp_storage/0038896449", client: 83.220.58.78, server: test.org, request: "POST /uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160 HTTP/1.1", host: "test.org", referrer: "http://test.org/" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".md5" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "9456bbbe7305698929a7ff9ab111602c" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".size" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "8261" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 malformed filename in part header 2013/11/05 19:17:45 [debug] 44995#0: *204201812 invalid Content-Disposition header 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http finalize request: 400, "/uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160" a:1, c:2 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http special response: 400, "/uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 uploadprogress error-tracker error: 400 2013/11/05 19:17:45 [debug] 44995#0: *204201812 uploadprogress error-tracker not tracking in this location 2013/11/05 19:17:45 [debug] 44995#0: *204201812 charset: "" > "utf-8" 2013/11/05 19:17:45 [debug] 44995#0: *204201812 HTTP/1.1 400 Bad Request Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244464,244464#msg-244464 From mdounin at mdounin.ru Tue Nov 5 16:58:53 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 5 Nov 2013 20:58:53 +0400 Subject: Nginx + Crome: part header is too long (400) In-Reply-To: References: Message-ID: <20131105165853.GA95765@mdounin.ru> Hello! On Tue, Nov 05, 2013 at 11:02:15AM -0500, Bionicman wrote: > Используеся nginx + flash uploader для загузки файлов в медиахранилище. В > целом, конфигурация стандартная. > > Возникла проблема с ответом от сервера кода 400 при попытке загрузки файлов > через crome (при этом неисправность плавающая и не зависит от самого файла). > Этот же файл в следующий раз загружается нормально, а какой-нибудь другой > отдаёт 400. Увеличение буферов не особо помогает. > > Тестировалось также в FF, Opera, Safari: проблема не проявляется. Читал о > схожей проблеме тут: http://forum.nginx.org/read.php?2,214924,214926 > Но не понял, какие из этого делать выводы. Приведённая ссылка - про совсем другую проблему. [...] > 2013/11/05 19:17:45 [info] 44995#0: *204201812 finished uploading file > "girl_walking_together_with_man_and_bike_into_the_sunset.jpg" to > "/home/web/tmp_storage/0038896449", client: 83.220.58.78, server: test.org, > request: "POST > /uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160 > HTTP/1.1", host: "test.org", referrer: "http://test.org/" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".md5" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: > "9456bbbe7305698929a7ff9ab111602c" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "Filedata" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script copy: ".size" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http script var: "8261" > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 malformed filename in part > header > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 invalid Content-Disposition > header > 2013/11/05 19:17:45 [debug] 44995#0: *204201812 http finalize request: 400, > "/uploadController/?username=test&userkey=aabc5f00f4140924e3014f2f42824160" > a:1, c:2 Судя по логу, используемому стороннему модулю не нравится заголовок Content-Disposition. -- Maxim Dounin http://nginx.org/en/donation.html From mitroko at gmail.com Tue Nov 5 20:03:25 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Wed, 6 Nov 2013 00:03:25 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131105140841.GU95765@mdounin.ru> References: <20131104201959.GL95765@mdounin.ru> <20131105140841.GU95765@mdounin.ru> Message-ID: Максим, спасибо огромное за подсказку с satisfy. Гораздо удобнее геомапинга. Я немного поэкспериментировал и выяснил, что nginx подвисает в подзапросе, если прилетает POST запрос. Я вставил следующее правило: location /auth { if ( $request_method = POST ) { return 200; } И все приложения заработали, как положено. Бэкенд отлично справляется с нагрузкой, дело не в нём. Видимо, когда приходит запрос на .https://ssl.stremki.net/project_nameметодом POST, то ngx_http_auth_request_module хочет сделать подзапрос таким же методом. Но, мало того, что он хочет это сделать, он зачем-то добавляет знак ? в конец локейшна /auth (это видно в дебаглоге) На стороне бэкенда в этот момент не видно никакого трафика от nginx. Тоесть, как только прилетает POST с данными на любой локейшн, который проверяется вашим модулем, nginx строит подзапрос с методом POST, добавляет символ ? и не делает подзапрос к бэкенду. Простите, если запутал. 2013/11/5 Maxim Dounin > Hello! > > On Tue, Nov 05, 2013 at 02:40:17PM +0400, Dzmitry Stremkouski wrote: > > > Максим, спасибо за ваш ответ. > > Я попробовал сделать апгрейд nginx по вашему замечанию, чтобы сузить > > область поиска ошибки. > > > > На данный момент у меня сборка следующая: > > nginx version: nginx/1.5.6 > > built by gcc 4.4.5 (Debian 4.4.5-8) > > TLS SNI support enabled > > configure arguments: --with-openssl=/usr/build/openssl-1.0.1e > > --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-http_flv_module --with-http_geoip_module > > --with-http_gzip_static_module --with-http_realip_module > > --with-http_stub_status_module --with-http_ssl_module > > --with-http_sub_module --with-mail --with-mail_ssl_module > > --add-module=/usr/build/nginx-upstream-fair-master > --with-http_spdy_module > > --with-http_auth_request_module > > > > Все симптомы остались прежними. > > CGI скрипты нагиоса работают через такую связку отлично, как и ранее. > > однако, другие приложения (owncloud, roundcube) требуют "медленного" > > прохода. > > Ещё сделал различие, что нагиос работает везде GET запросами, в то время, > > как owncloud, jenkins, roundcube делают периодически POST > > Возможно, это неверно как-то обрабатывается. > > > > Дополнительно, я попытался смягчить условия для мониторинга, прописал в > > http секцию > > > > geo $ip_range { > > default 0; > > 192.168.125.0/24 1; > > } > > > > и в секциях server/location > > > > set $auth_location /auth/; > > if ( $ip_range = 1 ) { > > set $auth_location /always_ok; > > } > > > > location = /always_ok { > > return 200; > > } > > > > location /jenkins { > > auth_request $auth_location; > > proxy_pass http://192.168.125.37:8080; > > proxy_buffering on; > > proxy_set_header SSL NO; > > proxy_set_header Host $host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_read_timeout 1800; > > } > > > > такая связка не работает. > > Ошибка в логе всё та же. auth_request зачем-то ищет файл $auth_location а > > не делает подзапрос в локейшн возращаемый переменной. > > > > 2013/11/05 13:17:13 [error] 32126#0: *1243 open() > > "/usr/local/nginx/html$auth_location" failed (2: No such file or > > directory), client: 185.6.244.255, server: ssl.stremki.net, request: > "GET > > /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", subrequest: > "$auth_location", > > host: "ssl.stremki.net", referrer: "https://ssl.stremki.net/jenkins/" > > 2013/11/05 13:17:13 [error] 32126#0: *1243 auth request unexpected > status: > > 404, client: 185.6.244.255, server: ssl.stremki.net, request: "GET > > /jenkins/login?from=%2Fjenkins%2F HTTP/1.1", host: "ssl.stremki.net", > > referrer: "https://ssl.stremki.net/jenkins/" > > > > Я включил дебаг для своего адреса. Вот, его вывод. > > http://pastebin.com/aKDG4gYk > > Директива auth_request не понимает переменных, и ваша конфигурация > ожидаемо пытается обратиться к файлу, которого не существует. > > Правильное решение исходной задачи "разрешить свою сеть, для > остальных - требовать авторизацию" - написать что-нибудь вроде: > > location / { > satisfy any; > > auth_request /auth; > > allow 192.168.125.0/24; > deny all; > > ... > } > > http://nginx.org/r/satisfy > > Что конкретно у вас происходит в случае, когда конфигурация > работоспособна и помогает "замедление" - надо смотреть, но скорее > всего просто авторизационный бекенд не справляется с нагрузкой. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Nov 6 07:38:12 2013 From: nginx-forum at nginx.us (ans34) Date: Wed, 06 Nov 2013 02:38:12 -0500 Subject: =?UTF-8?B?TmdpbnggMS4yLjcgKyBBcGFjaGUyIDIuMi4yNCBvbiBGcmVlYnNkIDkuMSDRhdC+?= =?UTF-8?B?0YHRgtC40L3QsyBzcGVlZHRlc3QgbWluaSDQv9GA0L7QsdC70LXQvNCwINGB?= =?UTF-8?B?IHVwbG9hZA==?= Message-ID: На сервере живет связка из Nginx 1.2.7 + Apache2 2.2.24. Конфиг nginx дефолтный, размеры буферов и т.п не переопределены. Перенес на этот сервер свой хост speedtest mini. Папка с файлами спидеста расположена на рамдиске и проблем с скоростью доступа к ним нет, скорость скачивания (downlaod) 300+ Mbit/s. Но есть проблемы с тестом скорости загрузки (upload) - 40-50 Mbit/s После отключения sendfile в конфиге nginx скорость подросла до 80-120 Mbit/s Во время теста загрузки в top io mode nginx показывает 100% загрузки VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 4839 0 0 16 0 16 100.00% nginx и gstat показывает активную запись на диск. Вынос client_body_temp_path на рамдиск и изменение переменных client_body* относительно дефолтных значений приводят только к ухудшению результата теста скорости. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244480#msg-244480 From kulmaks at gmail.com Wed Nov 6 09:31:53 2013 From: kulmaks at gmail.com (Maksim Kulik) Date: Wed, 6 Nov 2013 12:31:53 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: Вопрос уже поднимался в рассылке. Советом было: > Насколько я вижу, указанная зверушка проверяет скорость вверх с > помощью POST'ов размером 426565 байт. У вас же в конфиге: >> client_body_buffer_size 128k; > Т.е. все эти проверки скорости вверх - сначала попадают на nginx, > складываются им на диск, потом поднимаются с диска и отправляются на > апач. > Попробуйте для начала сделать > client_body_buffer_size 512k; > Должно заметно улучшить ситуацию. По дефолту у nginx client_body_buffer_size 8k|16k К сожалению, ответа на этот комментарий так и не поступило. 6 ноября 2013 г., 10:38 пользователь ans34 написал: > На сервере живет связка из Nginx 1.2.7 + Apache2 2.2.24. Конфиг nginx > дефолтный, размеры буферов и т.п не переопределены. Перенес на этот сервер > свой хост speedtest mini. Папка с файлами спидеста расположена на рамдиске > и > проблем с скоростью доступа к ним нет, скорость скачивания (downlaod) 300+ > Mbit/s. Но есть проблемы с тестом скорости загрузки (upload) - 40-50 Mbit/s > После отключения sendfile в конфиге nginx скорость подросла до 80-120 > Mbit/s > Во время теста загрузки в top io mode nginx показывает 100% загрузки > VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND > 4839 0 0 16 0 16 100.00% > nginx > > и gstat показывает активную запись на диск. > > Вынос client_body_temp_path на рамдиск и изменение переменных client_body* > относительно дефолтных значений приводят только к ухудшению результата > теста скорости. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244480,244480#msg-244480 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Nov 6 10:32:34 2013 From: nginx-forum at nginx.us (ans34) Date: Wed, 06 Nov 2013 05:32:34 -0500 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: Я игрался с этими параметрами. Все изменения (пробовал начиная с 8k до 1024k) приводили только к ухудшению результата в моем случае Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244489#msg-244489 From kulmaks at gmail.com Wed Nov 6 11:41:32 2013 From: kulmaks at gmail.com (Maksim Kulik) Date: Wed, 6 Nov 2013 14:41:32 +0300 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: А если тест проводить напрямую с Apache? Запись на какой носитель показывает gstat? На ramdisk или hdd? Можно попробовать подсмотреть что и куда он пишет (fstat или lsof). Можно проверить на последней версии nginx (nginx-devel в портах). Ну и последний вариант - перекомпилировать nginx с debug, включить дебаг логи и посмотреть что происходит при аплоаде. -------------- next part -------------- An HTML attachment was scrubbed... URL: From myc at barev.net Wed Nov 6 11:53:09 2013 From: myc at barev.net (Eugene Mychlo) Date: Wed, 6 Nov 2013 15:53:09 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131104201959.GL95765@mdounin.ru> References: <20131104201959.GL95765@mdounin.ru> Message-ID: <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> Добрый день, 05 нояб. 2013 г., в 0:19, Maxim Dounin написал(а): [?] > > Модуль auth_request не пытается реализовывать каких-либо > протколов сам, он просто делает подзапрос. Точно так же, как это > делает SSI или модуль addition. > > Настроить необходимую обработку для соответствующего URI, который > вы используете в auth_request - ваша задача, будь то проксирование > или что-либо ещё. [?] Раз возник топик про логику auth_request, задам и я пару уточняющих воросов: 1. Что вернется клиенту, если auth-подзапрос вернет код отличный от 200, 403 и 401, скажем 404 или 301, или 5xx? 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From citrin at citrin.ru Wed Nov 6 11:59:52 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Wed, 06 Nov 2013 15:59:52 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> Message-ID: <527A2F38.7080600@citrin.ru> On 11/06/13 15:53, Eugene Mychlo wrote: > 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? > Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. есть: http://nginx.org/r/auth_request_set From mdounin at mdounin.ru Wed Nov 6 12:07:42 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Nov 2013 16:07:42 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> <20131105140841.GU95765@mdounin.ru> Message-ID: <20131106120741.GC95765@mdounin.ru> Hello! On Wed, Nov 06, 2013 at 12:03:25AM +0400, Dzmitry Stremkouski wrote: > Максим, спасибо огромное за подсказку с satisfy. > Гораздо удобнее геомапинга. > > Я немного поэкспериментировал и выяснил, что nginx подвисает в подзапросе, > если прилетает POST запрос. > Я вставил следующее правило: > location /auth { > if ( $request_method = POST ) { return 200; } > > И все приложения заработали, как положено. Бэкенд отлично справляется с > нагрузкой, дело не в нём. > Видимо, когда приходит запрос на > .https://ssl.stremki.net/project_nameметодом POST, то > ngx_http_auth_request_module > хочет сделать подзапрос таким же методом. Нет, auth_request делает подзапрос методом GET. Если при POST'ах что-то не работает - скорее всего, вы недоконфигурили (или переконфигурили), и при обращении к бекенду передаётся заголовок Content-Length от основного запроса. Нужно, чтобы в location /auth стояло: proxy_set_header Content-Length ""; Покажите конфиг и debug log подвисания (без "if ($request_method) ...") - можно будет сказать подробнее. > Но, мало того, что он хочет это сделать, он зачем-то добавляет знак ? в > конец локейшна /auth (это видно в дебаглоге) > На стороне бэкенда в этот момент не видно никакого трафика от nginx. > Тоесть, как только прилетает POST с данными на любой локейшн, который > проверяется вашим модулем, nginx строит подзапрос с методом POST, добавляет > символ ? и не делает подзапрос к бэкенду. Символ "?" в отладочных логах - это нормально, он там есть всегда. -- Maxim Dounin http://nginx.org/en/donation.html From myc at barev.net Wed Nov 6 12:12:52 2013 From: myc at barev.net (Eugene Mychlo) Date: Wed, 6 Nov 2013 16:12:52 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <527A2F38.7080600@citrin.ru> References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> <527A2F38.7080600@citrin.ru> Message-ID: 06 нояб. 2013 г., в 15:59, Anton Yuzhaninov написал(а): > On 11/06/13 15:53, Eugene Mychlo wrote: >> 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? >> Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. > > есть: > http://nginx.org/r/auth_request_set > Замечательно. Спасибо. -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From mdounin at mdounin.ru Wed Nov 6 12:15:12 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Nov 2013 16:15:12 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> Message-ID: <20131106121512.GD95765@mdounin.ru> Hello! On Wed, Nov 06, 2013 at 03:53:09PM +0400, Eugene Mychlo wrote: > Добрый день, > > 05 нояб. 2013 г., в 0:19, Maxim Dounin написал(а): > > [?] > > > > > Модуль auth_request не пытается реализовывать каких-либо > > протколов сам, он просто делает подзапрос. Точно так же, как это > > делает SSI или модуль addition. > > > > Настроить необходимую обработку для соответствующего URI, который > > вы используете в auth_request - ваша задача, будь то проксирование > > или что-либо ещё. > > [?] > > Раз возник топик про логику auth_request, задам и я пару уточняющих воросов: > > 1. Что вернется клиенту, если auth-подзапрос вернет код отличный от 200, 403 и 401, скажем 404 или 301, или 5xx? Клиенту уйдёт 500, в логах появится запись "[error] ... auth request unexpected status: 404 ...". > 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? > Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. Антон уже отписал, директива auth_request_set - позволяет вынуть данные из заголовков ответа бекенда и сложить их в переменные. Использовать можно как-то так: location / { auth_request /auth; auth_request_set $backend $upstream_http_x_backend; proxy_pass http://$backend; } http://nginx.org/r/auth_request_set -- Maxim Dounin http://nginx.org/en/donation.html From myc at barev.net Wed Nov 6 12:31:46 2013 From: myc at barev.net (Eugene Mychlo) Date: Wed, 6 Nov 2013 16:31:46 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131106121512.GD95765@mdounin.ru> References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> <20131106121512.GD95765@mdounin.ru> Message-ID: 06 нояб. 2013 г., в 16:15, Maxim Dounin написал(а): > Hello! > > On Wed, Nov 06, 2013 at 03:53:09PM +0400, Eugene Mychlo wrote: > >> Добрый день, >> >> 05 нояб. 2013 г., в 0:19, Maxim Dounin написал(а): >> >> [?] >> >>> >>> Модуль auth_request не пытается реализовывать каких-либо >>> протколов сам, он просто делает подзапрос. Точно так же, как это >>> делает SSI или модуль addition. >>> >>> Настроить необходимую обработку для соответствующего URI, который >>> вы используете в auth_request - ваша задача, будь то проксирование >>> или что-либо ещё. >> >> [?] >> >> Раз возник топик про логику auth_request, задам и я пару уточняющих воросов: >> >> 1. Что вернется клиенту, если auth-подзапрос вернет код отличный от 200, 403 и 401, скажем 404 или 301, или 5xx? > > Клиенту уйдёт 500, в логах появится запись "[error] ... auth > request unexpected status: 404 ...?. > Понятно. >> 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? >> Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. > > Антон уже отписал, директива auth_request_set - позволяет вынуть > данные из заголовков ответа бекенда и сложить их в переменные. > Использовать можно как-то так: > > location / { > auth_request /auth; > auth_request_set $backend $upstream_http_x_backend; > > proxy_pass http://$backend; > } > > http://nginx.org/r/auth_request_set > В догонку. Директива auth_request понимает именованные локейшены? -- Regards, Eugene Mychlo MYC-RIPE EAMYC-RIPN From nginx-forum at nginx.us Wed Nov 6 13:48:07 2013 From: nginx-forum at nginx.us (ans34) Date: Wed, 06 Nov 2013 08:48:07 -0500 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: gstat показывает запись на hdd, lsof никакой разницы между открытыми на запись файлами в момент проведения теста и в момент бездействия не находит. Пересобирать nginx не вариант, т.к все ставилось вместе с ISP Manager, неизвестно какие опции применялись при установке пакетов. Да и сервер скорее боевой чем тестовый, сильно ломать его неохота. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244498#msg-244498 From mdounin at mdounin.ru Wed Nov 6 13:49:41 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Nov 2013 17:49:41 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> <20131106121512.GD95765@mdounin.ru> Message-ID: <20131106134941.GF95765@mdounin.ru> Hello! On Wed, Nov 06, 2013 at 04:31:46PM +0400, Eugene Mychlo wrote: [...] > >> 2. Есть ли возможность в основном запросе получить, в виде переменных, заголовки возвращаемые auth-подзапросом? > >> Просто есть желание заменить X-Accel-Redirect, и проксировать на разные бэкенды в зависимости от того, что вернул auth-бэкенд. > > > > Антон уже отписал, директива auth_request_set - позволяет вынуть > > данные из заголовков ответа бекенда и сложить их в переменные. > > Использовать можно как-то так: > > > > location / { > > auth_request /auth; > > auth_request_set $backend $upstream_http_x_backend; > > > > proxy_pass http://$backend; > > } > > > > http://nginx.org/r/auth_request_set > > > > В догонку. > Директива auth_request понимает именованные локейшены? Нет. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Nov 6 13:54:19 2013 From: nginx-forum at nginx.us (vulgast) Date: Wed, 06 Nov 2013 08:54:19 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggZ3ppcCDQvdC1INGA0LDQsdC+?= =?UTF-8?B?0YLQsNC10YIgY2h1bmstZW5jb2Rpbmc=?= In-Reply-To: <20131105143053.GV95765@mdounin.ru> References: <20131105143053.GV95765@mdounin.ru> Message-ID: <56aff6e5d1bf87e3783737f31c84c277.NginxMailingListRussian@forum.nginx.org> Фух... Спасибо большое! Помогло! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244400,244500#msg-244500 From mitroko at gmail.com Wed Nov 6 15:23:52 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Wed, 6 Nov 2013 19:23:52 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131106134941.GF95765@mdounin.ru> References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> <20131106121512.GD95765@mdounin.ru> <20131106134941.GF95765@mdounin.ru> Message-ID: Максим, я сделал ещё пару экспериментов в сторону упрощения конфигурации сервера. Выключение опции spdy: server { # listen 443 ssl spdy default_server; listen 443 ssl default_server; дало работоспособность вашего модуля на все сто, без костылей. http://static.stremki.net/nginx-debug.log Вот, дебаглог при простой конфигурации Локейшн /nauth 2013/11/6 Maxim Dounin > Hello! > > On Wed, Nov 06, 2013 at 04:31:46PM +0400, Eugene Mychlo wrote: > > [...] > > > >> 2. Есть ли возможность в основном запросе получить, в виде > переменных, заголовки возвращаемые auth-подзапросом? > > >> Просто есть желание заменить X-Accel-Redirect, и проксировать на > разные бэкенды в зависимости от того, что вернул auth-бэкенд. > > > > > > Антон уже отписал, директива auth_request_set - позволяет вынуть > > > данные из заголовков ответа бекенда и сложить их в переменные. > > > Использовать можно как-то так: > > > > > > location / { > > > auth_request /auth; > > > auth_request_set $backend $upstream_http_x_backend; > > > > > > proxy_pass http://$backend; > > > } > > > > > > http://nginx.org/r/auth_request_set > > > > > > > В догонку. > > Директива auth_request понимает именованные локейшены? > > Нет. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Nov 6 15:44:06 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 6 Nov 2013 19:44:06 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131104201959.GL95765@mdounin.ru> <91596973-7F49-4489-BFAF-FC1A4CCD2251@barev.net> <20131106121512.GD95765@mdounin.ru> <20131106134941.GF95765@mdounin.ru> Message-ID: <20131106154406.GH95765@mdounin.ru> Hello! On Wed, Nov 06, 2013 at 07:23:52PM +0400, Dzmitry Stremkouski wrote: > Максим, я сделал ещё пару экспериментов в сторону упрощения конфигурации > сервера. > Выключение опции spdy: > server { > # listen 443 ssl spdy default_server; > listen 443 ssl default_server; > > дало работоспособность вашего модуля на все сто, без костылей. > http://static.stremki.net/nginx-debug.log > Вот, дебаглог при простой конфигурации > Локейшн /nauth А, понятно. Цитирую документацию по модулю spdy, "модуль экспериментальный, поэтому возможно всё". Чтение тела запроса в spdy-модуле, скажем так, нуждается в доработке, в нетривиальных конструкциях с подзапросами там могут быть нюансы. Валентин, взгляни? ЕМНИП, я тебе уже как-то показывал пальцем на эту проблему в коде spdy. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Wed Nov 6 16:34:05 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 6 Nov 2013 20:34:05 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <20131106134941.GF95765@mdounin.ru> Message-ID: <201311062034.05630.vbart@nginx.com> On Wednesday 06 November 2013 19:23:52 Dzmitry Stremkouski wrote: > Максим, я сделал ещё пару экспериментов в сторону упрощения конфигурации > сервера. > Выключение опции spdy: > server { > # listen 443 ssl spdy default_server; > listen 443 ssl default_server; > > дало работоспособность вашего модуля на все сто, без костылей. > http://static.stremki.net/nginx-debug.log > Вот, дебаглог при простой конфигурации > Локейшн /nauth > [..] Должно помочь со SPDY: diff -r f817f9d1cded src/http/ngx_http_request_body.c --- a/src/http/ngx_http_request_body.c Mon Nov 04 17:00:25 2013 -0800 +++ b/src/http/ngx_http_request_body.c Wed Nov 06 20:32:15 2013 +0400 @@ -43,7 +43,7 @@ ngx_http_read_client_request_body(ngx_ht r->main->count++; #if (NGX_HTTP_SPDY) - if (r->spdy_stream) { + if (r->spdy_stream && r == r->main) { rc = ngx_http_spdy_read_request_body(r, post_handler); goto done; } -- Валентин Бартенев From mitroko at gmail.com Wed Nov 6 19:42:19 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Wed, 6 Nov 2013 23:42:19 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <201311062034.05630.vbart@nginx.com> References: <20131106134941.GF95765@mdounin.ru> <201311062034.05630.vbart@nginx.com> Message-ID: Увы, патч не помог. http://static.stremki.net/nginx-debug-spdy0.log Вот, лог. Я пока выключил spdy, жаль, конечно. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Wed Nov 6 21:49:34 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Thu, 7 Nov 2013 01:49:34 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <201311062034.05630.vbart@nginx.com> Message-ID: <201311070149.34393.vbart@nginx.com> On Wednesday 06 November 2013 23:42:19 Dzmitry Stremkouski wrote: > Увы, патч не помог. > http://static.stremki.net/nginx-debug-spdy0.log > Вот, лог. > Я пока выключил spdy, жаль, конечно. > ? Лог по ссылке в точности такой, как если бы nginx был собран без патча. Проверьте, что патч действительно был применен, что после применения патча сборка прошла успешно, и что был действительно запущен собранный с патчем nginx, а не какой-то другой. У меня на аналогичной конфигурации без патча проблема стабильно воспроизводится, с патчем - нет. -- Валентин Бартенев From chipitsine at gmail.com Thu Nov 7 02:50:16 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 7 Nov 2013 08:50:16 +0600 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: поддержка ISP Manager что говорит по поводу данной ситуации ? 6 ноября 2013 г., 19:48 пользователь ans34 написал: > gstat показывает запись на hdd, lsof никакой разницы между открытыми на > запись файлами в момент проведения теста и в момент бездействия не находит. > Пересобирать nginx не вариант, т.к все ставилось вместе с ISP Manager, > неизвестно какие опции применялись при установке пакетов. Да и сервер скорее > боевой чем тестовый, сильно ломать его неохота. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244498#msg-244498 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mitroko at gmail.com Thu Nov 7 05:35:43 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Thu, 7 Nov 2013 09:35:43 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <201311070149.34393.vbart@nginx.com> References: <201311062034.05630.vbart@nginx.com> <201311070149.34393.vbart@nginx.com> Message-ID: Да, прошу прощения, во время раскладки не скопировал новый бинарник. Сейчас всё работает! Спасибо огромное всем в этом треде! 2013/11/7 Валентин Бартенев > On Wednesday 06 November 2013 23:42:19 Dzmitry Stremkouski wrote: > > Увы, патч не помог. > > http://static.stremki.net/nginx-debug-spdy0.log > > Вот, лог. > > Я пока выключил spdy, жаль, конечно. > > ? > > Лог по ссылке в точности такой, как если бы nginx был собран без патча. > > Проверьте, что патч действительно был применен, что после применения патча > сборка прошла успешно, и что был действительно запущен собранный с патчем > nginx, а не какой-то другой. > > У меня на аналогичной конфигурации без патча проблема стабильно > воспроизводится, > с патчем - нет. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Nov 7 08:04:30 2013 From: nginx-forum at nginx.us (maxim88) Date: Thu, 07 Nov 2013 03:04:30 -0500 Subject: =?UTF-8?B?0KPQstC10LvQuNGH0LjQstCw0LXRgtGB0Y8g0LLRgNC10LzRjyDQvtGC0LLQtdGC?= =?UTF-8?B?0LAgTkdJTlg/?= Message-ID: <2e6e8f726aef74a086b042e53bf569f5.NginxMailingListRussian@forum.nginx.org> Добрый день. Имеем: Ubuntu 12.04 с 1Гиг RAM, NGINX, PHP-FPM+APC, Varnish, WordPress Иногда машина уходит в swap после которого время отклика NGINX увеличивается в десятки раз, иными словами вэб сервер дико тормозит до ребута. https://dl.dropboxusercontent.com/u/1290139/nginx.jpg Проблема еще в том, что иногда это происходит в течении короткого промежутка 10-15 минут, после чего вэб сервер начинает работать штатно без каких либо вмешательств. . Подскажите что это может быть и в какую строну двигаться? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244513,244513#msg-244513 From undying-m at yandex.ru Thu Nov 7 08:11:15 2013 From: undying-m at yandex.ru (Den Bozhok) Date: Thu, 07 Nov 2013 12:11:15 +0400 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C40LLQsNC10YLRgdGPINCy0YDQtdC80Y8g0L7RgtCy?= =?UTF-8?B?0LXRgtCwIE5HSU5YPw==?= In-Reply-To: <2e6e8f726aef74a086b042e53bf569f5.NginxMailingListRussian@forum.nginx.org> References: <2e6e8f726aef74a086b042e53bf569f5.NginxMailingListRussian@forum.nginx.org> Message-ID: <81911383811875@web2g.yandex.ru> An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Nov 7 10:13:20 2013 From: nginx-forum at nginx.us (ans34) Date: Thu, 07 Nov 2013 05:13:20 -0500 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: <826431f0d45e5afb2366d037039ddb1d.NginxMailingListRussian@forum.nginx.org> Илья Шипицин Wrote: ------------------------------------------------------- > поддержка ISP Manager что говорит по поводу данной ситуации ? > Еще не обращался к ним Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244516#msg-244516 From nginx-forum at nginx.us Thu Nov 7 14:21:54 2013 From: nginx-forum at nginx.us (dwow) Date: Thu, 07 Nov 2013 09:21:54 -0500 Subject: uWSGI Message-ID: Добрый день, такой вопрос, есть бэкенд, который обрабатывает запросы, можно ли сделать так, чтобы для некоторых локейшенов результаты работы кешировались? Т.е. бэкенд обрабатывает /a /b /c я хочу сделать, чтобы для /b ответ кешировался. Спасибо. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244521,244521#msg-244521 From nginx-forum at nginx.us Thu Nov 7 20:11:33 2013 From: nginx-forum at nginx.us (ZERGEV) Date: Thu, 07 Nov 2013 15:11:33 -0500 Subject: =?UTF-8?B?0J3QtdGB0LrQvtC70YzQutC+INGB0LDQudGC0L7QsiDQsiDQvtC00L3QvtC8INC0?= =?UTF-8?B?0L7QvNC10L3QtQ==?= Message-ID: Привет, Есть домен: http://example.com Нужно сделать несколько независимых сайтов на WordPress. URL должны быть вида: http://example.com/tiger http://example.com/lynx http://example.com/lion По каждой ссылке будет установлен WordPress. Для начала не могу понять что писать в server_name для каждого из сайтов и как вообще их разграничить. На данный момент есть такой конфиг: server { listen 80; server_name example.com; rewrite ^(.*) http://www.example.com$1 permanent; } server { listen 80; server_name www.example.com; client_max_body_size 5m; client_body_timeout 60; access_log /var/log/nginx/my-wordpress.com-access; error_log /var/log/nginx/my-wordpress.com-error error; root /var/www/html/my-wordpress.com/; index index.html index.php; ### root directory ### location / { try_files $uri $uri/ /index.php?$args; } ### security ### error_page 403 =404; location ~ /\. { access_log off; log_not_found off; deny all; } location ~ ~$ { access_log off; log_not_found off; deny all; } location ~* wp-admin/includes { deny all; } location ~* wp-includes/theme-compat/ { deny all; } location ~* wp-includes/js/tinymce/langs/.*\.php { deny all; } location /wp-includes/ { internal; } #location ~* wp-config.php { deny all; } location ~* ^/wp-content/uploads/.*.(html|htm|shtml|php)$ { types { } default_type text/plain; } # location ~* wp-admin { # allow ; # allow 127.0.0.1; # deny all; # } ### disable logging ### location = /robots.txt { access_log off; log_not_found off; } location = /favicon.ico { access_log off; log_not_found off; } ### caches ### location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ { access_log off; expires max; } location ~* \.(woff|svg)$ { access_log off; log_not_found off; expires 30d; } location ~* \.(js)$ { access_log off; log_not_found off; expires 7d; } ### php block ### location ~ \.php?$ { try_files $uri =404; include fastcgi_params; #fastcgi_pass 127.0.0.1:9001; fastcgi_pass unix:/var/run/php-wordpress.socket; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_intercept_errors on; fastcgi_split_path_info ^(.+\.php)(.*)$; #Prevent version info leakage fastcgi_hide_header X-Powered-By; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244522,244522#msg-244522 From postmaster at softsearch.ru Fri Nov 8 06:25:59 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Fri, 8 Nov 2013 10:25:59 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDRgdCw0LnRgtC+0LIg0LIg0L7QtNC90L4=?= =?UTF-8?B?0Lwg0LTQvtC80LXQvdC1?= In-Reply-To: References: Message-ID: <9510307114.20131108102559@softsearch.ru> Здравствуйте, ZERGEV. > Есть домен: > http://example.com > Нужно сделать несколько независимых сайтов на WordPress. > URL должны быть вида: > http://example.com/tiger > http://example.com/lynx > http://example.com/lion > По каждой ссылке будет установлен WordPress. > Для начала не могу понять что писать в server_name для каждого из сайтов example.com > и > как вообще их разграничить. по location-ам . -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Fri Nov 8 06:44:35 2013 From: nginx-forum at nginx.us (ZERGEV) Date: Fri, 08 Nov 2013 01:44:35 -0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDRgdCw0LnRgtC+0LIg0LIg0L7QtNC90L4=?= =?UTF-8?B?0Lwg0LTQvtC80LXQvdC1?= In-Reply-To: <9510307114.20131108102559@softsearch.ru> References: <9510307114.20131108102559@softsearch.ru> Message-ID: > example.com Так если server_name будет одинаковые, то конфиг будет не валидный и nginx будет ругаться. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244522,244525#msg-244525 From undying-m at yandex.ru Fri Nov 8 06:49:05 2013 From: undying-m at yandex.ru (Den Bozhok) Date: Fri, 08 Nov 2013 10:49:05 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDRgdCw0LnRgtC+0LIg0LIg0L7QtNC90L4=?= =?UTF-8?B?0Lwg0LTQvtC80LXQvdC1?= In-Reply-To: References: <9510307114.20131108102559@softsearch.ru> Message-ID: <38391383893345@web7h.yandex.ru> Так вы в одном конфиге для одного server_name укажите множество location 08.11.2013, 10:45, "ZERGEV" : >>  example.com > > Так если server_name будет одинаковые, то конфиг будет не валидный и nginx > будет ругаться. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244522,244525#msg-244525 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From undying-m at yandex.ru Fri Nov 8 06:53:32 2013 From: undying-m at yandex.ru (Den Bozhok) Date: Fri, 08 Nov 2013 10:53:32 +0400 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDRgdCw0LnRgtC+0LIg0LIg0L7QtNC90L4=?= =?UTF-8?B?0Lwg0LTQvtC80LXQvdC1?= In-Reply-To: <38391383893345@web7h.yandex.ru> References: <9510307114.20131108102559@softsearch.ru> <38391383893345@web7h.yandex.ru> Message-ID: <53191383893612@web7h.yandex.ru> An HTML attachment was scrubbed... URL: From sb at nginx.com Fri Nov 8 07:27:16 2013 From: sb at nginx.com (Sergey Budnevitch) Date: Fri, 8 Nov 2013 11:27:16 +0400 Subject: uWSGI In-Reply-To: References: Message-ID: On 07.11.2013, at 18:21, dwow wrote: > Добрый день, > такой вопрос, есть бэкенд, который обрабатывает запросы, можно ли сделать > так, чтобы для некоторых локейшенов результаты работы кешировались? > Т.е. бэкенд обрабатывает > /a > /b > /c > я хочу сделать, чтобы для /b ответ кешировался. uwsgi_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=one:10m; server { # ? location /b { # ? uwsgi_cache one; uwsgi_cache_valid 5m; } } From nginx-forum at nginx.us Fri Nov 8 08:36:33 2013 From: nginx-forum at nginx.us (vnginx) Date: Fri, 08 Nov 2013 03:36:33 -0500 Subject: The North Face Women's Jackets Gore Tex 3 in 1 Blue MJ1115 Message-ID: The first option we'll be [url=http://www.northfacedealsblackfriday.com]north face black Friday 2013[/url] checking out offers a fabulous choice for those of you who are looking for a little bit of funk while taking on the sloped. The North Face's 'Women's Julbilee Ltd. Jacket' will definitely add a little spice to your days out on the slopes. This mod coat boasts a classic hip-length style with adjustable hood, while boasting a seriously chic and modern geometric pattern running the length of the coat in red, black, and grey rectangles, on a white background. This pixel-pretty print adds a lot of fun, while the waterproof exterior, breathable interior, and fully sealed Gore-Tex Performance shell fabric make this a great choice when it comes to keeping warm and dry in just about any weather condition. Plus, its lightweight, thermal PrimaLoft Eco insulation, makes it nice and cozy on the inside, as well. Couple this cool coat with your favorite pair of snowboarding pants, bootleg jeans, and ski boots, and you'll be all set for the slopes. The North Face Womens Metropolis parka is definitely a winner as this knee length long cut jacket creates an extra shield against freezing weather and delivers exceptional thermal warmth thanks to the 600 fill down insulation. Another jacket which is a keeper is the North Face Itsy Jacket Womens which provides classic protection for a day on the slopes. Waterproof, breathable, and filled with a warm synthetic insulation, this jacket has all the features for your snow sports adventures. You can even customize your Itsy jacket, as both the adjustable hood and powder skirt detaches. This powder skirt has an elastic [url=http://www.northfacedealsblackfriday.com/north-face-gloves-c-23_24.html]black friday north face gloves deals[/url] gripper to prevent the snow from riding up your jacket. With the exception of making use of biodegradable, pollution free resources and recycling of commodity, there is now the tendency towards the use of raw materials that should be took advantage of a variety of goals. With an understanding of the lure of the natural challenges set by Mother Nature with regards to the mountaineering world, and as a result of their extensive creative research techniques north face arctic parka.North face arctic parka has recently surfaced as a popular winter-wear selling brand of North America. This brand offers a variety of winter outfits ranging from hooded jackets and coats to outdoor boots, sweat shirts and sweaters for both men and women belonging to different age groups. Jackets and coats are widely used products of this brand. Availability of different styles, simple colors of the garments that suits different occasions and instant warmth provided by these clothes are few reasons that make this brand popular. Teenagers and middle aged women generally prefer North face arctic parka jackets that come in thigh length cuts. They are small sized and stop right above your knee. They affectively cover your waistline and complement your body contour. These jackets are lined with fur and insulated materials that prevent your body heat from flowing outside. Men, on the contrary, prefer full-trimmed hooded jackets that are lined with faux fur or coyote fur to prevent cold winds and moisture from attacking you. Fur lining adds extra warmth to your body. Earlier manufacturers used rabbit fur as well however, due to active functioning of agencies that protect animal rights and declining number of furry animals, makers have started synthesizing synthetic furs for this purpose.If you're a proud owner or North face arctic parka jackets or coats, you must be familiar with the fact that these outfits are made using down feathers, faux fur or other delicate synthetically prepared fibers. As a result, these materials require extra care in terms of cleaning and storage. You need to be careful while handling North face winter wear. The cleaning process is very simple so, follow these simple tips in order to clean your jackets. Based on this point, the north face is usually able to meet the requirements of different customers. In addition, the latest version of the 2010 autumn and winter series of new products, not only with high-end fabrics, exterior design is also swept away the dreary winter dull impression of the design of mixed colors will be dazzling color and three-dimensional cut way of life in the city is also very suitable for wearing. On the side, North Face Institute of Technology reached with a lot of cooperation between industry, through sensible research and analysis to know the human body and each part of each movement muscles, nervous system, body temperature, developed the superlative fabrics are used for each area and function of outdoor products. With the popularity of outdoor sports, and changes in people's consumption idea, more and more people will go for to go outside for exercise for climbing or mountaineering. The North Face will benefit an advantage because of their [url=http://www.northfacedealsblackfriday.com]northfacedealsblackfriday.com[/url] most important adjustment in the price is bound extensively. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244531,244531#msg-244531 From nginx-forum at nginx.us Fri Nov 8 14:35:52 2013 From: nginx-forum at nginx.us (arty777) Date: Fri, 08 Nov 2013 09:35:52 -0500 Subject: nginx-1.5.6 In-Reply-To: <20131001140002.GH62063@mdounin.ru> References: <20131001140002.GH62063@mdounin.ru> Message-ID: С этой версией у меня проблема следующая: nginx -V ... --http-proxy-temp-path=/***/temp/proxy .... в конфиге прописано proxy_cache_path /***/temp/proxy так вот , только в этой версии стало , при запуске говорит что дубликат записи "/***/temp/proxy" в конфиге , указывает 1 реальную строку где путь к хранению кеша прописан и 1 нереальную , типа конец конфига . Как быть? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,243307,244540#msg-244540 From mdounin at mdounin.ru Fri Nov 8 15:12:54 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 8 Nov 2013 19:12:54 +0400 Subject: nginx-1.5.6 In-Reply-To: References: <20131001140002.GH62063@mdounin.ru> Message-ID: <20131108151254.GW95765@mdounin.ru> Hello! On Fri, Nov 08, 2013 at 09:35:52AM -0500, arty777 wrote: > С этой версией у меня проблема следующая: > nginx -V > ... > --http-proxy-temp-path=/***/temp/proxy > .... > > в конфиге прописано > proxy_cache_path /***/temp/proxy > > так вот , только в этой версии стало , при запуске говорит что дубликат > записи "/***/temp/proxy" в конфиге , указывает 1 реальную строку где путь к > хранению кеша прописан и 1 нереальную , типа конец конфига . > > > Как быть? Не пытаться использовать под кеш и временные файлы один и тот же каталог, указать разные. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Sat Nov 9 00:37:31 2013 From: nginx-forum at nginx.us (ZERGEV) Date: Fri, 08 Nov 2013 19:37:31 -0500 Subject: =?UTF-8?B?UmU6INCd0LXRgdC60L7Qu9GM0LrQviDRgdCw0LnRgtC+0LIg0LIg0L7QtNC90L4=?= =?UTF-8?B?0Lwg0LTQvtC80LXQvdC1?= In-Reply-To: <53191383893612@web7h.yandex.ru> References: <53191383893612@web7h.yandex.ru> Message-ID: Спасибо. Все получилось. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244522,244544#msg-244544 From nginx-forum at nginx.us Sat Nov 9 11:53:04 2013 From: nginx-forum at nginx.us (maxim88) Date: Sat, 09 Nov 2013 06:53:04 -0500 Subject: =?UTF-8?B?UmU6INCj0LLQtdC70LjRh9C40LLQsNC10YLRgdGPINCy0YDQtdC80Y8g0L7RgtCy?= =?UTF-8?B?0LXRgtCwIE5HSU5YPw==?= In-Reply-To: <2e6e8f726aef74a086b042e53bf569f5.NginxMailingListRussian@forum.nginx.org> References: <2e6e8f726aef74a086b042e53bf569f5.NginxMailingListRussian@forum.nginx.org> Message-ID: <8b1304658cce454bd993547146918682.NginxMailingListRussian@forum.nginx.org> Up Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244513,244546#msg-244546 From nginx-forum at nginx.us Sat Nov 9 15:03:58 2013 From: nginx-forum at nginx.us (Spoler) Date: Sat, 09 Nov 2013 10:03:58 -0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSB0cnkgZmlsZXMgLSBuZ2lueC4g0KXQtdC70L8u?= Message-ID: Здравствуйте уважаемые форумчане! Уже мозг кипит не могу понять где у меня косяк (только разбираюсь с nginx). Не работает try_files есть: Сервер A - fs.site.ru - так же используется как файловый кеш (flv) и два сервера B и С - хранилища файлов(flv) они же в upstream Задача: когда заходим по сылке http://fs.site.ru/data/z/111.111.111.111/5960a0dbce3b7b355b4672d850936e3c/2.flv файл отдает сервер А, если он есть на нем, иначе вытянуть файл с @video. Но когда файл удаляю с кеша на сервере А, то try_files не перебрасывает на @video и выдает 404 ошибку где тут собака зарыта не могу понять, хелп... OS: CentOS 6.4? nginx 1.4.3 upstream remore { # ip_hash; server storage.ru; server storage2.ru; } server { listen 80; server_name fs.site.ru; location / { try_files $uri @video; } location /data/ { rewrite /data/(.+)/(.*)/(.+)/(.*)\.flv$ /realvideo/$4.flv; } location /realvideo/ { rewrite ^/realvideo/(.*)$ /$1 break; internal; flv; root /mnt/cache; } location @video { proxy_pass http://remote; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-ARGS $args; proxy_set_header X-URI $uri; proxy_pass_header Set-Cookie; } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244547,244547#msg-244547 From mitroko at gmail.com Sat Nov 9 16:00:11 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Sat, 9 Nov 2013 20:00:11 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <201311062034.05630.vbart@nginx.com> <201311070149.34393.vbart@nginx.com> Message-ID: Прошу прощения, что беспокою ещё раз в этом треде. У меня бэкенд возвращает авторизационные печеньки для клиента. Когда я прописываю в локейшн проекта auth_request /auth; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; мне присылает только одну из двух печенек от бэкенда. Я это вижу по времени expire. Если бекенд делает установку печенек в следующем порядке: Set-Cookie TokenKey ... Set-Cookie TokenLogin ... То в браузер клиента из локейшна прилетает на обновление только первая печенька (TokenKey), вторая (TokenLogin) остаётся неизменной. Мне важно обновлять обе печеньки клиента, чтобы поддерживать аутентификацию. Как прописать в локейшне проекта auth_request_set, чтобы обновлялась вся группа печенек, возвращаемых бэкендом. Спасибо! 2013/11/7 Dzmitry Stremkouski > Да, прошу прощения, во время раскладки не скопировал новый бинарник. > > Сейчас всё работает! > Спасибо огромное всем в этом треде! > > > 2013/11/7 Валентин Бартенев > >> On Wednesday 06 November 2013 23:42:19 Dzmitry Stremkouski wrote: >> > Увы, патч не помог. >> > http://static.stremki.net/nginx-debug-spdy0.log >> > Вот, лог. >> > Я пока выключил spdy, жаль, конечно. >> > ? >> >> Лог по ссылке в точности такой, как если бы nginx был собран без патча. >> >> Проверьте, что патч действительно был применен, что после применения патча >> сборка прошла успешно, и что был действительно запущен собранный с патчем >> nginx, а не какой-то другой. >> >> У меня на аналогичной конфигурации без патча проблема стабильно >> воспроизводится, >> с патчем - нет. >> >> -- >> Валентин Бартенев >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > > -- >
> (o_ - Dzmitry Stremkouski.
> //\ - cel: +7 (916) 090-85-68
> V_/_- web: http://mitroko.com
> 
> --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Nov 9 17:01:44 2013 From: nginx-forum at nginx.us (sofiamay) Date: Sat, 09 Nov 2013 12:01:44 -0500 Subject: =?UTF-8?B?bGltaXQgcmF0ZSwgbGltaXQgcmVxINC4IGxpbWl0IGNvbm4g0LLQvdGD0YLRgNC4?= =?UTF-8?B?INGD0YHQu9C+0LLQuNGPIElG?= Message-ID: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Вот такой вот конфиг прекрасно работает внутри Location или внутри Server: location / { limit_req zone=reqip burst=128; limit_conn url_ip 4; set $limit_rate 312k; limit_rate 312k; } Но стоит вместо location / { написать if ($remote_addr = 'xx.xx.xx.xx') { то сервер ругается, ничего не работает. Мне нужно чтобы для всех клиентов действовали ограничения, а для сервера нет (когда запросы на сервер идут с самого сервера через скрипты). Подскажите пожалуйста, неужели все эти настройки Nginx не позволяет размещать внутри условия? Может я чего не так делаю. Если всё настолько плохо и не позволяет, то подскажите пожалуйста может кто-то знает каким путем можно решить возникшую проблему... Спасибо Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244549,244549#msg-244549 From nginx-forum at nginx.us Sun Nov 10 20:17:12 2013 From: nginx-forum at nginx.us (tchibo) Date: Sun, 10 Nov 2013 15:17:12 -0500 Subject: =?UTF-8?B?0J3QsNGB0YLRgNC+0LnQutCwIG1vZCByZXdyaXRl?= Message-ID: <776b8ad009b7d37862775c3bec28529e.NginxMailingListRussian@forum.nginx.org> Добрый день, господа. Помогите с адаптацией конфигурационного файла Apache .htaccess в инструкции конфигурационного файла nginx'а. RewriteCond %{REQUEST_URI} ^(.*)//(.*)$ RewriteRule . %1/%2 [R=301,L] RewriteRule ^(.*),(.*)$ $2.php?rewrite_params=$1&page_url=$2 RewriteCond %{QUERY_STRING} base64_encode.*(.*) [OR] RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) RewriteRule ^(.*)$ index.php [F,L] Пробовал генераторами - не помогает Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244551,244551#msg-244551 From vbart at nginx.com Mon Nov 11 10:21:57 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 11 Nov 2013 14:21:57 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEgdHJ5IGZpbGVzIC0gbmdpbnguINCl0LU=?= =?UTF-8?B?0LvQvy4=?= In-Reply-To: References: Message-ID: <201311111421.57377.vbart@nginx.com> On Saturday 09 November 2013 19:03:58 Spoler wrote: > Здравствуйте уважаемые форумчане! > Уже мозг кипит не могу понять где у меня косяк (только разбираюсь с nginx). > Не работает try_files > > есть: Сервер A - fs.site.ru - так же используется как файловый кеш (flv) > и два сервера B и С - хранилища файлов(flv) они же в upstream > > Задача: когда заходим по сылке > http://fs.site.ru/data/z/111.111.111.111/5960a0dbce3b7b355b4672d850936e3c/2 > .flv > > файл отдает сервер А, если он есть на нем, иначе вытянуть файл с @video. > > Но когда файл удаляю с кеша на сервере А, то try_files не перебрасывает на > @video и выдает 404 ошибку > > где тут собака зарыта не могу понять, хелп... [...] > location /data/ { > rewrite /data/(.+)/(.*)/(.+)/(.*)\.flv$ /realvideo/$4.flv; > } > > location /realvideo/ { Ваш запрос обрабатывается в данном location, где нет никакого try_files. > rewrite ^/realvideo/(.*)$ /$1 break; > internal; > flv; > root /mnt/cache; > } [..] Советую изучить: http://nginx.org/ru/docs/http/request_processing.html -- Валентин Бартенев From vbart at nginx.com Mon Nov 11 10:26:05 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Mon, 11 Nov 2013 14:26:05 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUsIGxpbWl0IHJlcSAg0LggbGltaXQgY29ubiDQstC90YM=?= =?UTF-8?B?0YLRgNC4INGD0YHQu9C+0LLQuNGPIElG?= In-Reply-To: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> References: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> Message-ID: <201311111426.05244.vbart@nginx.com> On Saturday 09 November 2013 21:01:44 sofiamay wrote: > Здравствуйте. Вот такой вот конфиг прекрасно работает внутри Location или > внутри Server: > > location / { > limit_req zone=reqip burst=128; > limit_conn url_ip 4; > set $limit_rate 312k; > limit_rate 312k; > } > > Но стоит вместо location / { написать if ($remote_addr = 'xx.xx.xx.xx') { > то сервер ругается, ничего не работает. > Мне нужно чтобы для всех клиентов действовали ограничения, а для сервера > нет (когда запросы на сервер идут с самого сервера через скрипты). > > Подскажите пожалуйста, неужели все эти настройки Nginx не позволяет > размещать внутри условия? Может я чего не так делаю. Если всё настолько > плохо и не позволяет, то подскажите пожалуйста может кто-то знает каким > путем можно решить возникшую проблему... Спасибо > [..] Используйте map и geo модули. Пример: http://stackoverflow.com/a/19685016/1341058 -- Валентин Бартенев From mdounin at mdounin.ru Mon Nov 11 13:15:40 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 11 Nov 2013 17:15:40 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <201311062034.05630.vbart@nginx.com> <201311070149.34393.vbart@nginx.com> Message-ID: <20131111131540.GA95765@mdounin.ru> Hello! On Sat, Nov 09, 2013 at 08:00:11PM +0400, Dzmitry Stremkouski wrote: > Прошу прощения, что беспокою ещё раз в этом треде. > У меня бэкенд возвращает авторизационные печеньки для клиента. > Когда я прописываю в локейшн проекта > > auth_request /auth; > auth_request_set $auth_cookie $upstream_http_set_cookie; > add_header Set-Cookie $auth_cookie; > > мне присылает только одну из двух печенек от бэкенда. Я это вижу по времени > expire. > Если бекенд делает установку печенек в следующем порядке: > Set-Cookie TokenKey ... > Set-Cookie TokenLogin ... > То в браузер клиента из локейшна прилетает на обновление только первая > печенька (TokenKey), вторая (TokenLogin) остаётся неизменной. > Мне важно обновлять обе печеньки клиента, чтобы поддерживать аутентификацию. > > Как прописать в локейшне проекта auth_request_set, чтобы обновлялась вся > группа печенек, возвращаемых бэкендом. > Спасибо! Простейшее решение - вернуть разные куки в разных заголовках. -- Maxim Dounin http://nginx.org/en/donation.html From mitroko at gmail.com Mon Nov 11 13:17:22 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Mon, 11 Nov 2013 17:17:22 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131111131540.GA95765@mdounin.ru> References: <201311062034.05630.vbart@nginx.com> <201311070149.34393.vbart@nginx.com> <20131111131540.GA95765@mdounin.ru> Message-ID: Я так и сделал, но это в моём случае, где я писал бэкенд. В общем случае, когда код бэкенда может стать закрытым, так не получится. 2013/11/11 Maxim Dounin > Hello! > > On Sat, Nov 09, 2013 at 08:00:11PM +0400, Dzmitry Stremkouski wrote: > > > Прошу прощения, что беспокою ещё раз в этом треде. > > У меня бэкенд возвращает авторизационные печеньки для клиента. > > Когда я прописываю в локейшн проекта > > > > auth_request /auth; > > auth_request_set $auth_cookie $upstream_http_set_cookie; > > add_header Set-Cookie $auth_cookie; > > > > мне присылает только одну из двух печенек от бэкенда. Я это вижу по > времени > > expire. > > Если бекенд делает установку печенек в следующем порядке: > > Set-Cookie TokenKey ... > > Set-Cookie TokenLogin ... > > То в браузер клиента из локейшна прилетает на обновление только первая > > печенька (TokenKey), вторая (TokenLogin) остаётся неизменной. > > Мне важно обновлять обе печеньки клиента, чтобы поддерживать > аутентификацию. > > > > Как прописать в локейшне проекта auth_request_set, чтобы обновлялась вся > > группа печенек, возвращаемых бэкендом. > > Спасибо! > > Простейшее решение - вернуть разные куки в разных заголовках. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Nov 11 13:34:15 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 11 Nov 2013 17:34:15 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: References: <201311062034.05630.vbart@nginx.com> <201311070149.34393.vbart@nginx.com> <20131111131540.GA95765@mdounin.ru> Message-ID: <20131111133415.GB95765@mdounin.ru> Hello! On Mon, Nov 11, 2013 at 05:17:22PM +0400, Dzmitry Stremkouski wrote: > Я так и сделал, но это в моём случае, где я писал бэкенд. В общем случае, > когда код бэкенда может стать закрытым, так не получится. В общем случае - предполагается, что авторизационный скрипт возвращает заголовок WWW-Authenticate, а всё что сверх того - вы пишите сами. Если хочется авторизации на куках - то я бы рекомендовал в случае неудачной проверки просто делать перенаправление на форму логина, где уже и обрабатывать все подробности с выдачей кук. Если же говорить о совсем общем случае, то заголовок Set-Cookie противоречит стандарту HTTP, т.к. не допускает схлопывание нескольких заголовков в один через запятую. Попытка же ввести Set-Cookie2 - бесславно провалилась. Так что там всё гораздо более запущено, чем кажется. -- Maxim Dounin http://nginx.org/en/donation.html From mitroko at gmail.com Mon Nov 11 14:03:34 2013 From: mitroko at gmail.com (Dzmitry Stremkouski) Date: Mon, 11 Nov 2013 18:03:34 +0400 Subject: =?UTF-8?B?UmU6INCj0YLQvtGH0L3QtdC90LjQtSDQu9C+0LPQuNC60Lgg0YDQsNCx0L7RgtGL?= =?UTF-8?B?IG5neF9odHRwX2F1dGhfcmVxdWVzdF9tb2R1bGU=?= In-Reply-To: <20131111133415.GB95765@mdounin.ru> References: <201311062034.05630.vbart@nginx.com> <201311070149.34393.vbart@nginx.com> <20131111131540.GA95765@mdounin.ru> <20131111133415.GB95765@mdounin.ru> Message-ID: Оу! Пойду почитаю RFC, спасибо за наводку! Отличный модуль! 2013/11/11 Maxim Dounin > Hello! > > On Mon, Nov 11, 2013 at 05:17:22PM +0400, Dzmitry Stremkouski wrote: > > > Я так и сделал, но это в моём случае, где я писал бэкенд. В общем случае, > > когда код бэкенда может стать закрытым, так не получится. > > В общем случае - предполагается, что авторизационный скрипт > возвращает заголовок WWW-Authenticate, а всё что сверх того - вы > пишите сами. Если хочется авторизации на куках - то я бы > рекомендовал в случае неудачной проверки просто делать > перенаправление на форму логина, где уже и обрабатывать все > подробности с выдачей кук. > > Если же говорить о совсем общем случае, то заголовок Set-Cookie > противоречит стандарту HTTP, т.к. не допускает схлопывание > нескольких заголовков в один через запятую. Попытка же ввести > Set-Cookie2 - бесславно провалилась. Так что там всё гораздо > более запущено, чем кажется. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > --
(o_ - Dzmitry Stremkouski.
//\ - cel: +7 (916) 090-85-68
V_/_- web: http://mitroko.com
-------------- next part -------------- An HTML attachment was scrubbed... URL: From zmey1992 at ya.ru Tue Nov 12 06:22:29 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Tue, 12 Nov 2013 10:22:29 +0400 Subject: =?UTF-8?B?UmU6IE5naW54IDEuMi43ICsgQXBhY2hlMiAyLjIuMjQgb24gRnJlZWJzZCA5LjEg?= =?UTF-8?B?0YXQvtGB0YLQuNC90LMgc3BlZWR0ZXN0IG1pbmkg0L/RgNC+0LHQu9C10Lw=?= =?UTF-8?B?0LAg0YEgdXBsb2Fk?= In-Reply-To: References: Message-ID: <114311384237349@web29h.yandex.ru> ISP ставит пакетики из реп, сам не собирает. Посмотрите ключики через nginx -V да примените их к свежей версии. Делов-то. 06.11.2013, 17:48, "ans34" : > gstat показывает запись на hdd, lsof никакой разницы между открытыми на > запись файлами в момент проведения теста и в момент бездействия не находит. > Пересобирать nginx не вариант, т.к все ставилось вместе с ISP Manager, > неизвестно какие опции применялись при установке пакетов. Да и сервер скорее > боевой чем тестовый, сильно ломать его неохота. > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244480,244498#msg-244498 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Tue Nov 12 20:11:21 2013 From: nginx-forum at nginx.us (init0) Date: Tue, 12 Nov 2013 15:11:21 -0500 Subject: =?UTF-8?B?0J7RgtC00LXQu9GM0L3Ri9C5IFBIUC1GUE0g0YHQtdGA0LLQtdGA?= Message-ID: <2856dd9b24ce66b613f2e7ed777d26ca.NginxMailingListRussian@forum.nginx.org> Всем привет! Целый день пытаюсь заставить работать NGINX с удаленным PHP-FPM сервером Не получается, никак, хоть башкой об стенку бейся Есть два сервера, сервер "А" и сервер "Б" На сервере "А" ведется разработка на PHP, и там же расположен NGINX На сервере "Б" находится база данных и бекенд PHP-FPM Конфигурация NGINX сервера "А": http { upstream php { server 10.0.0.10:9000; } server { listen 80; server_name example.com; root /var/www/test/web; index index.php; server_tokens off; location / { try_files $uri /index.php?$args; } location ~ \.php$ { fastcgi_pass php; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } error_log /var/log/nginx/example.com.error_log info; access_log /var/log/nginx/example.com.access_log; } IP адрес сервера "А" 10.0.0.5 Конфигурация PHP-FPM сервера "Б": [www] user = www-data group = www-data listen = 9000 listen.allowed_clients = 10.0.0.5 pm = dynamic pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm.max_requests = 200 access.log = /tmp/access.log IP адрес сервера "Б" 10.0.0.10 Когда захожу по адресу http://example.com получаю "File not found. " В логах сервера "А" следующее: 2013/11/13 02:07:20 [error] 8032#0: *120 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.1.100, server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://10.0.0.10:9000", host: "perhyar.liteproject.ru" 10.0.1.100 - - [13/Nov/2013:02:07:20 +0600] "GET / HTTP/1.1" 404 47 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0" В логах сервера "Б": 10.0.0.5 - 12/Nov/2013:15:07:20 -0500 "GET /index.php" 404 - 0.827 256 0.00% Господа, что я делаю не так?? Заранее спасибо! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244594#msg-244594 From mdounin at mdounin.ru Tue Nov 12 21:05:54 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 13 Nov 2013 01:05:54 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <2856dd9b24ce66b613f2e7ed777d26ca.NginxMailingListRussian@forum.nginx.org> References: <2856dd9b24ce66b613f2e7ed777d26ca.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131112210554.GR95765@mdounin.ru> Hello! On Tue, Nov 12, 2013 at 03:11:21PM -0500, init0 wrote: [...] > server { > listen 80; > server_name example.com; > root /var/www/test/web; [...] > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; [...] > Когда захожу по адресу http://example.com получаю > "File not found. " > > В логах сервера "А" следующее: > 2013/11/13 02:07:20 [error] 8032#0: *120 FastCGI sent in stderr: "Primary > script unknown" while reading response header from upstream, client: > 10.0.1.100, server: example.com, request: "GET / HTTP/1.1", upstream: > "fastcgi://10.0.0.10:9000", host: "perhyar.liteproject.ru" > > 10.0.1.100 - - [13/Nov/2013:02:07:20 +0600] "GET / HTTP/1.1" 404 47 "-" > "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 > Firefox/24.0" > > > В логах сервера "Б": > 10.0.0.5 - 12/Nov/2013:15:07:20 -0500 "GET /index.php" 404 - 0.827 256 > 0.00% > > > Господа, что я делаю не так?? Где при этом лежит php-скрипт на сервере Б? Судя по ответу, в /var/www/test/web/index.php его нет. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Nov 13 03:00:51 2013 From: nginx-forum at nginx.us (init0) Date: Tue, 12 Nov 2013 22:00:51 -0500 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <20131112210554.GR95765@mdounin.ru> References: <20131112210554.GR95765@mdounin.ru> Message-ID: Все PHP скрипты только на сервере "А" То есть то что я написал в принципе невозможно? upstream cluster_name { ip_hash; server 10.10.10.10:9000; server 172.16.172.16:9000; server 192.168.192.168:9000; server localhost:9000 backup; } И в данной конфигурации на всех 4 серверах в списке есть зеркала PHP скриптов?? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244601#msg-244601 From nginx-forum at nginx.us Wed Nov 13 04:29:43 2013 From: nginx-forum at nginx.us (daevy) Date: Tue, 12 Nov 2013 23:29:43 -0500 Subject: =?UTF-8?B?0L/QtdGA0LXQutC+0YEg0LIg0YDQsNGB0L/RgNC10LTQtdC70LXQvdC40Lgg0L8=?= =?UTF-8?B?0YDQuCBsZWFzdCBjb25u?= Message-ID: <7a674f45c98566c2dcfffffa0c9ea809.NginxMailingListRussian@forum.nginx.org> Всем привет! Включил least_conn в одном из апстримов и вроде бы все хорошо, распределяется более-менее равномерно. Но вот уже второй день подряд (с момента включения) замечаю что nginx в течение некоторого продолжительного времени перестает отправлять запросы на один из бэкендов в апстриме. При reload ситуация восстанавливается. Есть похожая тема, но она заканчивается ничем - http://forum.nginx.org/read.php?2,237621,237621#msg-237621 Из нее лишь понятно что у воркеров есть свои счетчики соединений. Но не понятно, то ли это инкрементальные счетчики которые все время растут, или счетчики текущего количества соединений с бэкендом? Если первый вариант, то понятно почему происходит перекос и если так тогда как с этим бороться? nginx version: nginx/1.2.2 worker_processes 10; upstream nginx_unicorn_01 { least_conn; server script1:8080 weight=23; server script2:8080 weight=31; server script3:8080 weight=23; server script4:8080 weight=23; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244603,244603#msg-244603 From mva at mva.name Wed Nov 13 07:06:54 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 13 Nov 2013 14:06:54 +0700 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: <20131112210554.GR95765@mdounin.ru> Message-ID: <14435733.o8nyIOXDLa@note> В письме от Вт, 12 ноября 2013 22:00:51 пользователь init0 написал: > Все PHP скрипты только на сервере "А" > > То есть то что я написал в принципе невозможно? А как php-fpm будет их исполнять, если у него нету доступа до них? > > upstream cluster_name { > ip_hash; > server 10.10.10.10:9000; > server 172.16.172.16:9000; > server 192.168.192.168:9000; > server localhost:9000 backup; > } > > И в данной конфигурации на всех 4 серверах в списке есть зеркала PHP > скриптов?? Ну, теоретически, можно использовать сетевые файловые системы, но именно в Вашем случае это принесёт больше вреда, чем пользы. -- Best regsrds, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From chipitsine at gmail.com Wed Nov 13 07:17:50 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Wed, 13 Nov 2013 13:17:50 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <14435733.o8nyIOXDLa@note> References: <20131112210554.GR95765@mdounin.ru> <14435733.o8nyIOXDLa@note> Message-ID: 13 ноября 2013 г., 13:06 пользователь Vadim A. Misbakh-Soloviov написал: > В письме от Вт, 12 ноября 2013 22:00:51 пользователь init0 написал: >> Все PHP скрипты только на сервере "А" >> >> То есть то что я написал в принципе невозможно? > > А как php-fpm будет их исполнять, если у него нету доступа до них? теоретически можно допустить, что скрипт будет передан на php-fpm непонятно, что делать, если в этот скрипт будут через require() подгружаться другие. про них то php-fpm ничего не узнает > >> >> upstream cluster_name { >> ip_hash; >> server 10.10.10.10:9000; >> server 172.16.172.16:9000; >> server 192.168.192.168:9000; >> server localhost:9000 backup; >> } >> >> И в данной конфигурации на всех 4 серверах в списке есть зеркала PHP >> скриптов?? > > Ну, теоретически, можно использовать сетевые файловые системы, но именно в > Вашем случае это принесёт больше вреда, чем пользы. > > -- > Best regsrds, > mva > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From citrin at citrin.ru Wed Nov 13 09:27:31 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Wed, 13 Nov 2013 13:27:31 +0400 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LrQvtGBINCyINGA0LDRgdC/0YDQtdC00LXQu9C10L3QuNC4?= =?UTF-8?B?INC/0YDQuCBsZWFzdCBjb25u?= In-Reply-To: <7a674f45c98566c2dcfffffa0c9ea809.NginxMailingListRussian@forum.nginx.org> References: <7a674f45c98566c2dcfffffa0c9ea809.NginxMailingListRussian@forum.nginx.org> Message-ID: <52834603.40200@citrin.ru> On 11/13/13 08:29, daevy wrote: > Включил least_conn в одном из апстримов и вроде бы все хорошо, > распределяется более-менее равномерно. Но вот уже второй день подряд (с > момента включения) замечаю что nginx в течение некоторого продолжительного > времени перестает отправлять запросы на один из бэкендов в апстриме. Для начала стоит включить error_log на уровне info и посмотреть нет ли там ничего про этот бэкенд. From vbart at nginx.com Wed Nov 13 10:30:34 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 13 Nov 2013 14:30:34 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: <20131112210554.GR95765@mdounin.ru> Message-ID: <201311131430.34139.vbart@nginx.com> On Wednesday 13 November 2013 07:00:51 init0 wrote: [..] > upstream cluster_name { > ip_hash; > server 10.10.10.10:9000; > server 172.16.172.16:9000; > server 192.168.192.168:9000; > server localhost:9000 backup; > } > > И в данной конфигурации на всех 4 серверах в списке есть зеркала PHP > скриптов?? > Так укажите правильный путь до скриптов на них. У вас указано: fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; где $document_root задана в /var/www/test/web, но видимо скрипты ваши в другом месте лежат на тех серверах. -- Валентин Бартенев From vbart at nginx.com Wed Nov 13 10:34:22 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Wed, 13 Nov 2013 14:34:22 +0400 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LrQvtGBINCyINGA0LDRgdC/0YDQtdC00LXQu9C10L3QuNC4?= =?UTF-8?B?INC/0YDQuCBsZWFzdCBjb25u?= In-Reply-To: <7a674f45c98566c2dcfffffa0c9ea809.NginxMailingListRussian@forum.nginx.org> References: <7a674f45c98566c2dcfffffa0c9ea809.NginxMailingListRussian@forum.nginx.org> Message-ID: <201311131434.22793.vbart@nginx.com> On Wednesday 13 November 2013 08:29:43 daevy wrote: > Всем привет! > > Включил least_conn в одном из апстримов и вроде бы все хорошо, > распределяется более-менее равномерно. Но вот уже второй день подряд (с > момента включения) замечаю что nginx в течение некоторого продолжительного > времени перестает отправлять запросы на один из бэкендов в апстриме. При > reload ситуация восстанавливается. Вероятно потому, что nginx считает ваш бэкенд умершим. За причиной следует смотреть в error_log. > > Есть похожая тема, но она заканчивается ничем - > http://forum.nginx.org/read.php?2,237621,237621#msg-237621 > Из нее лишь понятно что у воркеров есть свои счетчики соединений. Но не > понятно, то ли это инкрементальные счетчики которые все время растут, или > счетчики текущего количества соединений с бэкендом? Разумеется текущего. Об этом и в документации сказано. -- Валентин Бартенев From mva at mva.name Wed Nov 13 10:49:57 2013 From: mva at mva.name (Vadim A. Misbakh-Soloviov) Date: Wed, 13 Nov 2013 17:49:57 +0700 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <201311131430.34139.vbart@nginx.com> References: <20131112210554.GR95765@mdounin.ru> <201311131430.34139.vbart@nginx.com> Message-ID: <5068002.AiZimHopMZ@note> > > где $document_root задана в /var/www/test/web, но видимо скрипты ваши > в другом месте лежат на тех серверах. > их, на сколько мы тут поняли, вообще нету на сервере с PHP-FPM -- Best regsrds, mva -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From vbart at nginx.com Wed Nov 13 10:54:32 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 13 Nov 2013 14:54:32 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <5068002.AiZimHopMZ@note> References: <20131112210554.GR95765@mdounin.ru> <201311131430.34139.vbart@nginx.com> <5068002.AiZimHopMZ@note> Message-ID: <201311131454.32590.vbart@nginx.com> On Wednesday 13 November 2013 14:49:57 Vadim A. Misbakh-Soloviov wrote: > > где $document_root задана в /var/www/test/web, но видимо скрипты ваши > > в другом месте лежат на тех серверах. > > их, на сколько мы тут поняли, вообще нету на сервере с PHP-FPM Что тогда автор имел в виду под фразой: >> И в данной конфигурации на всех 4 серверах в списке есть зеркала PHP скриптов ? -- Валентин Бартенев From mdounin at mdounin.ru Wed Nov 13 11:01:23 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 13 Nov 2013 15:01:23 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <201311131454.32590.vbart@nginx.com> References: <20131112210554.GR95765@mdounin.ru> <201311131430.34139.vbart@nginx.com> <5068002.AiZimHopMZ@note> <201311131454.32590.vbart@nginx.com> Message-ID: <20131113110123.GV95765@mdounin.ru> Hello! On Wed, Nov 13, 2013 at 02:54:32PM +0400, Валентин Бартенев wrote: > On Wednesday 13 November 2013 14:49:57 Vadim A. Misbakh-Soloviov wrote: > > > где $document_root задана в /var/www/test/web, но видимо скрипты ваши > > > в другом месте лежат на тех серверах. > > > > их, на сколько мы тут поняли, вообще нету на сервере с PHP-FPM > > Что тогда автор имел в виду под фразой: > > >> И в данной конфигурации на всех 4 серверах в списке есть зеркала PHP скриптов > > ? Подозреваю, что вопрос. Там было аж два вопросительных знака, которые как бы намекают. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Nov 13 12:49:47 2013 From: nginx-forum at nginx.us (daevy) Date: Wed, 13 Nov 2013 07:49:47 -0500 Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LrQvtGBINCyINGA0LDRgdC/0YDQtdC00LXQu9C10L3QuNC4?= =?UTF-8?B?INC/0YDQuCBsZWFzdCBjb25u?= In-Reply-To: <201311131434.22793.vbart@nginx.com> References: <201311131434.22793.vbart@nginx.com> Message-ID: <7ca61f8a475a8b5811dafc167847df39.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > > Вероятно потому, что nginx считает ваш бэкенд умершим. > За причиной следует смотреть в error_log. Я думаю я немного недоговорил, nginx не игнорирует бэкенд полностью, он отправляет запросы, но очень небольшое количество. например из 100 запросов на первые 3 уходит равномерно между ними по 30 запросов, а на оставшийся с всего 10, т.е. недодает ему. Это очень хорошо видно если смотреть текущие коннекты к бэкендам со стороны nginx. netstat -tn |grep :8080 |awk '{print $5}' |cut -d\: -f1 |sort |uniq -c Так что он не считает его совсем уж мертвым. И еще, не стану скрывать, есть у нас одна ночная ситуация-операция при которой все бэкендЫ в разные моменты времени перестают отвечать. Но когда использовался round-robin, после того как ситуация прошла и бэкенды пришли в себя, запросы продолжают ходить и из апстрима никого не выкидывало. про логи... В конфигурации настроено error_log info. За период когда это произошло, есть только десяток сообщений такого типа: [info] 10359#0: *734774549 recv() failed (104: Connection reset by peer), client: 78.30.221.96, server: my_domain.ru, request: "GET / HTTP/1.0", host: "DOMAIN.RU" Надеюсь, я не внес неразберихи в свой вопрос? > > > Из нее лишь понятно что у воркеров есть свои счетчики соединений. Но не > > понятно, то ли это инкрементальные счетчики которые все время растут, или > > счетчики текущего количества соединений с бэкендом? > > Разумеется текущего. Об этом и в документации сказано. > значит меня ввела в заблуждение фраза "Currently, different workers have distinct counters of active connections." Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244603,244622#msg-244622 From nginx-forum at nginx.us Wed Nov 13 17:53:20 2013 From: nginx-forum at nginx.us (init0) Date: Wed, 13 Nov 2013 12:53:20 -0500 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <20131113110123.GV95765@mdounin.ru> References: <20131113110123.GV95765@mdounin.ru> Message-ID: Парни, всем спасибо! Хотел странного, чтобы php5-fpm реботал без php скриптов, а брал их по сети Сегодня вспомнил о "require-once", почитал доку NGINX и понял, что без локальных PHP скриптов ничего работать не будет Спасибо заответы! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244633#msg-244633 From me at kemko.ru Thu Nov 14 03:04:25 2013 From: me at kemko.ru (=?koi8-r?B?5M3J1NLJyiDhzsTSxcXX?=) Date: Thu, 14 Nov 2013 07:04:25 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: Message-ID: <220331384398265@web12m.yandex.ru> 13.11.2013, 21:53, "init0" : > Хотел странного, чтобы php5-fpm реботал без php скриптов, а брал их по сети Развернуть для этого nfs - не такая вроде и проблема. В итоге будет по сети, но прозрачно для php5-fpm. From nginx-forum at nginx.us Thu Nov 14 03:19:33 2013 From: nginx-forum at nginx.us (init0) Date: Wed, 13 Nov 2013 22:19:33 -0500 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <220331384398265@web12m.yandex.ru> References: <220331384398265@web12m.yandex.ru> Message-ID: <6e6704f188db3f338f11518b9f181cdb.NginxMailingListRussian@forum.nginx.org> На скорость работы не сильно повлияет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244650#msg-244650 From chipitsine at gmail.com Thu Nov 14 06:00:55 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 14 Nov 2013 12:00:55 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: <20131113110123.GV95765@mdounin.ru> Message-ID: для нагруженных проектов хорошо помогает склеить все скрипты в один (убрав require/include) и поставить, например, APC 13 ноября 2013 г., 23:53 пользователь init0 написал: > Парни, всем спасибо! > > Хотел странного, чтобы php5-fpm реботал без php скриптов, а брал их по сети > Сегодня вспомнил о "require-once", почитал доку NGINX и понял, что без > локальных PHP скриптов ничего работать не будет > > Спасибо заответы! > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244633#msg-244633 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From n.g.i.n.x.e.r at gmail.com Thu Nov 14 10:30:13 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Thu, 14 Nov 2013 14:30:13 +0400 Subject: FTP Proxy Message-ID: Здравствуйте. Есть куча вируталок во внутренней сети, н с одним нешним ip Можно ли проксировать в них ftp соединения через nginx? Или есть какое то аналогичное решение? -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu Nov 14 11:03:44 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Thu, 14 Nov 2013 15:03:44 +0400 Subject: FTP Proxy In-Reply-To: References: Message-ID: > Можно ли проксировать в них ftp соединения через nginx? можно проксировать HTTP соединения. From n.g.i.n.x.e.r at gmail.com Thu Nov 14 11:13:12 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Thu, 14 Nov 2013 15:13:12 +0400 Subject: FTP Proxy In-Reply-To: References: Message-ID: это я уже делаю 14 ноября 2013 г., 15:03 пользователь Daniel Podolsky написал: > > Можно ли проксировать в них ftp соединения через nginx? > можно проксировать HTTP соединения. > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Nov 14 11:17:30 2013 From: nginx-forum at nginx.us (hyper) Date: Thu, 14 Nov 2013 06:17:30 -0500 Subject: Image_filter resize & proxy_cache Message-ID: К сожалению не нашел описание похожей проблемы, может плохо искал. Все работает отлично, показываются превьюхи. После обновления картинок: http://mydomain.com/images/pic1.jpg - показывает новую http://mydomain.com/w220/images/pic1.jpg - берет из кеша. Как заставить нжинкс не брать превьюху из кеша если основной файл был изменен? Вот конфиг: http { proxy_cache_path /var/www/mydomain.com/cache/ levels=1:2 keys_zone=image-preview:20m max_size=256m inactive=1d; ...... server { listen 1.1.1.1:80; server_name mydomain.com; location ~^(/images/) { } location ~ ^/w(\d*)/(.*)$ { proxy_pass http://mydomain.com; rewrite ^/w(\d*)/(.*)$ /$2 break; image_filter resize $1 -; image_filter_jpeg_quality 95; image_filter_buffer 4M; proxy_cache image-preview; proxy_cache_key "$host$document_uri"; proxy_cache_valid 200 1d; proxy_cache_valid any 1m; } location / { root /var/www/mydomain.com; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /var/www/mydomain.com/index.php; include fastcgi_params; client_max_body_size 256M; fastcgi_buffer_size 32k; fastcgi_buffers 8 16k; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; } } } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244658,244658#msg-244658 From chipitsine at gmail.com Thu Nov 14 11:37:15 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Thu, 14 Nov 2013 17:37:15 +0600 Subject: FTP Proxy In-Reply-To: References: Message-ID: мы используем вот такую штуку http://www.openbsd.org/faq/pf/ru/ftp.html 14 ноября 2013 г., 16:30 пользователь Роман написал: > Здравствуйте. > > Есть куча вируталок во внутренней сети, н с одним нешним ip > > Можно ли проксировать в них ftp соединения через nginx? > > Или есть какое то аналогичное решение? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From motienko at gmail.com Thu Nov 14 13:59:05 2013 From: motienko at gmail.com (Oleg Motienko) Date: Thu, 14 Nov 2013 17:59:05 +0400 Subject: =?UTF-8?B?0JLQvtC/0YDQvtGBINC/0L4gc2V0X3JlYWxfaXBfZnJvbQ==?= Message-ID: Привет. set_real_ip_from отлично работает, но вот потребовалось получить адрес, который был до set_real_ip_from (фактически, адрес из tcp сессии) и послать его на бэкэнд в заголовке http. Как такое можно сделать? -- Regards, Oleg From swood at fotofor.biz Thu Nov 14 15:58:05 2013 From: swood at fotofor.biz (Anton Kiryushkin) Date: Thu, 14 Nov 2013 19:58:05 +0400 Subject: FTP Proxy In-Reply-To: References: Message-ID: haproxy ? 14 ноября 2013 г., 15:37 пользователь Илья Шипицин написал: > мы используем вот такую штуку http://www.openbsd.org/faq/pf/ru/ftp.html > > > > 14 ноября 2013 г., 16:30 пользователь Роман > написал: > > Здравствуйте. > > > > Есть куча вируталок во внутренней сети, н с одним нешним ip > > > > Можно ли проксировать в них ftp соединения через nginx? > > > > Или есть какое то аналогичное решение? > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Best regards, Anton Kiryushkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bombsiteunrested at gmail.com Thu Nov 14 17:15:46 2013 From: bombsiteunrested at gmail.com (=?KOI8-R?B?SWdvciAnTG8nICjpLkwuKQ==?=) Date: Thu, 14 Nov 2013 21:15:46 +0400 Subject: =?UTF-8?B?0JzQvtC00YPQu9C4OiDQutC+0LPQtNCwINGDIG5neF9odHRwX3ZhcmlhYmxlX3Qg?= =?UTF-8?B?0YHRgNCw0LHQsNGC0YvQstCw0LXRgiBnZXRfaGFuZGxlciDQuCBzZXRfaGFu?= =?UTF-8?B?ZGxlcj8=?= Message-ID: Есть filter module, в ходе работы которого задается одна переменная (ngx_http_variable_t). Причем у переменной определен только get_handler с сигнатурой that_variable_code(ngx_http_request_t *r, ngx_http_variable_value_t *v, uintptr_t data). Вопрос: что такое set_handler у переменных? Почему, хотя он не задан, в get'е получается выполнить процессинг данных ngx_http_request_t и присвоить значение? Второй вопрос: допустим, я хочу добавить еще одну переменную. Но при этом получение значений для обеих переменных выполняется один раз (тяжелая инициализация..). Куда можно запихнуть в ngx_http_request_t свое значение так, чтобы его смогли забрать оба get_handler'а? (учитывая то, что http_request_t вроде как может использоваться для нескольких запросов) Третий вопрос: каким образом можно задать значение строковой переменной, находясь в header filter и зная имя переменной (строку)? -- С уважением, Игор -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Thu Nov 14 18:49:22 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 14 Nov 2013 22:49:22 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNGD0LvQuDog0LrQvtCz0LTQsCDRgyBuZ3hfaHR0cF92YXJpYWJs?= =?UTF-8?B?ZV90INGB0YDQsNCx0LDRgtGL0LLQsNC10YIgZ2V0X2hhbmRsZXIg0Lggc2V0?= =?UTF-8?B?X2hhbmRsZXI/?= In-Reply-To: References: Message-ID: <20131114184922.GE95765@mdounin.ru> Hello! On Thu, Nov 14, 2013 at 09:15:46PM +0400, Igor 'Lo' (И.L.) wrote: > Есть filter module, в ходе работы которого задается одна переменная > (ngx_http_variable_t). > > Причем у переменной определен только get_handler с сигнатурой > that_variable_code(ngx_http_request_t *r, ngx_http_variable_value_t *v, > uintptr_t data). > > Вопрос: что такое set_handler у переменных? Почему, хотя он не задан, в > get'е получается выполнить процессинг данных ngx_http_request_t и присвоить > значение? Обработчик set_handler - это такая функция, которая будет вызвана кодом set $your_variables "some value"; E.g., при выполнении кода rewrite-модуля "set $args 'foo'" - в r->args записывается соответствующая строка. > Второй вопрос: допустим, я хочу добавить еще одну переменную. Но при этом > получение значений для обеих переменных выполняется один раз (тяжелая > инициализация..). Куда можно запихнуть в ngx_http_request_t свое значение > так, чтобы его смогли забрать оба get_handler'а? (учитывая то, что > http_request_t вроде как может использоваться для нескольких запросов) В контекст модуля. Смотреть ngx_http_set_ctx(), ngx_http_get_module_ctx(). > Третий вопрос: каким образом можно задать значение строковой переменной, > находясь в header filter и зная имя переменной (строку)? Лучше всего - не пытаться ставить чужие переменные, а предоставлять свои с нужными значениями. Но если очень хочется, то пример можно посмотреть в том же модуле rewrite (директива set) и/или в auth request. Общий смысл в том, что нужно знать индекс переменной (получить его на этапе конфигурации), и записать нужное значение в r->variables[index], а если у директивы есть set_handler - то позвать его. -- Maxim Dounin http://nginx.org/en/donation.html From n.g.i.n.x.e.r at gmail.com Thu Nov 14 21:14:53 2013 From: n.g.i.n.x.e.r at gmail.com (=?UTF-8?B?0KDQvtC80LDQvQ==?=) Date: Fri, 15 Nov 2013 01:14:53 +0400 Subject: FTP Proxy In-Reply-To: References: Message-ID: я тоже пробрасываю порт для своих целей, но хочется решения с индивидуальным подходом не вешать же кучу правил для каждой вируталки со своим внешним портом как то не красиво выглядит 14 ноября 2013 г., 15:37 пользователь Илья Шипицин написал: > мы используем вот такую штуку http://www.openbsd.org/faq/pf/ru/ftp.html > > > > 14 ноября 2013 г., 16:30 пользователь Роман > написал: > > Здравствуйте. > > > > Есть куча вируталок во внутренней сети, н с одним нешним ip > > > > Можно ли проксировать в них ftp соединения через nginx? > > > > Или есть какое то аналогичное решение? > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From onokonem at gmail.com Thu Nov 14 21:39:12 2013 From: onokonem at gmail.com (Daniel Podolsky) Date: Fri, 15 Nov 2013 01:39:12 +0400 Subject: FTP Proxy In-Reply-To: References: Message-ID: > не вешать же кучу правил для каждой вируталки со своим внешним портом портами (во множественном числе). ftp - очень неприятный протокол, проще перевести работу на http From nginx-forum at nginx.us Fri Nov 15 04:08:01 2013 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 14 Nov 2013 23:08:01 -0500 Subject: =?UTF-8?B?0JTQvtCx0LDQstC40YLRjCDQv9C10YDQtdC80LXQvdGD0Y4gJGNhY2hlIHN0YXR1?= =?UTF-8?B?cw==?= Message-ID: <40d53049039aa84ed5b4172e70eb5788.NginxMailingListRussian@forum.nginx.org> Для инвалидации кеша, мы планировали использовать такую схему: fastcgi_cache_valid 200 ? 1s; fastcgi_cache_use_stale error updating http_503; По истечения 1 секунды, запрос будет идти на бекенд, на котором РНР скрипт определяет изменились данные в БД которые использовались в данном URI с момента предыдущего запроса или нет (для проверки достаточно пару запросов к мемкешу), если данные не изменились, скрипт отдаст ответ с кодом 503, для того чтобы Nginx дальше использовал кеш запроса (cache_use_stale) и так каждую секунду. Даная схема позволяет, оперативно сбрасывать устаревший кеш и хранить кеш на длительный период если данные не изменялись. Но для корректной работы, РНР скрипту необходимо знать что у Nginx есть файл кеша, чтобы знать можно серверу ответить статусом 503 или нет, потому что если файла кеша нет, сервер 503 ошибку от РНР отправит браузеру а этого нам не надо. Проблема решается если в конфиге Nginx будет добавлена переменная типа - $cache_status которую я буду отправлять на бекенд через fastcgi_param CACHE_STATUS $cache_status; Тогда РНР скрипт сможет, точно определять возможность повторного использования кеша если данные не устарели. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244677#msg-244677 From kostenl at gmail.com Fri Nov 15 04:15:07 2013 From: kostenl at gmail.com (=?UTF-8?B?0JvQsNC/0L7Rh9C60LjQvSDQmtC+0L3RgdGC0LDQvdGC0LjQvQ==?=) Date: Fri, 15 Nov 2013 10:15:07 +0600 Subject: FTP Proxy In-Reply-To: References: Message-ID: <00b301cee1b9$453f51a0$cfbdf4e0$@gmail.com> Вам нужна балансировка нагрузки на внутрениие фтп? Если да, то haproxy или другие балансировщики. Если нет, то iptables с соответвующм модулем (nf_conntrack_ftp если память не подводит). Особенность протокола ftp в том, что он использует как минимум 2 порта: 21 для обмена служебной информацией и другие для данных. Nginx тут совсем не помощник. From: nginx-ru-bounces at nginx.org [mailto:nginx-ru-bounces at nginx.org] On Behalf Of Роман Sent: Friday, November 15, 2013 3:15 AM To: nginx-ru at nginx.org Subject: Re: FTP Proxy я тоже пробрасываю порт для своих целей, но хочется решения с индивидуальным подходом не вешать же кучу правил для каждой вируталки со своим внешним портом как то не красиво выглядит 14 ноября 2013 г., 15:37 пользователь Илья Шипицин написал: мы используем вот такую штуку http://www.openbsd.org/faq/pf/ru/ftp.html 14 ноября 2013 г., 16:30 пользователь Роман написал: > Здравствуйте. > > Есть куча вируталок во внутренней сети, н с одним нешним ip > > Можно ли проксировать в них ftp соединения через nginx? > > Или есть какое то аналогичное решение? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list nginx-ru at nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Fri Nov 15 06:02:46 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Fri, 15 Nov 2013 12:02:46 +0600 Subject: FTP Proxy In-Reply-To: References: Message-ID: именно так, для каждой виртуалки - куча правил. про haproxy вам зря посоветовали, в нем только зачатки балансировки ftp, не рабочее оно на текущий момент. 15 ноября 2013 г., 3:14 пользователь Роман написал: > я тоже пробрасываю порт для своих целей, но хочется решения с индивидуальным > подходом > не вешать же кучу правил для каждой вируталки со своим внешним портом > как то не красиво выглядит > > > 14 ноября 2013 г., 15:37 пользователь Илья Шипицин > написал: >> >> мы используем вот такую штуку http://www.openbsd.org/faq/pf/ru/ftp.html >> >> >> >> >> 14 ноября 2013 г., 16:30 пользователь Роман >> написал: >> > Здравствуйте. >> > >> > Есть куча вируталок во внутренней сети, н с одним нешним ip >> > >> > Можно ли проксировать в них ftp соединения через nginx? >> > >> > Или есть какое то аналогичное решение? >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Nov 15 07:11:12 2013 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 15 Nov 2013 02:11:12 -0500 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <40d53049039aa84ed5b4172e70eb5788.NginxMailingListRussian@forum.nginx.org> References: <40d53049039aa84ed5b4172e70eb5788.NginxMailingListRussian@forum.nginx.org> Message-ID: <1dc50df3329aef2dcbb744f4afce4c91.NginxMailingListRussian@forum.nginx.org> Нашел :) Переменная есть - $upstream_cache_status; Но будет, интересно услышать идеи как можно улучшить данную схему кеширования . Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244684#msg-244684 From universite at ukr.net Fri Nov 15 09:04:34 2013 From: universite at ukr.net (Vladislav Prodan) Date: Fri, 15 Nov 2013 11:04:34 +0200 Subject: =?UTF-8?B?0JrQsNC6INCyINGB0YLRgNCw0L3QuNGG0YMg0L7RiNC40LHQutC4IDQwNCDQuNC7?= =?UTF-8?B?0LggNTAzINC/0LXRgNC10LTQsNGC0YwgSVAg0LfQsNC/0YDQvtGI0LDRg9C1?= =?UTF-8?B?0LzQvtCz0L4/?= Message-ID: <1384506058.565372875.jchnw7sc@frv35.ukr.net> Сабж. Запросов очень много. error_page 503 /503.html; location = /503.html { root /path/to/the/page; } можно как-то встроенными средствами nginx отдать %%IP%% ? Заранее благодарю. -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From mdounin at mdounin.ru Fri Nov 15 10:30:03 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 Nov 2013 14:30:03 +0400 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQsiDRgdGC0YDQsNC90LjRhtGDINC+0YjQuNCx0LrQuCA0MDQg?= =?UTF-8?B?0LjQu9C4IDUwMyDQv9C10YDQtdC00LDRgtGMIElQINC30LDQv9GA0L7RiNCw?= =?UTF-8?B?0YPQtdC80L7Qs9C+Pw==?= In-Reply-To: <1384506058.565372875.jchnw7sc@frv35.ukr.net> References: <1384506058.565372875.jchnw7sc@frv35.ukr.net> Message-ID: <20131115103003.GG95765@mdounin.ru> Hello! On Fri, Nov 15, 2013 at 11:04:34AM +0200, Vladislav Prodan wrote: > > Сабж. > Запросов очень много. > > error_page 503 /503.html; > location = /503.html { > root /path/to/the/page; > } > > можно как-то встроенными средствами nginx отдать %%IP%% ? Куда отдать? Есть переменная $remote_addr, далее масса вариантов - начиная от SSI и вставки значения переменной на возвращаемую страницу с помощью команды echo: http://nginx.org/ru/docs/http/ngx_http_ssi_module.html -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Fri Nov 15 10:52:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 Nov 2013 14:52:33 +0400 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <1dc50df3329aef2dcbb744f4afce4c91.NginxMailingListRussian@forum.nginx.org> References: <40d53049039aa84ed5b4172e70eb5788.NginxMailingListRussian@forum.nginx.org> <1dc50df3329aef2dcbb744f4afce4c91.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131115105232.GI95765@mdounin.ru> Hello! On Fri, Nov 15, 2013 at 02:11:12AM -0500, S.A.N wrote: > Нашел :) > Переменная есть - $upstream_cache_status; > Но будет, интересно услышать идеи как можно улучшить данную схему > кеширования . В ближайшее время будет функциональность ревалидации кеша с помощью If-Modified-Since запросов. Оно улучшит данную схему. ;) -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Fri Nov 15 10:52:57 2013 From: nginx-forum at nginx.us (toxi-kb) Date: Fri, 15 Nov 2013 05:52:57 -0500 Subject: =?UTF-8?B?0JrRjdGI0LjRgNC+0LLQsNC90LjQtSDRgdGC0LDRgtC40LrQuC4=?= Message-ID: <6fbfd3e3e52f9dde4d6bf1b01398152b.NginxMailingListRussian@forum.nginx.org> Добрый день. У меня есть проблема со статикой. Я, к сожалению, не в силах решить её своими силами, поэтому буду благодарен за любую помощь. Суть проблемы: есть сайт, который работает на связке nginx + uwsgi + django. Когда мы заливаем изменения, нужно отключить доступ к сайту у обычных пользователей и оставить доступ у разработчиков. Решается это следующим образом: 1) В файле конфигурации: основное приложение перебрасывается на порт 8000, а на 80 отдается заглушка, говорящая о том, что у нас идут обновления. Nginx перезагружается. 2) Проходят какие-то технические работы. 3) Заглушка и основное приложение меняются портами в конфигурации. Nginx снова перезагружается. После этого, если зайти в приложение, мы не обнаруживаем часть картинок, причем у всех это разные картинки, а у кого-то вовсе нет проблем с этим. Т.е. запрос к картинке возвращает 404. Если сбросить кэш в браузере - все устаканится и статика вернется на место. Собственно вопрос: что с этим можно сделать, как исправить данную проблему и с чем она связана? Конфигурацию прилагаю в виде ссылки: http://prntscr.com/249v0c Заранее, большое спасибо за помощь! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244695,244695#msg-244695 From nginx-forum at nginx.us Fri Nov 15 11:29:30 2013 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 15 Nov 2013 06:29:30 -0500 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <20131115105232.GI95765@mdounin.ru> References: <20131115105232.GI95765@mdounin.ru> Message-ID: <451691782e59e437b436922fa61c034a.NginxMailingListRussian@forum.nginx.org> Можно где-то подробней почитать, про новые возможности для инвалидации кеша? If-Modified-Since - работает по дате, это хорошо, но для полноты возможностей, нужна поддержка ETag, но все равно спасибо вам, приятно видеть что идет прогресс в этом направлении. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244696,244698#msg-244698 From mdounin at mdounin.ru Fri Nov 15 12:18:20 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 15 Nov 2013 16:18:20 +0400 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <451691782e59e437b436922fa61c034a.NginxMailingListRussian@forum.nginx.org> References: <20131115105232.GI95765@mdounin.ru> <451691782e59e437b436922fa61c034a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131115121820.GM95765@mdounin.ru> Hello! On Fri, Nov 15, 2013 at 06:29:30AM -0500, S.A.N wrote: > Можно где-то подробней почитать, про новые возможности для инвалидации > кеша? Ревалидации. Текущую версию патча можно посмотреть тут: http://mdounin.ru/temp/patch-nginx-ims.txt Вкратце: proxy_cache_revalidate on; и nginx начинает использовать If-Modified-Since в запросах к бекенду, если в кеше есть устаревший ответ. В случае fastcgi - аналогично, fastcgi_cache_revalidate on, только что вместо If-Modified-Since будет переменная HTTP_IF_MODIFIED_SINCE. > If-Modified-Since - работает по дате, это хорошо, но для полноты > возможностей, нужна поддержка ETag, но все равно спасибо вам, приятно видеть > что идет прогресс в этом направлении. Поддержка ETag, возможно, тоже будет в светлом будущем, но не прямо сейчас, т.к. для этого придётся менять заголовки кеш-файлов и много чего другого. С точки зрения собственного бекенда - особой разницы между ETag'ами и Last-Modified нет. -- Maxim Dounin http://nginx.org/en/donation.html From vbart at nginx.com Fri Nov 15 13:19:18 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 15 Nov 2013 17:19:18 +0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60Lgu?= In-Reply-To: <6fbfd3e3e52f9dde4d6bf1b01398152b.NginxMailingListRussian@forum.nginx.org> References: <6fbfd3e3e52f9dde4d6bf1b01398152b.NginxMailingListRussian@forum.nginx.org> Message-ID: <201311151719.18062.vbart@nginx.com> On Friday 15 November 2013 14:52:57 toxi-kb wrote: > Добрый день. У меня есть проблема со статикой. Я, к сожалению, не в силах > решить её своими силами, поэтому буду благодарен за любую помощь. > Суть проблемы: есть сайт, который работает на связке nginx + uwsgi + > django. Когда мы заливаем изменения, нужно отключить доступ к сайту у > обычных пользователей и оставить доступ у разработчиков. Решается это > следующим образом: > 1) В файле конфигурации: основное приложение перебрасывается на порт 8000, > а на 80 отдается заглушка, говорящая о том, что у нас идут обновления. > Nginx перезагружается. > 2) Проходят какие-то технические работы. > 3) Заглушка и основное приложение меняются портами в конфигурации. Nginx > снова перезагружается. > После этого, если зайти в приложение, мы не обнаруживаем часть картинок, > причем у всех это разные картинки, а у кого-то вовсе нет проблем с этим. > Т.е. запрос к картинке возвращает 404. Если сбросить кэш в браузере - все > устаканится и статика вернется на место. > Собственно вопрос: что с этим можно сделать, как исправить данную проблему > и с чем она связана? > Конфигурацию прилагаю в виде ссылки: http://prntscr.com/249v0c > Заранее, большое спасибо за помощь! > Казалось бы, причем тут nginx? Необходимо использовать версионирование в ссылках. Скажем было /media/style/logo.png?1 , а когда загружаете новую версию файла - увеличиваете версию: /media/style/logo.png?2 -- Валентин Бартенев From nginx-forum at nginx.us Fri Nov 15 14:25:14 2013 From: nginx-forum at nginx.us (toxi-kb) Date: Fri, 15 Nov 2013 09:25:14 -0500 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60Lgu?= In-Reply-To: <201311151719.18062.vbart@nginx.com> References: <201311151719.18062.vbart@nginx.com> Message-ID: <20312273e28adba7ea9d1705ef5ba4ef.NginxMailingListRussian@forum.nginx.org> Валентин Бартенев Wrote: ------------------------------------------------------- > On Friday 15 November 2013 14:52:57 toxi-kb wrote: > > Добрый день. У меня есть проблема со статикой. Я, к сожалению, не в > силах > > решить её своими силами, поэтому буду благодарен за любую помощь. > > Суть проблемы: есть сайт, который работает на связке nginx + uwsgi + > > django. Когда мы заливаем изменения, нужно отключить доступ к сайту > у > > обычных пользователей и оставить доступ у разработчиков. Решается > это > > следующим образом: > > 1) В файле конфигурации: основное приложение перебрасывается на порт > 8000, > > а на 80 отдается заглушка, говорящая о том, что у нас идут > обновления. > > Nginx перезагружается. > > 2) Проходят какие-то технические работы. > > 3) Заглушка и основное приложение меняются портами в конфигурации. > Nginx > > снова перезагружается. > > После этого, если зайти в приложение, мы не обнаруживаем часть > картинок, > > причем у всех это разные картинки, а у кого-то вовсе нет проблем с > этим. > > Т.е. запрос к картинке возвращает 404. Если сбросить кэш в браузере > - все > > устаканится и статика вернется на место. > > Собственно вопрос: что с этим можно сделать, как исправить данную > проблему > > и с чем она связана? > > Конфигурацию прилагаю в виде ссылки: http://prntscr.com/249v0c > > Заранее, большое спасибо за помощь! > > > > Казалось бы, причем тут nginx? > > Необходимо использовать версионирование в ссылках. > > Скажем было /media/style/logo.png?1 , а когда загружаете новую версию > файла - > увеличиваете версию: /media/style/logo.png?2 > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо за отклик. Причем nginx... Честно говоря, не знаю куда ещё обратиться, ведь манипуляции я именно с ним произвожу, поэтому здесь вопрос и задаю. На самом деле, новые версии этих картинок, как раз, не загружаются. Обновление идет кода приложения, иногда, конечно, добавляется новая статика, но пропадают картинки контента, давно набитого через админку и они точно не обновлялись. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244695,244710#msg-244710 From vbart at nginx.com Fri Nov 15 18:39:31 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Fri, 15 Nov 2013 22:39:31 +0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60Lgu?= In-Reply-To: <20312273e28adba7ea9d1705ef5ba4ef.NginxMailingListRussian@forum.nginx.org> References: <201311151719.18062.vbart@nginx.com> <20312273e28adba7ea9d1705ef5ba4ef.NginxMailingListRussian@forum.nginx.org> Message-ID: <201311152239.31896.vbart@nginx.com> On Friday 15 November 2013 18:25:14 toxi-kb wrote: [..] > Спасибо за отклик. Причем nginx... Честно говоря, не знаю куда ещё > обратиться, ведь манипуляции я именно с ним произвожу, поэтому здесь вопрос > и задаю. На самом деле, новые версии этих картинок, как раз, не > загружаются. Обновление идет кода приложения, иногда, конечно, добавляется > новая статика, но пропадают картинки контента, давно набитого через > админку и они точно не обновлялись. > Если картинки "пропадают" с кодом 404, значит браузер их запросил и получил 404 в ответ. Вариантов тут не много, либо он запросил уже удаленные картинки и 404 ответил nginx, либо эти картинки обрабатывает бэкенд, и тот уже ответил 404. Запросить удаленные картинки он мог например по причине того, что у него были закэшированы страницы или css файлы с ссылками на уже удаленные элементы. Есть ещё вариант, что вы так настроили open_file_cache, но узнать этого наверняка нельзя, поскольку всю конфигурацию вы не показали. -- Валентин Бартенев From nginx-forum at nginx.us Fri Nov 15 18:46:24 2013 From: nginx-forum at nginx.us (S.A.N) Date: Fri, 15 Nov 2013 13:46:24 -0500 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <20131115121820.GM95765@mdounin.ru> References: <20131115121820.GM95765@mdounin.ru> Message-ID: Отличия ETag от Last-Modified, в формате значений, в ETag произвольный формат и многие разработчики это используют для передачи хеш состояний ответа, некоторые даже используют значения ETag для передачи серелизированой строки в которой хранится состояния ответа. Это удобный и гибкий способ, конечно дефакто в Last-Modified можно назначить любое значения, браузеры не анализируют значения как дату они просто, в следущем запросе возвращают это значения в неизменяемом виде назад серверу, но так делать не надо, поисковики будут не восторге. Многие используют ETag для передачи своих хешей и не захотят этот хеш передавать в Last-Modified, в их алгоритмах ревалидации обязательно получения от клиента хеша состояния, дата не может быть хешем. Возможно, есть способ как-то передать это в значения переменой $upstream_http_etag? Тогда выйдет все просто. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244718#msg-244718 From nginx-forum at nginx.us Fri Nov 15 19:53:33 2013 From: nginx-forum at nginx.us (toxi-kb) Date: Fri, 15 Nov 2013 14:53:33 -0500 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60Lgu?= In-Reply-To: <201311152239.31896.vbart@nginx.com> References: <201311152239.31896.vbart@nginx.com> Message-ID: Валентин Бартенев Wrote: ------------------------------------------------------- > On Friday 15 November 2013 18:25:14 toxi-kb wrote: > [..] > > Спасибо за отклик. Причем nginx... Честно говоря, не знаю куда ещё > > обратиться, ведь манипуляции я именно с ним произвожу, поэтому здесь > вопрос > > и задаю. На самом деле, новые версии этих картинок, как раз, не > > загружаются. Обновление идет кода приложения, иногда, конечно, > добавляется > > новая статика, но пропадают картинки контента, давно набитого через > > админку и они точно не обновлялись. > > > > Если картинки "пропадают" с кодом 404, значит браузер их запросил > и получил 404 в ответ. > > Вариантов тут не много, либо он запросил уже удаленные картинки > и 404 ответил nginx, либо эти картинки обрабатывает бэкенд, и тот > уже ответил 404. > > Запросить удаленные картинки он мог например по причине того, что > у него были закэшированы страницы или css файлы с ссылками на уже > удаленные элементы. > > Есть ещё вариант, что вы так настроили open_file_cache, но узнать > этого наверняка нельзя, поскольку всю конфигурацию вы не показали. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Картинки точно не удалялись. Как я отмечал, если очистить кэш браузера и обновить страницу - они вернутся на место. По поводу open_file_cache: а я вообще его не настраивал, может в том и проблема... Конфигурация на скриншоте была вся, которую я писал, остальное по умолчанию. Вот сожержание файла /etc/nginx/nginx.conf(закомментированое убрал, для компактности): worker_processes 4; pid /var/run/nginx.pid; events { worker_connections 768; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244695,244719#msg-244719 From unlexx at gmail.com Sat Nov 16 05:30:21 2013 From: unlexx at gmail.com (Un Lexx) Date: Sat, 16 Nov 2013 11:30:21 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: <20131113110123.GV95765@mdounin.ru> Message-ID: >для нагруженных проектов хорошо помогает склеить все скрипты в один >(убрав require/include) и поставить, например, APC про акселератор подтверждаю по поводу склейки если проект продолжает разрабатываться проще выделить в ОЗУ нужное число памяти и положить файлы туда чем возиться со склейкой при каждом изменении 14 ноября 2013 г., 12:00 пользователь Илья Шипицин написал: > для нагруженных проектов хорошо помогает склеить все скрипты в один > (убрав require/include) и поставить, например, APC > > 13 ноября 2013 г., 23:53 пользователь init0 > написал: > > Парни, всем спасибо! > > > > Хотел странного, чтобы php5-fpm реботал без php скриптов, а брал их по > сети > > Сегодня вспомнил о "require-once", почитал доку NGINX и понял, что без > > локальных PHP скриптов ничего работать не будет > > > > Спасибо заответы! > > > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244594,244633#msg-244633 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Nov 16 06:56:24 2013 From: nginx-forum at nginx.us (init0) Date: Sat, 16 Nov 2013 01:56:24 -0500 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: Message-ID: <6b78c8bc7b18808a1ded3b96f0bed2d7.NginxMailingListRussian@forum.nginx.org> Не, проекты не нагружены Задача была разгрузить сервер разработки, убрав с него БД, веб сервер и все остальное ПО, оставив только необходимый минимум (php-cli, git, subversion, mysql-client) и изолировать разработчиков друг от друга физически Поднял два сервера с OpenVZ на первом контейнеры разработчиков на втором все приложения(nginx, apache, mysql, mongodb, redis, memcached, php-fpm) - для каждого приложения отдельный контейнер Для php-fpm выделил 3 контейнера, нагрузка распределяется nginx(upstream\fcgi)между двумя серверами равномерно, и 3 как backup сервер в случае падения одного из первых двух Соединил два сервера между собой по NFS и все прекрасно заработало Проекты стали на быстрее на ~50ms, судя по dev контроллеру symfony2 Спасибо всем Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244734#msg-244734 From nginx-forum at nginx.us Sat Nov 16 17:08:09 2013 From: nginx-forum at nginx.us (Ncs) Date: Sat, 16 Nov 2013 12:08:09 -0500 Subject: =?UTF-8?B?0J/RgNC+0LrQvtC90YHRg9C70YzRgtC40YDRg9C50YLQtSDQv9C+INC+0YLQtNCw?= =?UTF-8?B?0YfQtSDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LIu?= Message-ID: Зачада такая: Имеется мощный сервер (FreeBsd 9.2, 8 ядер проц, 32гб памяти, 24х2тб винты, порт 1гбит/с), необходимо раздавать с него видеофайлы размером 50-500МБ Проблема в том, что не получается заставить nginx отдавать больше 500Мбит/с, после рестарта он какое-то время отдает под 800, но потом скорость отдачи проседает и всё. Конфиг nginx worker_processes auto; timer_resolution 100ms; worker_rlimit_nofile 204800; worker_priority -5; events { use kqueue; worker_connections 8192; } http { include mime.types; default_type application/octet-stream; sendfile off; aio on; etag off; access_log off; log_not_found off; directio off; expires max; proxy_buffering off; server {..........} } Настройки /etc/sysctl.conf kern.ipc.nmbjumbop=192000 kern.ipc.nmbclusters=400000 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=204800 net.inet.tcp.maxtcptw=163840 kern.maxfiles=204800 kern.ipc.somaxconn=4096 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 sysctl kern.ipc.shmall=67108864 kern.ipc.shmall=67108864 net.inet.tcp.rfc3465=0 net.route.netisr_maxqlen=4096 kern.ipc.maxsockbuf=83886080 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 Винчестеры не заняты. Есть какие-нибудь идеи? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244740,244740#msg-244740 From nginx-forum at nginx.us Sat Nov 16 17:57:00 2013 From: nginx-forum at nginx.us (Ncs) Date: Sat, 16 Nov 2013 12:57:00 -0500 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IHNldCByZWFsIGlwIGZyb20=?= In-Reply-To: References: Message-ID: <796a138536d731ca5c8009b5b1d9efd5.NginxMailingListRussian@forum.nginx.org> Попробуйте через proxy_set_header Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244662,244741#msg-244741 From nginx-forum at nginx.us Sat Nov 16 19:17:22 2013 From: nginx-forum at nginx.us (Valeriy) Date: Sat, 16 Nov 2013 14:17:22 -0500 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <20131115121820.GM95765@mdounin.ru> References: <20131115121820.GM95765@mdounin.ru> Message-ID: <614fc323dc64bd21dcd485d22c26bb4f.NginxMailingListRussian@forum.nginx.org> Максим! хочу с Вами не согласиться: ETag дает больше возможностей чем Last-Modified (как минимум потому что в него можно засунуть Last-Modified, но не на оборот). я храню флаги актуальности данных в shared memory. в ETag сериализую данные о флагах которые были задействованы при рендере страницы. когда получая ETag от клиента - я его десириализовываю, получаю нужные влаги и сравниваю с теми, которые хранятся в оперативной памяти понимая изменился контент или нет. процесс валидации очень быстрый и легкий. но к сожалению в данный момент я интегрировать его с nginx не могу :( остается ждать только того самого светлого будущего. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244742#msg-244742 From nginx-forum at nginx.us Sat Nov 16 22:10:13 2013 From: nginx-forum at nginx.us (Ncs) Date: Sat, 16 Nov 2013 17:10:13 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60L7QvdGB0YPQu9GM0YLQuNGA0YPQudGC0LUg0L/QviDQvtGC?= =?UTF-8?B?0LTQsNGH0LUg0LHQvtC70YzRiNC40YUg0YTQsNC50LvQvtCyLg==?= In-Reply-To: References: Message-ID: Оказывается все дело в балансировщике upstream mycloud { server t1.local:81; server t2.local:82; } server { listen 80; server_name example.com; access_log /var/log/nginx/proxy.log; location / { proxy_pass http://mycloud; } } У меня 2 локальных сервера читают одно и тоже с 2 разных дисков, таким образом снижается нагрузка на диски + есть активный бекап. И при такой схеме появляется ошибка при проксировании 5428242 zero size buf in output t:1 r:0 f:0 0000000801BED110 0000000801BED110-0000000801BED110 0000000000000000 0-0 while sending request to upstream Сделал получение файлов напрямую без проксирования, стало раздаваться как положено. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244740,244743#msg-244743 From vbart at nginx.com Sun Nov 17 01:03:25 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 17 Nov 2013 05:03:25 +0400 Subject: =?UTF-8?B?UmU6ICDQn9GA0L7QutC+0L3RgdGD0LvRjNGC0LjRgNGD0LnRgtC1INC/0L4g0L4=?= =?UTF-8?B?0YLQtNCw0YfQtSDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LIu?= In-Reply-To: References: Message-ID: <201311170503.25364.vbart@nginx.com> On Sunday 17 November 2013 02:10:13 Ncs wrote: > Оказывается все дело в балансировщике > upstream mycloud { > server t1.local:81; > server t2.local:82; > } > server { > listen 80; > server_name example.com; > access_log /var/log/nginx/proxy.log; > location / { > proxy_pass http://mycloud; > } > } > У меня 2 локальных сервера читают одно и тоже с 2 разных дисков, таким > образом снижается нагрузка на диски + есть активный бекап. > И при такой схеме появляется ошибка при проксировании > 5428242 zero size buf in output t:1 r:0 f:0 0000000801BED110 > 0000000801BED110-0000000801BED110 0000000000000000 0-0 while sending > request to upstream > Сделал получение файлов напрямую без проксирования, стало раздаваться как > положено. В вашей схеме вы скорее всего ещё убили производительность с помощью: proxy_buffering off; -- Валентин Бартенев From nginx-forum at nginx.us Sun Nov 17 01:38:33 2013 From: nginx-forum at nginx.us (Ncs) Date: Sat, 16 Nov 2013 20:38:33 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60L7QvdGB0YPQu9GM0YLQuNGA0YPQudGC0LUg0L/QviDQvtGC?= =?UTF-8?B?0LTQsNGH0LUg0LHQvtC70YzRiNC40YUg0YTQsNC50LvQvtCyLg==?= In-Reply-To: <201311170503.25364.vbart@nginx.com> References: <201311170503.25364.vbart@nginx.com> Message-ID: Нет, при включенной буферизации данные получаемые с локальных серверов записывались в /var/tmp/nginx, что просто убивало системный диск. На больших файлах, тем более проксируемых локально, это бесполезно. Тут проблема оказалась именно в баге "zero size buf in output while sending request to upstream" Пришлось отказаться от такой схемы балансировки и раздавать по принципу чет/нечет, благо это оказалось возможным. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244740,244745#msg-244745 From vbart at nginx.com Sun Nov 17 02:24:34 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 17 Nov 2013 06:24:34 +0400 Subject: =?UTF-8?B?UmU6ICDQn9GA0L7QutC+0L3RgdGD0LvRjNGC0LjRgNGD0LnRgtC1INC/0L4g0L4=?= =?UTF-8?B?0YLQtNCw0YfQtSDQsdC+0LvRjNGI0LjRhSDRhNCw0LnQu9C+0LIu?= In-Reply-To: References: <201311170503.25364.vbart@nginx.com> Message-ID: <201311170624.34129.vbart@nginx.com> On Sunday 17 November 2013 05:38:33 Ncs wrote: > Нет, при включенной буферизации данные получаемые с локальных серверов > записывались в /var/tmp/nginx, что просто убивало системный диск. Они у вас записываются потому, что директива proxy_max_temp_file_size имеет значение отличное от нуля. Читайте документацию: http://nginx.org/r/proxy_max_temp_file_size/ru Выключив буферизацию совсем, вы вынудили nginx проксировать синхронно, читать от бэкенда маленькими порциями, сразу же отправляя их. Что весьма негативно сказывается на производительности. Опять же, читайте документацию: http://nginx.org/r/proxy_buffering/ru > На больших файлах, тем более проксируемых локально, это бесполезно. > Тут проблема оказалась именно в баге "zero size buf in output while sending > request to upstream" Причина этого сообщения также кроется в proxy_buffering off, и, вероятно, устаревшей версии nginx. -- Валентин Бартенев From nginx-forum at nginx.us Sun Nov 17 16:14:37 2013 From: nginx-forum at nginx.us (Ncs) Date: Sun, 17 Nov 2013 11:14:37 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtC60L7QvdGB0YPQu9GM0YLQuNGA0YPQudGC0LUg0L/QviDQvtGC?= =?UTF-8?B?0LTQsNGH0LUg0LHQvtC70YzRiNC40YUg0YTQsNC50LvQvtCyLg==?= In-Reply-To: <201311170624.34129.vbart@nginx.com> References: <201311170624.34129.vbart@nginx.com> Message-ID: nginx/1.4.3 не самая старая версия, правда? Еще раз говорю, что файлы читались локально, все попадало в кеш, какой смысл в таком кеше? А об этом баге куча упоминаний и без отключения буферов. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244740,244750#msg-244750 From chipitsine at gmail.com Mon Nov 18 05:44:34 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 18 Nov 2013 11:44:34 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: <6b78c8bc7b18808a1ded3b96f0bed2d7.NginxMailingListRussian@forum.nginx.org> References: <6b78c8bc7b18808a1ded3b96f0bed2d7.NginxMailingListRussian@forum.nginx.org> Message-ID: symfony2 - шикарная вещь. это, пожалуй, единственный фреймворк, разработчики которого всерьез занимаются производительнолстью. сталкивался с разными php-фреймворками. о symfony очень хорошее впечатление. 16 ноября 2013 г., 12:56 пользователь init0 написал: > Не, проекты не нагружены > Задача была разгрузить сервер разработки, убрав с него БД, веб сервер и все > остальное ПО, оставив только необходимый минимум (php-cli, git, subversion, > mysql-client) и изолировать разработчиков друг от друга физически > > Поднял два сервера с OpenVZ > на первом контейнеры разработчиков > на втором все приложения(nginx, apache, mysql, mongodb, redis, memcached, > php-fpm) - для каждого приложения отдельный контейнер > Для php-fpm выделил 3 контейнера, нагрузка распределяется > nginx(upstream\fcgi)между двумя серверами равномерно, и 3 как backup сервер > в случае падения одного из первых двух > > Соединил два сервера между собой по NFS и все прекрасно заработало > Проекты стали на быстрее на ~50ms, судя по dev контроллеру symfony2 > > Спасибо всем > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244594,244734#msg-244734 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From public-mail at alekciy.ru Mon Nov 18 06:33:56 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Mon, 18 Nov 2013 10:33:56 +0400 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: <6b78c8bc7b18808a1ded3b96f0bed2d7.NginxMailingListRussian@forum.nginx.org> Message-ID: А разве в том же Yii по другому? Silex? Да и настолько ли большая разница? 18 ноября 2013 г., 9:44 пользователь Илья Шипицин написал: > symfony2 - шикарная вещь. > это, пожалуй, единственный фреймворк, разработчики которого всерьез > занимаются производительнолстью. > > сталкивался с разными php-фреймворками. о symfony очень хорошее > впечатление. > > 16 ноября 2013 г., 12:56 пользователь init0 > написал: > > Не, проекты не нагружены > > Задача была разгрузить сервер разработки, убрав с него БД, веб сервер и > все > > остальное ПО, оставив только необходимый минимум (php-cli, git, > subversion, > > mysql-client) и изолировать разработчиков друг от друга физически > > > > Поднял два сервера с OpenVZ > > на первом контейнеры разработчиков > > на втором все приложения(nginx, apache, mysql, mongodb, redis, memcached, > > php-fpm) - для каждого приложения отдельный контейнер > > Для php-fpm выделил 3 контейнера, нагрузка распределяется > > nginx(upstream\fcgi)между двумя серверами равномерно, и 3 как backup > сервер > > в случае падения одного из первых двух > > > > Соединил два сервера между собой по NFS и все прекрасно заработало > > Проекты стали на быстрее на ~50ms, судя по dev контроллеру symfony2 > > > > Спасибо всем > > > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244594,244734#msg-244734 > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chipitsine at gmail.com Mon Nov 18 06:52:44 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Mon, 18 Nov 2013 12:52:44 +0600 Subject: =?UTF-8?B?UmU6INCe0YLQtNC10LvRjNC90YvQuSBQSFAtRlBNINGB0LXRgNCy0LXRgA==?= In-Reply-To: References: <6b78c8bc7b18808a1ded3b96f0bed2d7.NginxMailingListRussian@forum.nginx.org> Message-ID: а по-разному. например, у Zend Framework считается в порядке вещей хранить в одном конфиге приложения несколько профилей (Development, Staging, Production) в формате ini и парсить это все на каждый запрос страницы. c Yii, кстати, тоже все в порядке в плане производительности. но у Symfony есть целый раздел на сайте, объясняющий что, как и почему с точки зрения производительности (и, кстати, это единственный фреймворк, где я видел поддержку ESI, edge side includes), про Yii такого не помню. 18 ноября 2013 г., 12:33 пользователь Алексей Сундуков написал: > А разве в том же Yii по другому? Silex? Да и настолько ли большая разница? > > > 18 ноября 2013 г., 9:44 пользователь Илья Шипицин > написал: > >> symfony2 - шикарная вещь. >> это, пожалуй, единственный фреймворк, разработчики которого всерьез >> занимаются производительнолстью. >> >> сталкивался с разными php-фреймворками. о symfony очень хорошее >> впечатление. >> >> 16 ноября 2013 г., 12:56 пользователь init0 >> написал: >> > Не, проекты не нагружены >> > Задача была разгрузить сервер разработки, убрав с него БД, веб сервер и >> > все >> > остальное ПО, оставив только необходимый минимум (php-cli, git, >> > subversion, >> > mysql-client) и изолировать разработчиков друг от друга физически >> > >> > Поднял два сервера с OpenVZ >> > на первом контейнеры разработчиков >> > на втором все приложения(nginx, apache, mysql, mongodb, redis, >> > memcached, >> > php-fpm) - для каждого приложения отдельный контейнер >> > Для php-fpm выделил 3 контейнера, нагрузка распределяется >> > nginx(upstream\fcgi)между двумя серверами равномерно, и 3 как backup >> > сервер >> > в случае падения одного из первых двух >> > >> > Соединил два сервера между собой по NFS и все прекрасно заработало >> > Проекты стали на быстрее на ~50ms, судя по dev контроллеру symfony2 >> > >> > Спасибо всем >> > >> > Posted at Nginx Forum: >> > http://forum.nginx.org/read.php?21,244594,244734#msg-244734 >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Mon Nov 18 13:57:47 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Nov 2013 17:57:47 +0400 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: References: <20131115121820.GM95765@mdounin.ru> Message-ID: <20131118135747.GJ41579@mdounin.ru> Hello! On Fri, Nov 15, 2013 at 01:46:24PM -0500, S.A.N wrote: > Отличия ETag от Last-Modified, в формате значений, в ETag произвольный > формат и многие разработчики это используют для передачи хеш состояний > ответа, некоторые даже используют значения ETag для передачи серелизированой > строки в которой хранится состояния ответа. > Это удобный и гибкий способ, конечно дефакто в Last-Modified можно назначить > любое значения, браузеры не анализируют значения как дату они просто, в > следущем запросе возвращают это значения в неизменяемом виде назад серверу, > но так делать не надо, поисковики будут не восторге. > Многие используют ETag для передачи своих хешей и не захотят этот хеш > передавать в Last-Modified, в их алгоритмах ревалидации обязательно > получения от клиента хеша состояния, дата не может быть хешем. Если бекенд свой - то можно банально получить время последней модификации, и использовать его. Понятно, что ETag имеет произвольный синтаксис и за счёт этого немного удобней. Столь же понятно, что Last-Modified - это гораздо шире поддерживаемая сущность, ибо это единственный доступный механизм в HTTP/1.0 (и в добавок - ложится на файловую систему, что позволяет его использовать всяким инструментам вроде curl). Принципиальной разницы, как я уже говорил, нет. Есть вопрос выбора. > Возможно, есть способ как-то передать это в значения переменой > $upstream_http_etag? > Тогда выйдет все просто. Как я уже писал, для этого придётся менять заголовки кеш-файлов. Что в свою очередь потребует вводить их версионирование, ибо его сейчас нет. Задача выполнимая, но не "всё просто". -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Mon Nov 18 14:01:51 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 18 Nov 2013 18:01:51 +0400 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <614fc323dc64bd21dcd485d22c26bb4f.NginxMailingListRussian@forum.nginx.org> References: <20131115121820.GM95765@mdounin.ru> <614fc323dc64bd21dcd485d22c26bb4f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131118140151.GK41579@mdounin.ru> Hello! On Sat, Nov 16, 2013 at 02:17:22PM -0500, Valeriy wrote: > Максим! > > хочу с Вами не согласиться: ETag дает больше возможностей чем Last-Modified > (как минимум потому что в него можно засунуть Last-Modified, но не на > оборот). > > я храню флаги актуальности данных в shared memory. > в ETag сериализую данные о флагах которые были задействованы при рендере > страницы. > когда получая ETag от клиента - я его десириализовываю, получаю нужные влаги > и сравниваю с теми, > которые хранятся в оперативной памяти понимая изменился контент или нет. > процесс валидации очень быстрый и легкий. > но к сожалению в данный момент я интегрировать его с nginx не могу :( > остается ждать только того самого светлого будущего. По-моему, то что вы описали - это задача не для ETag'а, а для URI. Некоторые ещё ETag используют вместо Cookie для отслеживания клиентов[1], но это скорее пример против ETag'ов, чем за. [1] http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Mon Nov 18 19:46:31 2013 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 18 Nov 2013 14:46:31 -0500 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <20131118135747.GJ41579@mdounin.ru> References: <20131118135747.GJ41579@mdounin.ru> Message-ID: Если в нашей дискуссии есть практический смысл (реализация Etag в ближайших версия). Я могу много рассказать про невозможность использовать Last-Modified для ревалидации. Реальный пример из жизни, у нас есть страница товара, ниже выводим комментарии пользователей, хедер страницы Last-Modified ? это дата создания/редактирования товара, это необходимо для поисковиков RSS клиентов и т.д. При добавления нового комментария мы не можешь изменить Last-Modified всей страницы, мы можем изменить только её ETag, и самая большая проблема Last-Modified это точность до секунды, к сожаления два комментария могут прийти в одну секунду, но в кеше появится только первый комментарий, второй комментарий просто не сможет сбросить кеш потому что у него такой же Last-Modified. Но главная особенность, Etag он может хранить серелизованые значения или хеши которые являются ключами в NoSQL, в них хранится расширенная мета информацию для использования её в бекенде при ревалидации, с Last-Modified этого сделать невозможно. Etag не просто удобней использовать, он даёт новые возможности которые не может дать Last-Modified, по этому поддержка Etag это стратегический вопрос а не тактический. Не понимаю зачем менять версию кеш файла, для передачи Etag в бекенд? Нам для полного счастья нужна одна мелочь HTTP_IF_NONE_MATCH, серверу нужно её заполнить значениям из файла кеша и передать на бекенд, все больше сервер ничего делать не должен, бекенд ответит статусом 304 или 200. Зачем ждать светлого будущего, если можно создать светлое настоящие для Nginx уже сегодня, осталось мелочь реализовать Etag в ревалидации Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244780#msg-244780 From gmm at csdoc.com Mon Nov 18 21:22:26 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Mon, 18 Nov 2013 23:22:26 +0200 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: References: <20131118135747.GJ41579@mdounin.ru> Message-ID: <528A8512.6060507@csdoc.com> On 18.11.2013 21:46, S.A.N wrote: > Я могу много рассказать про невозможность > использовать Last-Modified дляревалидации. "HTTP/1.0 clients and caches will ignore entity tags." - цитата из http://tools.ietf.org/html/rfc2616#section-13.3.4 и для ревалидации они будут использовать именно что Last-Modified. > Реальный пример из жизни, у нас есть страница товара, ниже выводим > комментарии пользователей, хедер страницы Last-Modified ? это дата > создания/редактирования товара, это необходимо для поисковиков RSS клиентов > и т.д. При добавления нового комментария мы не можешь изменить Last-Modified > всей страницы, мы можем изменить только её ETag, и самая большая проблема > Last-Modified это точность до секунды, к сожаления два комментария могут > прийти в одну секунду, но в кеше появится только первый комментарий, второй > комментарий просто не сможет сбросить кеш потому что у него такой же > Last-Modified. насколько я понимаю, ваш сайт будет нормально работать только с теми клиентами и прокси, которые работают исключительно по протоколу HTTP/1.1 -- Best regards, Gena From nginx-forum at nginx.us Mon Nov 18 21:54:39 2013 From: nginx-forum at nginx.us (S.A.N) Date: Mon, 18 Nov 2013 16:54:39 -0500 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: <528A8512.6060507@csdoc.com> References: <528A8512.6060507@csdoc.com> Message-ID: <3f0c26bf47bd6672f99ff1a2b69b8182.NginxMailingListRussian@forum.nginx.org> Проблем с HTTP/1.0 не будет в принципе, бекенд не работает на прямую с клиентом по HTTP/1.0, бекенд работает с Nginx, который в свою очередь должен передать HTTP_IF_NONE_MATCH взятым из файла кеша Nginx, бекенд проведет ревалидацию и ответит 304 или 200 с контентом страницы, клиент получит ответ от Nginx в любом случаи правильный. Как видите все упирается только в отсутствия поддержки HTTP_IF_NONE_MATCH в Nginx. Я практик и могу уверено сказать, что в реальной жизни необходим ETag для решения практических задач. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244677,244787#msg-244787 From mdounin at mdounin.ru Tue Nov 19 02:30:51 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Nov 2013 06:30:51 +0400 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: References: <20131118135747.GJ41579@mdounin.ru> Message-ID: <20131119023051.GR41579@mdounin.ru> Hello! On Mon, Nov 18, 2013 at 02:46:31PM -0500, S.A.N wrote: > Если в нашей дискуссии есть практический смысл (реализация Etag в ближайших > версия). > Я могу много рассказать про невозможность использовать Last-Modified для > ревалидации. > > Реальный пример из жизни, у нас есть страница товара, ниже выводим > комментарии пользователей, хедер страницы Last-Modified ? это дата > создания/редактирования товара, это необходимо для поисковиков RSS клиентов > и т.д. При добавления нового комментария мы не можешь изменить Last-Modified > всей страницы, мы можем изменить только её ETag, и самая большая проблема Если вы не меняете Last-Modified документа при его изменении - у вас проблема, как справедливо заметил Гена. Вне зависимости от того, кто выступает клиентом. Но это, опять же, не рассказ о том, почему не годится Last-Modified, а рассказ о том, как много всего можно напрограммировать криво. > Last-Modified это точность до секунды, к сожаления два комментария могут > прийти в одну секунду, но в кеше появится только первый комментарий, второй > комментарий просто не сможет сбросить кеш потому что у него такой же > Last-Modified. Проблема subsecond resulution - имеет чуть менее, чем бесконечное множество решений, начиная от совсем простого "подождать секунду" и до выдачи "умных" значений Expires / Cache-Control: max-age. > Но главная особенность, Etag он может хранить серелизованые значения или > хеши которые являются ключами в NoSQL, в них хранится расширенная мета > информацию для использования её в бекенде при ревалидации, с Last-Modified > этого сделать невозможно. Я уже в этом треде отвечал на попытку рассказать про такие "преимущества" ETag'а. То, что ETag допускает подобное использование не по назначению - это, наоборот, недостаток технологии, а не её достоинство. > Etag не просто удобней использовать, он даёт новые возможности которые не > может дать Last-Modified, по этому поддержка Etag это стратегический вопрос > а не тактический. На самом деле, основное практическое преимущество ETag'ов перед перед Last-Modified: без них не работает докачка в IE9+. Именно для этого, кстати, поддержка ETag'ов вообще появилась в nginx'е. > Не понимаю зачем менять версию кеш файла, для передачи Etag в бекенд? > Нам для полного счастья нужна одна мелочь HTTP_IF_NONE_MATCH, серверу нужно > её заполнить значениям из файла кеша и передать на бекенд, все больше сервер > ничего делать не должен, бекенд ответит статусом 304 или 200. > Зачем ждать светлого будущего, если можно создать светлое настоящие для > Nginx уже сегодня, осталось мелочь реализовать Etag в ревалидации В код вы, судя по всему, заглядывать не пытались. Тогда рекомендую просто поверить на слово тому, что уже было сказано - не верить и переспрашивать ещё раз бессмысленно, т.к. на выходе будет та же проблема - поверить или переспросить ещё раз. http://lurkmore.to/Рекурсия -- Maxim Dounin http://nginx.org/en/donation.html From me at kemko.ru Tue Nov 19 02:45:28 2013 From: me at kemko.ru (=?koi8-r?B?5M3J1NLJyiDhzsTSxcXX?=) Date: Tue, 19 Nov 2013 06:45:28 +0400 Subject: =?UTF-8?B?UmU6INCU0L7QsdCw0LLQuNGC0Ywg0L/QtdGA0LXQvNC10L3Rg9GOICRjYWNoZSBz?= =?UTF-8?B?dGF0dXM=?= In-Reply-To: Message-ID: <601384829128@web26g.yandex.ru> 18.11.2013, 23:46, "S.A.N" : > Реальный пример из жизни, у нас есть страница товара, ниже выводим > комментарии пользователей, хедер страницы Last-Modified ? это дата > создания/редактирования товара, это необходимо для поисковиков RSS клиентов Для поисковиков можно генерировать sitemap, какое дело rss клиентам до last-modified обычной html страницы не сообразил, что скрывается под и т.д. не знаю. From zmey1992 at ya.ru Tue Nov 19 10:34:51 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Tue, 19 Nov 2013 14:34:51 +0400 Subject: =?UTF-8?B?UmU6INCa0Y3RiNC40YDQvtCy0LDQvdC40LUg0YHRgtCw0YLQuNC60Lgu?= In-Reply-To: References: <201311152239.31896.vbart@nginx.com> Message-ID: <161301384857291@web10m.yandex.ru> А в логи смотрели? Там что-нибудь на тему пропавших файлов есть? Бэкэнд у вас логи ведёт? 15.11.2013, 23:53, "toxi-kb" : > Валентин Бартенев Wrote: > ------------------------------------------------------- > >>  On Friday 15 November 2013 18:25:14 toxi-kb wrote: >>  [..] >>>  Спасибо за отклик. Причем nginx... Честно говоря, не знаю куда ещё >>>  обратиться, ведь манипуляции я именно с ним произвожу, поэтому здесь >>  вопрос >>>  и задаю. На самом деле, новые версии этих картинок, как раз, не >>>  загружаются. Обновление идет кода приложения, иногда, конечно, >>  добавляется >>>  новая статика, но пропадают картинки контента, давно набитого через >>>  админку и они точно не обновлялись. >>  Если картинки "пропадают" с кодом 404, значит браузер их запросил >>  и получил 404 в ответ. >> >>  Вариантов тут не много, либо он запросил уже удаленные картинки >>  и 404 ответил nginx, либо эти картинки обрабатывает бэкенд, и тот >>  уже ответил 404. >> >>  Запросить удаленные картинки он мог например по причине того, что >>  у него были закэшированы страницы или css файлы с ссылками на уже >>  удаленные элементы. >> >>  Есть ещё вариант, что вы так настроили open_file_cache, но узнать >>  этого наверняка нельзя, поскольку всю конфигурацию вы не показали. >> >>  -- >>  Валентин Бартенев >>  _______________________________________________ >>  nginx-ru mailing list >>  nginx-ru at nginx.org >>  http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Картинки точно не удалялись. Как я отмечал, если очистить кэш браузера и > обновить страницу - они вернутся на место. По поводу open_file_cache: а я > вообще его не настраивал, может в том и проблема... Конфигурация на > скриншоте была вся, которую я писал, остальное по умолчанию. > Вот сожержание файла /etc/nginx/nginx.conf(закомментированое убрал, для > компактности): > > worker_processes 4; > pid /var/run/nginx.pid; > events { >         worker_connections 768; > } > http { >         sendfile on; >         tcp_nopush on; >         tcp_nodelay on; >         keepalive_timeout 65; >         types_hash_max_size 2048; > >         include /etc/nginx/mime.types; >         default_type application/octet-stream; > >         access_log /var/log/nginx/access.log; >         error_log /var/log/nginx/error.log; > >         gzip on; >         gzip_disable "msie6"; > >         include /etc/nginx/conf.d/*.conf; >         include /etc/nginx/sites-enabled/*; > } > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244695,244719#msg-244719 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Tue Nov 19 15:00:48 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Nov 2013 19:00:48 +0400 Subject: nginx-1.5.7 Message-ID: <20131119150048.GF41579@mdounin.ru> Изменения в nginx 1.5.7 19.11.2013 *) Безопасность: символ, следующий за незакодированным пробелом в строке запроса, обрабатывался неправильно (CVE-2013-4547); ошибка появилась в 0.8.41. Спасибо Ivan Fratric из Google Security Team. *) Изменение: уровень логгирования ошибок auth_basic об отсутствии пароля понижен с уровня error до info. *) Добавление: директивы proxy_cache_revalidate, fastcgi_cache_revalidate, scgi_cache_revalidate и uwsgi_cache_revalidate. *) Добавление: директива ssl_session_ticket_key. Спасибо Piotr Sikora. *) Исправление: директива "add_header Cache-Control ''" добавляла строку заголовка ответа "Cache-Control" с пустым значением. *) Исправление: директива "satisfy any" могла вернуть ошибку 403 вместо 401 при использовании директив auth_request и auth_basic. Спасибо Jan Marc Hoffmann. *) Исправление: параметры accept_filter и deferred директивы listen игнорировались для listen-сокетов, создаваемых в процессе обновления исполняемого файла. Спасибо Piotr Sikora. *) Исправление: часть данных, полученных от бэкенда при небуферизированном проксировании, могла не отправляться клиенту сразу, если использовались директивы gzip или gunzip. Спасибо Yichun Zhang. *) Исправление: в обработке ошибок в модуле ngx_http_gunzip_filter_module. *) Исправление: ответы могли зависать если использовался модуль ngx_http_spdy_module и директива auth_request. *) Исправление: утечки памяти в nginx/Windows. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Nov 19 15:01:11 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Nov 2013 19:01:11 +0400 Subject: nginx-1.4.4 Message-ID: <20131119150111.GJ41579@mdounin.ru> Изменения в nginx 1.4.4 19.11.2013 *) Безопасность: символ, следующий за незакодированным пробелом в строке запроса, обрабатывался неправильно (CVE-2013-4547); ошибка появилась в 0.8.41. Спасибо Ivan Fratric из Google Security Team. -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Tue Nov 19 15:02:33 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 19 Nov 2013 19:02:33 +0400 Subject: nginx security advisory (CVE-2013-4547) Message-ID: <20131119150232.GN41579@mdounin.ru> Hello! Ivan Fratric из Google Security Team обнаружил ошибку в nginx, которая позволяет в некоторых случаях обходить ограничения безопасности с помощью специального запроса, а также может иметь другие последствия (CVE-2013-4547). Некоторые проверки URI запроса не делались над символом, следующим за незакодированным символом пробела (незакодированный пробел недопустим в соответствии с протоколом HTTP, однако поддерживается начиная с nginx 0.8.41 из соображений совместимости). Одним из результатов ошибки была возможность получить доступ к файлу, закрытому с помощью ограничений доступа вида location /protected/ { deny all; } запросив его как "/foo /../protected/file" (в случае статических файлов - только если существует каталог "foo ", с пробелом на конце), а также возможность вызывать специальную обработку файла с пробелом на конце в конфигурации вида location ~ \.php$ { fastcgi_pass ... } запросив файл как "/file \0.php". Проблеме подвержены версии nginx 0.8.41 - 1.5.6. Проблема исправлена в nginx 1.5.7, 1.4.4. Патч, исправляющий проблему, доступен тут: http://nginx.org/download/patch.2013.space.txt В качестве временной защиты можно в каждом блоке server{} воспользоваться конфигурацией вида: if ($request_uri ~ " ") { return 444; } -- Maxim Dounin http://nginx.org/en/donation.html From zmey1992 at ya.ru Wed Nov 20 08:16:48 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 20 Nov 2013 12:16:48 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: <20130524182659.GJ69760@mdounin.ru> References: <20130524182659.GJ69760@mdounin.ru> Message-ID: <368491384935408@web16h.yandex.ru> Патч внесён в основную ветку? Или предназначен для данного треда? 24.05.2013, 22:27, "Maxim Dounin" : > Hello! > > On Tue, Apr 23, 2013 at 03:01:11PM +0400, Aleksey Chirkin wrote: > >>  Каждый день на основной сервер добавляется директория с кучей файлов >>  объемом несколько гигабайт. И пока она синхронизируется на другие сервера, >>  попытка доступа к файлам этой директории на синхронизируемых серверах >>  приводит к ошибке 403. upstream заканчивает попытки перебора серверов не >>  обработав этот код в proxy_next_upstream. > > Патч прилагается. > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > , > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zmey1992 at ya.ru Wed Nov 20 08:38:47 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 20 Nov 2013 12:38:47 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUsIGxpbWl0IHJlcSDQuCBsaW1pdCBjb25uINCy0L3Rg9GC?= =?UTF-8?B?0YDQuCDRg9GB0LvQvtCy0LjRjyBJRg==?= In-Reply-To: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> References: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> Message-ID: <64401384936727@web3g.yandex.ru> Hello. Можно, к примеру, сделать такой 09.11.2013, 21:01, "sofiamay" : > Здравствуйте. Вот такой вот конфиг прекрасно работает внутри Location или > внутри Server: > > location / { > limit_req zone=reqip burst=128; > limit_conn url_ip 4; > set $limit_rate 312k; > limit_rate  312k; > } > > Но стоит вместо location / { написать if ($remote_addr = 'xx.xx.xx.xx') { то > сервер ругается, ничего не работает. > Мне нужно чтобы для всех клиентов действовали ограничения, а для сервера нет > (когда запросы на сервер идут с самого сервера через скрипты). > > Подскажите пожалуйста, неужели все эти настройки Nginx не позволяет > размещать внутри условия? Может я чего не так делаю. Если всё настолько > плохо и не позволяет, то подскажите пожалуйста может кто-то знает каким > путем можно решить возникшую проблему... Спасибо > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244549,244549#msg-244549 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zmey1992 at ya.ru Wed Nov 20 08:40:09 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 20 Nov 2013 12:40:09 +0400 Subject: =?UTF-8?B?UmU6IGxpbWl0IHJhdGUsIGxpbWl0IHJlcSDQuCBsaW1pdCBjb25uINCy0L3Rg9GC?= =?UTF-8?B?0YDQuCDRg9GB0LvQvtCy0LjRjyBJRg==?= In-Reply-To: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> References: <07312ffc591fe3ccca5502ab6273b516.NginxMailingListRussian@forum.nginx.org> Message-ID: <65681384936809@web27j.yandex.ru> Оно отправилось раньше, чем надо было... Так вот, как вариант, можно создать аналогичный server{} без лимитов и с другим server_name и пускай скрипты ломятся туда. 09.11.2013, 21:01, "sofiamay" : > Здравствуйте. Вот такой вот конфиг прекрасно работает внутри Location или > внутри Server: > > location / { > limit_req zone=reqip burst=128; > limit_conn url_ip 4; > set $limit_rate 312k; > limit_rate  312k; > } > > Но стоит вместо location / { написать if ($remote_addr = 'xx.xx.xx.xx') { то > сервер ругается, ничего не работает. > Мне нужно чтобы для всех клиентов действовали ограничения, а для сервера нет > (когда запросы на сервер идут с самого сервера через скрипты). > > Подскажите пожалуйста, неужели все эти настройки Nginx не позволяет > размещать внутри условия? Может я чего не так делаю. Если всё настолько > плохо и не позволяет, то подскажите пожалуйста может кто-то знает каким > путем можно решить возникшую проблему... Спасибо > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244549,244549#msg-244549 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From zmey1992 at ya.ru Wed Nov 20 08:43:55 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 20 Nov 2013 12:43:55 +0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0L7RgSDQv9C+IHNldF9yZWFsX2lwX2Zyb20=?= In-Reply-To: References: Message-ID: <82371384937035@web27j.yandex.ru> proxy_set_header? http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header 14.11.2013, 17:59, "Oleg Motienko" : > Привет. > > set_real_ip_from отлично работает, но вот потребовалось получить > адрес, который был до set_real_ip_from (фактически, адрес из tcp > сессии) и послать его на бэкэнд в заголовке http. > > Как такое можно сделать? > > -- > Regards, > Oleg > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed Nov 20 11:58:41 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 20 Nov 2013 15:58:41 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: <368491384935408@web16h.yandex.ru> References: <20130524182659.GJ69760@mdounin.ru> <368491384935408@web16h.yandex.ru> Message-ID: <20131120115841.GX41579@mdounin.ru> Hello! On Wed, Nov 20, 2013 at 12:16:48PM +0400, Васильев "Zmey!" Олег wrote: > Патч внесён в основную ветку? Или предназначен для данного треда? Этот патч (с незначительными правками) есть в 1.5.7: http://hg.nginx.org/nginx/rev/43ccaf8e8728 Документация тут: http://nginx.org/r/proxy_cache_revalidate http://nginx.org/r/fastcgi_cache_revalidate -- Maxim Dounin http://nginx.org/en/donation.html From zmey1992 at ya.ru Wed Nov 20 13:44:59 2013 From: zmey1992 at ya.ru (=?koi8-r?B?98HTyczYxdcgIlptZXkhIiDvzMXH?=) Date: Wed, 20 Nov 2013 17:44:59 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: <20131120115841.GX41579@mdounin.ru> References: <20130524182659.GJ69760@mdounin.ru> <368491384935408@web16h.yandex.ru> <20131120115841.GX41579@mdounin.ru> Message-ID: <93411384955099@web14j.yandex.ru> Отлично, спасибо. 20.11.2013, 15:58, "Maxim Dounin" : > Hello! > > On Wed, Nov 20, 2013 at 12:16:48PM +0400, Васильев "Zmey!" Олег wrote: > >>  Патч внесён в основную ветку? Или предназначен для данного треда? > > Этот патч (с незначительными правками) есть в 1.5.7: > > http://hg.nginx.org/nginx/rev/43ccaf8e8728 > > Документация тут: > > http://nginx.org/r/proxy_cache_revalidate > http://nginx.org/r/fastcgi_cache_revalidate > > -- > Maxim Dounin > http://nginx.org/en/donation.html > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From mdounin at mdounin.ru Wed Nov 20 17:46:00 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 20 Nov 2013 21:46:00 +0400 Subject: proxy_next_upstream http_403 code In-Reply-To: <93411384955099@web14j.yandex.ru> References: <20130524182659.GJ69760@mdounin.ru> <368491384935408@web16h.yandex.ru> <20131120115841.GX41579@mdounin.ru> <93411384955099@web14j.yandex.ru> Message-ID: <20131120174600.GE41579@mdounin.ru> Hello! On Wed, Nov 20, 2013 at 05:44:59PM +0400, Васильев "Zmey!" Олег wrote: > Отлично, спасибо. > > 20.11.2013, 15:58, "Maxim Dounin" : > > Hello! > > > > On Wed, Nov 20, 2013 at 12:16:48PM +0400, Васильев "Zmey!" Олег wrote: > > > >>  Патч внесён в основную ветку? Или предназначен для данного треда? > > > > Этот патч (с незначительными правками) есть в 1.5.7: > > > > http://hg.nginx.org/nginx/rev/43ccaf8e8728 > > > > Документация тут: > > > > http://nginx.org/r/proxy_cache_revalidate > > http://nginx.org/r/fastcgi_cache_revalidate Oops, сорри, не про тот патч ответил. Тот появился аж в 1.5.1. http://nginx.org/r/proxy_next_upstream -- Maxim Dounin http://nginx.org/en/donation.html From public-mail at alekciy.ru Thu Nov 21 06:25:34 2013 From: public-mail at alekciy.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0KHRg9C90LTRg9C60L7Qsg==?=) Date: Thu, 21 Nov 2013 10:25:34 +0400 Subject: nginx-1.5.7 In-Reply-To: <20131119150048.GF41579@mdounin.ru> References: <20131119150048.GF41579@mdounin.ru> Message-ID: >часть данных, полученных от бэкенда при >небуферизированном проксировании, могла не отправляться клиенту >сразу, если использовались директивы gzip или gunzip. А это означает, что gzip или gunzip для клиента отключаются или же на бэкэнд ложиться задача сжатия ответа, а nginx просто сразу отправляет клиенту полученные с бэкэнда данные? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kulmaks at gmail.com Thu Nov 21 07:20:03 2013 From: kulmaks at gmail.com (Maksim Kulik) Date: Thu, 21 Nov 2013 10:20:03 +0300 Subject: nginx-1.5.7 In-Reply-To: References: <20131119150048.GF41579@mdounin.ru> Message-ID: На бэкенд ничего не ложится. Просто nginx должен был отправлять данные сразу (т.к. речь идет про небуферизованное проксирование), а он их задерживал. 21 ноября 2013 г., 9:25 пользователь Алексей Сундуков < public-mail at alekciy.ru> написал: > >часть данных, полученных от бэкенда при > >небуферизированном проксировании, могла не отправляться клиенту > >сразу, если использовались директивы gzip или gunzip. > > А это означает, что gzip или gunzip для клиента отключаются или же на > бэкэнд ложиться задача сжатия ответа, а nginx просто сразу отправляет > клиенту полученные с бэкэнда данные? > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at gelun.ru Fri Nov 22 20:47:41 2013 From: a at gelun.ru (Gelun, Artem) Date: Sat, 23 Nov 2013 00:47:41 +0400 Subject: =?UTF-8?B?0JfQsNGC0YvQutC4INC/0YDQuCDQvtGC0LTQsNGH0LUg0YHRgtCw0YLQuNC60Lg=?= Message-ID: Добрый вечер, коллеги Помогите, пожалуйста, разобраться с тормозами при отдаче статики (файлы порядка 2-4 МБайт, около 700-1000 rps, keep-alive не используется со стороны клиента (!), 99% клиентских сессий - с localhost, отдача начинает тормозить где-то на 2.7-3 Gbps) проблема выглядит как периодическое "залипание" загрузки файла на некоторый интервал (от долей секунды до нескольких секунд). Конфигурация: worker_processes 16; worker_rlimit_nofile 21000; worker_priority -5; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; timer_resolution 100ms; events { worker_connections 10240; use epoll; } http { sendfile on; # sendfile_max_chunk 1m; open_file_cache max=10240 inactive=300s; open_file_cache_valid 2000s; open_file_cache_min_uses 1; open_file_cache_errors on; # aio on; # directio 4k; # directio_alignment 4k; # output_buffers 128 512k; keepalive_timeout 60; underscores_in_headers on; server_tokens off; tcp_nodelay on; ... } Всё что закомментировано - проверялось без результата. Для теста сделал tmpfs (чтобы исключить тормоза HDD), поставил рядом apache2 (чтобы минимизировать вероятность тормозов сетевого стека), с соседнего сервера делаю запрос на файл в tmpfs, apache выдаёт его стабильно с 24-25MBps, nginx тот же файл - в лучшем случае 12MBps, Затыки также замечаются и на локалхосте. Скорость - от тех же 12MBps до 720MBps. Апач стабильно держит >1GBps. Вот пример времени выполнения запросов с локалхоста: real 0m4.167s user 0m0.008s sys 0m0.042s real 0m2.085s user 0m0.006s sys 0m0.049s real 0m2.079s user 0m0.007s sys 0m0.055s real 0m0.623s user 0m0.007s sys 0m0.064s real 0m1.225s user 0m0.004s sys 0m0.052s real 0m0.333s user 0m0.005s sys 0m0.057s real 0m2.097s user 0m0.004s sys 0m0.058s *ОС:* 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux net.core.netdev_max_backlog=20480 net.core.rmem_default=131072 net.core.rmem_max=1310720 net.core.somaxconn=2048 net.core.wmem_default=131072 net.core.wmem_max=1310720 net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.all.accept_source_route=0 net.ipv4.conf.all.log_martians=1 net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.all.secure_redirects=0 net.ipv4.conf.all.send_redirects=0 net.ipv4.conf.default.accept_redirects=0 net.ipv4.conf.default.accept_source_route=0 net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.default.secure_redirects=0 net.ipv4.conf.default.send_redirects=0 net.ipv4.icmp_echo_ignore_broadcasts=1 net.ipv4.icmp_ignore_bogus_error_responses=1 net.ipv4.ip_forward=0 net.ipv4.tcp_dsack=1 net.ipv4.tcp_mem=24576 32768 131072 net.ipv4.tcp_rmem=4096 65536 524288 net.ipv4.tcp_sack=1 net.ipv4.tcp_syncookies=1 net.ipv4.tcp_window_scaling=1 net.ipv4.tcp_wmem=4096 65536 524288 net.ipv4.udp_mem=8388608 12582912 33554432 net.ipv4.udp_rmem_min=16384 net.ipv4.udp_wmem_min=16384 проверялось также с: net.ipv4.tcp_sack=0 , бОльшими числами в tcp_mem, tcp_wmem , бОльшим числом worker'ов (до 32) результат одинаков. LA на сервере высокий (в основном, из-за чтения с HDD), на 16 ядрах держится около 16. Что я не так готовлю? -------------- next part -------------- An HTML attachment was scrubbed... URL: From voron at amhost.net Sat Nov 23 09:03:45 2013 From: voron at amhost.net (Alex Vorona) Date: Sat, 23 Nov 2013 11:03:45 +0200 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: References: Message-ID: <52906F71.9070705@amhost.net> 22.11.2013 22:47, Gelun, Artem wrote: > Добрый вечер, коллеги > > Помогите, пожалуйста, разобраться с тормозами при отдаче статики (файлы > порядка 2-4 МБайт, около 700-1000 rps, keep-alive не используется со > стороны клиента (!), 99% клиентских сессий - с localhost, отдача начинает > тормозить где-то на 2.7-3 Gbps) > проблема выглядит как периодическое "залипание" загрузки файла на некоторый > интервал (от долей секунды до нескольких секунд). перегрузка дисков? [...] > LA на сервере высокий (в основном, из-за чтения с HDD), на 16 ядрах > держится около 16. Если клиент умеет ходить в unix-сокет (например nginx) - попробуйте перевести. Для HDD nginx и ОС нужно настраивать так чтобы nginx читал с диска как можно бОльшими в пределах разумного кусками, 512к-2048к например. Для этого прочитанные данные должны влазить в буфер сокета, желательно также увеличить readahead, например через blockdev --setra С апачем проблем нет, так как он скорее всего prefork, и не занимается переключением между клиентами внутри одного процесса. С запущенным рядом ещё одним nginx, на который не идёт нагрузка, также не должно быть проблем. А вообще я не уверен что при перегруженных HDD проблема имеет решение, если поступающих запросов больше, чем может обслужить дисковая подсистема. From a at gelun.ru Sat Nov 23 11:11:27 2013 From: a at gelun.ru (Gelun, Artem) Date: Sat, 23 Nov 2013 15:11:27 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <52906F71.9070705@amhost.net> References: <52906F71.9070705@amhost.net> Message-ID: 23 ноября 2013 г., 13:03 пользователь Alex Vorona написал: > 22.11.2013 22:47, Gelun, Artem wrote: > > Добрый вечер, коллеги > > > > Помогите, пожалуйста, разобраться с тормозами при отдаче статики (файлы > > порядка 2-4 МБайт, около 700-1000 rps, keep-alive не используется со > > стороны клиента (!), 99% клиентских сессий - с localhost, отдача начинает > > тормозить где-то на 2.7-3 Gbps) > > проблема выглядит как периодическое "залипание" загрузки файла на > некоторый > > интервал (от долей секунды до нескольких секунд). > перегрузка дисков? > Для "боевой" нагрузки - возможно и так. Но что тогда с tmpfs? Или имеется ввиду перегрузка дисков и блокировка чего то (чего и когда?), что влечёт затыки и для tmpfs? > [...] > > LA на сервере высокий (в основном, из-за чтения с HDD), на 16 ядрах > > держится около 16. > Если клиент умеет ходить в unix-сокет (например nginx) - попробуйте > перевести. Для HDD > nginx и ОС нужно настраивать так чтобы nginx читал с диска как можно > бОльшими в пределах > разумного кусками, 512к-2048к например. Для этого прочитанные данные > должны влазить в > буфер сокета, желательно также увеличить readahead, например через > blockdev --setra > опять же, tmpfs, RA не актуален. unix socket не умеет (пока). Вообще, мысль хорошая, спасибо. в listen для проверки выставил уже запредельный sndbuf=8192k (благо памяти хватает), в sysctl - "net.ipv4.tcp_wmem = 4096 131072 8388608" - всё равно затыки даже на файлах по 4МБайта. При том затыкается именно где-то посередине в большинстве случаев, но в разные моменты (т.е. нет явной связи с объёмом закачки). Действительно ощущение, что что-то куда-то не влазит. Но, опять же, куда? > С апачем проблем нет, так как он скорее всего prefork, и не занимается > переключением между > клиентами внутри одного процесса. С запущенным рядом ещё одним nginx, на > который не идёт > нагрузка, также не должно быть проблем. > Насколько я понимаю, sendfile (который включен и должен отрабатывать) не блокирует worker'а. Единственное подозрение - воркеры блокируются при открытии файла с "перегруженного" HDD. Но: 1) как это проверить? 2) увеличение кол-ва worker'ов (до 64) не помогает 3) Если я правильно понимаю, при размере файла < размера буфера сокета и если sendfile_max_chunk не установлен, то sendfile должен вызываться один раз. Соответсвенно, если затык в nginx, то он будет перед началом отдачи данных. Но затыкаться может где угодно - и на 9%, и на 15%, и на 67%... (опять же, речь про tmpfs, с которой вообще никто ничего не читает, кроме теста) > > А вообще я не уверен что при перегруженных HDD проблема имеет решение, > если поступающих > запросов больше, чем может обслужить дисковая подсистема. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Sat Nov 23 12:07:02 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 23 Nov 2013 14:07:02 +0200 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <52906F71.9070705@amhost.net> References: <52906F71.9070705@amhost.net> Message-ID: <52909A66.30701@csdoc.com> On 23.11.2013 11:03, Alex Vorona wrote: > А вообще я не уверен что при перегруженных HDD проблема имеет решение, > если поступающих запросов больше, чем может обслужить дисковая подсистема. есть очень похожая задача - что делать, если трафика больше, чем Bandwidth сетевой подсистемы. и эта задача успешно решена практически во всех операционных системах. например, для линукса - http://xgu.ru/wiki/QoS_в_Linux, Hierarchy Token Bucket и т.п. разница только в том, что Bandwidth сетевой подсистемы измеряется в мегабитах в секунду, а Bandwidth дисковой подсистемы - в IOPS. например, в новых версиях OpenVZ уже появилась опция --iopslimit iops также в линуксе есть ionice с 4 класами и 8 приоритетами внутри класса. теоретически, - если клиенты не однородны, (например, те, кто платит деньги за доступ к контенту и те, кто получает доступ к нему бесплатно) то можно разделить их по классам и назначить разные уровни приоритета. сейчас же обычно все свалено в одну кучу, и никаких QoS настроек нет. поскольку native поддержки для этого в nginx нет и вряд ли когда-либо появится, то это все придется делать средствами операционной системы. хотя обычно тюнинг nginx и операционной системы, чтобы данные с дисков читались большими блоками по 1 мегабайту - помогает и этого достаточно. еще скрытые резервы для повышения производительности могут быть в том, что дисковое хранилище собрано в виде RAID массива 5/6/10/... - в таком случае сам RAID массив является узким местом и его лучше разобрать на "отдельные" диски или RAID-1 массивы из N дисков. в этом случае, если software raid / hardware raid не кривой - скорость random чтения с RAID-1 массива из N дисков будет примерно в N раз выше. или же - добавить SSD к системе хранения файлов в том или ином виде (Bcache,Flashcache,Btier,EnhanceIO, nginx+ngx_slowfs_cache, etc...) туда уйдет самый "горячий" контент и вся система выдаст больше IOPS. кстати, странно что функциональности модуля ngx_slowfs_cache нет в основной ветке nginx, - чтобы сделать что-то аналогичное без ngx_slowfs_cache придется использовать "двойное проксирование". хотя может быть overhead от этого не большой и это вполне приемлимо. но настройка получается не тривиальной: http://habrahabr.ru/post/202290/ -- Best regards, Gena From a at gelun.ru Sat Nov 23 12:32:41 2013 From: a at gelun.ru (Gelun, Artem) Date: Sat, 23 Nov 2013 16:32:41 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <52909A66.30701@csdoc.com> References: <52906F71.9070705@amhost.net> <52909A66.30701@csdoc.com> Message-ID: Геннадий, Вы говорите про оптимизацию дисковой подсистемы. А я - про то, что чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты времени по непонятным причинам. Это несколько разные проблемы. В этом случае ни ngx_slowfs_cache, ни SSD, ни двойное проксирование решения не дадут. 23 ноября 2013 г., 16:07 пользователь Gena Makhomed написал: > On 23.11.2013 11:03, Alex Vorona wrote: > > А вообще я не уверен что при перегруженных HDD проблема имеет решение, >> если поступающих запросов больше, чем может обслужить дисковая подсистема. >> > > есть очень похожая задача - что делать, если трафика больше, > чем Bandwidth сетевой подсистемы. и эта задача успешно решена > практически во всех операционных системах. например, для линукса > - http://xgu.ru/wiki/QoS_в_Linux, Hierarchy Token Bucket и т.п. > > разница только в том, что Bandwidth сетевой подсистемы измеряется > в мегабитах в секунду, а Bandwidth дисковой подсистемы - в IOPS. > например, в новых версиях OpenVZ уже появилась опция --iopslimit iops > также в линуксе есть ionice с 4 класами и 8 приоритетами внутри класса. > > теоретически, - если клиенты не однородны, (например, те, кто платит > деньги за доступ к контенту и те, кто получает доступ к нему бесплатно) > то можно разделить их по классам и назначить разные уровни приоритета. > сейчас же обычно все свалено в одну кучу, и никаких QoS настроек нет. > > поскольку native поддержки для этого в nginx нет и вряд ли когда-либо > появится, то это все придется делать средствами операционной системы. > > хотя обычно тюнинг nginx и операционной системы, чтобы данные с дисков > читались большими блоками по 1 мегабайту - помогает и этого достаточно. > > еще скрытые резервы для повышения производительности могут быть в том, > что дисковое хранилище собрано в виде RAID массива 5/6/10/... - в таком > случае сам RAID массив является узким местом и его лучше разобрать > на "отдельные" диски или RAID-1 массивы из N дисков. в этом случае, > если software raid / hardware raid не кривой - скорость random > чтения с RAID-1 массива из N дисков будет примерно в N раз выше. > > или же - добавить SSD к системе хранения файлов в том или ином виде > (Bcache,Flashcache,Btier,EnhanceIO, nginx+ngx_slowfs_cache, etc...) > туда уйдет самый "горячий" контент и вся система выдаст больше IOPS. > > кстати, странно что функциональности модуля ngx_slowfs_cache > нет в основной ветке nginx, - чтобы сделать что-то аналогичное > без ngx_slowfs_cache придется использовать "двойное проксирование". > хотя может быть overhead от этого не большой и это вполне приемлимо. > но настройка получается не тривиальной: http://habrahabr.ru/post/202290/ > > -- > Best regards, > Gena > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmm at csdoc.com Sat Nov 23 14:07:53 2013 From: gmm at csdoc.com (Gena Makhomed) Date: Sat, 23 Nov 2013 16:07:53 +0200 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: References: <52906F71.9070705@amhost.net> <52909A66.30701@csdoc.com> Message-ID: <5290B6B9.3040107@csdoc.com> On 23.11.2013 14:32, Gelun, Artem wrote: > ... чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты > времени по непонятным причинам. причины могут быть разные. например, 1 - машина уходит в swap, и на самом деле тогда "чтение из tmpfs" будет чтением с диска. 2 - если из tmpfs файлы считывает тот же nginx, который отдает и файлы с диска. на дисковых операциях worker`ы nginx блокируюся, поэтому и чтение из tmpfs тоже происходит с задержками и медленно. 3 - используется nginx с "левыми" модулями, которые и дают такие глюки. 4 - используется древняя версия nginx из EPEL, а не Pre-Built Packages для CentOS/RHEL из официального сайта http://nginx.org/en/download.html подробнее - см. пост http://habrahabr.ru/post/195742/#comment_6797402 5 - и т.д. и т.п. On 23.11.2013 13:11, Gelun, Artem wrote: >> Для HDD nginx и ОС нужно настраивать так чтобы nginx читал с диска >> как можно бОльшими в пределах разумного кусками, 512к-2048к например. в некоторых случаях nginx сможет отдавать файлы быстрее, если выключить sendfile и правильно настроить output_buffers (есть в архиве рассылки) еще для отдачи больших файлов может помочь включение режима aio, вот первая статья на эту тему: http://habrahabr.ru/post/68480/ чтобы уменьшить количество операций ввода/вывода - имеет смысл для access_log включить buffer, например, размером в 1 мегабайт, или вообще отключить access_log - "access_log off;". все диски и разделы имеет смысл монтировать с опцией noatime. в некоторых случаях может помочь использование XFS вместо ext4. > Насколько я понимаю, sendfile (который включен и должен отрабатывать) > не блокирует worker'а. блокирует. чтобы worker не блокировался - надо включать aio, http://nginx.org/en/docs/http/ngx_http_core_module.html#aio > Единственное подозрение - воркеры блокируются при > открытии файла с "перегруженного" HDD. Но: > 1) как это проверить? с помощью http://nginx.org/ru/docs/debugging_log.html указав debug_connection только для своего IP-адреса. > 3) Если я правильно понимаю, при размере файла < размера буфера сокета и > если sendfile_max_chunk не установлен, то sendfile должен вызываться > один раз. Соответсвенно, если затык в nginx, то он будет перед началом > отдачи данных. о том, что происходит когда включен sendfile и не установлен параметр sendfile_max_chunk - написано в документации к nginx. если выставить очень большой буфер сокета, - при 700-1000 rps не знаю как поведет себя операционная система в такой ситуации. особенно, когда кто-то захочет устроить Slowloris атаку против сервера. или она сама собой будет, если много медленных клиентов. уязвимость к Slowloris может быть и в том случае, если поставить "output_buffers 1 512k;", потому что никакой искуственный интеллект в nginx пока что не встроен и он не сможет распознать эту атаку и автоматически сбросить размер буферов для медленных клиентов. например, "output_buffers auto;" или "output_buffers adaptive;" но если не поставить "output_buffers 1 512k;" - тогда будет много iops для чтения файла с диска мелкими фрагментами и сервер тоже будет не доступен клиентам, как и в случае DDoS-атаки Slowloris. вот советы по тюнингу nginx в аналогичной ситуации: http://mailman.nginx.org/pipermail/nginx/2012-May/033761.html эти вопросы про оптимальную настройку nginx для отдачи файлов уже давно FAQ, но на странице http://nginx.org/en/docs/faq.html рекомендаций по настройке nginx для отдачи статики почему-то нет. P.S. кстати, стили на странице http://nginx.org/en/docs/faq.html используются ужасные, все элементы списка сливаются между собой, если между list items сделать больше интервал - читабельность вырастет. да и подчеркивания в тексте имееют смысл только тогда, когда это редкие слова или фразы являются гиперссылками. если весь текст подчеркнут - читать его очень трудно и неудобно. на сайте http://nginx.org/ не нашел информации куда писать с предложениями по улучшению доки, поэтому пишу в список рассылки - вдруг кто-то увидит и исправит эти глюки/проблемы? -- Best regards, Gena From a at gelun.ru Sat Nov 23 14:54:38 2013 From: a at gelun.ru (Gelun, Artem) Date: Sat, 23 Nov 2013 18:54:38 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <5290B6B9.3040107@csdoc.com> References: <52906F71.9070705@amhost.net> <52909A66.30701@csdoc.com> <5290B6B9.3040107@csdoc.com> Message-ID: В общем, рискнул на стектрейс и странную вещь обнаружил: 28986 open("/cache/d/3a/85c878925f816fdeee7127df6aa363ad", O_RDONLY|O_NONBLOCK) = 21 <0.000022> 28986 fstat(21, {st_mode=S_IFREG|0600, st_size=2175620, ...}) = 0 <0.000011> .... 28986 setsockopt(17, SOL_TCP, TCP_CORK, [1], 4) = 0 <0.000011> 28986 writev(17, [{"HTTP/1.1 200 OK\r\nServer: nginx\r\n"..., 155}], 1) = 155 <0.000014> *28986 sendfile(17, 21, [272], 2175348 * *28986 <... sendfile resumed> ) = 2175348 <8.692121>* 28986 --- SIGALRM (Alarm clock) @ 0 (0) --- 28986 rt_sigreturn(0xe) = 2175348 <0.000015> 28986 shutdown(17, 1 /* send */) = 0 <0.000031> 28986 recvfrom(17, "", 4096, 0, NULL, NULL) = 0 <0.000019> 28986 getsockname(17, {sa_family=AF_INET, sin_port=htons(8802), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 <0.000010> 28986 write(5, "127.0.0.1 [-] [89190498993976151"..., 240) = 240 <0.000035> 28986 close(21) = 0 <0.000012> До этого момента я убеждённо считал, что если файл открыт как O_NONBLOCK, то sendfile будет неблокирующим и при недостатке данных вернёт EAGAIN. Я ошибаюсь? или откуда может появиться время его выполнения в почти 8.7 секунды???.... 23 ноября 2013 г., 18:07 пользователь Gena Makhomed написал: > On 23.11.2013 14:32, Gelun, Artem wrote: > > ... чтение из tmpfs (считай, RAM) "застевает" в произвольные моменты >> времени по непонятным причинам. >> > > причины могут быть разные. например, 1 - машина уходит в swap, > и на самом деле тогда "чтение из tmpfs" будет чтением с диска. > 2 - если из tmpfs файлы считывает тот же nginx, который отдает > и файлы с диска. на дисковых операциях worker`ы nginx блокируюся, > поэтому и чтение из tmpfs тоже происходит с задержками и медленно. > 3 - используется nginx с "левыми" модулями, которые и дают такие глюки. > 4 - используется древняя версия nginx из EPEL, а не Pre-Built Packages для > CentOS/RHEL из официального сайта http://nginx.org/en/download.html > подробнее - см. пост http://habrahabr.ru/post/195742/#comment_6797402 > 5 - и т.д. и т.п. > > > On 23.11.2013 13:11, Gelun, Artem wrote: > > >> Для HDD nginx и ОС нужно настраивать так чтобы nginx читал с диска > >> как можно бОльшими в пределах разумного кусками, 512к-2048к например. > > в некоторых случаях nginx сможет отдавать файлы быстрее, если выключить > sendfile и правильно настроить output_buffers (есть в архиве рассылки) > > еще для отдачи больших файлов может помочь включение режима aio, > вот первая статья на эту тему: http://habrahabr.ru/post/68480/ > > чтобы уменьшить количество операций ввода/вывода - имеет смысл > для access_log включить buffer, например, размером в 1 мегабайт, > или вообще отключить access_log - "access_log off;". > > все диски и разделы имеет смысл монтировать с опцией noatime. > в некоторых случаях может помочь использование XFS вместо ext4. > > > > Насколько я понимаю, sendfile (который включен и должен отрабатывать) > > не блокирует worker'а. > > блокирует. чтобы worker не блокировался - надо включать aio, > http://nginx.org/en/docs/http/ngx_http_core_module.html#aio > > > > Единственное подозрение - воркеры блокируются при > > открытии файла с "перегруженного" HDD. Но: > > 1) как это проверить? > > с помощью http://nginx.org/ru/docs/debugging_log.html > указав debug_connection только для своего IP-адреса. > > > > 3) Если я правильно понимаю, при размере файла < размера буфера сокета и > > если sendfile_max_chunk не установлен, то sendfile должен вызываться > > один раз. Соответсвенно, если затык в nginx, то он будет перед началом > > отдачи данных. > > о том, что происходит когда включен sendfile и не установлен > параметр sendfile_max_chunk - написано в документации к nginx. > > если выставить очень большой буфер сокета, - при 700-1000 rps > не знаю как поведет себя операционная система в такой ситуации. > > особенно, когда кто-то захочет устроить Slowloris атаку против > сервера. или она сама собой будет, если много медленных клиентов. > > уязвимость к Slowloris может быть и в том случае, если поставить > "output_buffers 1 512k;", потому что никакой искуственный интеллект > в nginx пока что не встроен и он не сможет распознать эту атаку > и автоматически сбросить размер буферов для медленных клиентов. > например, "output_buffers auto;" или "output_buffers adaptive;" > > но если не поставить "output_buffers 1 512k;" - тогда будет много > iops для чтения файла с диска мелкими фрагментами и сервер тоже > будет не доступен клиентам, как и в случае DDoS-атаки Slowloris. > > вот советы по тюнингу nginx в аналогичной ситуации: > http://mailman.nginx.org/pipermail/nginx/2012-May/033761.html > > эти вопросы про оптимальную настройку nginx для отдачи файлов > уже давно FAQ, но на странице http://nginx.org/en/docs/faq.html > рекомендаций по настройке nginx для отдачи статики почему-то нет. > > P.S. > > кстати, стили на странице http://nginx.org/en/docs/faq.html > используются ужасные, все элементы списка сливаются между собой, > если между list items сделать больше интервал - читабельность вырастет. > да и подчеркивания в тексте имееют смысл только тогда, когда это редкие > слова или фразы являются гиперссылками. если весь текст подчеркнут - > читать его очень трудно и неудобно. на сайте http://nginx.org/ не нашел > информации куда писать с предложениями по улучшению доки, поэтому пишу > в список рассылки - вдруг кто-то увидит и исправит эти глюки/проблемы? > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vbart at nginx.com Sat Nov 23 16:43:26 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 23 Nov 2013 20:43:26 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: References: <52906F71.9070705@amhost.net> Message-ID: <201311232043.26788.vbart@nginx.com> On Saturday 23 November 2013 15:11:27 Gelun, Artem wrote: [..] > Насколько я понимаю, sendfile (который включен и должен отрабатывать) не > блокирует worker'а. На Linux блокирует если в памяти запрошенных данных нет. [..] > 3) Если я правильно понимаю, при размере файла < размера буфера сокета и > если sendfile_max_chunk не установлен, то sendfile должен вызываться один > раз. Нет, он будет зваться ровно столько раз, сколько понадобиться для отдачи всего файла. У вас nginx собран без сторонних модулей? -- Валентин Бартенев From vbart at nginx.com Sat Nov 23 16:50:54 2013 From: vbart at nginx.com (=?utf-8?b?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 23 Nov 2013 20:50:54 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: References: <5290B6B9.3040107@csdoc.com> Message-ID: <201311232050.54910.vbart@nginx.com> On Saturday 23 November 2013 18:54:38 Gelun, Artem wrote: [..] > До этого момента я убеждённо считал, что если файл открыт как O_NONBLOCK, > то sendfile будет неблокирующим и при недостатке данных вернёт EAGAIN. EAGAIN он вернет только когда заполнит буфер сокета. man sendfile EAGAIN Nonblocking I/O has been selected using O_NONBLOCK and the write would block. > Я ошибаюсь? или откуда может появиться время его выполнения в почти 8.7 > секунды???.... Ошибаетесь. sendfile() на Linux блокируется на чтении с диска, так же как и read(). -- Валентин Бартенев From vbart at nginx.com Sat Nov 23 16:54:27 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sat, 23 Nov 2013 20:54:27 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <5290B6B9.3040107@csdoc.com> References: <5290B6B9.3040107@csdoc.com> Message-ID: <201311232054.27843.vbart@nginx.com> On Saturday 23 November 2013 18:07:53 Gena Makhomed wrote: [..] > P.S. > > кстати, стили на странице http://nginx.org/en/docs/faq.html > используются ужасные, все элементы списка сливаются между собой, > если между list items сделать больше интервал - читабельность вырастет. > да и подчеркивания в тексте имееют смысл только тогда, когда это редкие > слова или фразы являются гиперссылками. если весь текст подчеркнут - > читать его очень трудно и неудобно. на сайте http://nginx.org/ не нашел > информации куда писать с предложениями по улучшению доки, поэтому пишу > в список рассылки - вдруг кто-то увидит и исправит эти глюки/проблемы? http://hg.nginx.org/nginx.org/ Патчи принимаются. -- Валентин Бартенев From a at gelun.ru Sun Nov 24 10:39:59 2013 From: a at gelun.ru (Gelun, Artem) Date: Sun, 24 Nov 2013 14:39:59 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <201311232050.54910.vbart@nginx.com> References: <5290B6B9.3040107@csdoc.com> <201311232050.54910.vbart@nginx.com> Message-ID: Валентин, спасибо. Видимо, я перепутал с BSD-шным sendfile... Комментарий "он будет зваться ровно столько раз, сколько понадобиться для отдачи всего файла" относится, судя по всему, именно к BSD? потому что на Linux просто блокируется вызов до получения полного файла и всё. Используем небольшой свой модуль, который из имени файла делает, по сути, range и отдаёт ответ с кодом 200. Внутри он вызывает ngx_http_output_filter, который занимается всем вводом-выводом, так что "в кишки" мы не лезем. Включать AIO - не вариант. Отсутствие RA снижает производительность дисков очень значительно (даже при выставлении больших буферов - видимо, за счёт RA RAID-контроллера, который тоже отключается) + отсутствие sendfile прибавляет почти десяткок процентов system time на и без того нагруженном сервере... Итого либо переходить на FreeBSD, либо писать что-то своё/переделывать существующее, что способно синхронно во много тредов отдавать файлы с sendfile вместо nginx (тот же апач не умеет отдавать на range ответ 200 + нужно корректно работать с кэшом на HDD, который тормозит не меньше) .... Всем спасибо, война закончена )) 23 ноября 2013 г., 20:50 пользователь Валентин Бартенев написал: > On Saturday 23 November 2013 18:54:38 Gelun, Artem wrote: > [..] >> До этого момента я убеждённо считал, что если файл открыт как O_NONBLOCK, >> то sendfile будет неблокирующим и при недостатке данных вернёт EAGAIN. > > EAGAIN он вернет только когда заполнит буфер сокета. > > man sendfile > > EAGAIN Nonblocking I/O has been selected using O_NONBLOCK and the write > would block. > > >> Я ошибаюсь? или откуда может появиться время его выполнения в почти 8.7 >> секунды???.... > > Ошибаетесь. > > sendfile() на Linux блокируется на чтении с диска, так же как и read(). > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart at nginx.com Sun Nov 24 15:26:39 2013 From: vbart at nginx.com (=?koi8-r?b?98HMxc7Uyc4g4sHS1MXOxdc=?=) Date: Sun, 24 Nov 2013 19:26:39 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: References: <201311232050.54910.vbart@nginx.com> Message-ID: <201311241926.39045.vbart@nginx.com> On Sunday 24 November 2013 14:39:59 Gelun, Artem wrote: > Валентин, спасибо. Видимо, я перепутал с BSD-шным sendfile... > > Комментарий "он будет зваться ровно столько раз, сколько понадобиться > для отдачи всего файла" относится, судя по всему, именно к BSD? потому > что на Linux просто блокируется вызов до получения полного файла и > всё. Нет. Как уже выше выяснили, он ещё EAGAIN возвращает. > > Используем небольшой свой модуль, который из имени файла делает, по > сути, range и отдаёт ответ с кодом 200. Внутри он вызывает > ngx_http_output_filter, который занимается всем вводом-выводом, так > что "в кишки" мы не лезем. Там много нюансов, чтобы сломать nginx не обязательно лезть "в кишки". > > Включать AIO - не вариант. Отсутствие RA снижает производительность > дисков очень значительно (даже при выставлении больших буферов - > видимо, за счёт RA RAID-контроллера, который тоже отключается) + > отсутствие sendfile прибавляет почти десяткок процентов system time на > и без того нагруженном сервере... Отсутствие RA? -- Валентин Бартенев From a at gelun.ru Sun Nov 24 20:59:22 2013 From: a at gelun.ru (Gelun, Artem) Date: Mon, 25 Nov 2013 00:59:22 +0400 Subject: =?UTF-8?B?UmU6INCX0LDRgtGL0LrQuCDQv9GA0Lgg0L7RgtC00LDRh9C1INGB0YLQsNGC0Lg=?= =?UTF-8?B?0LrQuA==?= In-Reply-To: <201311241926.39045.vbart@nginx.com> References: <201311232050.54910.vbart@nginx.com> <201311241926.39045.vbart@nginx.com> Message-ID: 24 ноября 2013 г., 19:26 пользователь Валентин Бартенев написал: > On Sunday 24 November 2013 14:39:59 Gelun, Artem wrote: > > Валентин, спасибо. Видимо, я перепутал с BSD-шным sendfile... > > > > Комментарий "он будет зваться ровно столько раз, сколько понадобиться > > для отдачи всего файла" относится, судя по всему, именно к BSD? потому > > что на Linux просто блокируется вызов до получения полного файла и > > всё. > > Нет. Как уже выше выяснили, он ещё EAGAIN возвращает. > Ну EAGAIN, вроде, остаётся только при недостаточности буфера сокета. А в моём первом вопросе было "при размере файла < размера буфера сокета", соответственно, данных должно быть меньше, чем буфер и EAGAIN возвращаться не должен. Или я опять что-то не так понял? )) > > > > Используем небольшой свой модуль, который из имени файла делает, по > > сути, range и отдаёт ответ с кодом 200. Внутри он вызывает > > ngx_http_output_filter, который занимается всем вводом-выводом, так > > что "в кишки" мы не лезем. > > Там много нюансов, чтобы сломать nginx не обязательно лезть "в кишки". > > > > > > Включать AIO - не вариант. Отсутствие RA снижает производительность > > дисков очень значительно (даже при выставлении больших буферов - > > видимо, за счёт RA RAID-контроллера, который тоже отключается) + > > отсутствие sendfile прибавляет почти десяткок процентов system time на > > и без того нагруженном сервере... > > Отсутствие RA? > > ReadAhead, который отключается при DIRECT_IO, который обязателен для AIO в linux. > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rommer at active.by Mon Nov 25 02:00:31 2013 From: rommer at active.by (=?UTF-8?B?0KDQvtC80LDQvSDQqNC40YjQvdC10LI=?=) Date: Mon, 25 Nov 2013 05:00:31 +0300 Subject: =?UTF-8?Q?X-Accel-Redirect_=D0=B8_uri_escape?= Message-ID: <5292AF3F.6060409@active.by> Hello, Обнаружил несколько странное поведение nginx при обработке X-Accel-Redirect от upstream: При появлении знака "?" в имени файла в заголовке, uri обрезается до этого знака, а все остальное складывается в аргументы. Попробовал этот знак заменить на %3F, все стало ещё интереснее - в uri заменяются на стороне nginx все символы "%" на "%25", в итоге выходит что-то вроде "%253F" при передаче на следующий upstream. Полагаю, если в имени файла встретится последовательность "\r\n", этот файл вообще нельзя будет отправить в nginx с помощью X-Accel-Redirect. В явном виде эта последовательность закончит uri в заголовке на себе, а остаток имени будет следующим зоголовком, а в виде %0D%0A будет превращена в %250D%250A. В первом случае файл "aaa\r\nRefresh: 0;url=login" отправит клиента по другому адресу, а во втором случае комбинацию никакой upstream не разберет. Вопрос как сейчас передавать в nginx с помощью X-Accel-Redirect файлы в имени которых есть спец-символы? Может стоит сделать отдельную опцию (что-нибудь в духе safe_redirect on/off) при включении которой nginx не будет дополнительно escape'ать uri в X-Accel-Redirect? --93FB2808C9.1385344859/rl01.atservers.net-- From mdounin at mdounin.ru Mon Nov 25 12:55:37 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 25 Nov 2013 16:55:37 +0400 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <5292AF3F.6060409@active.by> References: <5292AF3F.6060409@active.by> Message-ID: <20131125125537.GX41579@mdounin.ru> Hello! On Mon, Nov 25, 2013 at 05:00:31AM +0300, Роман Шишнев wrote: > Hello, > > Обнаружил несколько странное поведение nginx при обработке > X-Accel-Redirect от upstream: > > При появлении знака "?" в имени файла в заголовке, uri обрезается до > этого знака, а все остальное складывается в аргументы. Попробовал > этот знак заменить на %3F, все стало ещё интереснее - в uri заменяются > на стороне nginx все символы "%" на "%25", в итоге выходит что-то вроде > "%253F" при передаче на следующий upstream. > > Полагаю, если в имени файла встретится последовательность "\r\n", этот > файл вообще нельзя будет отправить в nginx с помощью X-Accel-Redirect. > В явном виде эта последовательность закончит uri в заголовке на себе, > а остаток имени будет следующим зоголовком, а в виде %0D%0A будет > превращена в %250D%250A. > > В первом случае файл "aaa\r\nRefresh: 0;url=login" отправит клиента > по другому адресу, а во втором случае комбинацию никакой upstream не > разберет. > > Вопрос как сейчас передавать в nginx с помощью X-Accel-Redirect > файлы в имени которых есть спец-символы? > > Может стоит сделать отдельную опцию (что-нибудь в духе > safe_redirect on/off) при включении которой nginx не будет > дополнительно escape'ать uri в X-Accel-Redirect? Сейчас nginx полагает, что в X-Accel-Redirect передаётся незакодированный URI. Есть мнение, что это неправильно (в частности потому, что файл с "?" в имени отправить нельзя), и надо изменить логику так, чтобы передавался закодированный URI. Где-то тут про это есть чуть больше подробностей, а также ссылки на предыдущие попытки решить проблему: http://trac.nginx.org/nginx/ticket/316 -- Maxim Dounin http://nginx.org/en/donation.html From rommer at active.by Mon Nov 25 16:38:08 2013 From: rommer at active.by (Rommer) Date: Mon, 25 Nov 2013 19:38:08 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <20131125125537.GX41579@mdounin.ru> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> Message-ID: <52937CF0.4070508@active.by> Hello, Насколько я вижу, все предыдущие попытки ни к чему конструктивному так и не привели. Поэтому предлагаю новую опцию safe_redirect on/off. Если установлена в "on" в http, server или location, откуда идет proxy_pass, путь в X-Accel-Redirect воспринимает как escaped uri. По дефолту стоит в off и поведение парсера не меняет. On 11/25/13 15:55, Maxim Dounin wrote: > Hello! > > On Mon, Nov 25, 2013 at 05:00:31AM +0300, Роман Шишнев wrote: > >> Hello, >> >> Обнаружил несколько странное поведение nginx при обработке >> X-Accel-Redirect от upstream: >> >> При появлении знака "?" в имени файла в заголовке, uri обрезается до >> этого знака, а все остальное складывается в аргументы. Попробовал >> этот знак заменить на %3F, все стало ещё интереснее - в uri заменяются >> на стороне nginx все символы "%" на "%25", в итоге выходит что-то вроде >> "%253F" при передаче на следующий upstream. >> >> Полагаю, если в имени файла встретится последовательность "\r\n", этот >> файл вообще нельзя будет отправить в nginx с помощью X-Accel-Redirect. >> В явном виде эта последовательность закончит uri в заголовке на себе, >> а остаток имени будет следующим зоголовком, а в виде %0D%0A будет >> превращена в %250D%250A. >> >> В первом случае файл "aaa\r\nRefresh: 0;url=login" отправит клиента >> по другому адресу, а во втором случае комбинацию никакой upstream не >> разберет. >> >> Вопрос как сейчас передавать в nginx с помощью X-Accel-Redirect >> файлы в имени которых есть спец-символы? >> >> Может стоит сделать отдельную опцию (что-нибудь в духе >> safe_redirect on/off) при включении которой nginx не будет >> дополнительно escape'ать uri в X-Accel-Redirect? > > Сейчас nginx полагает, что в X-Accel-Redirect передаётся > незакодированный URI. Есть мнение, что это неправильно (в > частности потому, что файл с "?" в имени отправить нельзя), и > надо изменить логику так, чтобы передавался закодированный URI. > > Где-то тут про это есть чуть больше подробностей, а также ссылки > на предыдущие попытки решить проблему: > > http://trac.nginx.org/nginx/ticket/316 > -------------- next part -------------- A non-text attachment was scrubbed... Name: nginx-1.4.4-safe_redirect.patch Type: text/x-patch Size: 3809 bytes Desc: not available URL: From mdounin at mdounin.ru Mon Nov 25 17:21:24 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 25 Nov 2013 21:21:24 +0400 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <52937CF0.4070508@active.by> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> Message-ID: <20131125172124.GF41579@mdounin.ru> Hello! On Mon, Nov 25, 2013 at 07:38:08PM +0300, Rommer wrote: > Hello, > > Насколько я вижу, все предыдущие попытки ни к чему конструктивному > так и не привели. > > Поэтому предлагаю новую опцию safe_redirect on/off. > Если установлена в "on" в http, server или location, откуда > идет proxy_pass, путь в X-Accel-Redirect воспринимает > как escaped uri. По дефолту стоит в off и поведение > парсера не меняет. Я не возражаю против того, чтобы поведение парсера таки поменять без всяких опций (более того, я против того, чтобы вводить подобные опции - проще один раз сделать правильно). Проблема в том, что никто так и не сделал приличный патч, консистентно меняющий поведение парсера. [...] > diff -Nru a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c > --- a/src/http/ngx_http_core_module.c 2013-11-19 15:25:25.000000000 +0400 > +++ b/src/http/ngx_http_core_module.c 2013-11-25 18:49:09.253001176 +0400 > @@ -746,6 +746,13 @@ > offsetof(ngx_http_core_loc_conf_t, resolver_timeout), > NULL }, > > + { ngx_string("safe_redirect"), > + NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_FLAG, > + ngx_conf_set_flag_slot, > + NGX_HTTP_LOC_CONF_OFFSET, > + offsetof(ngx_http_core_loc_conf_t, safe_redirect), > + NULL }, Совершенно непонятно, зачем вы решили сделать опцию в ngx_http_core_module... [...] > --- a/src/http/ngx_http_upstream.c 2013-11-19 15:25:25.000000000 +0400 > +++ b/src/http/ngx_http_upstream.c 2013-11-25 20:19:44.019000094 +0400 > @@ -1893,14 +1893,18 @@ > static ngx_int_t > ngx_http_upstream_process_headers(ngx_http_request_t *r, ngx_http_upstream_t *u) > { > + u_char *dst, *src; > + size_t len; > ngx_str_t *uri, args; > ngx_uint_t i, flags; > ngx_list_part_t *part; > ngx_table_elt_t *h; > ngx_http_upstream_header_t *hh; > ngx_http_upstream_main_conf_t *umcf; > + ngx_http_core_loc_conf_t *clcf; > > umcf = ngx_http_get_module_main_conf(r, ngx_http_upstream_module); > + clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module); > > if (u->headers_in.x_accel_redirect > && !(u->conf->ignore_headers & NGX_HTTP_UPSTREAM_IGN_XA_REDIRECT)) > @@ -1938,9 +1942,27 @@ > ngx_str_null(&args); > flags = NGX_HTTP_LOG_UNSAFE; > > - if (ngx_http_parse_unsafe_uri(r, uri, &args, &flags) != NGX_OK) { > - ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND); > - return NGX_DONE; > + if (clcf->safe_redirect) { ...и при этом используете её только в upstream'е. > + > + dst = uri->data; > + src = uri->data; > + > + ngx_unescape_uri(&dst, &src, uri->len, NGX_UNESCAPE_URI); > + > + len = (uri->data + uri->len) - src; > + if (len) { > + dst = ngx_movemem(dst, src, len); > + } > + > + uri->len = dst - uri->data; > + > + } else { > + > + if (ngx_http_parse_unsafe_uri(r, uri, &args, &flags) != NGX_OK) { > + ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND); > + return NGX_DONE; > + } > + Так совсем неправильно: аргументы в "X-Accel-Redirect" обрабатываются только в том случае, если флаг clcf->safe_redirect не установлен. Не говоря уже про unsafe-проверки, которые не делаются. И даже если сделать как в SSI, то проблема "?" в пути не решается. -- Maxim Dounin http://nginx.org/en/donation.html From rommer at active.by Mon Nov 25 22:47:36 2013 From: rommer at active.by (=?KOI8-R?Q?=F2=CF=CD=C1=CE_=FB=C9=DB=CE=C5=D7?=) Date: Tue, 26 Nov 2013 01:47:36 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <20131125172124.GF41579@mdounin.ru> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> Message-ID: <5293D388.8070403@active.by> Hello, Тогда всё проще и вот так. P.S. зачем flags в ngx_http_parse_unsafe_uri() передается по ссылке? On 11/25/2013 08:21 PM, Maxim Dounin wrote: > Hello! > > On Mon, Nov 25, 2013 at 07:38:08PM +0300, Rommer wrote: > >> Hello, >> >> Насколько я вижу, все предыдущие попытки ни к чему конструктивному >> так и не привели. >> >> Поэтому предлагаю новую опцию safe_redirect on/off. >> Если установлена в "on" в http, server или location, откуда >> идет proxy_pass, путь в X-Accel-Redirect воспринимает >> как escaped uri. По дефолту стоит в off и поведение >> парсера не меняет. > > Я не возражаю против того, чтобы поведение парсера таки поменять > без всяких опций (более того, я против того, чтобы вводить > подобные опции - проще один раз сделать правильно). > > Проблема в том, что никто так и не сделал приличный патч, > консистентно меняющий поведение парсера. > > [...] > >> diff -Nru a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c >> --- a/src/http/ngx_http_core_module.c 2013-11-19 15:25:25.000000000 +0400 >> +++ b/src/http/ngx_http_core_module.c 2013-11-25 18:49:09.253001176 +0400 >> @@ -746,6 +746,13 @@ >> offsetof(ngx_http_core_loc_conf_t, resolver_timeout), >> NULL }, >> >> + { ngx_string("safe_redirect"), >> + NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_FLAG, >> + ngx_conf_set_flag_slot, >> + NGX_HTTP_LOC_CONF_OFFSET, >> + offsetof(ngx_http_core_loc_conf_t, safe_redirect), >> + NULL }, > > Совершенно непонятно, зачем вы решили сделать опцию в > ngx_http_core_module... > > [...] > >> --- a/src/http/ngx_http_upstream.c 2013-11-19 15:25:25.000000000 +0400 >> +++ b/src/http/ngx_http_upstream.c 2013-11-25 20:19:44.019000094 +0400 >> @@ -1893,14 +1893,18 @@ >> static ngx_int_t >> ngx_http_upstream_process_headers(ngx_http_request_t *r, ngx_http_upstream_t *u) >> { >> + u_char *dst, *src; >> + size_t len; >> ngx_str_t *uri, args; >> ngx_uint_t i, flags; >> ngx_list_part_t *part; >> ngx_table_elt_t *h; >> ngx_http_upstream_header_t *hh; >> ngx_http_upstream_main_conf_t *umcf; >> + ngx_http_core_loc_conf_t *clcf; >> >> umcf = ngx_http_get_module_main_conf(r, ngx_http_upstream_module); >> + clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module); >> >> if (u->headers_in.x_accel_redirect >> && !(u->conf->ignore_headers & NGX_HTTP_UPSTREAM_IGN_XA_REDIRECT)) >> @@ -1938,9 +1942,27 @@ >> ngx_str_null(&args); >> flags = NGX_HTTP_LOG_UNSAFE; >> >> - if (ngx_http_parse_unsafe_uri(r, uri, &args, &flags) != NGX_OK) { >> - ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND); >> - return NGX_DONE; >> + if (clcf->safe_redirect) { > > ...и при этом используете её только в upstream'е. > >> + >> + dst = uri->data; >> + src = uri->data; >> + >> + ngx_unescape_uri(&dst, &src, uri->len, NGX_UNESCAPE_URI); >> + >> + len = (uri->data + uri->len) - src; >> + if (len) { >> + dst = ngx_movemem(dst, src, len); >> + } >> + >> + uri->len = dst - uri->data; >> + >> + } else { >> + >> + if (ngx_http_parse_unsafe_uri(r, uri, &args, &flags) != NGX_OK) { >> + ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND); >> + return NGX_DONE; >> + } >> + > > Так совсем неправильно: аргументы в "X-Accel-Redirect" > обрабатываются только в том случае, если флаг clcf->safe_redirect > не установлен. Не говоря уже про unsafe-проверки, которые не > делаются. > > И даже если сделать как в SSI, то проблема "?" в пути не решается. > -- С уважением, Роман Шишнёв, CTO | ActiveCloud | http://www.active.by Т +375 17 2 911 511 доб. 308 | rommer at active.by Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг -------------- next part -------------- diff -Nru a/src/http/ngx_http_parse.c c/src/http/ngx_http_parse.c --- a/src/http/ngx_http_parse.c 2013-11-19 15:25:25.000000000 +0400 +++ c/src/http/ngx_http_parse.c 2013-11-26 02:24:12.897000136 +0400 @@ -1799,7 +1799,7 @@ continue; } - if (ch == '?') { + if (ch == '?' && args != NULL) { args->len = len - 1; args->data = p; uri->len -= len; diff -Nru a/src/http/ngx_http_upstream.c c/src/http/ngx_http_upstream.c --- a/src/http/ngx_http_upstream.c 2013-11-19 15:25:25.000000000 +0400 +++ c/src/http/ngx_http_upstream.c 2013-11-26 02:30:36.354000390 +0400 @@ -1893,6 +1893,8 @@ static ngx_int_t ngx_http_upstream_process_headers(ngx_http_request_t *r, ngx_http_upstream_t *u) { + u_char *dst, *src; + size_t len; ngx_str_t *uri, args; ngx_uint_t i, flags; ngx_list_part_t *part; @@ -1943,6 +1945,23 @@ return NGX_DONE; } + dst = uri->data; + src = uri->data; + + ngx_unescape_uri(&dst, &src, uri->len, NGX_UNESCAPE_URI); + + len = (uri->data + uri->len) - src; + if (len) { + dst = ngx_movemem(dst, src, len); + } + + uri->len = dst - uri->data; + + if (ngx_http_parse_unsafe_uri(r, uri, NULL, &flags) != NGX_OK) { + ngx_http_finalize_request(r, NGX_HTTP_NOT_FOUND); + return NGX_DONE; + } + if (r->method != NGX_HTTP_HEAD) { r->method = NGX_HTTP_GET; } From mdounin at mdounin.ru Mon Nov 25 23:35:37 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 26 Nov 2013 03:35:37 +0400 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <5293D388.8070403@active.by> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> Message-ID: <20131125233536.GK41579@mdounin.ru> Hello! On Tue, Nov 26, 2013 at 01:47:36AM +0300, Роман Шишнев wrote: > Hello, > > Тогда всё проще и вот так. Совершенно точно нет. Проверить, разескейпить, потом ещё раз проверить - это совсем не тот подход, которым следует пользоваться. Не говоря уже о том, что ssi и dav это не лечит. Перечитайте ещё раз то, что уже было написано по данному вопросу. Тикет, всё-таки, не совсем бесполезен, там по ссылкам есть review предыдущих попыток. http://trac.nginx.org/nginx/ticket/316 > P.S. зачем flags в ngx_http_parse_unsafe_uri() > передается по ссылке? Исходно этот параметр использовался для возврата флагов, в частности - NGX_HTTP_ZERO_IN_URI: http://hg.nginx.org/nginx/diff/58475592100c/src/http/ngx_http_parse.c С тех пор флаг NGX_HTTP_ZERO_IN_URI упразднили, но интерфейс остался. -- Maxim Dounin http://nginx.org/en/donation.html From rommer at active.by Tue Nov 26 04:59:46 2013 From: rommer at active.by (=?KOI8-R?Q?=F2=CF=CD=C1=CE_=FB=C9=DB=CE=C5=D7?=) Date: Tue, 26 Nov 2013 07:59:46 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <20131125233536.GK41579@mdounin.ru> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> <20131125233536.GK41579@mdounin.ru> Message-ID: <52942AC2.7000202@active.by> Hello, Хотел обойтись малой кровью From rommer at active.by Tue Nov 26 04:59:46 2013 From: rommer at active.by (=?KOI8-R?Q?=F2=CF=CD=C1=CE_=FB=C9=DB=CE=C5=D7?=) Date: Tue, 26 Nov 2013 07:59:46 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <20131125233536.GK41579@mdounin.ru> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> <20131125233536.GK41579@mdounin.ru> Message-ID: <52942AC2.7000202@active.by> Hello, Хотел обойтись малой кровью=. Но раз ssi и dav туда-же, то вот мой следующий опус. Надеюсь, на этот раз в нужном направлении. Заодно закроется бага с редиректом "../blablabla" которая считалась safe. P.S. это едиственный coding style? http://wiki.nginx.org/CodingStyle On 11/26/2013 02:35 AM, Maxim Dounin wrote: > Hello! > > On Tue, Nov 26, 2013 at 01:47:36AM +0300, Роман Шишнев wrote: > >> Hello, >> >> Тогда всё проще и вот так. > > Совершенно точно нет. Проверить, разескейпить, потом ещё раз > проверить - это совсем не тот подход, которым следует > пользоваться. Не говоря уже о том, что ssi и dav это не лечит. > > Перечитайте ещё раз то, что уже было написано по данному вопросу. > Тикет, всё-таки, не совсем бесполезен, там по ссылкам есть review > предыдущих попыток. > > http://trac.nginx.org/nginx/ticket/316 > >> P.S. зачем flags в ngx_http_parse_unsafe_uri() >> передается по ссылке? > > Исходно этот параметр использовался для возврата флагов, в > частности - NGX_HTTP_ZERO_IN_URI: > > http://hg.nginx.org/nginx/diff/58475592100c/src/http/ngx_http_parse.c > > С тех пор флаг NGX_HTTP_ZERO_IN_URI упразднили, но интерфейс > остался. > -- С уважением, Роман Шишнёв, CTO | ActiveCloud | http://www.active.by Т +375 17 2 911 511 доб. 308 | rommer at active.by Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг -------------- next part -------------- diff -Nrup a/src/http/ngx_http_parse.c d/src/http/ngx_http_parse.c --- a/src/http/ngx_http_parse.c 2013-11-19 15:25:25.000000000 +0400 +++ d/src/http/ngx_http_parse.c 2013-11-26 08:43:58.611996498 +0400 @@ -1777,57 +1777,191 @@ ngx_int_t ngx_http_parse_unsafe_uri(ngx_http_request_t *r, ngx_str_t *uri, ngx_str_t *args, ngx_uint_t *flags) { - u_char ch, *p; - size_t len; + ngx_str_t original_uri; + u_char *d, *s, ch, c, decoded; + size_t len; + enum { + sw_usual = 0, + sw_quoted, + sw_quoted_second + } state; + s = uri->data; + d = uri->data; len = uri->len; - p = uri->data; - if (len == 0 || p[0] == '?') { + state = 0; + decoded = 0; + + if (len == 0 || s[0] == '?') { + if (*flags & NGX_HTTP_LOG_UNSAFE) { + original_uri.len = uri->len; + original_uri.data = uri->data; + } + goto unsafe; } - if (p[0] == '.' && len == 3 && p[1] == '.' && (ngx_path_separator(p[2]))) { - goto unsafe; + if (*flags & NGX_HTTP_LOG_UNSAFE) { + original_uri.len = uri->len; + original_uri.data = ngx_pstrdup(r->pool, uri); } - for ( /* void */ ; len; len--) { + while (len--) { - ch = *p++; + ch = *s++; - if (usual[ch >> 5] & (1 << (ch & 0x1f))) { - continue; - } + switch (state) { + case sw_usual: + if (usual[ch >> 5] & (1 << (ch & 0x1f))) { + *d++ = ch; + break; + } - if (ch == '?') { - args->len = len - 1; - args->data = p; - uri->len -= len; + if (ch == '\0') { + goto unsafe; + } - return NGX_OK; - } + if (ch == '%') { + state = sw_quoted; + break; + } - if (ch == '\0') { - goto unsafe; - } + if (ch == '?') { + goto args; + } - if (ngx_path_separator(ch) && len > 2) { + if (ngx_path_separator(ch)) { - /* detect "/../" */ + if (d - 2 == uri->data && + *(d - 2) == '.' && *(d - 1) == '.') { + goto unsafe; + } + + if (d - 2 > uri->data && + ngx_path_separator(*(d - 3)) && + *(d - 2) == '.' && *(d - 1) == '.') { + goto unsafe; + } + } + + *d++ = ch; + break; + + case sw_quoted: + if (ch >= '0' && ch <= '9') { + decoded = (u_char) (ch - '0'); + state = sw_quoted_second; + break; + } - if (p[0] == '.' && p[1] == '.' && ngx_path_separator(p[2])) { + c = (u_char) (ch | 0x20); + if (c >= 'a' && c <= 'f') { + decoded = (u_char) (c - 'a' + 10); + state = sw_quoted_second; + break; + } + + if (ch == '\0') { goto unsafe; } + + if (ch == '%') { + *d++ = '%'; + break; + } + + if (ch == '?') { + *d++ = '%'; + goto args; + } + + *d++ = '%'; *d++ = ch; + state = sw_usual; + break; + + case sw_quoted_second: + + state = sw_usual; + + if (ch >= '0' && ch <= '9') { + ch = (u_char) ((decoded << 4) + ch - '0'); + *d++ = ch; + break; + } + + c = (u_char) (ch | 0x20); + if (c >= 'a' && c <= 'f') { + ch = (u_char) ((decoded << 4) + c - 'a' + 10); + + if (ngx_path_separator(ch)) { + + if (d - 2 == uri->data && + *(d - 2) == '.' && *(d - 1) == '.') { + goto unsafe; + } + + if (d - 2 > uri->data && + ngx_path_separator(*(d - 3)) && + *(d - 2) == '.' && *(d - 1) == '.') { + goto unsafe; + } + } + + *d++ = ch; + break; + } + + if (ch == '\0') { + goto unsafe; + } + + if (ch == '%') { + *d++ = '%'; *d++ = *(s - 2); + state = sw_quoted; + break; + } + + if (ch == '?') { + *d++ = '%'; *d++ = *(s - 2); + goto args; + } + + *d++ = '%'; *d++ = *(s - 2); *d++ = ch; + break; } } + switch (state) { + case sw_usual: + break; + case sw_quoted: + *d++ = '%'; + break; + case sw_quoted_second: + *d++ = '%'; + *d++ = *(s - 1); + break; + } + + uri->len = d - uri->data; + + return NGX_OK; + +args: + + args->len = len; + args->data = s; + + uri->len = d - uri->data; + return NGX_OK; unsafe: if (*flags & NGX_HTTP_LOG_UNSAFE) { ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, - "unsafe URI \"%V\" was detected", uri); + "unsafe URI \"%V\" was detected", &original_uri); } return NGX_ERROR; From rommer at active.by Tue Nov 26 05:09:11 2013 From: rommer at active.by (=?KOI8-R?Q?=F2=CF=CD=C1=CE_=FB=C9=DB=CE=C5=D7?=) Date: Tue, 26 Nov 2013 08:09:11 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <20131125233536.GK41579@mdounin.ru> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> <20131125233536.GK41579@mdounin.ru> Message-ID: <52942CF7.2020208@active.by> Hello, Не влез патч в рассылку. Повторюсь. Хотел обойтись малой кровью Но раз ssi и dav туда-же, то вот мой следующий опус: http://pastebin.com/raw.php?i=CPBwq7xY Надеюсь, на этот раз в нужном направлении. Заодно закроется бага с редиректом "../blablabla" которая считалась safe. P.S. это едиственный coding style? http://wiki.nginx.org/CodingStyle On 11/26/2013 02:35 AM, Maxim Dounin wrote: > Hello! > > On Tue, Nov 26, 2013 at 01:47:36AM +0300, Роман Шишнев wrote: > >> Hello, >> >> Тогда всё проще и вот так. > > Совершенно точно нет. Проверить, разескейпить, потом ещё раз > проверить - это совсем не тот подход, которым следует > пользоваться. Не говоря уже о том, что ssi и dav это не лечит. > > Перечитайте ещё раз то, что уже было написано по данному вопросу. > Тикет, всё-таки, не совсем бесполезен, там по ссылкам есть review > предыдущих попыток. > > http://trac.nginx.org/nginx/ticket/316 > >> P.S. зачем flags в ngx_http_parse_unsafe_uri() >> передается по ссылке? > > Исходно этот параметр использовался для возврата флагов, в > частности - NGX_HTTP_ZERO_IN_URI: > > http://hg.nginx.org/nginx/diff/58475592100c/src/http/ngx_http_parse.c > > С тех пор флаг NGX_HTTP_ZERO_IN_URI упразднили, но интерфейс > остался. > -- С уважением, Роман Шишнёв, CTO | ActiveCloud | http://www.active.by Т +375 17 2 911 511 доб. 308 | rommer at active.by Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг From rommer at active.by Tue Nov 26 05:22:29 2013 From: rommer at active.by (=?KOI8-R?Q?=F2=CF=CD=C1=CE_=FB=C9=DB=CE=C5=D7?=) Date: Tue, 26 Nov 2013 08:22:29 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <52942CF7.2020208@active.by> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> <20131125233536.GK41579@mdounin.ru> <52942CF7.2020208@active.by> Message-ID: <52943015.2000507@active.by> Hello, Забыл проверить "%00", апдейт тут: http://pastebin.com/raw.php?i=cFsthQEi On 11/26/2013 08:09 AM, Роман Шишнев wrote: > Hello, > > Не влез патч в рассылку. Повторюсь. > > Хотел обойтись малой кровью Но раз ssi и dav туда-же, > то вот мой следующий опус: > http://pastebin.com/raw.php?i=CPBwq7xY > > Надеюсь, на этот раз в нужном направлении. > > Заодно закроется бага с редиректом "../blablabla" > которая считалась safe. > > P.S. это едиственный coding style? > http://wiki.nginx.org/CodingStyle > > On 11/26/2013 02:35 AM, Maxim Dounin wrote: >> Hello! >> >> On Tue, Nov 26, 2013 at 01:47:36AM +0300, Роман Шишнев wrote: >> >>> Hello, >>> >>> Тогда всё проще и вот так. >> >> Совершенно точно нет. Проверить, разескейпить, потом ещё раз >> проверить - это совсем не тот подход, которым следует >> пользоваться. Не говоря уже о том, что ssi и dav это не лечит. >> >> Перечитайте ещё раз то, что уже было написано по данному вопросу. >> Тикет, всё-таки, не совсем бесполезен, там по ссылкам есть review >> предыдущих попыток. >> >> http://trac.nginx.org/nginx/ticket/316 >> >>> P.S. зачем flags в ngx_http_parse_unsafe_uri() >>> передается по ссылке? >> >> Исходно этот параметр использовался для возврата флагов, в >> частности - NGX_HTTP_ZERO_IN_URI: >> >> http://hg.nginx.org/nginx/diff/58475592100c/src/http/ngx_http_parse.c >> >> С тех пор флаг NGX_HTTP_ZERO_IN_URI упразднили, но интерфейс >> остался. >> > -- С уважением, Роман Шишнёв, CTO | ActiveCloud | http://www.active.by Т +375 17 2 911 511 доб. 308 | rommer at active.by Облачные решения | Серверы и инфраструктура | IaaS | SaaS | Хостинг From denis at webmaster.spb.ru Tue Nov 26 11:58:04 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 26 Nov 2013 15:58:04 +0400 Subject: =?UTF-8?B?0LvQvtCz0LjQutCwINGA0LDQsdC+0YLRiyBIb3N0INC/0YDQuCDQv9GA0L7QutGB?= =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?= Message-ID: <52948CCC.8070705@webmaster.spb.ru> Добрый день. Не могу понять логику работы с Host. Есть приложение, которое надо проксировать на нестандартном порту (пример конфига) server { listen *:8080; server_name aaa.spb.ru; include conf.all/tunes-main.conf; location / { proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://192.168.2.32:8080; } } При обращении там идут редиректы, при этом Location возвращается без указания порта (8080) и поэтому ничего не работает. При этом установка proxy_set_header Host aaa.spb.ru:8080; после блока proxy_set_header также ничего не дает - этот блок вынесен в отдельный файл для всех сайтов. Но стоит убрать строку proxy_set_header Host $host; - и порт нормально появляется в редиректе. В чём логика? Host нельзя переопределить 2 строкой? или при этом уходит запрос с 2 хостами и система сама выбирает что больше нравится? или как? И как тогда правильнее задать в выносном блоке, можно ли как Host $host$port? Или просто не добавлять, а для секции с изменением порта - задавать Host уже в нужном location? И попутно мелкий вопросик: была ситуация наоборот, проксируем запрос внутрь с 80 порта на 8080, пока явно не прописали Host $host:80; - периодически порт 8080 проявлялся в адресной строке. Хотя на десятке других серверов такого не было, при том что секция одинаковая. From vadim.lazovskiy at gmail.com Tue Nov 26 12:08:17 2013 From: vadim.lazovskiy at gmail.com (Vadim Lazovskiy) Date: Tue, 26 Nov 2013 16:08:17 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCDRgNCw0LHQvtGC0YsgSG9zdCDQv9GA0Lgg0L/RgNC+?= =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lg=?= In-Reply-To: <52948CCC.8070705@webmaster.spb.ru> References: <52948CCC.8070705@webmaster.spb.ru> Message-ID: Здравствуйте. Host здесь ни при чем. Смотреть нужно в сторону proxy_redirect: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect 26 ноября 2013 г., 15:58 пользователь denis написал: > Добрый день. > > Не могу понять логику работы с Host. Есть приложение, которое надо > проксировать на нестандартном порту (пример конфига) > > server > { > listen *:8080; > > server_name aaa.spb.ru; > > include conf.all/tunes-main.conf; > > location / { > proxy_redirect off; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For > $proxy_add_x_forwarded_for; > proxy_set_header Host $host; > > proxy_pass http://192.168.2.32:8080; > } > } > > При обращении там идут редиректы, при этом Location возвращается без > указания порта (8080) и поэтому ничего не работает. > При этом установка > proxy_set_header Host aaa.spb.ru:8080; > после блока proxy_set_header также ничего не дает - этот блок вынесен в > отдельный файл для всех сайтов. > > Но стоит убрать строку proxy_set_header Host $host; - и порт нормально > появляется в редиректе. В чём логика? Host нельзя переопределить 2 строкой? > или при этом уходит запрос с 2 хостами и система сама выбирает что больше > нравится? или как? И как тогда правильнее задать в выносном блоке, можно ли > как Host $host$port? Или просто не добавлять, а для секции с изменением > порта - задавать Host уже в нужном location? > > И попутно мелкий вопросик: была ситуация наоборот, проксируем запрос > внутрь с 80 порта на 8080, пока явно не прописали Host $host:80; - > периодически порт 8080 проявлялся в адресной строке. Хотя на десятке других > серверов такого не было, при том что секция одинаковая. > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best Regards, Vadim Lazovskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at webmaster.spb.ru Tue Nov 26 12:21:48 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 26 Nov 2013 16:21:48 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCDRgNCw0LHQvtGC0YsgSG9zdCDQv9GA0Lgg0L/RgNC+?= =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lg=?= In-Reply-To: References: <52948CCC.8070705@webmaster.spb.ru> Message-ID: <5294925C.4010106@webmaster.spb.ru> 26.11.2013 16:08, Vadim Lazovskiy пишет: > Здравствуйте. > > Host здесь ни при чем. > Смотреть нужно в сторону proxy_redirect: > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect > небольное уточнение: если оставить 1 Host, где выставляются и хост и порт - работает нормально. Без указания proxy_redirect по умолчанию как раз default, но и в таком варианте не работало. И еще момент: нужно, чтобы строка была универсальной, чтобы не править адреса и порты в сотне конфигов если что, а поменять в 1 общем описании и всё. Надо попробовать поиграться с $server_port можно описать как-нибудь универсально, чтобы брался порт из запроса или listen и автоматом ставилось где надо? From denis at webmaster.spb.ru Tue Nov 26 13:28:18 2013 From: denis at webmaster.spb.ru (denis) Date: Tue, 26 Nov 2013 17:28:18 +0400 Subject: =?UTF-8?B?UmU6INC70L7Qs9C40LrQsCDRgNCw0LHQvtGC0YsgSG9zdCDQv9GA0Lgg0L/RgNC+?= =?UTF-8?B?0LrRgdC40YDQvtCy0LDQvdC40Lg=?= In-Reply-To: References: <52948CCC.8070705@webmaster.spb.ru> Message-ID: <5294A1F2.3020601@webmaster.spb.ru> 26.11.2013 16:08, Vadim Lazovskiy пишет: > Здравствуйте. > > Host здесь ни при чем. > Смотреть нужно в сторону proxy_redirect: > http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect > удалось таки нарисовать схему работы с proxy_redirect: 1) делаем запрос, где будет некорректный порт. Учитывая, что в proxy_pass может быть localhost, айпи-адрес, имя хоста - надо через curl -I получить Location. Ситуация осложняется тем, что может быть выставлен Host, и он тут тоже будет иметь значение. 2) пишем proxy_redirect http://(тут то, что получили в location)/ http://aaa.spb.ru:8080/; версия default очень сильно ограничена в применении, потому что она по сути заменяет строку из proxy_pass (с учетом возможно выставленного Host) на /, НЕ вписывая корректный порт. Имеет ограниченную применимость при обращении на внутренние нестандартные порты при необходимости получения Location на 80 порт, но вообще никак не работает, когда снаружи тоже нестандартный порт. В общем, решение через явно заданный Host мне видится значительно более логичным и читаемым, без этих двойных аргументов. Было бы проще, если proxy_redirect в версии с 1 аргументом ставил по умолчанию 1 аргумент на базе proxy_pass+Host, давая менять только второй, это улучшило бы читаемость, но еще снизилось понимание теми кто "не шарит". Не убирая версию с 2 аргументами, которую как раз применять надо для замены путей, что в доке выше показано хорошо. А подмена хоста там явно побочная фича. Попутно был проверен 3 метод, и он также работает, легко читаем и понимаем proxy_redirect off; proxy_set_header Host $host:$server_port; From lists at zadevalov.com Tue Nov 26 13:54:48 2013 From: lists at zadevalov.com (Eugeny Zadevalov) Date: Tue, 26 Nov 2013 15:54:48 +0200 Subject: =?UTF-8?B?0LLQvtC/0YDQvtGBINC/0L4gZmFzdGNnaV9zdG9yZQ==?= Message-ID: <5294A828.2070306@zadevalov.com> Здравствуйте, Есть конфигурация один в один как в примере http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_store Из документации не ясно, можно ли заставить nginx не сохранять ответ бекенда в файл в каких то случаях? Допустим, если бекенд возвращает заголовок какой-то, или если статус ответа скажем 404 или ещё как нибудь? Спасибо! -- Eugeny Zadevalov From mdounin at mdounin.ru Tue Nov 26 15:56:03 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 26 Nov 2013 19:56:03 +0400 Subject: =?UTF-8?B?UmU6INCy0L7Qv9GA0L7RgSDQv9C+IGZhc3RjZ2lfc3RvcmU=?= In-Reply-To: <5294A828.2070306@zadevalov.com> References: <5294A828.2070306@zadevalov.com> Message-ID: <20131126155603.GF93176@mdounin.ru> Hello! On Tue, Nov 26, 2013 at 03:54:48PM +0200, Eugeny Zadevalov wrote: > Здравствуйте, > > Есть конфигурация один в один как в примере http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_store > > Из документации не ясно, можно ли заставить nginx не сохранять ответ > бекенда в файл в каких то случаях? > > Допустим, если бекенд возвращает заголовок какой-то, или если статус > ответа скажем 404 или ещё как нибудь? Строго говоря - штатного способа нет. Если сохранение ответов включено, то ответы всегда сохраняются. Хак - вернуть "X-Accel-Buffering: no", при небуферизированном проксировании ответы не сохраняются. Для fastcgi это будет работать в nginx 1.5.6+ (в более ранних версиях отсутствует возможность небуферизированной работы с fastcgi-бекендами, см. http://nginx.org/r/fastcgi_buffering). -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Nov 27 02:07:51 2013 From: nginx-forum at nginx.us (S.A.N) Date: Tue, 26 Nov 2013 21:07:51 -0500 Subject: Cache Revalidate Message-ID: <80dda174ed526b8aeb1b13342739b5f1.NginxMailingListRussian@forum.nginx.org> Есть досадные мелочи, которые хотелось бы исправить, при включении fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда отправляется на сервер, даже если кеша нет, бекенду будет отправлен параметр с пустым значением. По стандартам HTTP при отсутствии кеша, клиент не должен отправлять заголовок If-Modified-Since. Более правильно если Nginx так же как и браузеры, при отсутствии кеша не будет передавать в бекенд пустой хедер If-Modified-Since, т.е нет кеша нет хедера, сейчас приходится в конфиге писать fastcgi_param HTTP_IF_MODIFIED_SINCE $upstream_cache_last_modified if_not_empty; чтобы пустой хедер не приходил, как этого требует стандарт. Настроить subsecond ревалидацию в Nginx по стандартам HTTP тоже невозможно. Если бекенд отдает заголовок Cache-Control: max-age=0 и/или Expires: -1 Nginx воспринимает их как указания не кешировать ответ, но по стандартам эти заголовки не запрещают кешировать они указывают клиенту что ответ сервера можно кешировать, но он сразу же устаревает и следущий запрос должен пройти ревалидацию, т.е клиент должен каждый запрос отправлять с хедерем If-Modified-Since. Мы нашли способ, как заставить Nginx кешировать такие ответы, отправить ему хедер X-Accel-Expires: @$time-1 Тогда Nginx ведет себя правильно, т.е. так же как браузеры, которым достаточно отправить Cache-Control: max-age=0 Если, есть более красивое решения вместо X-Accel-Expires: @$time-1, хотелось бы его узнать. Во всем остальном ревалидация работает отлично, ждем с нетерпением реализацию If-None-Match :) С наличием ETag, будет все очень классно и правильно! Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,244991#msg-244991 From mdounin at mdounin.ru Wed Nov 27 14:06:41 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 Nov 2013 18:06:41 +0400 Subject: Cache Revalidate In-Reply-To: <80dda174ed526b8aeb1b13342739b5f1.NginxMailingListRussian@forum.nginx.org> References: <80dda174ed526b8aeb1b13342739b5f1.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131127140641.GK93176@mdounin.ru> Hello! On Tue, Nov 26, 2013 at 09:07:51PM -0500, S.A.N wrote: > Есть досадные мелочи, которые хотелось бы исправить, при включении > fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда > отправляется на сервер, даже если кеша нет, бекенду будет отправлен > параметр с пустым значением. > > По стандартам HTTP при отсутствии кеша, клиент не должен отправлять > заголовок If-Modified-Since. > Более правильно если Nginx так же как и браузеры, при отсутствии кеша не > будет передавать в бекенд пустой хедер If-Modified-Since, т.е нет кеша нет > хедера, сейчас приходится в конфиге писать > fastcgi_param HTTP_IF_MODIFIED_SINCE $upstream_cache_last_modified > if_not_empty; > чтобы пустой хедер не приходил, как этого требует стандарт. Да, это имеет смысл поправить. В proxy-то всё нормально, а вот в fastcgi/scgi/uwsgi из-за необходимости местами посылать пустые параметры - теперь уходит пустое значение в HTTP_IF_MODIFIED_SINCE. Патч какой-то такой: # HG changeset patch # User Maxim Dounin # Date 1385558623 -14400 # Wed Nov 27 17:23:43 2013 +0400 # Node ID ca0cde10bf45b5a1d7c0574a1752dcde01b04061 # Parent 19afb15852d2b4c5354a24a2de25a33d5fa77364 Upstream: skip empty cache headers. Notably this fixes HTTP_IF_MODIFIED_SINCE which was always sent with cache enabled in fastcgi/scgi/uwsgi after 43ccaf8e8728. diff --git a/src/http/modules/ngx_http_fastcgi_module.c b/src/http/modules/ngx_http_fastcgi_module.c --- a/src/http/modules/ngx_http_fastcgi_module.c +++ b/src/http/modules/ngx_http_fastcgi_module.c @@ -2796,7 +2796,7 @@ ngx_http_fastcgi_merge_params(ngx_conf_t s->key = h->key; s->value = h->value; - s->skip_empty = 0; + s->skip_empty = 1; next: diff --git a/src/http/modules/ngx_http_scgi_module.c b/src/http/modules/ngx_http_scgi_module.c --- a/src/http/modules/ngx_http_scgi_module.c +++ b/src/http/modules/ngx_http_scgi_module.c @@ -1506,7 +1506,7 @@ ngx_http_scgi_merge_params(ngx_conf_t *c s->key = h->key; s->value = h->value; - s->skip_empty = 0; + s->skip_empty = 1; next: diff --git a/src/http/modules/ngx_http_uwsgi_module.c b/src/http/modules/ngx_http_uwsgi_module.c --- a/src/http/modules/ngx_http_uwsgi_module.c +++ b/src/http/modules/ngx_http_uwsgi_module.c @@ -1670,7 +1670,7 @@ ngx_http_uwsgi_merge_params(ngx_conf_t * s->key = h->key; s->value = h->value; - s->skip_empty = 0; + s->skip_empty = 1; next: > Настроить subsecond ревалидацию в Nginx по стандартам HTTP тоже невозможно. > Если бекенд отдает заголовок > Cache-Control: max-age=0 и/или Expires: -1 > Nginx воспринимает их как указания не кешировать ответ, но по стандартам эти > заголовки не запрещают кешировать они указывают клиенту что ответ сервера > можно кешировать, но он сразу же устаревает и следущий запрос должен пройти > ревалидацию, т.е клиент должен каждый запрос отправлять с хедерем > If-Modified-Since. > Мы нашли способ, как заставить Nginx кешировать такие ответы, отправить ему > хедер > X-Accel-Expires: @$time-1 > Тогда Nginx ведет себя правильно, т.е. так же как браузеры, которым > достаточно отправить Cache-Control: max-age=0 > Если, есть более красивое решения вместо X-Accel-Expires: @$time-1, хотелось > бы его узнать. А use case какой? С учётом характерных времён доступа по http - запрет кеширования даже на 1 секунду выглядит странно. Вообще я склонен думать, что тот факт, что X-Accel-Expires в таком виде работает - это скорее баг. Впрочем, можно его таким и оставить. -- Maxim Dounin http://nginx.org/en/donation.html From denis at webmaster.spb.ru Wed Nov 27 14:46:42 2013 From: denis at webmaster.spb.ru (denis) Date: Wed, 27 Nov 2013 18:46:42 +0400 Subject: Cache Revalidate In-Reply-To: <20131127140641.GK93176@mdounin.ru> References: <80dda174ed526b8aeb1b13342739b5f1.NginxMailingListRussian@forum.nginx.org> <20131127140641.GK93176@mdounin.ru> Message-ID: <529605D2.80405@webmaster.spb.ru> 27.11.2013 18:06, Maxim Dounin пишет: > Вообще я склонен думать, что тот факт, что X-Accel-Expires в таком > виде работает - это скорее баг. Впрочем, можно его таким и > оставить. ...это скорее баг. Поправим в следующей версии. )))) From nginx-forum at nginx.us Wed Nov 27 18:22:46 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 Nov 2013 13:22:46 -0500 Subject: Cache Revalidate In-Reply-To: <20131127140641.GK93176@mdounin.ru> References: <20131127140641.GK93176@mdounin.ru> Message-ID: <744a3742e447dfb06a02222c181cfe4c.NginxMailingListRussian@forum.nginx.org> > А use case какой? С учётом характерных времён доступа по http - > запрет кеширования даже на 1 секунду выглядит странно. Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить, это нормальная практика, вот цифры. Бекенд, генерит страницу за 0,8 сек, проведения ревалидации кеша на бекенде и ответ с кодом 304 занимает по времени 0.01 сек, разница как видите огромная. Если средний rps не меньше хотя бы 10, тогда есть смысл в кешировании таких страниц с постоянной ревалидацией. Если нет других способов заставить Nginx, кешировать как этого требует HTTP стандарты, тогда нужно оставить способ с X-Accel-Expires, даже если это баг :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245011#msg-245011 From mdounin at mdounin.ru Wed Nov 27 18:40:13 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 Nov 2013 22:40:13 +0400 Subject: Cache Revalidate In-Reply-To: <744a3742e447dfb06a02222c181cfe4c.NginxMailingListRussian@forum.nginx.org> References: <20131127140641.GK93176@mdounin.ru> <744a3742e447dfb06a02222c181cfe4c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131127184013.GR93176@mdounin.ru> Hello! On Wed, Nov 27, 2013 at 01:22:46PM -0500, S.A.N wrote: > > А use case какой? С учётом характерных времён доступа по http - > > запрет кеширования даже на 1 секунду выглядит странно. > > Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка > даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить, > это нормальная практика, вот цифры. > Бекенд, генерит страницу за 0,8 сек, проведения ревалидации кеша на бекенде > и ответ с кодом 304 занимает по времени 0.01 сек, разница как видите > огромная. > Если средний rps не меньше хотя бы 10, тогда есть смысл в кешировании таких > страниц с постоянной ревалидацией. Вот и я о том же - если страница генерится 0.8 секунд, то как может быть недопустимым кешировать её на 1 секунду? Откуда взялось требование о недопустимости? > Если нет других способов заставить Nginx, кешировать как этого требует HTTP > стандарты, тогда нужно оставить способ с X-Accel-Expires, даже если это баг > :) У вас какие-то странные представления о http-стандартах. Они вообще ничего не требуют кешировать. Кеш - дело сугубо добровольное. ;) -- Maxim Dounin http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Wed Nov 27 18:43:24 2013 From: a.vasilishin at kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Wed, 27 Nov 2013 20:43:24 +0200 Subject: =?UTF-8?B?b3V0cHV0X2J1ZmZlcnMg0L/QviDQtNC10YTQvtC70YLRgw==?= Message-ID: <52963D4C.3000607@kpi.ua> Здравствуйте! Ни в документации нив вики не нашел, по дефолту чему равно output_buffers, работает ли директива без aio и directio для линукс? From mdounin at mdounin.ru Wed Nov 27 19:05:14 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 Nov 2013 23:05:14 +0400 Subject: =?UTF-8?B?UmU6IG91dHB1dF9idWZmZXJzINC/0L4g0LTQtdGE0L7Qu9GC0YM=?= In-Reply-To: <52963D4C.3000607@kpi.ua> References: <52963D4C.3000607@kpi.ua> Message-ID: <20131127190514.GS93176@mdounin.ru> Hello! On Wed, Nov 27, 2013 at 08:43:24PM +0200, Андрей Василишин wrote: > Здравствуйте! > Ни в документации > нив вики не нашел, по дефолту чему равно output_buffers, работает ли > директива без aio и directio для линукс? Default - 1 буфер размером 32k. Директива работает всегда, когда нужно прочитать ответ с диска. -- Maxim Dounin http://nginx.org/en/donation.html From a.vasilishin at kpi.ua Wed Nov 27 19:19:50 2013 From: a.vasilishin at kpi.ua (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F7=C1=D3=C9=CC=C9=DB=C9=CE?=) Date: Wed, 27 Nov 2013 21:19:50 +0200 Subject: =?UTF-8?B?UmU6IG91dHB1dF9idWZmZXJzINC/0L4g0LTQtdGE0L7Qu9GC0YM=?= In-Reply-To: <20131127190514.GS93176@mdounin.ru> References: <52963D4C.3000607@kpi.ua> <20131127190514.GS93176@mdounin.ru> Message-ID: <529645D6.1010303@kpi.ua> 27.11.2013 21:05, Maxim Dounin пишет: > Hello! > > On Wed, Nov 27, 2013 at 08:43:24PM +0200, Андрей Василишин wrote: > >> Здравствуйте! >> Ни в документации >> нив вики не нашел, по дефолту чему равно output_buffers, работает ли >> директива без aio и directio для линукс? > > Default - 1 буфер размером 32k. Директива работает всегда, когда > нужно прочитать ответ с диска. > как я понял, с sendfile on; не работает. From mdounin at mdounin.ru Wed Nov 27 19:22:39 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 27 Nov 2013 23:22:39 +0400 Subject: =?UTF-8?B?UmU6IG91dHB1dF9idWZmZXJzINC/0L4g0LTQtdGE0L7Qu9GC0YM=?= In-Reply-To: <529645D6.1010303@kpi.ua> References: <52963D4C.3000607@kpi.ua> <20131127190514.GS93176@mdounin.ru> <529645D6.1010303@kpi.ua> Message-ID: <20131127192238.GT93176@mdounin.ru> Hello! On Wed, Nov 27, 2013 at 09:19:50PM +0200, Андрей Василишин wrote: > 27.11.2013 21:05, Maxim Dounin пишет: > >Hello! > > > >On Wed, Nov 27, 2013 at 08:43:24PM +0200, Андрей Василишин wrote: > > > >>Здравствуйте! > >>Ни в документации > >>нив вики не нашел, по дефолту чему равно output_buffers, работает ли > >>директива без aio и directio для линукс? > > > >Default - 1 буфер размером 32k. Директива работает всегда, когда > >нужно прочитать ответ с диска. > > > > как я понял, с sendfile on; не работает. Если использование sendfile возможно (разрешено с помощью директивы sendfile, и какая-либо обработка ответа не требуется) - то читать ответ с диска nginx'у не нужно, и соответственно буфера для этого не нужны. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Nov 27 19:30:01 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 Nov 2013 14:30:01 -0500 Subject: Cache Revalidate In-Reply-To: <20131127184013.GR93176@mdounin.ru> References: <20131127184013.GR93176@mdounin.ru> Message-ID: <294977899b1bdb1b90ab4287ea2bf0e0.NginxMailingListRussian@forum.nginx.org> > Они > вообще ничего не требуют кешировать. Кеш - дело сугубо > добровольное. ;) max-age=0 не требует кешировать ответ, смысл в том что он не запрещает кешировать ответ, в Nginx max-age=0 запрещает кеширования, в этом и есть не соответвия Nginx с спецификацией HTTP. В Nginx есть деректива fastcgi_cache on, и бекенд отдал хедер Cache-Control: max-age=0, который по спецификации HTTP не запрещает кешировать ответ, в этом случаи Nginx должен кешировать ответ бекенда, это логично и соответствует спецификации HTTP. Но сейчас чтобы этого добиться нужно эксплуатировать баг с X-Accel-Expires: @$time-1. Я понимаю что так сложилось исторически, раньше в Nginx не было ревалидации кеша, по этому max-age=0 мог означать только запрет на кеширования, но при наличии ревалидации, это уже не совсем правильно. Я не настаиваю чтобы вы это меняли хотя возможно как вариант сделать чтобы Nginx понимал хедер Cache-Control: must-revalidate, как указания кешировать но всегда ревалидировать. Это уже на ваше усмотрения. Главное чтобы была возможность добиться от Nginx постоянной ревалидации. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245018#msg-245018 From mdounin at mdounin.ru Wed Nov 27 20:22:55 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Nov 2013 00:22:55 +0400 Subject: Cache Revalidate In-Reply-To: <294977899b1bdb1b90ab4287ea2bf0e0.NginxMailingListRussian@forum.nginx.org> References: <20131127184013.GR93176@mdounin.ru> <294977899b1bdb1b90ab4287ea2bf0e0.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131127202255.GU93176@mdounin.ru> Hello! On Wed, Nov 27, 2013 at 02:30:01PM -0500, S.A.N wrote: > > Они > > вообще ничего не требуют кешировать. Кеш - дело сугубо > > добровольное. ;) > > max-age=0 не требует кешировать ответ, смысл в том что он не запрещает > кешировать ответ, в Nginx max-age=0 запрещает кеширования, в этом и есть не > соответвия Nginx с спецификацией HTTP. Повторюсь: несоответствия тут нет, кеш - дело сугубо добровольное. В подавляющем большинстве случаев max-age=0 означает, что кешировать ответ смысла нет, и nginx не тратит лишних ресурсов на то, чтобы этим заниматься. Жаль, что вы с таким упорством отказываетесь рассказать про ваш use case и о происхождении требования о недопустимости кеширования даже на 1 секунду. Возможно, это позволило бы пересмотреть существующее поведение при max-age=0, благо в Cache-Control есть и другие способы запрета кеширования. -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Wed Nov 27 21:21:37 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 Nov 2013 16:21:37 -0500 Subject: Cache Revalidate In-Reply-To: <20131127202255.GU93176@mdounin.ru> References: <20131127202255.GU93176@mdounin.ru> Message-ID: <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> > use case и о происхождении требования о недопустимости кеширования > даже на 1 секунду. Возможно, это позволило бы пересмотреть > существующее поведение при max-age=0, благо в Cache-Control есть и > другие способы запрета кеширования. use case продиктован нашей бизнес логикой, мы кешируем все даже страницы для залогиненых пользователей (персонал данные подтягиваются через ajax с использованием клиентского кэширования браузера), в этом есть смысл, цифры я уже писал, разница скорости в генерации страницы и в ревалидации отличается в десятки раз, в пользу ревалидации. Есть сайт с хорошей посещаемостью, залогиненые пользователи имеют возможность общатся, создавать свой контент, редактировать, удалять, есть так же платные сервисы. Наши клиенты не хотят и не должны ждать, даже если это одна секунда, ну например, клиент написал комментарий на сайте, POST ушел на сервер, если у нас кеширования на 1 секунду, мы клиенту не можем сразуже показать новую страницу, должны сделать задержку на 1 сек потом обновить его страницу или как на Хабре все комментарии видны с задержкой и люди это терпят. Конечно мы тоже можем так сделать, но зачем, если скорость ревалидации нам позволяет убрать необходимость в задержках и клиент будет доволен и работать все будет стабильно, главное это сделать совсем не сложно. Сейчас мы это делаем на уровне кеше браузера, с применением ETag, но если Nginx сделает возможность в постоянной ревалидации по ETag, тогда этот алгоритм кеширования который проверен и отлично работает на клиенском кеше браузера мы сможем перенести на кеш Nginx, что во многом увеличит повторное использования кеша, особенно для незалогиненых юзеров. Нам не интересно делать задержки в кеше, представте если бы Facebook делал задержки в отображении, даже если бы на этом форуме были задержки в отображении написанных постов, все бы конечно смерились но это совсем не круто. Есть другой вариант обычно так и делают, не кешируют страницы которые критичны к задержкам и часто обновляются, но это тоже не круто, такие запросы будут нагружать бекенд, время отклика будет падать, очередь запросов к FastCGI будет расти, так до таймаутов осталось не долго. В общем, мы знаем как можно обойтись без постоянной ревалидации, но так же мы знаем как все будет круто, если реализовать постоянную ревалидацию. Почему бы и нет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245024#msg-245024 From nginx-forum at nginx.us Wed Nov 27 21:47:37 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 Nov 2013 16:47:37 -0500 Subject: Cache Revalidate In-Reply-To: <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> References: <20131127202255.GU93176@mdounin.ru> <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> Message-ID: Уточнения, там где контент совсем статичный мы кешируем его на долго без ревалидации. Постоянная ревалидация нам нужна только на динамичном контенте, все написанное выше имеет отношения только к динамичному контенту. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245025#msg-245025 From alexander.moskalenko at gmail.com Wed Nov 27 21:48:29 2013 From: alexander.moskalenko at gmail.com (Alexander Moskalenko) Date: Wed, 27 Nov 2013 23:48:29 +0200 Subject: Cache Revalidate In-Reply-To: <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> References: <20131127202255.GU93176@mdounin.ru> <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> Message-ID: А что вам мешает организовать кеш в мемкеше или другом подобном хранилище? Мы у себя так сделали, кеш (на nginx) выключили вообще за ненадобностью. 2013/11/27 S.A.N > > use case и о происхождении требования о недопустимости кеширования > > даже на 1 секунду. Возможно, это позволило бы пересмотреть > > существующее поведение при max-age=0, благо в Cache-Control есть и > > другие способы запрета кеширования. > > use case продиктован нашей бизнес логикой, мы кешируем все даже страницы > для > залогиненых пользователей (персонал данные подтягиваются через ajax с > использованием клиентского кэширования браузера), в этом есть смысл, цифры > я > уже писал, разница скорости в генерации страницы и в ревалидации отличается > в десятки раз, в пользу ревалидации. > > Есть сайт с хорошей посещаемостью, залогиненые пользователи имеют > возможность общатся, создавать свой контент, редактировать, удалять, есть > так же платные сервисы. > > Наши клиенты не хотят и не должны ждать, даже если это одна секунда, ну > например, клиент написал комментарий на сайте, POST ушел на сервер, если у > нас кеширования на 1 секунду, мы клиенту не можем сразуже показать новую > страницу, должны сделать задержку на 1 сек потом обновить его страницу или > как на Хабре все комментарии видны с задержкой и люди это терпят. > > Конечно мы тоже можем так сделать, но зачем, если скорость ревалидации нам > позволяет убрать необходимость в задержках и клиент будет доволен и > работать все будет стабильно, главное это сделать совсем не сложно. > > Сейчас мы это делаем на уровне кеше браузера, с применением ETag, но если > Nginx сделает возможность в постоянной ревалидации по ETag, тогда этот > алгоритм кеширования который проверен и отлично работает на клиенском кеше > браузера мы сможем перенести на кеш Nginx, что во многом увеличит повторное > использования кеша, особенно для незалогиненых юзеров. > > Нам не интересно делать задержки в кеше, представте если бы Facebook делал > задержки в отображении, даже если бы на этом форуме были задержки в > отображении написанных постов, все бы конечно смерились но это совсем не > круто. > > Есть другой вариант обычно так и делают, не кешируют страницы которые > критичны к задержкам и часто обновляются, но это тоже не круто, такие > запросы будут нагружать бекенд, время отклика будет падать, очередь > запросов > к FastCGI будет расти, так до таймаутов осталось не долго. > > В общем, мы знаем как можно обойтись без постоянной ревалидации, но так же > мы знаем как все будет круто, если реализовать постоянную ревалидацию. > > Почему бы и нет? > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244991,245024#msg-245024 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Wed Nov 27 22:02:06 2013 From: nginx-forum at nginx.us (S.A.N) Date: Wed, 27 Nov 2013 17:02:06 -0500 Subject: Cache Revalidate In-Reply-To: References: Message-ID: <67b0b207feefa789e0921d67dfe392fb.NginxMailingListRussian@forum.nginx.org> > А что вам мешает организовать кеш в мемкеше или другом подобном > хранилище? > Мы у себя так сделали, кеш (на nginx) выключили вообще за > ненадобностью. Мы так же реализуем, слой кеширования в Memcache, в нем кешируются SQL запросы другие данные, но тесты показывают что ответить 304 намного быстрей, чем генерировать страницу на основе кеша из Memcache, по этому мы этот слой кеша используем только для персонализированных запросов, которые привязаны к сессии клиента, все остальное хотелось бы кешить в Nginx, это более эффективно и на случай падения бекенда, есть возможность отдавать данные их кеша. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245027#msg-245027 From mdounin at mdounin.ru Thu Nov 28 09:19:09 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 28 Nov 2013 13:19:09 +0400 Subject: Cache Revalidate In-Reply-To: <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> References: <20131127202255.GU93176@mdounin.ru> <4d0581e316a4254a953cd42d96fa7741.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131128091909.GY93176@mdounin.ru> Hello! On Wed, Nov 27, 2013 at 04:21:37PM -0500, S.A.N wrote: > > use case и о происхождении требования о недопустимости кеширования > > даже на 1 секунду. Возможно, это позволило бы пересмотреть > > существующее поведение при max-age=0, благо в Cache-Control есть и > > другие способы запрета кеширования. > > use case продиктован нашей бизнес логикой, мы кешируем все даже страницы для > залогиненых пользователей (персонал данные подтягиваются через ajax с > использованием клиентского кэширования браузера), в этом есть смысл, цифры я > уже писал, разница скорости в генерации страницы и в ревалидации отличается > в десятки раз, в пользу ревалидации. > > Есть сайт с хорошей посещаемостью, залогиненые пользователи имеют > возможность общатся, создавать свой контент, редактировать, удалять, есть > так же платные сервисы. > > Наши клиенты не хотят и не должны ждать, даже если это одна секунда, ну > например, клиент написал комментарий на сайте, POST ушел на сервер, если у > нас кеширования на 1 секунду, мы клиенту не можем сразуже показать новую > страницу, должны сделать задержку на 1 сек потом обновить его страницу или > как на Хабре все комментарии видны с задержкой и люди это терпят. Т.е. задача - показать клиенту, добавившему комментарий с помощью POST'а, страницу с его комментарием непосредственно после перенаправления, отдаваемого на POST, правильно? Спасибо, так констуркция понятна, хотя и несколько странна. Just in case, альтернативные решения на вскидку: - Добавлять комментарий без перезагрузки страницы javascript'ом, отправлять на сервер - через ajax. Так, насколько я понимаю, сейчас делают чуть менее, чем все, в том числе упоминаемый вами же facebook. - Добавлять комментарий, после чего возвращать перенаправление на специальный адрес (e.g. со случайным числом в аргументе) для прохода кешей. Такой подход позволяет не зависеть от реализуемых по пути алгоритмов кеширования, и в то же время обеспечить нормальное кеширование страниц (и беспроблемную навигацию по истории). Кеши страниц на nginx'е при этом можно склеить с помощью грамотного указания ключа кеширования и использования proxy_cache_bypass. Так делали раньше чуть менее, чем все. [...] -- Maxim Dounin http://nginx.org/en/donation.html From nginx-forum at nginx.us Thu Nov 28 09:56:14 2013 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 28 Nov 2013 04:56:14 -0500 Subject: Cache Revalidate In-Reply-To: <20131128091909.GY93176@mdounin.ru> References: <20131128091909.GY93176@mdounin.ru> Message-ID: <2022d1d08cf0b512406f78f1ccbed193.NginxMailingListRussian@forum.nginx.org> > - Добавлять комментарий без перезагрузки страницы javascript'ом, > отправлять на сервер - через ajax. Так, насколько я понимаю, > сейчас делают чуть менее, чем все, в том числе упоминаемый вами же > facebook. Я же написал, что мы знаем как можно работать с задержками, но зачем это всё если бекенд отлично держит трафик на ревалидацию без задержек. Чтобы не подумали что мы маньяки кеширования немного уточню, у нас кеширования настроено под каждый модуль сайта, исходя из особенностей каждого модуля. Для не залогиненых, мы кешируем весь фронтент с задержкой на 5 минут, это нормально с учетом что там почти каждый день пытаются нас досить. Сайт для залогиненых, настроен более лояльно к посетителям, там задержек на ревалидацию нет, как и нет кеширования Nginx, там сейчас есть только умное кеширования в браузерах основанное на ETag. Но мы хотим, в будущем данную модель кеширования в браузерах перенести на Nginx, это позволит увеличить повторное использования кеша. Если в Nginx сделают подержку кеширования с дерективой max-age=0 при условии что в конфиге включена ревалидация кеша, будем с удовольствием её юзать, если нет, будем эксплотировать баг с X-Accel-Expires: @$time-1, исправите этот баг, посетители сайта получат задержку в ревалидации. Если интересно моё мнения, я бы max-age=0 оставил как разрешения на кеширования, запретом на кеширования оставить дерективы: no-store, no-cache, private. Это все мелочи, нас больше интересует, реалезация ревалидации по If-None-Match, на эту тему мы уже общались, нам остается только ждать, когда она появится. Надеюсь наше общения на форуме, не отнимает у вас свободное время, которое можно было бы потратить на реализацию ревалидации по ETag :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245044#msg-245044 From nefer05 at gmail.com Thu Nov 28 10:05:01 2013 From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Thu, 28 Nov 2013 14:05:01 +0400 Subject: Cache Revalidate In-Reply-To: <2022d1d08cf0b512406f78f1ccbed193.NginxMailingListRussian@forum.nginx.org> References: <20131128091909.GY93176@mdounin.ru> <2022d1d08cf0b512406f78f1ccbed193.NginxMailingListRussian@forum.nginx.org> Message-ID: > > Если интересно моё мнения, я бы max-age=0 оставил как разрешения на > кеширования, запретом на кеширования оставить дерективы: no-store, > no-cache, > private. > Извините что вклиниваюсь, но это полная победа разума над логикой. А идти вразрез с логикой правильно только в алгоритмах защиты, дабы спутать врага. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Nov 28 10:15:50 2013 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 28 Nov 2013 05:15:50 -0500 Subject: Cache Revalidate In-Reply-To: References: Message-ID: > Извините что вклиниваюсь, но это полная победа разума над логикой. > А идти вразрез с логикой правильно только в алгоритмах защиты, дабы > спутать > врага. Я же не настаиваю на этом решении, это уже вам решать. Если интересно как юзается max-age=0 для кеширования, далеко ходить не надо, Google в результатах поиска отдает хедер Cache-Control: private, max-age=0, если вы повторно ведете тот же поисковый запрос, Google вам ответит статусом 304, скажу даже больше, вместо ETag они используют куки, в которых хранится хеш по которому проходит ревалидация. Вот такие вот реалии, Google конечно те ещё ребята и могут запутать врагов, но их схема позволяет им снизить нагрузку на сервера и уменьшить трафик, чего и мы желаем добится при использовании кеша Nginx. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245046#msg-245046 From nefer05 at gmail.com Thu Nov 28 10:32:41 2013 From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Thu, 28 Nov 2013 14:32:41 +0400 Subject: Cache Revalidate In-Reply-To: References: Message-ID: Кому как, мне вот только что ответил двухсоткой. Несколько раз. Различный контент пошел уже с 304, но там и max-age далеко не ноль. Про использование кук и прочих ETag я ничего не говорил, но кеширование при max-age=0 это совершенно бессмысленное действо с точки зрения банальной логики. ибо при повторном запросе age будет не ноль и кеш должен стать невалидным. А решать одну проблему через встраивание костылей в другой, хоть и соседский, механизм - неправильно. 2013/11/28 S.A.N > > Извините что вклиниваюсь, но это полная победа разума над логикой. > > А идти вразрез с логикой правильно только в алгоритмах защиты, дабы > > спутать > > врага. > > Я же не настаиваю на этом решении, это уже вам решать. > > Если интересно как юзается max-age=0 для кеширования, далеко ходить не > надо, > Google в результатах поиска отдает хедер Cache-Control: private, max-age=0, > если вы повторно ведете тот же поисковый запрос, Google вам ответит > статусом > 304, скажу даже больше, вместо ETag они используют куки, в которых хранится > хеш по которому проходит ревалидация. > Вот такие вот реалии, Google конечно те ещё ребята и могут запутать врагов, > но их схема позволяет им снизить нагрузку на сервера и уменьшить трафик, > чего и мы желаем добится при использовании кеша Nginx. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244991,245046#msg-245046 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Nov 28 10:51:19 2013 From: nginx-forum at nginx.us (S.A.N) Date: Thu, 28 Nov 2013 05:51:19 -0500 Subject: Cache Revalidate In-Reply-To: References: Message-ID: <3be0bef808a49b385cfa841aaa7e86ad.NginxMailingListRussian@forum.nginx.org> Роман Москвитин Wrote: ------------------------------------------------------- > Кому как, мне вот только что ответил двухсоткой. Несколько раз. > Различный > контент пошел уже с 304, но там и max-age далеко не ноль. > Про использование кук и прочих ETag я ничего не говорил, но > кеширование при > max-age=0 это совершенно бессмысленное действо с точки зрения > банальной > логики. > ибо при повторном запросе age будет не ноль и кеш должен стать > невалидным. > А решать одну проблему через встраивание костылей в другой, хоть и > соседский, механизм - неправильно. Страно, мне отдает в Хроме статус 304. Насчет max-age=0, я спорить не буду, вам видней, я исходил из того как это работает в браузерах, как это реализовать в Nginx решать вам. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245048#msg-245048 From nefer05 at gmail.com Thu Nov 28 10:52:58 2013 From: nefer05 at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQnNC+0YHQutCy0LjRgtC40L0=?=) Date: Thu, 28 Nov 2013 14:52:58 +0400 Subject: Cache Revalidate In-Reply-To: <3be0bef808a49b385cfa841aaa7e86ad.NginxMailingListRussian@forum.nginx.org> References: <3be0bef808a49b385cfa841aaa7e86ad.NginxMailingListRussian@forum.nginx.org> Message-ID: Я не имею отношения к Nginx иного, ктоме как пользователь!!! И пользуюсь firefox'ом. 2013/11/28 S.A.N > Роман Москвитин Wrote: > ------------------------------------------------------- > > Кому как, мне вот только что ответил двухсоткой. Несколько раз. > > Различный > > контент пошел уже с 304, но там и max-age далеко не ноль. > > Про использование кук и прочих ETag я ничего не говорил, но > > кеширование при > > max-age=0 это совершенно бессмысленное действо с точки зрения > > банальной > > логики. > > ибо при повторном запросе age будет не ноль и кеш должен стать > > невалидным. > > А решать одну проблему через встраивание костылей в другой, хоть и > > соседский, механизм - неправильно. > > Страно, мне отдает в Хроме статус 304. > Насчет max-age=0, я спорить не буду, вам видней, я исходил из того как это > работает в браузерах, как это реализовать в Nginx решать вам. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,244991,245048#msg-245048 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Thu Nov 28 11:04:50 2013 From: nginx-forum at nginx.us (Romano) Date: Thu, 28 Nov 2013 06:04:50 -0500 Subject: =?UTF-8?B?0JzQvtC00LjRhNC40LrQsNGG0LjRjyDQutGN0YjQuNGA0L7QstCw0L3QvdC+0Lkg?= =?UTF-8?B?0YHRgtGA0LDQvdC40YbRiw==?= Message-ID: <07c7f1bcf0f050b84a3827a23be0cab1.NginxMailingListRussian@forum.nginx.org> Здравствуйте! Возможно ли добавить в кэшируемую страницу (в контент) произвольный текст, например, ссылку на дополнительный файл стилей CSS в секции
? Сайтов много, а один элементов дизайна общий для всех, но разный для каждого браузера. Хотелось бы переложить задачу на Nginx, который бы определял тип браузера и подключал тот или иной файл стилей. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245050,245050#msg-245050 From nginx-forum at nginx.us Thu Nov 28 19:47:50 2013 From: nginx-forum at nginx.us (Sferg) Date: Thu, 28 Nov 2013 14:47:50 -0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQt9Cw0LPRgNGD0LfQutC+0Lkg0LjQt9C+0LE=?= =?UTF-8?B?0YDQsNC20LXQvdC40Lkg0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw0L0=?= =?UTF-8?B?0LjQuCBsaW1pdCByZXEuINCa0LDQuiDQv9C+0LHQvtGA0L7RgtGMPw==?= Message-ID: Здравствуйте, господа. Установлена связка nginx + php-fpm. Возникла проблема с загрузкой изображений при использовании limit_req. В секции http прописал: limit_req_zone $binary_remote_addr zone=reqPerSec1:1m rate=1r/s; Далее, определены следующие локэйшены: location / { #try_files $uri $uri/ /index.php$uri$is_args$args; limit_req zone=reqPerSec1 burst=5 nodelay; } location ~ [4-5][0-9][0-9].html { internal; } location /favicon.ico { access_log off; log_not_found off; expires 1y; #empty_gif; return 204; } location ~ ^.+\.php(?:/.*)?$ { limit_req zone=reqPerSec1 burst=5 nodelay; include conf.d/php.conf; } location ~* ^.+\.(jpg|jpeg|gif|png|css|js|swf)$ { access_log off; log_not_found off; expires 1y; } location ~ (?:/\..*|~)$ { access_log off; log_not_found off; deny all; } В результате получается, что при загрузке html-странички, css и картинки грузятся исправно, даже если часто понажимать F5, а вот при вызове phpinfo, логотипы пропадают после первого же обновления странички. В чём может быть проблема и каким образом её можно побороть? К обработке html-страничек вопросов никаких, но хотелось бы, чтоб и с php limit_req функционировал исправно. С уважением, Геннадий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245058,245058#msg-245058 From citrin at citrin.ru Fri Nov 29 08:41:45 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri, 29 Nov 2013 12:41:45 +0400 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0LfQsNCz0YDRg9C30LrQvtC5INC40Lc=?= =?UTF-8?B?0L7QsdGA0LDQttC10L3QuNC5INC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LI=?= =?UTF-8?B?0LDQvdC40LggbGltaXQgcmVxLiDQmtCw0Log0L/QvtCx0L7RgNC+0YLRjD8=?= In-Reply-To: References: Message-ID: <52985349.4090701@citrin.ru> On 11/28/13 23:47, Sferg wrote: > > location ~ ^.+\.php(?:/.*)?$ { > limit_req zone=reqPerSec1 burst=5 nodelay; > include conf.d/php.conf; > } > В результате получается, что при загрузке html-странички, css и картинки > грузятся исправно, даже если часто понажимать F5, а вот при вызове phpinfo, > логотипы пропадают после первого же обновления странички. Потому что логотипы для phpinfo генерятся тем же самым php. Не поленитесь посмотреть через Firebug или аналогичные инструменты других бразуеров. Ну и логи nginx смотреть то же бывает полезно. From citrin at citrin.ru Fri Nov 29 08:54:57 2013 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Fri, 29 Nov 2013 12:54:57 +0400 Subject: =?UTF-8?B?UmU6INCc0L7QtNC40YTQuNC60LDRhtC40Y8g0LrRjdGI0LjRgNC+0LLQsNC90L0=?= =?UTF-8?B?0L7QuSDRgdGC0YDQsNC90LjRhtGL?= In-Reply-To: <07c7f1bcf0f050b84a3827a23be0cab1.NginxMailingListRussian@forum.nginx.org> References: <07c7f1bcf0f050b84a3827a23be0cab1.NginxMailingListRussian@forum.nginx.org> Message-ID: <52985661.4010409@citrin.ru> On 11/28/13 15:04, Romano wrote: > Здравствуйте! Возможно ли добавить в кэшируемую страницу (в контент) > произвольный текст, например, ссылку на дополнительный файл стилей CSS в > секции
? http://nginx.org/ru/docs/http/ngx_http_sub_module.html Насколько знаю, sub_filter должен применяться уже после того, как ответ вынут из кэша. From greenh at gmail.com Fri Nov 29 16:10:08 2013 From: greenh at gmail.com (greenh) Date: Fri, 29 Nov 2013 18:10:08 +0200 Subject: =?UTF-8?B?0KHRgtGA0LDQvdC90L7QtSDQutC10YjRgNC+0LLQsNC90LjQtSDQsiBuZ2lueA==?= Message-ID: Добрый день подскажите плз, что это может быть за кеширование и кто за него отвечает создаю файл 1.php кладу в него ЛЮБОЙ контент, допустим "12345" открываю в браузере, и вижу 12345 попытка изменить файл не приводит к измеению отдачи в логах так же не меняется размер перезагрузка nginx так же ничего не дает /usr/local/etc/nginx # nginx -v nginx version: nginx/1.4.3 вот конфиг user www www; worker_processes 2; worker_rlimit_nofile 32768; pid /var/run/nginx.pid; error_log /dev/null; events { worker_connections 32768; use kqueue; } http { fastcgi_cache off; fastcgi_store off; default_type application/octet-stream; client_header_timeout 600; client_body_timeout 600; send_timeout 1200; proxy_read_timeout 180; proxy_connect_timeout 180; proxy_send_timeout 180; proxy_buffer_size 8k; proxy_buffers 4 32k; proxy_buffering off; proxy_cache off; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 256k; gzip on; gzip_min_length 1100; gzip_buffers 4 32k; gzip_types text/plain application/x-javascript text/css text/php text/x-php application/php application/x-php application/x-httpd-php application/x-httpd-php-source; client_max_body_size 50m; client_body_buffer_size 128k; client_header_buffer_size 1k; large_client_header_buffers 4 4k; sendfile on; tcp_nopush on; tcp_nodelay on; output_buffers 1 32k; postpone_output 1460; lingering_time 30; lingering_timeout 6; reset_timedout_connection on; keepalive_timeout 5; optimize_server_names on; server_names_hash_bucket_size 64; include mime.types; server { listen *:80; server_name stat; root /home/client/staе; auth_basic "Restricted"; auth_basic_user_file /home/client/stat/.htpasswd; location / { fastcgi_pass unix:/home/client/run/socket; fastcgi_index index.php; fastcgi_param PHPRC "/home/client/php"; fastcgi_param SCRIPT_FILENAME /home/client/stat$fastcgi_script_name; include fastcgi_params; } error_log /home/client/logs/stat-error.log; access_log /home/client/logs/stat-access.log; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd at jdwuzhere.ru Fri Nov 29 16:31:34 2013 From: jd at jdwuzhere.ru (jd at jdwuzhere.ru) Date: Fri, 29 Nov 2013 20:31:34 +0400 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LrQtdGI0YDQvtCy0LDQvdC40LUg0LIgbmdp?= =?UTF-8?B?bng=?= In-Reply-To: References: Message-ID: APC > On 29 нояб. 2013 г., at 20:10, greenh wrote: > > Добрый день > подскажите плз, что это может быть за кеширование и кто за него отвечает > создаю файл > 1.php > кладу в него ЛЮБОЙ контент, допустим "12345" > открываю в браузере, и вижу 12345 > попытка изменить файл не приводит к измеению отдачи > в логах так же не меняется размер > перезагрузка nginx так же ничего не дает > > /usr/local/etc/nginx # nginx -v > nginx version: nginx/1.4.3 > > вот конфиг > > user www www; > worker_processes 2; > worker_rlimit_nofile 32768; > pid /var/run/nginx.pid; > error_log /dev/null; > > events { > worker_connections 32768; > use kqueue; > } > > http { > > fastcgi_cache off; > fastcgi_store off; > > default_type application/octet-stream; > client_header_timeout 600; > client_body_timeout 600; > send_timeout 1200; > proxy_read_timeout 180; > proxy_connect_timeout 180; > proxy_send_timeout 180; > proxy_buffer_size 8k; > proxy_buffers 4 32k; > proxy_buffering off; > proxy_cache off; > proxy_busy_buffers_size 64k; > proxy_temp_file_write_size 256k; > gzip on; > gzip_min_length 1100; > gzip_buffers 4 32k; > gzip_types text/plain application/x-javascript text/css text/php text/x-php application/php application/x-php application/x-httpd-php application/x-httpd-php-source; > client_max_body_size 50m; > client_body_buffer_size 128k; > client_header_buffer_size 1k; > large_client_header_buffers 4 4k; > sendfile on; > tcp_nopush on; > tcp_nodelay on; > output_buffers 1 32k; > postpone_output 1460; > lingering_time 30; > lingering_timeout 6; > reset_timedout_connection on; > keepalive_timeout 5; > optimize_server_names on; > server_names_hash_bucket_size 64; > include mime.types; > server { > listen *:80; > server_name stat; > root /home/client/staе; > auth_basic "Restricted"; > auth_basic_user_file /home/client/stat/.htpasswd; > > location / { > > fastcgi_pass unix:/home/client/run/socket; > fastcgi_index index.php; > fastcgi_param PHPRC "/home/client/php"; > fastcgi_param SCRIPT_FILENAME /home/client/stat$fastcgi_script_name; > include fastcgi_params; > > } > error_log /home/client/logs/stat-error.log; > access_log /home/client/logs/stat-access.log; > > } > > > } > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Fri Nov 29 16:49:53 2013 From: nginx-forum at nginx.us (Digan) Date: Fri, 29 Nov 2013 11:49:53 -0500 Subject: =?UTF-8?B?0JHQsNC70LDQvdGB0LjRgNC+0LLQutCwINC+0LHRgNCw0YnQtdC90LjQuSDQuiA=?= =?UTF-8?B?0YHQtdGA0LLQuNGB0LDQvA==?= Message-ID: <45b8f9d039bd921ccbca7586abe327c6.NginxMailingListRussian@forum.nginx.org> Есть MVC приложение, в котором указан ServiceReference на сервисы. В коде на С# есть обращения к этим сервисам. Сервисы установлены на двух серверах. Требуется балансировать нагрузку на сервисы по этим серверам. Для балансировки использую nginx с модулем nginx-sticky-module. Он, как известно, привязывает запрос по куки route. Но в этом случае я так понимаю не работает эта привязка, наверное нужные куки не создаются. До того как что-то отобразиться в браузере происходит 3 запроса к сервису. Судя по логам, сначала к одному серверу, потом в к другому. Хотя при привязке по куки route они должны уходить на один сервер. Вопрос. Почему привязка по куки не работают? Мой конфиг: #user nobody; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; worker_processes 1; worker_rlimit_nofile 20240; events { worker_connections 20240; } http { log_format upstream 'Request: "$request" [$time_local] BI_SERVER_IP: $upstream_addr STATUS: $status' $upstream_cache_status - $upstream_status - $upstream_response_time - $upstream_http_host - $upstream_http_content_type - $upstream_http_content_length - $upstream_http_location; #sendfile on; #tcp_nopush on; #keepalive_timeout 0; #gzip on; upstream backend { sticky; server 10.0.7.99; server 10.0.6.140; } server { listen 555; server_name localhost; access_log logs/nginx_upstream_access.log upstream; location /MyService{ proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host:555; proxy_connect_timeout 10m; proxy_send_timeout 10m; proxy_read_timeout 8m; proxy_next_upstream off; proxy_pass http://backend/MyService; } } } #$upstream_http_host Nginx и веб-приложение на одной и той же машине. ОС Windows. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245084,245084#msg-245084 From greenh at gmail.com Fri Nov 29 16:53:28 2013 From: greenh at gmail.com (greenh) Date: Fri, 29 Nov 2013 18:53:28 +0200 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LrQtdGI0YDQvtCy0LDQvdC40LUg0LIgbmdp?= =?UTF-8?B?bng=?= In-Reply-To: References: Message-ID: 29 ноября 2013 г., 18:31 пользователь написал: > APC > apc который в Php? странное поведение.. > > > On 29 нояб. 2013 г., at 20:10, greenh wrote: > > > > Добрый день > > подскажите плз, что это может быть за кеширование и кто за него отвечает > > создаю файл > > 1.php > > кладу в него ЛЮБОЙ контент, допустим "12345" > > открываю в браузере, и вижу 12345 > > попытка изменить файл не приводит к измеению отдачи > > в логах так же не меняется размер > > перезагрузка nginx так же ничего не дает > > > > /usr/local/etc/nginx # nginx -v > > nginx version: nginx/1.4.3 > > > > вот конфиг > > > > user www www; > > worker_processes 2; > > worker_rlimit_nofile 32768; > > pid /var/run/nginx.pid; > > error_log /dev/null; > > > > events { > > worker_connections 32768; > > use kqueue; > > } > > > > http { > > > > fastcgi_cache off; > > fastcgi_store off; > > > > default_type application/octet-stream; > > client_header_timeout 600; > > client_body_timeout 600; > > send_timeout 1200; > > proxy_read_timeout 180; > > proxy_connect_timeout 180; > > proxy_send_timeout 180; > > proxy_buffer_size 8k; > > proxy_buffers 4 32k; > > proxy_buffering off; > > proxy_cache off; > > proxy_busy_buffers_size 64k; > > proxy_temp_file_write_size 256k; > > gzip on; > > gzip_min_length 1100; > > gzip_buffers 4 32k; > > gzip_types text/plain application/x-javascript text/css text/php > text/x-php application/php application/x-php application/x-httpd-php > application/x-httpd-php-source; > > client_max_body_size 50m; > > client_body_buffer_size 128k; > > client_header_buffer_size 1k; > > large_client_header_buffers 4 4k; > > sendfile on; > > tcp_nopush on; > > tcp_nodelay on; > > output_buffers 1 32k; > > postpone_output 1460; > > lingering_time 30; > > lingering_timeout 6; > > reset_timedout_connection on; > > keepalive_timeout 5; > > optimize_server_names on; > > server_names_hash_bucket_size 64; > > include mime.types; > > server { > > listen *:80; > > server_name stat; > > root /home/client/staе; > > auth_basic "Restricted"; > > auth_basic_user_file /home/client/stat/.htpasswd; > > > > location / { > > > > fastcgi_pass unix:/home/client/run/socket; > > fastcgi_index index.php; > > fastcgi_param PHPRC "/home/client/php"; > > fastcgi_param SCRIPT_FILENAME > /home/client/stat$fastcgi_script_name; > > include fastcgi_params; > > > > } > > error_log /home/client/logs/stat-error.log; > > access_log /home/client/logs/stat-access.log; > > > > } > > > > > > } > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru at nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From sargaskn at gmail.com Fri Nov 29 18:10:17 2013 From: sargaskn at gmail.com (Sargas) Date: Fri, 29 Nov 2013 20:10:17 +0200 Subject: =?UTF-8?B?UmU6INCh0YLRgNCw0L3QvdC+0LUg0LrQtdGI0YDQvtCy0LDQvdC40LUg0LIgbmdp?= =?UTF-8?B?bng=?= In-Reply-To: References: Message-ID: Или Opcache с opcache.revalidate_freq=n секунд 29 ноября 2013 г., 18:53 пользователь greenh написал: > > 29 ноября 2013 г., 18:31 пользователь написал: > >> APC >> > > apc который в Php? странное поведение.. > >> >> > On 29 нояб. 2013 г., at 20:10, greenh wrote: >> > >> > Добрый день >> > подскажите плз, что это может быть за кеширование и кто за него отвечает >> > создаю файл >> > 1.php >> > кладу в него ЛЮБОЙ контент, допустим "12345" >> > открываю в браузере, и вижу 12345 >> > попытка изменить файл не приводит к измеению отдачи >> > в логах так же не меняется размер >> > перезагрузка nginx так же ничего не дает >> > >> > /usr/local/etc/nginx # nginx -v >> > nginx version: nginx/1.4.3 >> > >> > вот конфиг >> > >> > user www www; >> > worker_processes 2; >> > worker_rlimit_nofile 32768; >> > pid /var/run/nginx.pid; >> > error_log /dev/null; >> > >> > events { >> > worker_connections 32768; >> > use kqueue; >> > } >> > >> > http { >> > >> > fastcgi_cache off; >> > fastcgi_store off; >> > >> > default_type application/octet-stream; >> > client_header_timeout 600; >> > client_body_timeout 600; >> > send_timeout 1200; >> > proxy_read_timeout 180; >> > proxy_connect_timeout 180; >> > proxy_send_timeout 180; >> > proxy_buffer_size 8k; >> > proxy_buffers 4 32k; >> > proxy_buffering off; >> > proxy_cache off; >> > proxy_busy_buffers_size 64k; >> > proxy_temp_file_write_size 256k; >> > gzip on; >> > gzip_min_length 1100; >> > gzip_buffers 4 32k; >> > gzip_types text/plain application/x-javascript text/css text/php >> text/x-php application/php application/x-php application/x-httpd-php >> application/x-httpd-php-source; >> > client_max_body_size 50m; >> > client_body_buffer_size 128k; >> > client_header_buffer_size 1k; >> > large_client_header_buffers 4 4k; >> > sendfile on; >> > tcp_nopush on; >> > tcp_nodelay on; >> > output_buffers 1 32k; >> > postpone_output 1460; >> > lingering_time 30; >> > lingering_timeout 6; >> > reset_timedout_connection on; >> > keepalive_timeout 5; >> > optimize_server_names on; >> > server_names_hash_bucket_size 64; >> > include mime.types; >> > server { >> > listen *:80; >> > server_name stat; >> > root /home/client/staе; >> > auth_basic "Restricted"; >> > auth_basic_user_file /home/client/stat/.htpasswd; >> > >> > location / { >> > >> > fastcgi_pass unix:/home/client/run/socket; >> > fastcgi_index index.php; >> > fastcgi_param PHPRC "/home/client/php"; >> > fastcgi_param SCRIPT_FILENAME >> /home/client/stat$fastcgi_script_name; >> > include fastcgi_params; >> > >> > } >> > error_log /home/client/logs/stat-error.log; >> > access_log /home/client/logs/stat-access.log; >> > >> > } >> > >> > >> > } >> > >> > _______________________________________________ >> > nginx-ru mailing list >> > nginx-ru at nginx.org >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru at nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Fri Nov 29 19:44:10 2013 From: nginx-forum at nginx.us (proforg) Date: Fri, 29 Nov 2013 14:44:10 -0500 Subject: =?UTF-8?B?ZGVidWcgcG9pbnRzIGFib3J0LCDRh9GC0L4g0LTQtdC70LDRgtGMINGBINC60L4=?= =?UTF-8?B?0YDQutCw0LzQuA==?= Message-ID: <8e9e582d7461fdf1e051d909d07b878a.NginxMailingListRussian@forum.nginx.org> Их как-то неприлично много развелось в последние дни gdb показывает вот такое: Program terminated with signal 6, Aborted. #0 0x00007f694d6a41b5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f694d6a41b5 in raise () from /lib/libc.so.6 #1 0x00007f694d6a6fc0 in abort () from /lib/libc.so.6 #2 0x0000000000424527 in ngx_debug_point () at src/os/unix/ngx_process.c:608 #3 0x000000000040c460 in ngx_output_chain (ctx=0x2483430, in=0x0) at src/core/ngx_output_chain.c:114 #4 0x000000000044e21a in ngx_http_upstream_send_request (r=0x5afdbc0, u=0x24833a0) at src/http/ngx_http_upstream.c:1499 #5 0x0000000000450b2e in ngx_http_upstream_send_request_handler (r=0x5afdbc0, u=0x24833a0) at src/http/ngx_http_upstream.c:1588 #6 0x000000000044c432 in ngx_http_upstream_handler (ev=0x7f694a7e6080) at src/http/ngx_http_upstream.c:972 #7 0x000000000041f6c9 in ngx_event_process_posted (cycle=0x2468c90, posted=0x6cd4c0) at src/event/ngx_event_posted.c:40 #8 0x000000000041f4f7 in ngx_process_events_and_timers (cycle=0x2468c90) at src/event/ngx_event.c:276 #9 0x00000000004263d5 in ngx_worker_process_cycle (cycle=0x2468c90, data=) at src/os/unix/ngx_process_cycle.c:816 #10 0x0000000000424aec in ngx_spawn_process (cycle=0x2468c90, proc=0x4262df , data=, name=0x49783b "worker process", respawn=0) at src/os/unix/ngx_process.c:198 #11 0x0000000000426e5e in ngx_reap_children (cycle=0x2468c90) at src/os/unix/ngx_process_cycle.c:627 #12 ngx_master_process_cycle (cycle=0x2468c90) at src/os/unix/ngx_process_cycle.c:180 #13 0x000000000040969a in main (argc=, argv=) at src/core/nginx.c:407 в логах при этом примерно такое: 2013/11/28 17:30:39 [alert] 22491#0: *94121469 zero size buf in output t:1 r:0 f:0 0000000005C98C53 0000000005C98C53-0000000005C98C53 0000000000000000 0-0 while sending request to upstream, client: 62.151.197.187, server: peeteevee.com, request: "POST /is_login_json.php HTTP/1.1", upstream: "http://127.0.0.1:80/is_login_json.php", host: "www.xxxxxx.com", referrer: "http://www.xxxxxx.com/albums/video/zzzzzzzz/" что с этим делать? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245088,245088#msg-245088 From rommer at active.by Fri Nov 29 20:17:23 2013 From: rommer at active.by (Rommer) Date: Fri, 29 Nov 2013 23:17:23 +0300 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <52943015.2000507@active.by> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> <20131125233536.GK41579@mdounin.ru> <52942CF7.2020208@active.by> <52943015.2000507@active.by> Message-ID: <5298F653.8060400@active.by> Hello, Максим, этот пачт может решить проблему? Или все-таки на этот раз тоже неверный подход к решению? On 11/26/13 08:22, Роман Шишнев wrote: > Hello, > > Забыл проверить "%00", апдейт тут: > http://pastebin.com/raw.php?i=cFsthQEi > > On 11/26/2013 08:09 AM, Роман Шишнев wrote: >> Hello, >> >> Не влез патч в рассылку. Повторюсь. >> >> Хотел обойтись малой кровью Но раз ssi и dav туда-же, >> то вот мой следующий опус: >> http://pastebin.com/raw.php?i=CPBwq7xY >> >> Надеюсь, на этот раз в нужном направлении. >> >> Заодно закроется бага с редиректом "../blablabla" >> которая считалась safe. >> >> P.S. это едиственный coding style? >> http://wiki.nginx.org/CodingStyle >> >> On 11/26/2013 02:35 AM, Maxim Dounin wrote: >>> Hello! >>> >>> On Tue, Nov 26, 2013 at 01:47:36AM +0300, Роман Шишнев wrote: >>> >>>> Hello, >>>> >>>> Тогда всё проще и вот так. >>> >>> Совершенно точно нет. Проверить, разескейпить, потом ещё раз >>> проверить - это совсем не тот подход, которым следует >>> пользоваться. Не говоря уже о том, что ssi и dav это не лечит. >>> >>> Перечитайте ещё раз то, что уже было написано по данному вопросу. >>> Тикет, всё-таки, не совсем бесполезен, там по ссылкам есть review >>> предыдущих попыток. >>> >>> http://trac.nginx.org/nginx/ticket/316 >>> >>>> P.S. зачем flags в ngx_http_parse_unsafe_uri() >>>> передается по ссылке? >>> >>> Исходно этот параметр использовался для возврата флагов, в >>> частности - NGX_HTTP_ZERO_IN_URI: >>> >>> http://hg.nginx.org/nginx/diff/58475592100c/src/http/ngx_http_parse.c >>> >>> С тех пор флаг NGX_HTTP_ZERO_IN_URI упразднили, но интерфейс >>> остался. >>> >> > From mdounin at mdounin.ru Fri Nov 29 22:15:12 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 30 Nov 2013 02:15:12 +0400 Subject: =?UTF-8?Q?Re=3A_X-Accel-Redirect_=D0=B8_uri_escape?= In-Reply-To: <5298F653.8060400@active.by> References: <5292AF3F.6060409@active.by> <20131125125537.GX41579@mdounin.ru> <52937CF0.4070508@active.by> <20131125172124.GF41579@mdounin.ru> <5293D388.8070403@active.by> <20131125233536.GK41579@mdounin.ru> <52942CF7.2020208@active.by> <52943015.2000507@active.by> <5298F653.8060400@active.by> Message-ID: <20131129221511.GQ93176@mdounin.ru> Hello! On Fri, Nov 29, 2013 at 11:17:23PM +0300, Rommer wrote: > Hello, > > Максим, этот пачт может решить проблему? > Или все-таки на этот раз тоже неверный подход к решению? Подход - верный, в том смысле, что именно там и надо решать. Но не полный (ssi, например, ломает, ибо он пытается делать unescape uri самостоятельно), и не того качества, чтобы это коммитить (безусловный strdup - это как-то слишком, да и переписывать переданный uri - это, вероятно, не самая лучшая идея, особенно если всё равно копировать строку). Ну и я просто оставлю эту ссылку тут: http://nginx.org/en/docs/contributing_changes.html -- Maxim Dounin http://nginx.org/en/donation.html From mdounin at mdounin.ru Fri Nov 29 22:20:50 2013 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 30 Nov 2013 02:20:50 +0400 Subject: =?UTF-8?B?UmU6IGRlYnVnIHBvaW50cyBhYm9ydCwg0YfRgtC+INC00LXQu9Cw0YLRjCDRgSA=?= =?UTF-8?B?0LrQvtGA0LrQsNC80Lg=?= In-Reply-To: <8e9e582d7461fdf1e051d909d07b878a.NginxMailingListRussian@forum.nginx.org> References: <8e9e582d7461fdf1e051d909d07b878a.NginxMailingListRussian@forum.nginx.org> Message-ID: <20131129222050.GR93176@mdounin.ru> Hello! On Fri, Nov 29, 2013 at 02:44:10PM -0500, proforg wrote: > Их как-то неприлично много развелось в последние дни > > gdb показывает вот такое: > > Program terminated with signal 6, Aborted. > #0 0x00007f694d6a41b5 in raise () from /lib/libc.so.6 > (gdb) bt > #0 0x00007f694d6a41b5 in raise () from /lib/libc.so.6 > #1 0x00007f694d6a6fc0 in abort () from /lib/libc.so.6 > #2 0x0000000000424527 in ngx_debug_point () at > src/os/unix/ngx_process.c:608 > #3 0x000000000040c460 in ngx_output_chain (ctx=0x2483430, in=0x0) at > src/core/ngx_output_chain.c:114 > #4 0x000000000044e21a in ngx_http_upstream_send_request (r=0x5afdbc0, > u=0x24833a0) at src/http/ngx_http_upstream.c:1499 > #5 0x0000000000450b2e in ngx_http_upstream_send_request_handler > (r=0x5afdbc0, u=0x24833a0) at src/http/ngx_http_upstream.c:1588 > #6 0x000000000044c432 in ngx_http_upstream_handler (ev=0x7f694a7e6080) at > src/http/ngx_http_upstream.c:972 > #7 0x000000000041f6c9 in ngx_event_process_posted (cycle=0x2468c90, > posted=0x6cd4c0) at src/event/ngx_event_posted.c:40 > #8 0x000000000041f4f7 in ngx_process_events_and_timers (cycle=0x2468c90) at > src/event/ngx_event.c:276 > #9 0x00000000004263d5 in ngx_worker_process_cycle (cycle=0x2468c90, > data=) at src/os/unix/ngx_process_cycle.c:816 > #10 0x0000000000424aec in ngx_spawn_process (cycle=0x2468c90, proc=0x4262df > , data=, name=0x49783b > "worker process", respawn=0) at src/os/unix/ngx_process.c:198 > #11 0x0000000000426e5e in ngx_reap_children (cycle=0x2468c90) at > src/os/unix/ngx_process_cycle.c:627 > #12 ngx_master_process_cycle (cycle=0x2468c90) at > src/os/unix/ngx_process_cycle.c:180 > #13 0x000000000040969a in main (argc=, argv= optimized out>) at src/core/nginx.c:407 > > > в логах при этом примерно такое: > 2013/11/28 17:30:39 [alert] 22491#0: *94121469 zero size buf in output t:1 > r:0 f:0 0000000005C98C53 0000000005C98C53-0000000005C98C53 0000000000000000 > 0-0 while sending request to upstream, client: 62.151.197.187, server: > peeteevee.com, request: "POST /is_login_json.php HTTP/1.1", upstream: > "http://127.0.0.1:80/is_login_json.php", host: "www.xxxxxx.com", referrer: > "http://www.xxxxxx.com/albums/video/zzzzzzzz/" > > > что с этим делать? nginx -V, конфиг, debug log? http://wiki.nginx.org/Debugging -- Maxim Dounin http://nginx.org/en/donation.html From chipitsine at gmail.com Sat Nov 30 07:45:11 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 30 Nov 2013 09:45:11 +0200 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvtCx0YDQsNGJ0LXQvdC40Lkg?= =?UTF-8?B?0Log0YHQtdGA0LLQuNGB0LDQvA==?= In-Reply-To: <45b8f9d039bd921ccbca7586abe327c6.NginxMailingListRussian@forum.nginx.org> References: <45b8f9d039bd921ccbca7586abe327c6.NginxMailingListRussian@forum.nginx.org> Message-ID: А обращение к сервису осуществляет самодельное приложение ? Оно запоминает и передает куки? пятница, 29 ноября 2013 г. пользователь Digan писал: > Есть MVC приложение, в котором указан ServiceReference на сервисы. > В коде на С# есть обращения к этим сервисам. Сервисы установлены на двух > серверах. Требуется балансировать нагрузку на сервисы по этим серверам. > > Для балансировки использую nginx с модулем nginx-sticky-module. Он, как > известно, привязывает запрос по куки route. Но в этом случае я так понимаю > не работает эта привязка, наверное нужные куки не создаются. До того как > что-то отобразиться в браузере происходит 3 запроса к сервису. > Судя по логам, сначала к одному серверу, потом в к другому. Хотя при > привязке по куки route они должны уходить на один сервер. Вопрос. Почему > привязка по куки не работают? > > Мой конфиг: > > #user nobody; > #error_log logs/error.log; > #error_log logs/error.log notice; > #error_log logs/error.log info; > > #pid logs/nginx.pid; > > worker_processes 1; > worker_rlimit_nofile 20240; > events { > worker_connections 20240; > } > > http { > log_format upstream 'Request: "$request" [$time_local] > BI_SERVER_IP: > $upstream_addr STATUS: $status' $upstream_cache_status - $upstream_status - > $upstream_response_time - $upstream_http_host - $upstream_http_content_type > - $upstream_http_content_length - $upstream_http_location; > #sendfile on; > #tcp_nopush on; > #keepalive_timeout 0; > #gzip on; > > upstream backend { > sticky; > server 10.0.7.99; > server 10.0.6.140; > } > > server { > listen 555; > server_name localhost; > > access_log logs/nginx_upstream_access.log upstream; > > location /MyService{ > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header Host $host:555; > > proxy_connect_timeout 10m; > proxy_send_timeout 10m; > proxy_read_timeout 8m; > proxy_next_upstream off; > > proxy_pass http://backend/MyService; > } > > } > } > > #$upstream_http_host > > Nginx и веб-приложение на одной и той же машине. ОС Windows. > > Posted at Nginx Forum: > http://forum.nginx.org/read.php?21,245084,245084#msg-245084 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From nginx-forum at nginx.us Sat Nov 30 11:06:43 2013 From: nginx-forum at nginx.us (Digan) Date: Sat, 30 Nov 2013 06:06:43 -0500 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvtCx0YDQsNGJ0LXQvdC40Lkg?= =?UTF-8?B?0Log0YHQtdGA0LLQuNGB0LDQvA==?= In-Reply-To: References: Message-ID: <693300f6c55a4208f27a8462798325f3.NginxMailingListRussian@forum.nginx.org> Самодельное.В самом приложении куки создаются и передаются, а вот при обращении к сирвисам, что происходит через nginx нужные для привязки куки не создаются. Илья Шипицин Wrote: ------------------------------------------------------- > А обращение к сервису осуществляет самодельное приложение ? Оно > запоминает > и передает куки? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245084,245097#msg-245097 From chipitsine at gmail.com Sat Nov 30 11:48:01 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 30 Nov 2013 13:48:01 +0200 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvtCx0YDQsNGJ0LXQvdC40Lkg?= =?UTF-8?B?0Log0YHQtdGA0LLQuNGB0LDQvA==?= In-Reply-To: <693300f6c55a4208f27a8462798325f3.NginxMailingListRussian@forum.nginx.org> References: <693300f6c55a4208f27a8462798325f3.NginxMailingListRussian@forum.nginx.org> Message-ID: используете свойство HttpWebRequest.CookieContainer ? http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.cookiecontainer%28v=vs.110%29.aspx 30 ноября 2013 г., 13:06 пользователь Digan написал: > Самодельное.В самом приложении куки создаются и передаются, а вот при > обращении к сирвисам, что происходит через nginx нужные для привязки куки не > создаются. > > Илья Шипицин Wrote: > ------------------------------------------------------- >> А обращение к сервису осуществляет самодельное приложение ? Оно >> запоминает >> и передает куки? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245084,245097#msg-245097 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From chipitsine at gmail.com Sat Nov 30 12:01:20 2013 From: chipitsine at gmail.com (=?KOI8-R?B?6czY0SD7ydDJw8nO?=) Date: Sat, 30 Nov 2013 14:01:20 +0200 Subject: =?UTF-8?B?UmU6INCR0LDQu9Cw0L3RgdC40YDQvtCy0LrQsCDQvtCx0YDQsNGJ0LXQvdC40Lkg?= =?UTF-8?B?0Log0YHQtdGA0LLQuNGB0LDQvA==?= In-Reply-To: <693300f6c55a4208f27a8462798325f3.NginxMailingListRussian@forum.nginx.org> References: <693300f6c55a4208f27a8462798325f3.NginxMailingListRussian@forum.nginx.org> Message-ID: кстати, у nginx-sticky-module ужасный механизм работы. он при получении куки с маршрутом, пробегает по всем возможным бекендам и для каждого вычисляет хеш. и так каждый раз. на большом количестве бекендов процессор нагружается просто адски. мы используем режим "hash=index", чтобы избежать этого эффекта. переделать по-человечески, конечно, руки не дошли. 30 ноября 2013 г., 13:06 пользователь Digan написал: > Самодельное.В самом приложении куки создаются и передаются, а вот при > обращении к сирвисам, что происходит через nginx нужные для привязки куки не > создаются. > > Илья Шипицин Wrote: > ------------------------------------------------------- >> А обращение к сервису осуществляет самодельное приложение ? Оно >> запоминает >> и передает куки? > > Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245084,245097#msg-245097 > > _______________________________________________ > nginx-ru mailing list > nginx-ru at nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum at nginx.us Sat Nov 30 18:59:01 2013 From: nginx-forum at nginx.us (Sferg) Date: Sat, 30 Nov 2013 13:59:01 -0500 Subject: =?UTF-8?B?0J3QtdC/0L7QvdGP0YLQvdGL0LUg0YHRgtGA0L7Rh9C60Lgg0LIgYWNjZXNzLmxv?= =?UTF-8?B?Zy4uLg==?= Message-ID: <6e48b2ac940275ed9ca7a16267da04e1.NginxMailingListRussian@forum.nginx.org> Здравствуйте. Обратил внимание, что время от времени в access.log наряду с обычными строчками вида: [30/Nov/2013:22:52:33 +0400] 192.168.0.31 "GET / HTTP/1.1" 200 1240 "-" "Opera/9.80 (Windows NT 6.2; WOW64) Presto/2.12.388 Version/12.16" "-" "-" пишутся ещё строчки вида: [30/Nov/2013:22:48:29 +0400] 37.110.44.240 - "Q\x9E+\x95i\xD4a\xCCry\xC2\x1Bw\xA6\xAB\x15a\xBD\x9C\x7F\xCE\x16\xAD\xAA\xA0\xB0\x8C\xD1iF9\xC2\xC5{(m\xE1h\xEB\x9A|\x8B7\x977>\x01R\xCA\xC1" 400 310 "-" "-" "-" "-" Собственно, вопросы: 1. Из-за чего эти непонятные строчки появляются? Некорректные настройки Nginx или особенности ботов? 2. Как отшить\фильтровать\заблокировать этих буржуев, которые столь красивый лог портят? С уважением. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245101,245101#msg-245101 From postmaster at softsearch.ru Sat Nov 30 20:31:11 2013 From: postmaster at softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 1 Dec 2013 00:31:11 +0400 Subject: =?UTF-8?B?UmU6INCd0LXQv9C+0L3Rj9GC0L3Ri9C1INGB0YLRgNC+0YfQutC4INCyIGFjY2Vz?= =?UTF-8?B?cy5sb2cuLi4=?= In-Reply-To: <6e48b2ac940275ed9ca7a16267da04e1.NginxMailingListRussian@forum.nginx.org> References: <6e48b2ac940275ed9ca7a16267da04e1.NginxMailingListRussian@forum.nginx.org> Message-ID: <657366241.20131201003111@softsearch.ru> Здравствуйте, Sferg. Вы писали 30 ноября 2013 г., 22:59:01: > Здравствуйте. Обратил внимание, что время от времени в access.log наряду с > обычными строчками вида: > [30/Nov/2013:22:52:33 +0400] 192.168.0.31 "GET / HTTP/1.1" 200 1240 "-" > "Opera/9.80 (Windows NT 6.2; WOW64) Presto/2.12.388 Version/12.16" "-" "-" > пишутся ещё строчки вида: > [30/Nov/2013:22:48:29 +0400] 37.110.44.240 - > "Q\x9E+\x95i\xD4a\xCCry\xC2\x1Bw\xA6\xAB\x15a\xBD\x9C\x7F\xCE\x16\xAD\xAA\xA0\xB0\x8C\xD1iF9\xC2\xC5{(m\xE1h\xEB\x9A|\x8B7\x977>\x01R\xCA\xC1" > 400 310 "-" "-" "-" "-" > Собственно, вопросы: > 1. Из-за чего эти непонятные строчки появляются? Некорректные настройки > Nginx или особенности ботов? Почитайте, что значит код ответа веб-сервера 400. > 2. Как отшить\фильтровать\заблокировать этих буржуев, которые столь красивый > лог портят? Ну можно включить акцепт-фильтр во freebsd, например. -- С уважением, Михаил mailto:postmaster at softsearch.ru From nginx-forum at nginx.us Sat Nov 30 21:18:47 2013 From: nginx-forum at nginx.us (proforg) Date: Sat, 30 Nov 2013 16:18:47 -0500 Subject: =?UTF-8?B?UmU6IGRlYnVnIHBvaW50cyBhYm9ydCwg0YfRgtC+INC00LXQu9Cw0YLRjCDRgSA=?= =?UTF-8?B?0LrQvtGA0LrQsNC80Lg=?= In-Reply-To: <20131129222050.GR93176@mdounin.ru> References: <20131129222050.GR93176@mdounin.ru> Message-ID: Linux shc 3.6-trunk-amd64 #1 SMP Debian 3.6.8-1~experimental.1 x86_64 GNU/Linux nginx version: nginx/1.5.7 built by gcc 4.4.5 (Debian 4.4.5-8) TLS SNI support enabled 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 --with-http_spdy_module --with-http_gunzip_module --add-module=mod_zip --add-module=nginx-upload-progress-module --with-http_geoip_module --with-http_sub_module --add-module=ngx_http_substitutions_filter_module конфиг локейшна: location / { proxy_pass http://localhost; client_body_buffer_size 128k; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_redirect off; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } пример debug log по такому запросу: 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http cl:0 max:524288000 2013/11/30 16:06:49 [debug] 17787#0: *4925169 rewrite phase: 3 2013/11/30 16:06:49 [debug] 17787#0: *4925169 upload-progress: get_tracking_id 2013/11/30 16:06:49 [debug] 17787#0: *4925169 upload-progress: get_tracking_id no header found 2013/11/30 16:06:49 [debug] 17787#0: *4925169 upload-progress: get_tracking_id no id found 2013/11/30 16:06:49 [debug] 17787#0: *4925169 trackuploads no id found in POST upload req 2013/11/30 16:06:49 [debug] 17787#0: *4925169 rewrite phase: 4 2013/11/30 16:06:49 [debug] 17787#0: *4925169 post rewrite phase: 5 2013/11/30 16:06:49 [debug] 17787#0: *4925169 generic phase: 6 2013/11/30 16:06:49 [debug] 17787#0: *4925169 generic phase: 7 2013/11/30 16:06:49 [debug] 17787#0: *4925169 generic phase: 8 2013/11/30 16:06:49 [debug] 17787#0: *4925169 access phase: 9 2013/11/30 16:06:49 [debug] 17787#0: *4925169 access phase: 10 2013/11/30 16:06:49 [debug] 17787#0: *4925169 post access phase: 11 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http client request body preread 148 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http request body content length filter 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http body new buf t:1 f:0 0000000000AE16BC, pos 0000000000AE16BC, size: 0 file: 0, size: 0 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http init upstream, client timer: 0 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: "Host: " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script var: "www.peeteevee.com" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: " " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: "X-Real-IP: " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script var: "174.228.5.201" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: " " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: "Connection: close " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: "Content-Length: " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script var: "0" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http script copy: " " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Accept-Encoding: gzip" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Accept-Language: en-US" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "x-wap-profile: http://uaprof.vtext.com/sam/i110/i110.xml" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Cookie: PHPSESSID=5v7800ff2r6a275ff04vegoud2; __utma=217064471.1861251399.1363650475.1385836523.1385843022.453; __utmc=217064471; __utmz=217064471.1385697596.448.203.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=ann42%20peeteevee; cEMAIL=mailman412%40gmail.com; cEMAILVERIFIED=yes; cUID=12062; cUSERNAME=ann42; cmyUID=12062" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "X-Requested-With: XMLHttpRequest" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Referer: http://www.peeteevee.com/video.php" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.6; en-us; SCH-S720C Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Origin: http://www.peeteevee.com" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "Accept: */*" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http proxy header: "POST /is_login_json.php HTTP/1.0 Host: www.peeteevee.com X-Real-IP: 174.228.5.201 Connection: close Content-Length: 0 Accept-Encoding: gzip Accept-Language: en-US x-wap-profile: http://uaprof.vtext.com/sam/i110/i110.xml Cookie: PHPSESSID=5v7800ff2r6a275ff04vegoud2; __utma=217064471.1861251399.1363650475.1385836523.1385843022.453; __utmc=217064471; __utmz=217064471.1385697596.448.203.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=ann42%20peeteevee; cEMAIL=mailman412%40gmail.com; cEMAILVERIFIED=yes; cUID=12062; cUSERNAME=ann42; cmyUID=12062 X-Requested-With: XMLHttpRequest Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7 Referer: http://www.peeteevee.com/video.php User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.6; en-us; SCH-S720C Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Origin: http://www.peeteevee.com Accept: */* " 2013/11/30 16:06:49 [debug] 17787#0: *4925169 posix_memalign: 0000000003FEC8A0:4096 @16 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http cleanup add: 00000000007F9678 2013/11/30 16:06:49 [debug] 17787#0: *4925169 get rr peer, try: 1 2013/11/30 16:06:49 [debug] 17787#0: *4925169 socket 126 2013/11/30 16:06:49 [debug] 17787#0: *4925169 epoll add connection: fd:126 ev:80002005 2013/11/30 16:06:49 [debug] 17787#0: *4925169 connect to 127.0.0.1:80, fd:126 #4925461 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http upstream connect: -2 2013/11/30 16:06:49 [debug] 17787#0: *4925169 posix_memalign: 0000000004020760:128 @16 2013/11/30 16:06:49 [debug] 17787#0: *4925169 event timer add: 126: 90000:1385845699332 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http finalize request: -4, "/is_login_json.php?" a:1, c:2 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http request count:2 blk:0 2013/11/30 16:06:49 [debug] 17787#0: *4925169 post event 00007FB96CE68808 2013/11/30 16:06:49 [debug] 17787#0: *4925169 delete posted event 00007FB96CE68808 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http upstream request: "/is_login_json.php?" 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http upstream send request handler 2013/11/30 16:06:49 [debug] 17787#0: *4925169 http upstream send request 2013/11/30 16:06:49 [alert] 17787#0: *4925169 zero size buf in output t:1 r:0 f:0 0000000000AE16BC 0000000000AE16BC-0000000000AE16BC 0000000000000000 0-0 while sending request to upstream, client: 174.228.5.201, server: peeteevee.com, request: "POST /is_login_json.php HTTP/1.1", upstream: "http://127.0.0.1:80/is_login_json.php", host: "www.peeteevee.com", referrer: "http://www.peeteevee.com/video.php" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245091,245104#msg-245104