Re: announcing freenginx.org

[Slawa Olhovchenkov]

On Fri, Feb 16, 2024 at 01:29:26PM +0300, Andrey Kopeyko wrote:

> Илья Шипицин писал 2024-02-16 12:51:
> > пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov
> > :
> > 
> >> On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:
> >> 
> >>> Примерно в середине марта 2020 года
> >> началось явное, наблюдаемое извне,
> >>> отползание следаков от "дела nginx".
> >> Что закончилось ЕМНИП в мае
> >>> вынесением постановления о
> >> закрытии дела с феерической
> >> формулировкой
> >>> "... в связи с отсутствием факта
> >> преступления".
> >> 
> >> а что феерического в данной
> >> формулировке?
> 
> Обычно прекращение дела формулируется как "отсутствие состава 
> преступления".
> 
> Т.е. факт действий был подтверждён, но квалифицировать их по УК не 
> получилось.
> 
> 
> Здесь же следствие постулировало что "самого факта не нашли".
> 
> Что неудивительно - заявление о возбуждении дела (его мотивировочная 
> часть полностью вошла в постановление об обыске в офисе nginx, утекшее в 
> РБК в середине дня) писали люди плохо знакомые с историей Рамблера, 
> поэтому изложенных там "фактов" не существовало в природе. И я точно 
> указал где в доказательной базе следствия содержится строгое 
> доказательство отсутствия этих "фактов".

я позанудничаю -- фееричность-то в чем?
в том, что прекращений по такой формулировке предельно мало?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Slawa Olhovchenkov]

On Fri, Feb 16, 2024 at 10:51:13AM +0100, Илья Шипицин wrote:

> пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov :
> 
> > On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:
> >
> > > Примерно в середине марта 2020 года началось явное, наблюдаемое извне,
> > > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае
> > > вынесением постановления о закрытии дела с феерической формулировкой
> > > "... в связи с отсутствием факта преступления".
> >
> > а что феерического в данной формулировке?
> >
> 
> ну, первое столкновение с правовой системой вызывают эмоции.
> 
> когда в 10-й раз видишь примерно одни и те же патерны, это приедается.
> возможно, Андрею каждый раз как первый )) или до 2019-го бог его хранил от
> правоохранителей

я ничего не понял в том, что ты хотел сказать
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: announcing freenginx.org

[Slawa Olhovchenkov]

On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote:

> Примерно в середине марта 2020 года началось явное, наблюдаемое извне, 
> отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае 
> вынесением постановления о закрытии дела с феерической формулировкой 
> "... в связи с отсутствием факта преступления".

а что феерического в данной формулировке?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginxQuic: скорость загрузки при активации kTLS

[Slawa Olhovchenkov]

On Mon, Jan 08, 2024 at 02:46:32PM +0400, Roman Arutyunyan wrote:

> Добрый день,
> 
> On Tue, Jan 02, 2024 at 11:50:08PM +0300, izor...@gmail.com wrote:
> > Здравствуйте.
> > 
> > Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> > разными протоколами:
> >  - HTTP/1.1 - ~102 МБит/сек
> >  - HTTP/2 - ~97 МБит/сек
> >  - HTTP/3 - ~125 МБит/сек
> > 
> > После активации поддержки kTLS результаты улучшились, но не для протокола
> > HTTP/2:
> >  - HTTP/1.1 - ~169 МБит/сек
> >  - HTTP/2 - ~70 МБит/сек
> >  - HTTP/3 - ~132 МБит/сек
> > 
> > Возможно ли добиться повышения скорости для протокола HTTP/3 при поддержке
> > kTLS, сопоставимой со скоростью по протоколу HTTP/1.1?
> 
> kTLS не работает для HTTP/3.  Шифрование QUIC-пакетов производится вручную в
> коде nginx.  Не очень понятно, как kTLS может помочь в случае QUIC, учитывая
> сложность протокола.

а так же изначально постулируемую цель иметь не-ядерную реализацию,
определяемую приложением
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginxQuic: скорость загрузки при активации kTLS

[Slawa Olhovchenkov]

On Fri, Jan 05, 2024 at 12:08:36PM +0100, Илья Шипицин wrote:

> On Fri, Jan 5, 2024, 12:00 Slawa Olhovchenkov  wrote:
> 
> > On Thu, Jan 04, 2024 at 09:25:28PM +0100, Илья Шипицин wrote:
> >
> > > http2 и http/3 делают для браузера более кайфово. ценой некоторого доп
> > > расхода цпу. браузер себя лимитирует 2-мя tcp
> > > сессиями, в рамках http/1.1 браузер может скачивать одновременно 2
> > > объекта.
> >
> > откуда такая фантазия?
> >
> 
> Про 2 соединения?

да

> >
> Фронтендеры говорили, я им верил
> 
> https://savvy.co.il/en/blog/wordpress-speed/speed-optimzations-http2-era/

в интернетах пишут иное.
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginxQuic: скорость загрузки при активации kTLS

[Slawa Olhovchenkov]

On Thu, Jan 04, 2024 at 09:25:28PM +0100, Илья Шипицин wrote:

> http2 и http/3 делают для браузера более кайфово. ценой некоторого доп
> расхода цпу. браузер себя лимитирует 2-мя tcp
> сессиями, в рамках http/1.1 браузер может скачивать одновременно 2
> объекта.

откуда такая фантазия?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginxQuic: скорость загрузки при активации kTLS

[Slawa Olhovchenkov]

On Tue, Jan 02, 2024 at 11:50:08PM +0300, izor...@gmail.com wrote:

> Здравствуйте.
> 
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> разными протоколами:
>  - HTTP/1.1 - ~102 МБит/сек
>  - HTTP/2 - ~97 МБит/сек
>  - HTTP/3 - ~125 МБит/сек
> 
> После активации поддержки kTLS результаты улучшились, но не для протокола
> HTTP/2:
>  - HTTP/1.1 - ~169 МБит/сек
>  - HTTP/2 - ~70 МБит/сек
>  - HTTP/3 - ~132 МБит/сек
> 
> Возможно ли добиться повышения скорости для протокола HTTP/3 при поддержке
> kTLS, сопоставимой со скоростью по протоколу HTTP/1.1?

а что, существуют коммиты в ведра, которые добавляют расширяют
поддержку ktls за пределы TCP?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Исправления срабатываний статического анализатора.

[Slawa Olhovchenkov]

On Wed, Oct 05, 2022 at 09:24:19AM +, Korobov Vladimir via nginx-ru wrote:

> Окей, неправально выразился. 
> Я понимаю, что делает этот патч и он не делает хуже.

окей, возьмем скажем второй кусок патча.

diff -r ba5cf8f73a2d -r ee42d7efc9a6
src/http/modules/ngx_http_proxy_module.c
--- a/src/http/modules/ngx_http_proxy_module.c  Thu Sep 08 13:53:49
2022 +0400
+++ b/src/http/modules/ngx_http_proxy_module.c  Fri Sep 23 03:52:37
2022 -0700
@@ -1485,9 +1485,11 @@

 continue;
 }
-
-code = *(ngx_http_script_code_pt *) e.ip;
-code((ngx_http_script_engine_t *) );
+
+if (*(uintptr_t *) e.ip) {
+code = *(ngx_http_script_code_pt *) e.ip;
+code((ngx_http_script_engine_t *) );
+}

 *e.pos++ = ':'; *e.pos++ = ' ';

взяли и просто выкинули исполнение кода (вопрос о том, может ли в e.ip
вообще чисто теоретически быть NULL -- пока опустим) раскрытия макросов.

но сдвиг по строке оставили. это точно то, что надо делать и это не
сделает хуже?

при этом, если посмотреть внимательно, то ниже, после цикла while у
нас написанно

e.ip += sizeof(uintptr_t);

т.е. если предположить, что по какой-то причине у нас структрура
headers->values->elts (по которой и бежит e.ip) побилась, и там вдруг
возник NULL где не надо, то мы его пропустим и дальше будем уже
выполнять мусор. ну или еще NULL пропустим, пока мусор не попадется.
после этого его выполним.

точно-точно не хуже?

> С уважением,
> Владимир Коробов
> 
> 
> -Original Message-
> From: Slawa Olhovchenkov  
> Sent: Wednesday, October 5, 2022 12:13 PM
> To: Korobov Vladimir via nginx-ru 
> Subject: Re: Исправления срабатываний статического анализатора.
> 
> On Wed, Oct 05, 2022 at 05:22:10AM +, Korobov Vladimir via nginx-ru wrote:
> 
> > Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более 
> > анализатор генерирует несколько сотен предупреждений, а исправляются патчем 
> > только несколько.
> 
> погоди-погоди, как так "кажется"?
> ны написал какой-то код, но сам не понимаешь что он делает?
> а не делает ли он хуже?
> 
> > С уважением,
> > Владимир Коробов
> > 
> > 
> > -Original Message-
> > From: Slawa Olhovchenkov 
> > Sent: Tuesday, October 4, 2022 4:05 PM
> > To: Korobov Vladimir via nginx-ru 
> > Subject: Re: Исправления срабатываний статического анализатора.
> > 
> > On Tue, Oct 04, 2022 at 12:00:57PM +, Korobov Vladimir via nginx-ru 
> > wrote:
> > 
> > > Добрый день
> > > 
> > > После проверки исходного кода статическим анализатором (Svace 
> > > https://www.ispras.ru/technologies/svace/) выделено несколько 
> > > потенциально опасных мест, закрывающихся приложенным патчем.
> > > 
> > > Прошу рассмотреть возможность включения указанных изменений в исходный 
> > > код проекта.
> > 
> > а эти исправления на самом деле что делают?
> > Успокаивают статистический анализатор или исправляют ошибки?
> > ___
> > nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an 
> > email to nginx-ru-le...@nginx.org 
> > ___
> > nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an 
> > email to nginx-ru-le...@nginx.org
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to 
> nginx-ru-le...@nginx.org
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Исправления срабатываний статического анализатора.

[Slawa Olhovchenkov]

On Wed, Oct 05, 2022 at 05:22:10AM +, Korobov Vladimir via nginx-ru wrote:

> Кажется, что да, что-то делают. Цели успокоить анализатора нет, тем более 
> анализатор генерирует несколько сотен предупреждений, а исправляются патчем 
> только несколько.

погоди-погоди, как так "кажется"?
ны написал какой-то код, но сам не понимаешь что он делает?
а не делает ли он хуже?

> С уважением,
> Владимир Коробов
> 
> 
> -Original Message-
> From: Slawa Olhovchenkov  
> Sent: Tuesday, October 4, 2022 4:05 PM
> To: Korobov Vladimir via nginx-ru 
> Subject: Re: Исправления срабатываний статического анализатора.
> 
> On Tue, Oct 04, 2022 at 12:00:57PM +, Korobov Vladimir via nginx-ru wrote:
> 
> > Добрый день
> > 
> > После проверки исходного кода статическим анализатором (Svace 
> > https://www.ispras.ru/technologies/svace/) выделено несколько потенциально 
> > опасных мест, закрывающихся приложенным патчем.
> > 
> > Прошу рассмотреть возможность включения указанных изменений в исходный код 
> > проекта.
> 
> а эти исправления на самом деле что делают?
> Успокаивают статистический анализатор или исправляют ошибки?
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to 
> nginx-ru-le...@nginx.org
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Исправления срабатываний статического анализатора.

[Slawa Olhovchenkov]

On Tue, Oct 04, 2022 at 12:00:57PM +, Korobov Vladimir via nginx-ru wrote:

> Добрый день
> 
> После проверки исходного кода статическим анализатором (Svace 
> https://www.ispras.ru/technologies/svace/) выделено несколько потенциально 
> опасных мест, закрывающихся приложенным патчем.
> 
> Прошу рассмотреть возможность включения указанных изменений в исходный код 
> проекта.

а эти исправления на самом деле что делают?
Успокаивают статистический анализатор или исправляют ошибки?
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Поменять дефолтную $scheme с http на https

[Slawa Olhovchenkov]

On Sat, Jul 23, 2022 at 04:11:01AM +0400, Sergey Kandaurov wrote:

> On Fri, Jul 22, 2022 at 06:57:53PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote:
> > 
> > > а что показывает в хедере Location, если сделать "return 301 /path" ?
> > > там абсолютный адрес со схемой или относительный ?
> > 
> > абсолютный со схемой
> 
> Используйте директиву absolute_redirect для относительных редиректов.

я же прямо пишу в конфиге директива return 301 /path
и менять эти (и другие аналогичные места) я не хочу.

> > 
> > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov :
> > > 
> > > > Как на уровне сервера для return задать другую схему?
> > > > т.е. в конфиге что бы можно было писать 'return 301 /path'
> > > > сам nginx работает на http, но есть вариант что через проксю с
> > > > терминацией https на ней и в этом случае хотелось бы что бы
> > > > 'return 301 /path' использовал https.
> > > >
> > > > и map и set на $scheme ругаются: the duplicate "scheme" variable
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Поменять дефолтную $scheme с http на https

[Slawa Olhovchenkov]

On Fri, Jul 22, 2022 at 09:09:14PM +0500, Илья Шипицин wrote:

> а если сделать не "return 301 /path", а абсолютный урл, так работает ?
> или задача именно в том, чтобы возвращать https не указывая абсолютного
> урла ?

задача в том, что бы не переписывать конфиг сервера (который типа от
какого nextcloud и этих ретурнов там до жопы и может не только return)

> пт, 22 июл. 2022 г. в 20:57, Slawa Olhovchenkov :
> 
> > On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote:
> >
> > > а что показывает в хедере Location, если сделать "return 301 /path" ?
> > > там абсолютный адрес со схемой или относительный ?
> >
> > абсолютный со схемой
> >
> > > пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov :
> > >
> > > > Как на уровне сервера для return задать другую схему?
> > > > т.е. в конфиге что бы можно было писать 'return 301 /path'
> > > > сам nginx работает на http, но есть вариант что через проксю с
> > > > терминацией https на ней и в этом случае хотелось бы что бы
> > > > 'return 301 /path' использовал https.
> > > >
> > > > и map и set на $scheme ругаются: the duplicate "scheme" variable
> > > > ___
> > > > nginx-ru mailing list -- nginx-ru@nginx.org
> > > > To unsubscribe send an email to nginx-ru-le...@nginx.org
> > > >
> >
> > > ___
> > > nginx-ru mailing list -- nginx-ru@nginx.org
> > > To unsubscribe send an email to nginx-ru-le...@nginx.org
> >
> > ___
> > nginx-ru mailing list -- nginx-ru@nginx.org
> > To unsubscribe send an email to nginx-ru-le...@nginx.org
> >

> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Поменять дефолтную $scheme с http на https

[Slawa Olhovchenkov]

On Fri, Jul 22, 2022 at 08:47:12PM +0500, Илья Шипицин wrote:

> а что показывает в хедере Location, если сделать "return 301 /path" ?
> там абсолютный адрес со схемой или относительный ?

абсолютный со схемой

> пт, 22 июл. 2022 г. в 20:13, Slawa Olhovchenkov :
> 
> > Как на уровне сервера для return задать другую схему?
> > т.е. в конфиге что бы можно было писать 'return 301 /path'
> > сам nginx работает на http, но есть вариант что через проксю с
> > терминацией https на ней и в этом случае хотелось бы что бы
> > 'return 301 /path' использовал https.
> >
> > и map и set на $scheme ругаются: the duplicate "scheme" variable
> > ___
> > nginx-ru mailing list -- nginx-ru@nginx.org
> > To unsubscribe send an email to nginx-ru-le...@nginx.org
> >

> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Поменять дефолтную $scheme с http на https

[Slawa Olhovchenkov]

Как на уровне сервера для return задать другую схему?
т.е. в конфиге что бы можно было писать 'return 301 /path'
сам nginx работает на http, но есть вариант что через проксю с
терминацией https на ней и в этом случае хотелось бы что бы
'return 301 /path' использовал https.

и map и set на $scheme ругаются: the duplicate "scheme" variable
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Мусорные запросы

[Slawa Olhovchenkov]

On Wed, Apr 27, 2022 at 02:17:52PM +0500, Илья Шипицин wrote:

> ср, 27 апр. 2022 г. в 13:53, alexander_st :
> 
> > Илья Шипицин Wrote:
> > ---
> > > если у вас "access forbidden by rule", то по сути вы и так эти
> > > запросы
> > > блокируете (на уровне nginx, не iptables).
> > > можно сделать "access_log off;" и забыть
> > g
> > > >
> > > ___
> > > nginx-ru mailing list -- nginx-ru@nginx.org
> > > To unsubscribe send an email to nginx-ru-le...@nginx.org
> >
> > Есть желание именно на уровне iptables это сделать. Все равно, когда до
> > nginx эти запросы долетают, тратятся его ресурсы.
> >
> 
> теоретически на машинерию, которая парсит логи и управляет iptables может
> уйти больше ресурсов.
> ну и, всякий ISP NAT, когда домашний провайдер с одного адреса выпускает
> целый город. вы весь город отправите в бан.

ну ты сравнил, тут на кону стоит судьба двух микроватов, которые
сожрет нгинкс, не время беспокоится о судьбе городов.
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Тонкости работы FastCGI (phpfpm)

[Slawa Olhovchenkov]

On Wed, Apr 21, 2021 at 02:58:21PM +0700, Victor Sudakov wrote:

> Тут у меня еще сработали ассоциации с обычным CGI. Там ведь насколько я
> помню, закрыли stdin CGI-скрипту - и скрипт сразу прекратил выполнение.
> Или тоже помню неверно?

неверно
ничего со скриптом не случается пока он не будет читать или писать в
закрытый сокет

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Тонкости работы FastCGI (phpfpm)

[Slawa Olhovchenkov]

On Tue, Apr 13, 2021 at 02:46:57PM +0700, Victor Sudakov wrote:

> greenh wrote:
> > Nginx закроет соединение, а php код будет работать до того момента, пока не
> > наступит max_time_limit в самом пхп, либо, если он будет установлен в 0 -
> > то безконечно.
> 
> Вот это плохо.
> 
> А почему так? Ведь обычная программа (не демон), как правило,
> завершается или хотя бы останавливается, если ей каналы ввода-вывода
> закрыли.

да нет же.
это твои влажные фантазии.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

[Slawa Olhovchenkov]

On Thu, Apr 08, 2021 at 07:03:19PM +0600, raven...@megaline.kg wrote:

> По поводу скорости - да, я возможно не совсем корректно охарактеризовал 
> суть в теме, каюсь. А какую смысловую нагрузку несет ваш выпад?)
> 
> 08.04.2021 18:56, Slawa Olhovchenkov пишет:
> > On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:
> >
> > топквотинг
> >
> >
> Сударь использует GPRS?)
> 

такую, что в топквотинговой переписке я объяснений давать не буду

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

[Slawa Olhovchenkov]

On Thu, Apr 08, 2021 at 06:52:44PM +0600, raven...@megaline.kg wrote:

топквотинг

> Я не отрицаю, что ssl требует больше времени на шифрование. Но почему 
> оно более чем в 2 раза для ttfb?

не

> 08.04.2021 18:46, Slawa Olhovchenkov пишет:

надо

> > On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:

использовать

> >> Доброго дня!
> >>
> >> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.

и время до первого байта

> >> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> > а откуда идея что должно быть иначе?
> > ___
> > nginx-ru mailing list

и путать

> > nginx-ru@nginx.org

скорость

> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

[Slawa Olhovchenkov]

On Thu, Apr 08, 2021 at 03:48:38PM +0300, Константин Ткаченко wrote:

> >> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
> >> 
> >> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> > 
> > а откуда идея что должно быть иначе?
> 
> Google активно пиарит, что первый байт должен быстро приходить вот и сеошники 
> мучают админов.

покажи цитату из которой следует что первый байт в случае https должен
приходить так же быстро или быстрее как в случае http.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Низкая скорость передачи данных при использовании https

[Slawa Olhovchenkov]

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven...@megaline.kg wrote:

> Доброго дня!
> 
> nginx 1.18.0, собран с OpenSSL 1.1.1c FIPS.
> 
> Замечено, что по https отдача первого байта происходит на 200мс дольше.

а откуда идея что должно быть иначе?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

$uri для try_files

[Slawa Olhovchenkov]

А есть какой-то способ в случае try_files логировать не имя файла,
которе совпало, а собственно текущий uri?

$request_uri не подходит т.к. во-первых с аргументами, во-вторых потом
его через rewrite прогнали. Т.е. я хочу в лог записать без аргументов,
после rewrite, но не результат try_files.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location / внутри location /

[Slawa Olhovchenkov]

On Wed, Jan 27, 2021 at 08:35:41PM +0300, Maxim Dounin wrote:

> > > > а кстати, есть ли какой-то более изящный способ сделать внутрений
> > > > редирект на @proxy в данном случае?
> > > 
> > > Можно сделать 
> > > 
> > > error_page 418 @proxy;
> > > return 418;
> > > 
> > > "Более изящный" ли это способ - затрудняюсь сказать, но более 
> > > смешной.
> > > 
> > > Более правильным в данном случае будет просто прописать 
> > > проксирование явно.
> > 
> > в смысле два раза копировать конфигурацию прокси?
> > она сильно развесистая, не хотелось бы дублирования.
> 
> Конфигурацию прокси можно задать на уровне http или server, а в 
> соответствующих location'ах писать исключительно proxy_pass.  Если 

в том числе и proxy_cache proxy_hide_header aws_sign ?

> конфигурацию зачем-то требуется задавать непосредственно в 
> location - то это можно сделать с помощью директивы include.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location / внутри location /

[Slawa Olhovchenkov]

On Wed, Jan 27, 2021 at 07:07:35PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Jan 27, 2021 at 06:43:10PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > А возможна ли конструкция типа такой:
> > > > 
> > > > location / {
> > > >rewrite ;
> > > >rewrite ;
> > > >location ~ /../(..)... {
> > > >  try_files /$2/$3/$2$3$4_$1.bin @proxy;
> > > >}
> > > >location / {
> > > >  try_files /notexist @proxy;
> > > >}
> > > > }
> > > > location @proxy {
> > > > }
> > > > 
> > > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с
> > > > апстрима, а что под маску попадает -- проверять на диске и если нет --
> > > > брать с апстрима.
> > > 
> > > Возможна.  Впрочем, в предложенной конструкции вложенный "location /" 
> > > избыточен, его содержимое можно написать непосредственно во 
> > > внешнем "location /".
> > 
> > а кстати, есть ли какой-то более изящный способ сделать внутрений
> > редирект на @proxy в данном случае?
> 
> Можно сделать 
> 
> error_page 418 @proxy;
> return 418;
> 
> "Более изящный" ли это способ - затрудняюсь сказать, но более 
> смешной.
> 
> Более правильным в данном случае будет просто прописать 
> проксирование явно.

в смысле два раза копировать конфигурацию прокси?
она сильно развесистая, не хотелось бы дублирования.

> > > Заодно и написанные во внешнем "location /" директивы rewrite 
> > > обретут какой-то смысл (впрочем, скорее всего по прежнему 
> > > неверный, так как эти директивы не применяются к запросам, 
> > > попавшим в любой из вложенных location'ов).
> > 
> > разве rewrite применяется не до разбора вложенных локейшинов?
> 
> Нет.  Дерево location'ов - общее, поиск подходящего location'а по 
> URI - это единая операция.  Директивы rewrite применяются из 
> найденного подходящего к запросу location'а.  Подробности 
> применения директив rewrite расписаны в описании модуля rewrite, 
> тут:
> 
> http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html

читал, но понял видимо неправильно, в том куске который "Если
директива указана внутри location, дальнейшая обработка запроса
продолжается в этом location.". я это понял так, что при наличии там
вложенных локейшинов подбор будет продолжен с них.

а почему, кстати, может игнориоваться директива set?
я по дебаг логу смотрю, попадаю во вложенный локейшен, там у меня есть
set но он даже выполняться не собирался.

да, сейчас туда скопированы rewrite.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location / внутри location /

[Slawa Olhovchenkov]

On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote:
> 
> > А возможна ли конструкция типа такой:
> > 
> > location / {
> >rewrite ;
> >rewrite ;
> >location ~ /../(..)... {
> >  try_files /$2/$3/$2$3$4_$1.bin @proxy;
> >}
> >location / {
> >  try_files /notexist @proxy;
> >}
> > }
> > location @proxy {
> > }
> > 
> > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с
> > апстрима, а что под маску попадает -- проверять на диске и если нет --
> > брать с апстрима.
> 
> Возможна.  Впрочем, в предложенной конструкции вложенный "location /" 
> избыточен, его содержимое можно написать непосредственно во 
> внешнем "location /".

а кстати, есть ли какой-то более изящный способ сделать внутрений
редирект на @proxy в данном случае?

> Заодно и написанные во внешнем "location /" директивы rewrite 
> обретут какой-то смысл (впрочем, скорее всего по прежнему 
> неверный, так как эти директивы не применяются к запросам, 
> попавшим в любой из вложенных location'ов).

разве rewrite применяется не до разбора вложенных локейшинов?
а они не наследуся ли, кстати?

да, я забыл в примере укзать, там рядом с rewrite у меня еще и
auth_request есть, это тоже добавит сложностей?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

location / внутри location /

[Slawa Olhovchenkov]

А возможна ли конструкция типа такой:

location / {
   rewrite ;
   rewrite ;
   location ~ /../(..)... {
 try_files /$2/$3/$2$3$4_$1.bin @proxy;
   }
   location / {
 try_files /notexist @proxy;
   }
}
location @proxy {
}

Ну т.е. смысл в том, что не попадает под маску -- сразу брать с
апстрима, а что под маску попадает -- проверять на диске и если нет --
брать с апстрима.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблемы со связностью по ipv6 сайта nginx.org

[Slawa Olhovchenkov]

On Fri, Sep 25, 2020 at 08:51:53PM +0300, Evgeniy Berdnikov wrote:

> On Fri, Sep 25, 2020 at 08:37:22PM +0300, Slawa Olhovchenkov wrote:
> > > теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но 
> > > отказались
> > 
> > побитно тогда уж!
> > как он не кратный четерем может быть-то?
> 
>  Анонсированный MSS -- запросто. :)) Вписал нечётный в правило, и вуаля.
>  Iptables пропустит и ядро линикса поставит. Насчёт фрюх и цисок не знаю.

ну и зачем дураков копировать?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблемы со связностью по ipv6 сайта nginx.org

[Slawa Olhovchenkov]

On Fri, Sep 25, 2020 at 10:30:01PM +0500, Илья Шипицин wrote:

> > > мы итерационно подошли к этой цифре.
> > > я попросил техподдержку эскалировать на меня кейсы, когда они
> > подкручивали
> > > MTU на клиенте.
> > >
> > > и на очередном клиенты мы по одному байту крутили
> >
> > а чего по байту-то?
> >
> 
> делением пополам, конечно.
> 
> я к сожалению не документировал шаги. самому было бы интересно посмотреть.
> из того, что вспоминается, было две итерации, когда подгоняли под клиента.
> 
> за первую мы снизились до 1456 кажется. и потом был еще один клиент, мы
> упали до 1416
> 
> теоретически, могла быть итерация с подгонкой под MTU ~ 1300, но отказались

побитно тогда уж!
как он не кратный четерем может быть-то?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблемы со связностью по ipv6 сайта nginx.org

[Slawa Olhovchenkov]

On Fri, Sep 25, 2020 at 09:54:36PM +0500, Илья Шипицин wrote:

> >> >   Насчёт "самая распостранённая" -- статистика есть? Как её вообще
> >> >  собирать?
> >> >
> >> >по нашей оценке 1 пользователь на 10 тысяч пользователей
> >> сталкивается с
> >> >поломанным MTU
> >>
> >>  Какое значение MSS анонсируют ваши серверы?
> >>
> >
> > 1416
> >
> >
> 
> мы итерационно подошли к этой цифре.
> я попросил техподдержку эскалировать на меня кейсы, когда они подкручивали
> MTU на клиенте.
> 
> и на очередном клиенты мы по одному байту крутили

а чего по байту-то?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: резолвятся не все имена host-файла

[Slawa Olhovchenkov]

On Thu, Sep 10, 2020 at 03:36:57PM +0300, Alexey Galygin wrote:

> не, grep'ом с нуля набивал
> 
> ‘c’ могла бы быть проблемой
> 
> но до того как сервис srv_c стал последним, проблемы были с srv_b …
> это что-то эфемерное, и от того так неприятно

хексдамп всего файла в студию

> > On 10 Sep 2020, at 15:01, Evgeniy Berdnikov  wrote:
> > 
> > On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote:
> >> почему резолвится только часть имён? да и что за чудеса, чем upstream так 
> >> помогает резолвингу?
> > 
> > Проверьте на стандартную ошибку: где-то имя написано с символом в кириллице
> > (скорее всего в конфиге nginx), а при проверках копи-пастилась откуда-то
> > без кириллицы. Обычным грепом легко это выявить, и hd помогает.
> > -- 
> > Eugene Berdnikov
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy timeout code

[Slawa Olhovchenkov]

On Thu, Sep 03, 2020 at 07:42:59PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Sep 03, 2020 at 07:38:55PM +0300, Slawa Olhovchenkov wrote:
> 
> > А есть какой-либо код у upstream timeout?
> > Хочется для auth_request по таймауту считать OK.
> > Ну а для этого прописать что-то типа
> > 
> > error_page XXX =200 /50x.html
> > 
> > Но что писать для XXX?
> 
> 504 Gateway Timeout
> https://tools.ietf.org/html/rfc7231#section-6.6.5

Спасибо, просто как-то в логах не обнаружил в явном виде.
А если так все апстримы будут заблокированны ("upstream server
temporarily disabled while reading response header from upstream"), то
с каким кодом будет auth_request фэйлится? (ну т.е. у него нет
живых апстримов)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy timeout code

[Slawa Olhovchenkov]

А есть какой-либо код у upstream timeout?
Хочется для auth_request по таймауту считать OK.
Ну а для этого прописать что-то типа

error_page XXX =200 /50x.html

Но что писать для XXX?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

[Slawa Olhovchenkov]

On Mon, Aug 31, 2020 at 06:11:17PM +0300, Alexey Galygin wrote:

> на тестовом запуске мы словили примерно 200 запросов к статике в секунду в 
> среднем (иногда больше, иногда меньше)
> в общем-то это не так уж и много (картинки, стили, документы
> 
> может быть такое, что если дисковая система стала медленнее (а судя по 
> косвенным замерам, которые я провёл, она медленнее в разы)
> то прежняя конфигурация nginx просто не успевает раздавать статику?
> 
> скорость сети больше чем скорость дисков
> запросов от клиентов приходит масса
> ком нарастает
> 
> процессы висят в статусе “D", медленно считывают и копят это в память
> 
> если отключить sendfile, включить aio, добавить ограничений, это поможет?

а у линукса aio научился в кешь?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

[Slawa Olhovchenkov]

On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:

> привет всем
>  
> случилось странное, переехали на сервера по параметрам в разы большие, чем 
> сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на 
> штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 
> 10%))
>  
> через 5 минут после старта nginx ест всю память и весь swap! (см. 
> https://prnt.sc/u8nia0 )
> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а 
> не БД!…
>  
> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 
> 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост 
> nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера 
> nginx:1.18.0)
>  
> из особенностей используются ngx_http_js_module.so — для исторического 
> escape/unescape URI и ngx_http_image_filter_module.so — для подрезки 
> изображений
>   
> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным 
> atime
> и из docker вынесли nginx в хост
>  
> и внутренние системы исключили…
>  
> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>  
> упорно кончается вся память через 5 минут, все 256 Гб и своп
>  
> идей практически не осталось, куда можно ещё копать?

Попробовать FreeBSD?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx proxy MISS

[Slawa Olhovchenkov]

On Mon, Aug 10, 2020 at 08:19:40PM +0300, Gena Makhomed wrote:

> On 10.08.2020 19:33, Slawa Olhovchenkov wrote:
> 
> >> Если не поможет - смотреть debug log'и, там всё должно быть
> >> плюс-минус очевидно.
> 
> > это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> > с них и начал бы).
> 
> http://nginx.org/ru/docs/ngx_core_module.html#debug_connection
> 
> разве не поможет сделать отладку прямо на проде?

и что я туда напишу?
нет, у меня так не со всеми клиентами.
нет, я не знаю чем отличаются те клиенты от которых MISS.
или после которых MISS.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx proxy MISS

[Slawa Olhovchenkov]

On Mon, Aug 10, 2020 at 08:16:49PM +0300, Maxim Dounin wrote:

> > это что, Vary: Origin гадит? фильтрануть его с бэкенда, что ли?
> 
> Это выглядит как наиболее вероятная причина.
> 
> При наличии "Vary: Origin" запросы с разными значениями заголовка 
> Origin - это запросы, на которые могут быть разные ответы, и 
> соответственно каждое новое значение - это очередной MISS в логах.
> 
> Для лечения есть ручка "proxy_ignore_headers Vary;" 
> (http://nginx.org/r/proxy_ignore_headers).

попробую, спасибо.

> > > Особенно в этом плане характерны запросы от одного клиента:
> > > 
> > > > 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> > > > 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> > > 
> > > 3. Ну и проверить, что вообще в ключе кэширования, не добавлено ли 
> > > там чего-либо клиентоспецифичного случайно.
> > 
> > вообще не модифицировалось
> 
> По умолчанию там конструкция, близкая к 
> $scheme$proxy_host$request_uri, и, скажем $proxy_host может 
> зависить от клиента, если в proxy_pass написать что-нибудь с 
> переменными.

не, такого нет. у меня proxy_pass тупо на upstream;

> > > Если не поможет - смотреть debug log'и, там всё должно быть 
> > > плюс-минус очевидно.
> > 
> > это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> > с них и начал бы).
> 
> Just in case, дебаг можно включать не для всех, а только для части 
> клиентов (http://nginx.org/r/debug_connection), это можно 
> относительно безопасно делать в том числе и в продакшне.  Следя, 
> естественно, чтобы не включить слишком много, и чтобы место под 
> логи не кончалось.

да кто ж знает что там за клиент(ы).
я просто заинтересовался чего это у меня MISS много?
дальше поел смотреть по какому URI из больше всего и почему бы это
могло быть.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx proxy MISS

[Slawa Olhovchenkov]

On Mon, Aug 10, 2020 at 07:13:22PM +0300, Maxim Dounin wrote:

> > > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
> > > времена приведены в логах, но $request_time там точно нет, а если 
> > 
> > $request_time $connection $upstream_cache_status $upstream_connect_time 
> > $upstream_response_time $upstream_bytes_received
> > 
> > > запросы общаются с бэкендом одновременно и proxy_cache_lock не 
> > 
> > да не вопрос.
> > 
> > > используется - то и MISS'ов может быть одновременно много, при 
> > > этом завершаться запросы могут в заметно разное время.
> > 
> > не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть 
> > в 21:01:47. апстрим отдался почти мгновенно.
> > теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.
> 
> Дальше имеет смысл смотреть на:
> 
> 1. Откуда вообще логи, с одной ли машины?  Такой разброс времени 
> при логгировании можно, конечно, получить при буферизированном 
> логгировании, но выглядит подозрительно.

с одной, буферезированно

> 2. Что на самом деле в заголовках ответов бэкенда?  Скажем, 
> наличие какого-нибудь Vary легко объясняет наблюдаемый эффект.  

я поищу объект в кеше на диске.
бакэнд -- ceph radosgw, он довстаточно тупой, кмк и ничего такого
выдавать не должен.
у типичного объекта заголовки выглядят так:

KEY:
http://rgw/xxxxxx/720p_00480.ts
HTTP/1.1 200 OK
Content-Length: 925524
Accept-Ranges: bytes
Last-Modified: Tue, 28 Jul 2020 11:24:38 GMT
x-rgw-object-type: Normal
ETag: "872d2e58236625d418f4c5b5b95938a6"
x-amz-request-id: tx004e0151a-005f316581-a67b17a-default
Access-Control-Allow-Origin: https://some.site
Vary: Origin
Access-Control-Allow-Methods: GET
Access-Control-Expose-Headers: Content-Length,Content-Type
Content-Type: video/MP2T
Date: Mon, 10 Aug 2020 15:19:29 GMT
Connection: close

это что, Vary: Origin гадит? фильтрануть его с бэкенда, что ли?

> Особенно в этом плане характерны запросы от одного клиента:
> 
> > 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts 
> > HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> > 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts 
> > HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> 
> 3. Ну и проверить, что вообще в ключе кэширования, не добавлено ли 
> там чего-либо клиентоспецифичного случайно.

вообще не модифицировалось

> Если не поможет - смотреть debug log'и, там всё должно быть 
> плюс-минус очевидно.

это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
с них и начал бы).
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx proxy MISS

[Slawa Olhovchenkov]

On Mon, Aug 10, 2020 at 06:38:11PM +0500, Илья Шипицин wrote:

> а содержимое файла /720p_02815.ts может меняться ?

я же показал что таймстамп июньский.

> если контент уникален, может включить proxy store ?

а как объем контролировать и устаревание?
и в принципе да, содержимое меняться теоретически может.

> пн, 10 авг. 2020 г. в 18:04, Slawa Olhovchenkov :
> 
> > On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:
> >
> > > Hello!
> > >
> > > On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> > >
> > > > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > > >
> > > > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > > >
> > > > > > Response: {'status': 200, 'headers': {'content-length': '615700',
> > 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified':
> > 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag':
> > '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > > > > >  'tx00451618a-005f306158-a6edb7b-default', 'date':
> > 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason':
> > 'OK'}
> > > > > >
> > > > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET
> > /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]"GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300] "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]"GET
> > /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > > >
> > > > > > какие причины могут быть для возникновения MISS?
> > > > > >
> > > > > > зона не заполнена даже наполовину.
> > > > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2
> > max_size=6000g inactive=10d use_temp_path=off;
> > > > >
> > > > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь
> > > > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы
> > > > > причины для возникновения HIT?
> > > > >
> > > > > В отсутствии явно заданных заголовков Cache-Control / Expire /
> > > > > X-Accel-Expire - единственная возможная причина кэширования это
> > > > > директива proxy_cache_valid, если она в конфиге есть - то
> > > > > вероятнее всего отвечает на оба вопроса.
> > > >
> > > > proxy_cache_valid  200  5d;
> > >
> > > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за
> > > времена приведены в логах, но $request_time там точно нет, а если
> >
> > $request_time $connection $upstream_cache_status $upstream_connect_time
> > $upstream_response_time $upstream_bytes_received
> >
> > > запросы общаются с бэкендом одновременно и proxy_cache_lock не
> >
> > да не вопрос.
> >
> > > используется - то и MISS'ов может быть одновременно много, при
> > > этом завершаться запросы могут в заметно разное время.
> >
> > не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пу

Re: nginx proxy MISS

[Slawa Olhovchenkov]

On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> 
> > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > 
> > > > Response: {'status': 200, 'headers': {'content-length': '615700', 
> > > > 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 
> > > > 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 
> > > > 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 
> > > > 'x-amz-request-id':
> > > >  'tx00451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 
> > > > Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
> > > >  
> > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]"GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300] "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616330 HIT - - -
> > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]"GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616316 HIT - - -
> > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts 
> > > > HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > 
> > > > какие причины могут быть для возникновения MISS?
> > > > 
> > > > зона не заполнена даже наполовину.
> > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g 
> > > > inactive=10d use_temp_path=off;
> > > 
> > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
> > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
> > > причины для возникновения HIT?
> > > 
> > > В отсутствии явно заданных заголовков Cache-Control / Expire / 
> > > X-Accel-Expire - единственная возможная причина кэширования это 
> > > директива proxy_cache_valid, если она в конфиге есть - то 
> > > вероятнее всего отвечает на оба вопроса.
> > 
> > proxy_cache_valid  200  5d;
> 
> Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
> времена приведены в логах, но $request_time там точно нет, а если 

$request_time $connection $upstream_cache_status $upstream_connect_time 
$upstream_response_time $upstream_bytes_received

> запросы общаются с бэкендом одновременно и proxy_cache_lock не 

да не вопрос.

> используется - то и MISS'ов может быть одновременно много, при 
> этом завершаться запросы могут в заметно разное время.

не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть в 
21:01:47. апстрим отдался почти мгновенно.
теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.

188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts 
HTTP/1.1" 200 616330 0.106 78233513 MISS 0.000 0.016 616206
212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts 
HTTP/1.1" 200 616330 0.409 71530389 HIT - - -
109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts 
HTTP/1.1" 200 616330 0.106 78883331 HIT - - -
165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET /720p_02815.ts 
HTTP/1.1" 200 616330 0.045 78875231 MISS 0.000 0.043 616196
176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts 
HTT

Re: nginx proxy MISS

[Slawa Olhovchenkov]

On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> 
> > Есть файл, не меняется, заголовков про expire не имеет.
> > 
> > Response: {'status': 200, 'headers': {'content-length': '615700', 
> > 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 
> > 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': 
> > '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> >  'tx00451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 
> > 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
> >  
> > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]"GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300] "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts 
> > HTTP/1.1" 200 616330 HIT - - -
> > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]"GET /720p_02815.ts 
> > HTTP/1.1" 200 616316 HIT - - -
> > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts 
> > HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > 
> > какие причины могут быть для возникновения MISS?
> > 
> > зона не заполнена даже наполовину.
> > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g 
> > inactive=10d use_temp_path=off;
> 
> Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
> не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
> причины для возникновения HIT?
> 
> В отсутствии явно заданных заголовков Cache-Control / Expire / 
> X-Accel-Expire - единственная возможная причина кэширования это 
> директива proxy_cache_valid, если она в конфиге есть - то 
> вероятнее всего отвечает на оба вопроса.

proxy_cache_valid  200  5d;

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx proxy MISS

[Slawa Olhovchenkov]

Есть файл, не меняется, заголовков про expire не имеет.

Response: {'status': 200, 'headers': {'content-length': '615700', 
'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 
08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': 
'"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
 'tx00451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 
2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
 
188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts 
HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]"GET /720p_02815.ts 
HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]"GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300] "GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts 
HTTP/1.1" 200 616330 HIT - - -
5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]"GET /720p_02815.ts 
HTTP/1.1" 200 616316 HIT - - -
95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts 
HTTP/1.1" 200 616316 MISS 0.000 0.020 616032

какие причины могут быть для возникновения MISS?

зона не заполнена даже наполовину.
proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g 
inactive=10d use_temp_path=off;
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: tcpdump tls

[Slawa Olhovchenkov]

On Mon, Jul 27, 2020 at 02:44:37PM +0500, Илья Шипицин wrote:

> у chrome есть net-internals
> 
> https://support.google.com/chrome/a/answer/6271171?hl=en

интересная штука, но похоже SSL там в нерасшифрованном виде и вопрос
ключей остается.

> пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov :
> 
> > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
> >
> > > 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> > >
> > > > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > > >
> > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > > > типа
> > > >
> > > > 
> > > > Server's response
> > > >
> > > > Full response:
> > > > 0 Missing status code HTTP/1.1
> > > > =
> > > >
> > > >
> > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > > > именно пришло.
> > >
> > > В случае сеансовых ключей RSA можно попробовать в Wireshark:
> > > меню Редактирование/Параметры (Edit/Preference),
> > > дальше Protocols/TLS и там есть место вставить серверный ключ.
> >
> > И брать его из браузера? Как?
> >
> > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> > > дампить сессионные ключи, чтобы потом можно было их использовать в
> > Wireshark,
> > > в (Pre)-Master-Secret log filename.
> >
> > Отлично, меня это устроит, какие ключевые слова гуглить?
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru

> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: tcpdump tls

[Slawa Olhovchenkov]

On Mon, Jul 27, 2020 at 04:32:20PM +0700, Eugene Grosbein wrote:

> 27.07.2020 16:15, Slawa Olhovchenkov пишет:
> > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
> 
> >> В случае сеансовых ключей RSA можно попробовать в Wireshark:
> >> меню Редактирование/Параметры (Edit/Preference),
> >> дальше Protocols/TLS и там есть место вставить серверный ключ.
> > 
> > И брать его из браузера? Как?
> 
> Тут имелся в виду фиксированный серверный приватный ключ.
> 
> >> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> >> дампить сессионные ключи, чтобы потом можно было их использовать в 
> >> Wireshark,
> >> в (Pre)-Master-Secret log filename.
> > 
> > Отлично, меня это устроит, какие ключевые слова гуглить?
> 
> Я гуглил так: wireshark decode https
> Второй ссылкой было https://support.citrix.com/article/CTX116557
> How to Decrypt SSL and TLS Traffic Using Wireshark
> 
> Четвертой https://wiki.wireshark.org/TLS#TLS_Decryption

Key logging is enabled by setting the environment variable
SSLKEYLOGFILE to point to a file. Note: starting with NSS 3.24 (used
by Firefox 48 and 49 only), the SSLKEYLOGFILE approach is disabled by
default for optimized builds using the Makefile (those using gyp via
build.sh are not affected). Distributors can re-enable it at compile
time though (using the NSS_ALLOW_SSLKEYLOGFILE=1 make variable) which
is done for the official Firefox binaries. (See bug 1188657.) Notably,
Debian does not have this option enabled, see Debian bug 842292.

и народ на SO жалуется что хромы не пишут. даже с  --ssl-key-log-file.

The SSLKEYLOGFILE was originally disabled when the Mozilla team were
debugging an NSS issue in Firefox 65. I had reported the bug here
originally. It was subsequently reenabled in Firefox 66. However, once
again for Firefox 67 it had accidentally been disabled in release
builds again. I once again reopened that original bugzilla ticket to
report it. And they then opened up a new bugzilla task that you linked
in your post. A recent commit has removed the conditional that should
now prevent that bug from reoccurring in future releases. My guess,
the SSLKEYLOGFILE env. variable will work again when Firefox 68
releases, and on some Nightly version very shortly.

ну ок, я понял как это врубить по крайне мере у себя.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: tcpdump tls

[Slawa Olhovchenkov]

On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:

> 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> 
> > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > 
> > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > типа
> > 
> > 
> > Server's response
> > 
> > Full response:
> > 0 Missing status code HTTP/1.1
> > =
> > 
> > 
> > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > именно пришло.
> 
> В случае сеансовых ключей RSA можно попробовать в Wireshark:
> меню Редактирование/Параметры (Edit/Preference),
> дальше Protocols/TLS и там есть место вставить серверный ключ.

И брать его из браузера? Как?

> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark,
> в (Pre)-Master-Secret log filename.

Отлично, меня это устроит, какие ключевые слова гуглить?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: tcpdump tls

[Slawa Olhovchenkov]

On Mon, Jul 27, 2020 at 09:56:16AM +0300, Evgeniy Berdnikov wrote:

> On Sun, Jul 26, 2020 at 08:47:40PM +0300, Slawa Olhovchenkov wrote:
> > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> 
>  Это 7 вёрст крюк, проще включить на сервере debug log...

иногда и в сервере бывают баги и хочется понять какая черепашка врет.
(бага может быть и в драйвере сетевухи)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: tcpdump tls

[Slawa Olhovchenkov]

On Sun, Jul 26, 2020 at 08:58:00PM +0300, Daniel Podolsky wrote:

> только на спецом сконфигурированных ciphers. но, вообще-то, это гуглится.

в пору персонализированного гугла что угодно может оказаться
неглибельным

PS: да, я попытался погуглить. возможно неправильно запрос задал.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

tcpdump tls

[Slawa Olhovchenkov]

А что-как можно сделать что бы расшифровать https сессию в .pcap?

Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
типа


Server's response

Full response:
0 Missing status code HTTP/1.1
=


и я хочу своими глазами увидеть что конкретно ему отправилось и что
именно пришло.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: json log и "экранирование" неопределенных переменных

[Slawa Olhovchenkov]

On Sun, Jul 26, 2020 at 10:07:23PM +0500, Илья Шипицин wrote:

> вс, 26 июл. 2020 г. в 22:05, Slawa Olhovchenkov :
> 
> > On Sun, Jul 26, 2020 at 09:52:35PM +0500, Илья Шипицин wrote:
> >
> > > > https://stackoverflow.com/questions/21120999/representing-null-in-json
> > > >
> > > > в предположении что значение числовое.
> > > >
> > >
> > > а как правильно ескейпить "0.001, - , 0.002"
> >
> 
> первый бекенд вернул 503
> второй сбросил tcp
> третий вернул 200

а, ок.
ну в общем я вариант сказал.

а может даже так [0.001,null,0.002]

> и у меня proxy_next_upstream http_503
> 
> 
> >
> > да, хороший вопрос
> > только почему у нас два ответа?
> >
> > но я думаю что если одно число -- то как число
> > если ничего -- не было обращений к апстирму -- null
> > иначе строка в кавычках.
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru

> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: json log и "экранирование" неопределенных переменных

[Slawa Olhovchenkov]

On Sun, Jul 26, 2020 at 09:52:35PM +0500, Илья Шипицин wrote:

> > https://stackoverflow.com/questions/21120999/representing-null-in-json
> >
> > в предположении что значение числовое.
> >
> 
> а как правильно ескейпить "0.001, - , 0.002"

да, хороший вопрос
только почему у нас два ответа?

но я думаю что если одно число -- то как число
если ничего -- не было обращений к апстирму -- null
иначе строка в кавычках.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: json log и "экранирование" неопределенных переменных

[Slawa Olhovchenkov]

On Sun, Jul 26, 2020 at 07:29:04PM +0300, Валентин Бартенев wrote:

> On Sunday, 26 July 2020 19:15:20 MSK Slawa Olhovchenkov wrote:
> > On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:
> > 
> > > 
> > > > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov  wrote:
> > > > 
> > > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > > они идут как "-". может в этом случае их выводить как null?
> > > 
> > > Такая подстановка используется в эскейпинге по умолчанию,
> > > если значение переменной не найдено.  В других форматах
> > > эскейпинга значение не выводится, подробнее здесь:
> > > http://nginx.org/r/log_format/ru
> > 
> > ну по спецификации json отстувиие должно кодироваться как null, не?
> 
> Это где такое написано? 

https://stackoverflow.com/questions/21120999/representing-null-in-json

в предположении что значение числовое.

в любом случае варианта выводить ничего нет -- для чисел будет не
валидный json, а все числа пихать в виде строк в "" -- как-то тоже
кажется неправильным.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: json log и "экранирование" неопределенных переменных

[Slawa Olhovchenkov]

On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:

> 
> > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov  wrote:
> > 
> > Внезапно выяснилось что если пишем в json формате (ну ок,
> > экранирование json), то отсутсвующе числовые значения все ломают.
> > они идут как "-". может в этом случае их выводить как null?
> 
> Такая подстановка используется в эскейпинге по умолчанию,
> если значение переменной не найдено.  В других форматах
> эскейпинга значение не выводится, подробнее здесь:
> http://nginx.org/r/log_format/ru

ну по спецификации json отстувиие должно кодироваться как null, не?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и завышение трафика.

[Slawa Olhovchenkov]

On Thu, Jul 23, 2020 at 08:22:34PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Thu, Jul 23, 2020 at 06:54:16PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Thu, Jul 23, 2020 at 06:27:49PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
> > > > два раза больше того что учитывается сетевым оборудованием.
> > > > 
> > > > В чем может быть дело? Куда копать?
> > > 
> > > Что значит "трафик который он считает отданным клиенту"?  Речь про 
> > > сумму значений переменных $bytes_sent?  Эта переменная отражает 
> > > количество байт, отправелнных клиенту, то есть записанных в буфер 
> > > сокета.  Что дальше с этими байтами происходило - nginx'у 
> > > незвестно, если клиент их получать на уровне TCP не стал и закрыл 
> > > соединение - то значение $bytes_sent может быть больше, чем ушло 
> > > через интерфейс, на размер буфера сокета.  Дальше уже вопрос к 
> > > типичным размерам ответов, размерам буферов и поведению клиентов.
> > 
> > это все понятно и очевидно, но два раза -- это два раза.
> > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > закрывать не должны.
> 
> Ну вот столь же очевидное место практической проверки - 
> предположение про "не должны".  Если действительно не закрывают - 
> есть повод для разбирательства, а если таки закрывают - то 
> наблюдаемый эффект хорошо объясняется поведением клиентов.
> 
> При таких размерах ответ скорее всего целиком влезает в буфер 
> сокета, и два раза - это примерно каждый второй ответ остался 
> неотправленным.  Должно быть хорошо видно, если сличать глазами 
> логи и пакеты к соответствующим клиентам из дампа траффика.

Всё-таки это клиенты.
Они закрывают сокет иной раз после отправки им 50кб ответа (из 256кб
буфера).
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: json log и "экранирование" неопределенных переменных

[Slawa Olhovchenkov]

On Fri, Jul 24, 2020 at 04:17:11PM +0500, Илья Шипицин wrote:

> через map можете назначить свою переменную и логировать уже ее.

ну вот для upstream_response_time так прокатит ли?
и не правильней ли все же при экранировании json это делать на уровне mod_log?

> а что за переменные ? просто, там есть, например, upstream_response_time,
> он может быть числом (если ответил один бекенд), прочерком (если не ответил
> ни один), и комбинацией чисел и прочерков через запятую (если несколько
> бекендов зафейлили, а последний ответил)

вообще да, именно он.

> пт, 24 июл. 2020 г. в 16:14, Slawa Olhovchenkov :
> 
> > Внезапно выяснилось что если пишем в json формате (ну ок,
> > экранирование json), то отсутсвующе числовые значения все ломают.
> > они идут как "-". может в этом случае их выводить как null?
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru

> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

json log и "экранирование" неопределенных переменных

[Slawa Olhovchenkov]

Внезапно выяснилось что если пишем в json формате (ну ок,
экранирование json), то отсутсвующе числовые значения все ломают.
они идут как "-". может в этом случае их выводить как null?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и завышение трафика.

[Slawa Olhovchenkov]

On Thu, Jul 23, 2020 at 11:08:43PM +0500, Илья Шипицин wrote:

> чт, 23 июл. 2020 г. в 22:39, Slawa Olhovchenkov :
> 
> >
> > On Thu, Jul 23, 2020 at 08:33:25PM +0300, Evgeniy Berdnikov wrote:
> >
> > > On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> > > > On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
> > > ...
> > > > >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> > > > >  адресовать претензии к nginx или к канальному оборудованию.
> > > >
> > > > я не понимаю к чему это все, я уже сказал -- канальное оборудование
> > > > (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> > > > чем по учету bytes_sent.
> > >
> > >  Чтобы понять, какая из двух линеек крива, следует приложить третью.
> >
> > Что непонятно в следующем утверждении: счетчики l2 от операционной
> > системы и свича совпадают? Это канает как две дополнительных линейки?
> >
> > >  А чтобы не путаться в лесу, лучше всего изучить отдельную сосну.
> > >
> > >  Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
> > >  аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
> > >  и ретрансмиссий, но тогда они в дампе будут отлично видны.
> >
> > Откуда я для одной конекции возьму аппартные счетчики?
> >
> > Каким образом 50% заголовков и ретрансмиссий дадут вдвое меньше
> > трафика на апапртаных счетчиках?
> >
> 
> а подзапросы используются ?

для auth_request

> конфиг это proxy_pass или что-то хитрее ?

auth_request
aws_sign (но он трафика не делает)
proxy_cache

ну и переписывание URI.

что еще может влиять?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и завышение трафика.

[Slawa Olhovchenkov]

On Thu, Jul 23, 2020 at 08:33:25PM +0300, Evgeniy Berdnikov wrote:

> On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> > On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
> ...
> > >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> > >  адресовать претензии к nginx или к канальному оборудованию.
> > 
> > я не понимаю к чему это все, я уже сказал -- канальное оборудование
> > (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> > чем по учету bytes_sent.
> 
>  Чтобы понять, какая из двух линеек крива, следует приложить третью.

Что непонятно в следующем утверждении: счетчики l2 от операционной
системы и свича совпадают? Это канает как две дополнительных линейки?

>  А чтобы не путаться в лесу, лучше всего изучить отдельную сосну.
> 
>  Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
>  аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
>  и ретрансмиссий, но тогда они в дампе будут отлично видны.

Откуда я для одной конекции возьму аппартные счетчики?

Каким образом 50% заголовков и ретрансмиссий дадут вдвое меньше
трафика на апапртаных счетчиках?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и завышение трафика.

[Slawa Olhovchenkov]

On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:

> On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> > это все понятно и очевидно, но два раза -- это два раза.
> > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > закрывать не должны.
> 
>  Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
>  Эта утилита прямо номера байт с начала коннекции покажет.
>  В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
>  Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
>  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
>  адресовать претензии к nginx или к канальному оборудованию.

я не понимаю к чему это все, я уже сказал -- канальное оборудование
(системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
чем по учету bytes_sent.

PS: а что, ssl как-то хитро bytes_sent искажает?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx и завышение трафика.

[Slawa Olhovchenkov]

On Thu, Jul 23, 2020 at 06:54:16PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Jul 23, 2020 at 06:27:49PM +0300, Slawa Olhovchenkov wrote:
> 
> > В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
> > два раза больше того что учитывается сетевым оборудованием.
> > 
> > В чем может быть дело? Куда копать?
> 
> Что значит "трафик который он считает отданным клиенту"?  Речь про 
> сумму значений переменных $bytes_sent?  Эта переменная отражает 
> количество байт, отправелнных клиенту, то есть записанных в буфер 
> сокета.  Что дальше с этими байтами происходило - nginx'у 
> незвестно, если клиент их получать на уровне TCP не стал и закрыл 
> соединение - то значение $bytes_sent может быть больше, чем ушло 
> через интерфейс, на размер буфера сокета.  Дальше уже вопрос к 
> типичным размерам ответов, размерам буферов и поведению клиентов.

это все понятно и очевидно, но два раза -- это два раза.
типичный размер ответа -- 400кб, клиенты сокет до получения ответа
закрывать не должны.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx и завышение трафика.

[Slawa Olhovchenkov]

В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
два раза больше того что учитывается сетевым оборудованием.

В чем может быть дело? Куда копать?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: rewrite и ngx_aws_auth

[Slawa Olhovchenkov]

On Wed, Jul 22, 2020 at 05:07:20PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Jul 22, 2020 at 04:27:58PM +0300, Slawa Olhovchenkov wrote:
> 
> > Пытаюсь подружить rewrite и ngx_aws_auth и выходит что-то странное.
> > 
> > в конфигурации локейшена у меня
> > 
> > rewrite /(.*) /$host/$1;
> > rewrite /([^.]+)[^/]+/(.*) /$1/$2 break;
> > aws_sign;
> > 
> > В дебаге видно что rewrite uri меняет, а ngx_aws_auth получает
> > немодифицированный uri.
> > 
> > если в локейшине написать if -- ngx_aws_auth вообще не срабатывает
> > (хотя тут я могу догадаться что он не наследуется).
> > 
> > Отсюда вопросы:
> > 
> > что за фигня?
> > что происходит?
> > какую переменную на самом деле меняет rewrite?
> 
> Заглянул в код этого ngx_aws_auth, всплакнул.

да я уже неделю матерюсь. он еще и переменных где надо не понимает.

> Всё правильно, работать не будет.  И не только после rewrite'а, но 
> и в других непредсказуемых ситуациях - при наличии аргументов в 
> запросе модуль лезет в r->uri_start, значение которого имее смысл 
> только в момент парсинга URI и не гарантируется в остальное 
> время[1][2].  
> 
> Лечится переписыванием модуля, чтобы использовал r->uri всегда.

Ах вот оно как. Отлично, это из-за аргументов, а мне они нахрен не
нужны.
Отрезание помогает.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

rewrite и ngx_aws_auth

[Slawa Olhovchenkov]

Пытаюсь подружить rewrite и ngx_aws_auth и выходит что-то странное.

в конфигурации локейшена у меня

rewrite /(.*) /$host/$1;
rewrite /([^.]+)[^/]+/(.*) /$1/$2 break;
aws_sign;

В дебаге видно что rewrite uri меняет, а ngx_aws_auth получает
немодифицированный uri.

если в локейшине написать if -- ngx_aws_auth вообще не срабатывает
(хотя тут я могу догадаться что он не наследуется).

Отсюда вопросы:

что за фигня?
что происходит?
какую переменную на самом деле меняет rewrite?



___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: auth_request и переменные в proxy_pass

[Slawa Olhovchenkov]

On Tue, Jul 21, 2020 at 09:22:36PM +0300, Slawa Olhovchenkov wrote:

> On Tue, Jul 21, 2020 at 08:47:15PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Tue, Jul 21, 2020 at 08:22:50PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> > > > 
> > > > > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > > > > auth_request никакие переменые от rewrite и/или $arg_ использовать не 
> > > > > удастся?
> > > > 
> > > > Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
> > > 
> > > ну вот попытка сделать set (блоком выше и потом использовать
> > > переменную) у меня как-то не сработала -- пусто.
> > > а set -- это rewrite только в порфиль.
> > 
> > Видимо, "как-то не сработала" по каким-то другим причинам.  
> > Скажем, если делать set на уровне server - то он потом ещё раз 
> > сделается в подзапросе, и результат может быть отличен от 
> > ожидаемого (особенно если этот set использует переменные $arg_*, 
> > которые в подзапросе будут иметь другие значения).
> 
> Возможно.
> Сейчас еще раз перепрверил -- таки работает.

А rewrite внутри location с auth_request срабатывает до или после
сабреквеста?
можно ли в нем использовать результат  auth_request_set?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: auth_request и переменные в proxy_pass

[Slawa Olhovchenkov]

On Tue, Jul 21, 2020 at 08:47:15PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Tue, Jul 21, 2020 at 08:22:50PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > > > auth_request никакие переменые от rewrite и/или $arg_ использовать не 
> > > > удастся?
> > > 
> > > Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
> > 
> > ну вот попытка сделать set (блоком выше и потом использовать
> > переменную) у меня как-то не сработала -- пусто.
> > а set -- это rewrite только в порфиль.
> 
> Видимо, "как-то не сработала" по каким-то другим причинам.  
> Скажем, если делать set на уровне server - то он потом ещё раз 
> сделается в подзапросе, и результат может быть отличен от 
> ожидаемого (особенно если этот set использует переменные $arg_*, 
> которые в подзапросе будут иметь другие значения).

Возможно.
Сейчас еще раз перепрверил -- таки работает.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: auth_request и переменные в proxy_pass

[Slawa Olhovchenkov]

On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> 
> > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > auth_request никакие переменые от rewrite и/или $arg_ использовать не 
> > удастся?
> 
> Почему нет?  Ну то есть с переменными от модуля rewrite вообще 

ну вот попытка сделать set (блоком выше и потом использовать
переменную) у меня как-то не сработала -- пусто.
а set -- это rewrite только в порфиль.

> никаких проблем быть не должно, а в части $arg_* важно понимать, 
> что они будут не от исходного запроса, а от подзапроса 
> аутентификации (и скорее всего пустые, ибо директива auth_request 
> принимает URI без аргументов).

Ах вот как.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: auth_request и переменные в proxy_pass

[Slawa Olhovchenkov]

On Tue, Jul 21, 2020 at 07:08:53PM +0400, Константин Ткаченко wrote:

> 
> > 21 июля 2020 г., в 19:05, Slawa Olhovchenkov  написал(а):
> > 
> > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > auth_request никакие переменые от rewrite и/или $arg_ использовать не 
> > удастся?
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> Можно. Я использую там $request_uri;

А $request_uri к какой категории относится -- rewrite или $arg_?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

auth_request и переменные в proxy_pass

[Slawa Olhovchenkov]

А я правильно понимаю, что в блоке proxy_pass который активируется по
auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?

[Slawa Olhovchenkov]

On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote:

> чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov :
> 
> > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> > > дополнительный запрос к ресурсу.
> >
> >  Если клиент умеет cache digest, то да, может отказаться заранее.
> >  А если нет, то к тому моменту, когда клиент сможет отклонить push,
> >  данные уже летят по сети и отъедают пропускную способность канала,
> >  это обстоятельство может навредить желанию загрузить все причандалы
> >  к странице побыстрее.
> >
> >  Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
> >  профит от сложной и очень тяжёлой технологии". И push в том ряду.
> >
> 
> 
> http2 решает искуственную проблему - у браузера по каким-то странным
> причинам ограничего количество одновременных
> tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит
> два оочень медленных ответа, все остальные
> элементы, как то css стили, которые нужны для того, чтобы отрендерить
> страницу, на паузе.
> 
> т.е. браузер решил сам себе ограничить количество сессий - удачи ему.
> а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp
> сессии будет типа еще один инкапсулированный tcp
> с мультиплексированием". ну то есть нам дорого открыть несколько честных
> tcp потоков, лучше мы заморочимся тем, что будем
> мультиплексировать tcp внутри tcp.

нет-нет.
не так все было.
много соединений на сервер == много одновременных запросов == большая
нагрузка на сервер (особенно если там апач или томкат).
это же почти DDoS!

разработчики браузеров сказали -- а мы за все хорошее и против всего
плохого!
ограничим число одновоременных запросов от каждого браузера двумя!
фиг вам зловереды а не DDoS!

прошло некоторое время, все уже забыли почему так получилось и
разрабочки стандарта придумали э... монстра.

ну надеюсь теперь все догадываются что будет дальше?
подсказываю: зловредные страницы котрые будут содержать миллионы
ссылок на http2 сайты которые будут по двум соединениям делать 100500
одновременных запросов на разные ресурсы. после этого разработчки
браузеров разрешат по каждому http2 соединению делать не более 2
запосов.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_store и ranges

[Slawa Olhovchenkov]

On Thu, Apr 23, 2020 at 01:09:52AM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote:
> 
> > А что происходит если у нас есть proxy_store а исходный запрос -- с
> > ranges?
> > Скачиваем и сохраняем все, отдаем кусок?
> > Скачиваем и сохраняем кусок а потом глючим?
> 
> Директива proxy_store не предполагает собственной логики кроме 
> собственно сохранения ответов.  При это сохраняются только ответы 
> с кодом 200.  Соответственно если бекенд возвращает 206 (Partial 
> content), то ответ сохранён не будет.
> 
> Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно 
> убрать из запроса на бекенд с помощью директивы proxy_set_header.  
> Если при этом хочется ещё и вернуть клиенту ответ с учётом 
> запрошенных диапазонов, то в простых случаях это можно сделать, 
> включив директиву proxy_force_ranges.

а когда клиент -- это на самом деле модуль который сделал сабреквест
-- это относится к простым случаям?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy_store и ranges

[Slawa Olhovchenkov]

А что происходит если у нас есть proxy_store а исходный запрос -- с
ranges?
Скачиваем и сохраняем все, отдаем кусок?
Скачиваем и сохраняем кусок а потом глючим?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: переменные $1

[Slawa Olhovchenkov]

On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > А это нормально что переменные $1..$N не являются локальными для
> > > > регэкспа?
> > > > 
> > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > браться из map.
> > > > Что-то мне кажется это не логично.
> > > 
> > > Это следствие того, что regexp и использование $1..$N могут быть 
> > > разнесены, например, в конструкциях вида (цитата из 
> > > http://nginx.org/r/if):
> > > 
> > > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > set $id $1;
> > > }
> > > 
> > > Для rewrite'а это, конечно, не нормально, надо править.  Про это 
> > > даже есть тикет:
> > 
> > не для rewrite, а для map.
> > вроде как логично ожидать, что map срабатывает выдавая указанную
> > переменную без каких-либо дополнительных побочных эффектов.
> 
> Ну да, одно из возможных решений - отучить регулярные выражения в 
> map'е трогать $1..$N.  С другой стороны - конфигурации вида
> 
> map $uri $foo {
> ~(.+) $1;
> }
> 
> тоже никто не отменял.

не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.

> > > https://trac.nginx.org/nginx/ticket/564
> > > 
> > > Patches are welcome.
> > 
> > 6 лет...
> 
> Да, за 6 лет никто не сподобился даже попытаться прислать патч.  
> Что как бы позволяет предложить, что - не жмёт.

или никто не может разобраться.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: переменные $1

[Slawa Olhovchenkov]

On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> 
> > А это нормально что переменные $1..$N не являются локальными для
> > регэкспа?
> > 
> > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > результате используется еще и результат map с регэкспом, то $1 будет
> > браться из map.
> > Что-то мне кажется это не логично.
> 
> Это следствие того, что regexp и использование $1..$N могут быть 
> разнесены, например, в конструкциях вида (цитата из 
> http://nginx.org/r/if):
> 
> if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> set $id $1;
> }
> 
> Для rewrite'а это, конечно, не нормально, надо править.  Про это 
> даже есть тикет:

не для rewrite, а для map.
вроде как логично ожидать, что map срабатывает выдавая указанную
переменную без каких-либо дополнительных побочных эффектов.

> https://trac.nginx.org/nginx/ticket/564
> 
> Patches are welcome.

6 лет...
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

переменные $1

[Slawa Olhovchenkov]

А это нормально что переменные $1..$N не являются локальными для
регэкспа?

Т.е. если например у нас есть rewrite и там что-то захватывается, а в
результате используется еще и результат map с регэкспом, то $1 будет
браться из map.
Что-то мне кажется это не логично.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: зачем писать FastCGI сервер?

[Slawa Olhovchenkov]

On Thu, Nov 07, 2019 at 12:36:20PM -0500, greenwar wrote:

> Slawa Olhovchenkov Wrote:
> ---
> > по теме и есть, там апп-сервер на плюсах, без нгинкса.
> 
> это значит "написать второй NGINX", я этот вариант отмёл.

а что же так?
и что у тебя с опытом и экспертизой? насколько можно доверять твоим оценкам?

> > простая -- это какая? и как это определили?
> 
> простая это 1-2 раза считать из редиски, а остальное всё расчёты в C++
> уровня "собрать строку ..."

ну и как определили что проблема в коммуникации между nginx и
приложением? какие замеры и как проводились?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: зачем писать FastCGI сервер?

[Slawa Olhovchenkov]

On Wed, Nov 06, 2019 at 07:34:44AM -0500, greenwar wrote:

> Slawa Olhovchenkov Wrote:
> ---
> > да до сих пор так делают
> > https://www.youtube.com/watch?v=yM8trpiuxys
> 
> что делают? зачем тут видео про Docker и майнтейн проектов? Давайте без
> мусора, по теме.

по теме и есть, там апп-сервер на плюсах, без нгинкса.

> > > Нет, это не ответ на вопрос "можно ли NGINX эффективно запрячь
> > 
> > а зачем?
> 
> "чтобы убрать всё лишнее" - написал же.
> Вопрос в сабже - можно ли обойтись БЕЗ fcgi и насколько это эффективно?

я думаю лишнее тут -- люди, начинать надо с убирания людей.

> > > бизнес-логикой безо всяких fcgi и получить 30-40-50к рпс".
> > 
> > так надо всякого в нгинкс понапихать и потрахаться или 50к рпс получить?
> 
> моя мысль была в том, что чем ближе к NGINX, тем ближе 50к...
> Здесь я пытаюсь её подтвердить ИЛИ опровергнуть.

практика -- критерий истины. т.е. сделай и посмотри.

> > а 50крпс вообще в конкретном случае возможны? а они точно в связку
> упираются?
> 
> ну там простая БЛ без расчётов погоды...

простая -- это какая? и как это определили?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: зачем писать FastCGI сервер?

[Slawa Olhovchenkov]

On Wed, Nov 06, 2019 at 07:02:53AM -0500, greenwar wrote:

> kvt Wrote:
> ---
> > Ну вообще раньше так и было, писали код на Си, потом рутинные задачи
> > (прием, отправку и диспетчерезацию запросов) возложили на веб-сервер,
> > а бизнес-логику либо продолжали писать на плюсах или на perl. Но это
> > все было медленно и неудобно, разработка, я имею ввиду. Позже
> > появились языки более высокого уровня, для создания бизнес-логики и их
> > интерпретаторы в виде модулей для веб-сервера. Что сильно ускорило
> > разработку и внесение изменений в код продуктов. Такие дела. Я ответил
> > на Ваш вопрос?
> 
> "писали код на Си, когда ещё не было веб-серверов" - это что за времена
> такие? Под морфином? ))

да до сих пор так делают
https://www.youtube.com/watch?v=yM8trpiuxys

> Нет, это не ответ на вопрос "можно ли NGINX эффективно запрячь

а зачем?

> бизнес-логикой безо всяких fcgi и получить 30-40-50к рпс".

так надо всякого в нгинкс понапихать и потрахаться или 50к рпс получить?
а 50крпс вообще в конкретном случае возможны? а они точно в связку упираются?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx http_x_forwarded_for blocking ip

[Slawa Olhovchenkov]

On Thu, Sep 26, 2019 at 01:58:19PM +0300, Evgeniy Berdnikov wrote:

> On Thu, Sep 26, 2019 at 06:06:54AM -0400, classic85 wrote:
> > всем привет
> > 
> > подкажите плиз
> > нужно блокировать ip по заголовку: 
> > http_x_forward_for":«10.13.2.14, 10.99.111.25:13555 
> > нужно блокировать только если эти два ip вместе приходят 
> > пробовал разные способы. все равно проходит
> > 
> > пример
> > 
> > if ($http_x_forward_for ~ " ?10\.13\.2\.14*") {
> >   return 403;
> 
>  А такой заголовок вообще есть? Бывает X-Forwarded-For.

заголовок может быть какой угодно, если он удоволтворяет грамматике.
придумывай свои, сколько хочешь.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location

[Slawa Olhovchenkov]

On Tue, Jul 09, 2019 at 11:51:19AM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Mon, Jul 08, 2019 at 07:24:33PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote:
> > 
> > > > > > action тут разный. я на этом внимание не заострил, думал и так 
> > > > > > понятно
> > > > > 
> > > > > Понятно.  И также понятно, что даже при одном и том же action - 
> > > > > приведённые команды делают разное, и результаты могут кардинально 
> > > > > отличаться в том числе из-за этого.  Именно поэтому я и указал на 
> > > > > эту проблему как на одну из возможных причин наблюдаемого 
> > > > > поведения.  Дабы подобную проблему гарантированно исключить - 
> > > > > лучше всего использовать одну и ту же форму команды.
> > > > 
> > > > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start`
> > > 
> > > Зато бывает "service nginx reload" и "service nginx restart".
> > > 
> > > (Ну и вообще, использовать "nginx -s ..." на юникс-системах - 
> > > странно.  Как минимум попадаем на двойной парсинг конфигурации, 
> > > как максимум - на невозможность использовать эти команды, если 
> > > PID-файл надо переложить в другое место.)
> > 
> > набирать короче, давно заучил, а эти service вечно меняются...
> 
> Форма "service  " работает начиная с FreeBSD 7.3, и 
> с момента появления не менялась.

есть еще линуксы в разных вариантах и они сбивают.
а у них еще и имя сервиса различается в зависимости от пакета.
ну и я с фрей работаю начиная с 2.0.5 :)

> > > > > - После чего был сделан reload - и привёл к той же ошибке "module 
> > > > >   ... is already loaded", что было проигнорировано.  Так
> > > > 
> > > > нет, он не нашел ndk_* символов.
> > > > после чего я добавил строку с загрузко ndk_http.
> > > 
> > > Не нашёл символов - в процессе тестирования конфигурации с помощью 
> > > "nginx -t" и/или при парсинге конфигурации в процессе запуска 
> > > "nginx -s"?
> > 
> > вот тут не помню.
> > 
> > > Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет 
> > > загруженных модулей, и они получают то, что было на диске.  И это 
> > > одна из причин, почему reload не стоит предварять запуском "nginx -t", 
> > > и не стоит использовать "nginx -s".
> > 
> > ничего не понял.
> 
> В рассматриваемом случае содержимое бинарных файлов на диске 
> (nginx + модули) - поменялось.  Более того, поменялось - 
> несовместимо, для работы старых бинарных файлов требовалась одна 
> конфигурация, для работы новых - другая.
> 
> Когда такое происходит, использование "nginx -t" и "nginx -s 
> " совместно с перезагрузкой конфигурации на лету - 
> невозможно.  Проблема в том, что эти команды требуют конфигурацию, 
> совместимую с новыми бинарными файлами, тогда как для перезагрузки 
> конфигурации работающего nginx'а - нужна конфигурация, совместимая 
> со старыми бинарными файлами.
> 
> Проще всего - в такую ситуацию не попадать, и после обновления 
> бинарных файлов (что самого nginx'а, что модулей) - сразу делать 
> upgrade, синхронизируя бинарники на дисках, и в памяти.  Но вообще 
> говоря работа в несинхронизированном состоянии тоже возможна - 
> просто надо пользоваться сигналами, а не пытаться использовать 
> nginx с диска (который не совпадает с тем, что в памяти).

так, т.е. nginx -s reload не эквивалентно kill -HUP `cat /var/run/nginx.pid`?
и вторая комманда срабоатла бы по старому варианту конфига и не стала
бы ругаться на неопределенные символы?

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location

[Slawa Olhovchenkov]

On Mon, Jul 08, 2019 at 07:11:59PM +0300, Maxim Dounin wrote:

> > > > action тут разный. я на этом внимание не заострил, думал и так понятно
> > > 
> > > Понятно.  И также понятно, что даже при одном и том же action - 
> > > приведённые команды делают разное, и результаты могут кардинально 
> > > отличаться в том числе из-за этого.  Именно поэтому я и указал на 
> > > эту проблему как на одну из возможных причин наблюдаемого 
> > > поведения.  Дабы подобную проблему гарантированно исключить - 
> > > лучше всего использовать одну и ту же форму команды.
> > 
> > так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start`
> 
> Зато бывает "service nginx reload" и "service nginx restart".
> 
> (Ну и вообще, использовать "nginx -s ..." на юникс-системах - 
> странно.  Как минимум попадаем на двойной парсинг конфигурации, 
> как максимум - на невозможность использовать эти команды, если 
> PID-файл надо переложить в другое место.)

набирать короче, давно заучил, а эти service вечно меняются...

> > > - После чего был сделан reload - и привёл к той же ошибке "module 
> > >   ... is already loaded", что было проигнорировано.  Так
> > 
> > нет, он не нашел ndk_* символов.
> > после чего я добавил строку с загрузко ndk_http.
> 
> Не нашёл символов - в процессе тестирования конфигурации с помощью 
> "nginx -t" и/или при парсинге конфигурации в процессе запуска 
> "nginx -s"?

вот тут не помню.

> Ожидаемо, так как у свежезапущенных экземпляров nginx'а нет 
> загруженных модулей, и они получают то, что было на диске.  И это 
> одна из причин, почему reload не стоит предварять запуском "nginx -t", 
> и не стоит использовать "nginx -s".

ничего не понял.

> > >   происходит, потому что с помощью reload'а нельзя изменить ранее 
> > >   загруженный модуль - so-шка уже в памяти, и при попытке её снова 
> > >   открыть - откроется старая so-шка.  Чтобы загрузить новые модули 
> > >   после изменения их so-файлов на диске - нужно делать upgrade.
> > 
> > а чего он их тогда полез открывать-то?
> > меня устроили бы старые модули.
> 
> В новой конфигурации - новый список модулей, они открываются / 
> загружаются в соответствии с тем, что задано в директивах 
> load_module в конфиге.  Поскольку в список добавился ndk - nginx 
> его попытался загрузить, поскольку в результате оказалось 
> загружено два одинаковых модуля - выдал ошибку и откатился на 
> предыдущую конфигурацию.

погоди. изначально список модулей не менялся, но конфигурация не
применилась потому что при открытии модуля выяснилось что его разбили
на два и теперь у него символы не находятся.

но как сказанно выше -- изменять загруженные модули нельзя, т.е. его и
не надо было открывать и тогда этой ошибки и не было бы. так?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location

[Slawa Olhovchenkov]

On Mon, Jul 08, 2019 at 04:29:06PM +0300, Maxim Dounin wrote:

> > > > есть кусок конфига
> > > > location /pkg { alias /poudriere/data/packages; index  index.html 
> > > > index.htm; }
> > > > добавляем
> > > > 
> > > > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; }
> > > > nginx -s reload
> > > > 
> > > > и призапросе получеам такую ошибку:
> > > > 
> > > > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of 
> > > > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> > > > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ 
> > > > HTTP/1.1", host: "pkg.int.integros.com"
> > > > 
> > > > что за фигня?
> > > > а если сделать
> > > > 
> > > > /usr/local/etc/rc.d/nginx restart
> > > > 
> > > > то все начинает работать
> > > > что за нафиг?
> > > 
> > > In no particular order:
> > > 
> > > - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не 
> > 
> > action тут разный. я на этом внимание не заострил, думал и так понятно
> 
> Понятно.  И также понятно, что даже при одном и том же action - 
> приведённые команды делают разное, и результаты могут кардинально 
> отличаться в том числе из-за этого.  Именно поэтому я и указал на 
> эту проблему как на одну из возможных причин наблюдаемого 
> поведения.  Дабы подобную проблему гарантированно исключить - 
> лучше всего использовать одну и ту же форму команды.

так не бывает же `nginx -s restart`, т.е. `nginx stop && nginx start`

> [...]
> 
> > > - reload может быть невозможен при некоторых изменениях - в 
> > >   частности, "на лету" нельзя менять путь и levels у кэша, так как 
> > >   для их изменения требуется повторная загрузка кэша - либо же 
> > 
> > кэш не менялся, я привел разницу в строках.
> 
> С учётом того, что ошибка reload'а нашлась только после явного 
> указания на то, что надо искать - мы не знаем, что менялось, а что 
> нет.
> 
> > >   может просто завершиться ошибкой по внешним причинам; ошибки об 
> > >   этом будут в глобальном логе в процессе перезагрузки конфигурации;
> > 
> > а вот тут интересный момент.
> > restart прошел успешно с тем же конфигом. значит конфиг норм, да?
> > а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг
> > поймешь (такой уж лог).
> > 
> > 2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not 
> > equal to the number of "worker_cpu_affinity" masks, using last mask for 
> > remaining worker processes
> > 2019/07/05 19:13:59 [notice] 81052#0: signal process started
> > 2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, 
> > reconfiguring
> > 2019/07/05 19:13:59 [notice] 939#0: reconfiguring
> > 2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already 
> > loaded in /usr/local/etc/nginx/nginx.conf:1
> > 2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of 
> > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", 
> > host: ""
> > 
> > ну вот что я должен заключить? вроде emerg. но написанно is already loaded. 
> > т.е. фиг с ним?
> 
> Уровень emerg - это фатальная ошибка, после таких ошибок парсинг 
> конфигурации прекращается.  Если бы nginx считал, что проблему 
> можно игнорировать - уровень ошибки был бы другой, и, для высоких 
> уровней, рядом было бы написано "ignored".

а alert у нас что?

> Что до самой ошибки и того факта, что ломается оно только на 
> релоаде, но не на рестарте - то единственный сценарий, который 
> приходит в голову, какой-то такой:
> 
> - Был загружен модуль, совмещающий в одном so-файле что-то ещё и 
>   ndk_http_module;

lua скорее всего.

> - Файл *.so на диске поменялся, и теперь содержит только что-то ещё, 
>   а ndk_http_module был добавлен отдельной директивой load_module.

не исключаю что так и было.

> - После чего был сделан reload - и привёл к той же ошибке "module 
>   ... is already loaded", что было проигнорировано.  Так

нет, он не нашел ndk_* символов.
после чего я добавил строку с загрузко ndk_http.

>   происходит, потому что с помощью reload'а нельзя изменить ранее 
>   загруженный модуль - so-шка уже в памяти, и при попытке её снова 
>   открыть - откроется старая so-шка.  Чтобы загрузить новые модули 
>   после изменения их so-файлов на диске - нужно делать upgrade.

а чего он их тогда полез открывать-то?
меня устроили бы старые модули.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: location

[Slawa Olhovchenkov]

On Sat, Jul 06, 2019 at 08:38:19PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Fri, Jul 05, 2019 at 07:17:01PM +0300, Slawa Olhovchenkov wrote:
> 
> > есть кусок конфига
> > 
> > location /pkg { alias /poudriere/data/packages; index  index.html 
> > index.htm; }
> > 
> > добавляем
> > 
> > location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; }
> > 
> > nginx -s reload
> > 
> > и призапросе получеам такую ошибку:
> > 
> > 2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of 
> > "/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
> > 81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", 
> > host: "pkg.int.integros.com"
> > 
> > что за фигня?
> > а если сделать
> > 
> > /usr/local/etc/rc.d/nginx restart
> > 
> > то все начинает работать
> > что за нафиг?
> 
> In no particular order:
> 
> - "nginx -s " и "/usr/local/etc/rc.d/nginx " - не 

action тут разный. я на этом внимание не заострил, думал и так понятно

>   одно и то же, и могут делать совсем разное, если, например, на 
>   машине более чем один nginx;

один

> - reload может быть невозможен при некоторых изменениях - в 
>   частности, "на лету" нельзя менять путь и levels у кэша, так как 
>   для их изменения требуется повторная загрузка кэша - либо же 

кэш не менялся, я привел разницу в строках.

>   может просто завершиться ошибкой по внешним причинам; ошибки об 
>   этом будут в глобальном логе в процессе перезагрузки конфигурации;

а вот тут интересный момент.
restart прошел успешно с тем же конфигом. значит конфиг норм, да?
а reload -- нифига. было ли об этом сказанно в лог -- ну вот фиг
поймешь (такой уж лог).

2019/07/05 19:13:59 [warn] 81052#0: the number of "worker_processes" is not 
equal to the number of "worker_cpu_affinity" masks, using last mask for 
remaining worker processes
2019/07/05 19:13:59 [notice] 81052#0: signal process started
2019/07/05 19:13:59 [notice] 939#0: signal 1 (SIGHUP) received from 81052, 
reconfiguring
2019/07/05 19:13:59 [notice] 939#0: reconfiguring
2019/07/05 19:13:59 [emerg] 939#0: module "ndk_http_module" is already loaded 
in /usr/local/etc/nginx/nginx.conf:1
2019/07/05 19:14:03 [error] 23182#0: *102391 directory index of 
"/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: 
""

ну вот что я должен заключить? вроде emerg. но написанно is already loaded. 
т.е. фиг с ним?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

location

[Slawa Olhovchenkov]

есть кусок конфига

location /pkg { alias /poudriere/data/packages; index  index.html index.htm; }

добавляем

location /pkg/edge12-default { proxy_pass http://X.Y.Z.Q; }

nginx -s reload

и призапросе получеам такую ошибку:

2019/07/05 19:07:05 [error] 23182#0: *102388 directory index of 
"/poudriere/data/packages/edge12-default/All/" is forbidden, client: 
81.211.90.2, server: , request: "GET /pkg/edge12-default/All/ HTTP/1.1", host: 
"pkg.int.integros.com"

что за фигня?
а если сделать

/usr/local/etc/rc.d/nginx restart

то все начинает работать
что за нафиг?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: limit_conn_zone

[Slawa Olhovchenkov]

On Fri, Apr 26, 2019 at 09:52:56AM -0400, dymov.ra wrote:

> Добрый день. Столкнулся со след проблемой.
> 
> В версии 1.14 не работает limit_conn_zone (ubuntu 18 lts\nginx-extras). 
> Соответственно на старой версии 1.10, все было корректно (ubuntu 16
> lts\nginx-extras)
> Так же проверял в докере с nginx-alpine соответствующих версий - там картина
> индетинчная.
> 
> limit_conn_zone $binary_remote_addr zone=ip:16m;
> limit_conn ip 1;
> limit_conn_zone $server_name zone=server:8m;
> limit_conn server 5;

а разве в докере это имеет хоть какой-то смысл?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: https cpu load

[Slawa Olhovchenkov]

On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote:

> > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это.
> >
> > и при этом не сообщая ничего о своем (референсном в данном случае)
> > профиле нагрузке? оригинально
> >
> 
> это некое предположение, что "среднее хорошо написанное веб-приложение для
> браузера" работает примерно одинаково.

я не заметил, там говорилось что нгинкс колокейтится с приложением?
он не статику раздает, не проксей работает?

> 
> >
> > >
> > > >
> > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было
> > как
> > > > > раз про это.
> > > >
> > > > нет никакого смысла смотреть профайлер в данный момент.
> > > >
> > >
> > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть
> > > профайлер. какие еще есть варианты ?
> >
> > очевидно он расходуется на https, это бесполезное знание.
> >
> 
> 
> неочевидно.
> например, у нас 70% cpu это компрессия.
> 
> опять же, https это как минимум два вида нагрузки - ассиметричные хендшейки
> и симметричное шифрование. сколько каждого из них, весьма интересно.

это бесполезное знание, пока мы не узнали что на это расходуется
больше ожидаемого. если у нас большая частота новых соединений то
будет пик в ассиметричных хендшейках и что дальше? так и должно быть.
и смотреть надо на это для начала, а не профайлинг запускать.

да и вообще, поинтересоваться что за процессор и все такое.

> из интересных моментов, каким-то странным образом при сборке портов
> freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной
> оптимизацией.

это надо было постараться, да.
даже дважды (т.е. что бы для начала системный не устроил)

> по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику
> (которая в случае включенной ассемблерной оптимизации умножилась на ноль).
> 
> еще из интересных моментов, был странный опыт с подменой ответа (какой-то
> баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении
> тимсити) привела к всплеску cpu. увидели это тоже по gperftools

это проявлялось тоьлко на https?

> сколько раз использовал gperftools, еще не было повода пожалеть.

ни разу не использовал и не жалею.
предпочитаю pcstat, но тогда когда имеет смысл.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: https cpu load

[Slawa Olhovchenkov]

On Sun, Apr 07, 2019 at 10:02:22PM +0500, Илья Шипицин wrote:

> вс, 7 апр. 2019 г. в 20:51, Slawa Olhovchenkov :
> 
> > On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote:
> >
> > > On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov  wrote:
> > >
> > > > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote:
> > > >
> > > > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov :
> > > > >
> > > > > > Здравствуйте,
> > > > > >
> > > > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет:
> > > > > >
> > > > > > > 1 установленных соединений или 1 новых соединений в
> > секунду ?
> > > > > >
> > > > > > спасибо, установленных)
> > > > > >
> > > > >
> > > > >
> > > > > 20 установленных на 1 сервер обрабатываем
> > > >
> > > > какая разница сколько их, если скажем они все простаивают?
> > > >
> > > > имеет значение количество передаваемого трафика по этим соединениям (в
> > > > гигабитах/с) и количество устанавливаемых соединений в секунду (когда
> > > > считаются вся ассиметричная математика).
> > > >
> > >
> > > Я предполагаю, что на больших объёмах действует закон больших чисел, и
> > > количество установленных соединений вытекает из того, что вы написали.
> >
> > прежде чем ссылаться на закон больших чисел надо убедиться что в обоих
> > случаях происодит один и тот же эксперимент.
> >
> 
> естественно. я предполагаю, что тот, кто будет сравнивать, понимает это.

и при этом не сообщая ничего о своем (референсном в данном случае)
профиле нагрузке? оригинально

> 
> >
> > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было как
> > > раз про это.
> >
> > нет никакого смысла смотреть профайлер в данный момент.
> >
> 
> в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть
> профайлер. какие еще есть варианты ?

очевидно он расходуется на https, это бесполезное знание.
интересоваться профалингом следует тоьлко если производительность не
соответсвет ожидаемой, а это пока не известно.

> gperftools хорош для этой задачи.

не имеет значениею
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: https cpu load

[Slawa Olhovchenkov]

On Sun, Apr 07, 2019 at 06:14:18PM +0500, Илья Шипицин wrote:

> On Sun, Apr 7, 2019, 1:17 AM Slawa Olhovchenkov  wrote:
> 
> > On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote:
> >
> > > сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov :
> > >
> > > > Здравствуйте,
> > > >
> > > > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет:
> > > >
> > > > > 1 установленных соединений или 1 новых соединений в секунду ?
> > > >
> > > > спасибо, установленных)
> > > >
> > >
> > >
> > > 20 установленных на 1 сервер обрабатываем
> >
> > какая разница сколько их, если скажем они все простаивают?
> >
> > имеет значение количество передаваемого трафика по этим соединениям (в
> > гигабитах/с) и количество устанавливаемых соединений в секунду (когда
> > считаются вся ассиметричная математика).
> >
> 
> Я предполагаю, что на больших объёмах действует закон больших чисел, и
> количество установленных соединений вытекает из того, что вы написали.

прежде чем ссылаться на закон больших чисел надо убедиться что в обоих
случаях происодит один и тот же эксперимент.

> Вообще, я с вами согласен, моё предложение посмотреть профайлер было как
> раз про это.

нет никакого смысла смотреть профайлер в данный момент.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: https cpu load

[Slawa Olhovchenkov]

On Sun, Apr 07, 2019 at 12:14:51AM +0500, Илья Шипицин wrote:

> сб, 6 апр. 2019 г. в 23:40, Evgenii Davidov :
> 
> > Здравствуйте,
> >
> > On Sat, Apr 06, 2019 at 11:11:19PM +0500, Илья Шипицин пишет:
> >
> > > 1 установленных соединений или 1 новых соединений в секунду ?
> >
> > спасибо, установленных)
> >
> 
> 
> 20 установленных на 1 сервер обрабатываем

какая разница сколько их, если скажем они все простаивают?

имеет значение количество передаваемого трафика по этим соединениям (в
гигабитах/с) и количество устанавливаемых соединений в секунду (когда
считаются вся ассиметричная математика).
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Модуль с постоянным сетевым соединением

[Slawa Olhovchenkov]

А как правильно писать модуль, который будет держать постоянное
сетевое соединение, по которому будет бегать трафик?

Рекомендации, туториалы, примеры?

Да, предполагается, что он форкнет отдельного воркера. Соединение
иницируется модулем и реконект должен выполнятся по его же инициативе.
Не HTTP.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Периодические проблемы под нагрузкой

[Slawa Olhovchenkov]

On Thu, Feb 21, 2019 at 06:39:46PM +0500, damir bikmuhametov wrote:

> On Thu, Feb 21, 2019 at 07:06:11AM -0500, waster wrote:
> > Все-таки странно, mtr не показывает проблем с пингом до ориджина во время
> > таких скачков
> 
> "conntrack: table full, dropping packet"?

я бы скорее ожидал что-то типа

# netstat -s | grep -i list
172775 SYNs to LISTEN sockets dropped
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: один alias

[Slawa Olhovchenkov]

On Wed, Nov 07, 2018 at 07:34:18AM -0500, inkognito0609 wrote:

> кейс такой:
> Основной проект лежит
> root   /srv/www/app/web;
> 
> Появился новый проект по url /restore, отдаем html по другому адресу
> location /restore {
> alias /srv/www/frontend/build/;
> 
> В дальнейшем планируется n количество url, например /some для которого
> придется пилить свой и т.д.
> location /some {
> alias /srv/www/frontend/build/;
> 
> Какие есть практики чтоб не кошмарить такой большой конф файл, со своим
> location для каждого будущего url.
> На ум приходит создать location в который вкладывать остальные..

я сделал скрипт на lua и он из редиса достает мапинги
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Почему статические файлы (20Кб) в локальной сети(1Gbit/s) отдаются 1,5 секунды?

[Slawa Olhovchenkov]

On Fri, Jul 06, 2018 at 08:41:48AM -0400, YuriN wrote:

> > В дампе, при подозрении на потери в канале, прежде всего следует искать
> пакеты с селективными подтверждениями (sack), 
> Сделал фильтр по tcp.options.sack.count - Wireshark показал множество таких
> пакетов.
> Скажем я снимал дамп секунд 10 (время загрузки титульной страницы сайта) и 
> за это время в дампе оказалось 285 пакетов с SACK из 2284 суммарно.
> Что с этим можно сделать?

наврное лучше всего оплатить консультацию квалифицированного сетевого
инженера, который сможет проанализировать дампы. потому что по таким
признакам ("285 пакетов с SACK из 2284 суммарно") что-то достоверно
сказать нельзя, но их как-то черезчур многовато и возникают подозрения
не проблемы на сетевом уровне. возможно проблемы с half/full дуплексом
со стороны сервера.

> >Разумеется, нужно убедиться, при tcp-шном хендшейке что обе стороны
> договорились эту опцию использовать.
> handshake’а нет в этом дампе, смогу написать несколько позже о том, что
> происходит нём.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Запуск php скриптов из разных директории

[Slawa Olhovchenkov]

On Sat, Jun 30, 2018 at 02:55:16PM +0300, Роман Москвитин wrote:

> В линуксе mount --bind /dev /mnt/dev ЕМНИП

это разве смешивает, а не перекрывает?

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Запуск php скриптов из разных директории

[Slawa Olhovchenkov]

On Fri, Jun 29, 2018 at 05:59:00PM +0300, Gena Makhomed wrote:

> > Т.е. директории должны быть как бы зеркалами друг друга.
> > 
> > Это возможно сделать?
> 
> Теоретически - наверное возможно, если написать свой модуль ядра,
> который будет реализовывать эту логику на уровне файловой системы.
> 

кажется в лялихе тоже такое было.

MOUNT_UNIONFS(8)FreeBSD System Manager's Manual   MOUNT_UNIONFS(8)

NAME
 mount_unionfs — mount union file systems

SYNOPSIS
 mount_unionfs [-b] [-o options] directory uniondir

DESCRIPTION
 The mount_unionfs utility attaches directory above uniondir in such a way
 that the contents of both directory trees remain visible.  By default,
 directory becomes the upper layer and uniondir becomes the lower layer.

 The options are as follows:

 -b  Deprecated.  Use -o below instead.

 -o  Options are specified with the -o flag followed by an option.
 The following options are available:

 below   Inverts the default position, so that directory becomes
 the lower layer and uniondir becomes the upper layer.
 However, uniondir remains the mount point.

 copymode = traditional | transparent | masquerade
 Specifies the way to create a file or a directory in the
 upper layer automatically when needed.  The traditional
 mode uses the same way as the old unionfs for backward
 compatibility, and transparent duplicates the file and
 directory mode bits and the ownership in the lower layer
 to the created file in the upper layer.  For behavior of
 the masquerade mode, see MASQUERADE MODE below.

 whiteout = always | whenneeded
 Specifies whether whiteouts should always be made in the
 upper layer when removing a file or directory or only
 when it already exists in the lower layer.

 udir=mode
 Specifies directory mode bits in octal for masquerade
 mode.

 ufile=mode
 Specifies file mode bits in octal for masquerade mode.

 gid=gid
 Specifies group for masquerade mode.

 uid=uid
 Specifies user for masquerade mode.

 To enforce file system security, the user mounting a file system must be
 superuser or else have write permission on the mounted-on directory.  In
 addition, the vfs.usermount sysctl(8) variable must be set to 1 to permit
 file system mounting by ordinary users.  However, note that transparent
 and masquerade modes require vfs.usermount to be set to 0 because this
 functionality can only be used by superusers.

 Filenames are looked up in the upper layer and then in the lower layer.
 If a directory is found in the lower layer, and there is no entry in the
 upper layer, then a shadow directory will be created in the upper layer.
 The ownership and the mode bits are set depending on the copymode option.
 In traditional mode, it will be owned by the user who originally did the
 union mount, with mode 0777 (“rwxrwxrwx”) modified by the umask in effect
 at that time.

 If a file exists in the upper layer then there is no way to access a file
 with the same name in the lower layer.  If necessary, a combination of
 loopback and union mounts can be made which will still allow the lower
 files to be accessed by a different pathname.

 Except in the case of a directory, access to an object is granted via the
 normal file system access checks.  For directories, the current user must
 have access to both the upper and lower directories (should they both
 exist).

 Requests to create or modify objects in uniondir are passed to the upper
 layer with the exception of a few special cases.  An attempt to open for
 writing a file which exists in the lower layer causes a copy of the
 entire file to be made to the upper layer, and then for the upper layer
 copy to be opened.  Similarly, an attempt to truncate a lower layer file
 to zero length causes an empty file to be created in the upper layer.
 Any other operation which would ultimately require modification to the
 lower layer fails with EROFS.

 The union file system manipulates the namespace, rather than individual
 file systems.  The union operation applies recursively down the directory
 tree now rooted at uniondir.  Thus any file systems which are mounted
 under uniondir will take part in the union operation.  This differs from
 the union option to mount(8) which only applies the union operation to
 the mount point itself, and then only for lookups.

___
nginx-ru mailing list

Re: Странное взаимодействие с uWSGI

[Slawa Olhovchenkov]

On Tue, Feb 20, 2018 at 11:11:24AM -0500, VeeSot wrote:

> tcpdump поможет собрать информацию если обмен идет по сокету? Я выше привел
> выдержку из конфига.

можно попробовать через socat.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Странное взаимодействие с uWSGI

[Slawa Olhovchenkov]

On Tue, Feb 20, 2018 at 10:49:19AM -0500, VeeSot wrote:

> Тут интересная сиутация второй день подряд, может подскажешь шо..
> 
> Есть  сервис, который отдает зип-файлики. Перва собирает ХМЛ-ку потом
> заворачивает в зип и потом отдает.
> Поверх сервиса работает uWSGI.Обеспечивает некую многопоточность.
> Поверх всего этого добра - работает NGINX.
> 
> И в половине случаев - всё хорошо,файлики доходят до потребителя(в нашем
> случае робот Яндекс.Маркета).
> Но в другой половине случаев - uWSGI отдает файлик размером 2мб, на nginx -
> уже отдает файлик размером в несколько КБ.И причем отдает не сразу, а через
> некоторое время.
> 
> В логах uWSGI вижу что он передает то что ожидается, в логах NGINX - пустое
> тело ответа.
> 
> Косяк где то на уровне их сопряжения... но хде?? Всё облазил, всё покрутил.
> Сбоит без всякой очевидной причины. Может  отработать три запроса нормально,
> а на четвертый вернуть пустоту.
> 
> Пример логирования с подключеным lua
> 
> 5.45.235.119 - - [20/Feb/2018:20:40:20 +0500] "GET /my_url/1/ HTTP/1.1" 200
> 15941 "-" "YandexMarket/1.9-2 (compatible; http://market.yandex.ru)" 94.683
> <"-" >""
> 5.45.235.73 - - [20/Feb/2018:20:42:11 +0500] "GET /my_url/2/ HTTP/1.1" 200
> 15938 "-" "YandexMarket/1.9-2 (compatible; http://market.yandex.ru)" 104.958
> <"-" >""
> 
> в то же время в uWSGI
> 
> [pid: 6261|app: 0|req: 36/88] 5.45.235.119 () {36 vars in 467 bytes} [Tue
> Feb 20 20:38:45 2018] GET /my_url/1/  => generated 1605423 bytes in 34680
> msecs (HTTP/1.1 200) 5 headers in 308 bytes (8 switches on core 0)
> 
> [pid: 6261|app: 0|req: 37/90] 5.45.235.73 () {36 vars in 464 bytes} [Tue Feb
> 20 20:40:26 2018] GET  /my_url/2/  => generated 2030314 bytes in 44940 msecs
> (HTTP/1.1 200) 5 headers in 311 bytes (10 switches on core 2)

зачем думать, если можно трясти? оно же повторяется?
tcpdumpом записать и потом смотреть, например в вайршарке.
писать лучше с обоих концов сразу.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопрос по access_log

[Slawa Olhovchenkov]

On Fri, Feb 09, 2018 at 10:27:22PM +0300, Ruslan Ermilov wrote:

> On Fri, Feb 09, 2018 at 04:35:05PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:
> > 
> > > On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > > > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > > > 
> > > > > Hello!
> > > > > 
> > > > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > > > 
> > > > > Как и все остальные директивы, access_log наследуется с 
> > > > > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > > > > указано директив access_log.
> > > > 
> > > > и при этом, кажется, нет возможности просто включать/выключать acceess
> > > > log, не трогая его настройки?
> > > 
> > > Запись в лог может быть условной при помощи параметра "if=".
> > > 
> > > Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> > > а на вложенном уровне (напр., location) указать "access_log off;".
> > > Тогда на данном вложенном уровне access_log'и будут отключены, а
> > > на других вложенных уровнях (где не указаны свои access_log'и) будут
> > > действовать настройки как на внешнем уровне.
> > > 
> > > Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.
> > 
> > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > буферезиция и все такое). а потом по дефолту его запретить. и
> > разрешать только для отдельный location.
> > 
> > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > location директивы access_log со всеми этими параметрами.
> 
> Мне кажется, я уже ответил на Ваш вопрос ранее.
> 
> access_log <много_параметров> if="$log";
> 
> location /1 {
> set $log 1;
> <тут он будет работать>
> }
> 
> location /2 {
> <а тут - нет>
> }

а что при этом с производительностью?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопрос по access_log

[Slawa Olhovchenkov]

On Fri, Feb 09, 2018 at 04:32:35PM +0200, Alex Vorona wrote:

> Привет,
> 
> 09.02.18 15:35, Slawa Olhovchenkov wrote:
> [...]
> 
> > ну хочется указать accesslog. с кучей параметров (ну там путь,
> > буферезиция и все такое). а потом по дефолту его запретить. и
> > разрешать только для отдельный location.
> > 
> > ну вот я не вижу возможности так поступить, не повторяя в каждом
> > location директивы access_log со всеми этими параметрами.
> Использую для похожих задач include.

я прямо испытываю оргазм от одной мысли так делать.
нарезать все по одной строке и инклюды-инклюды-инклюды!
а уж какой кайф это редактировать или пытаться понять как конфиг
выглядит.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопрос по access_log

[Slawa Olhovchenkov]

On Fri, Feb 09, 2018 at 04:26:42PM +0300, Ruslan Ermilov wrote:

> On Fri, Feb 09, 2018 at 04:11:16PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> > > 
> > > [...]
> > > 
> > > > access_log в нижестоящем контексте отменяет все вышестоящие?
> > > 
> > > Как и все остальные директивы, access_log наследуется с 
> > > предыдущих уровней тогда и только тогда, когда на данном уровне не 
> > > указано директив access_log.
> > 
> > и при этом, кажется, нет возможности просто включать/выключать acceess
> > log, не трогая его настройки?
> 
> Запись в лог может быть условной при помощи параметра "if=".
> 
> Кроме того, можно на внешнем уровне (напр., server) задать access_log'и,
> а на вложенном уровне (напр., location) указать "access_log off;".
> Тогда на данном вложенном уровне access_log'и будут отключены, а
> на других вложенных уровнях (где не указаны свои access_log'и) будут
> действовать настройки как на внешнем уровне.
> 
> Я, впрочем, не уверен, что понял Ваш витиеватый вопрос правильно.

ну хочется указать accesslog. с кучей параметров (ну там путь,
буферезиция и все такое). а потом по дефолту его запретить. и
разрешать только для отдельный location.

ну вот я не вижу возможности так поступить, не повторяя в каждом
location директивы access_log со всеми этими параметрами.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вопрос по access_log

[Slawa Olhovchenkov]

On Fri, Feb 09, 2018 at 04:01:09PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Fri, Feb 09, 2018 at 12:38:32PM +0300, CoDDoC wrote:
> 
> [...]
> 
> > access_log в нижестоящем контексте отменяет все вышестоящие?
> 
> Как и все остальные директивы, access_log наследуется с 
> предыдущих уровней тогда и только тогда, когда на данном уровне не 
> указано директив access_log.

и при этом, кажется, нет возможности просто включать/выключать acceess
log, не трогая его настройки?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Объём отданного запроса с учётом SSL- overhead'а

[Slawa Olhovchenkov]

On Wed, Dec 13, 2017 at 03:09:51PM +0300, Александр Николаев wrote:

> > как минимум с учётом затрат на SSL при HTTPS.
> >>
> >>  $_bytes_sent__ _ -  содержит число байт,
> >> переданное клиенту, по HTTP (т.е.
> >> тело+заголовки), но не учитывает
> >> расходы трафик на транспорт (SSL, TCP/IP)
> >>
> >
> > Значит, на транспортном уровне и надо мерять.
> > Например, считать объём минутного TCP-трафика на порту и вычитать из него
> > сумму значений $bytes_sent за ту же минуту.
> >
> > Правда, в этом случае вы потеряете разблюдовку по IP-адресам и по клиентам.
> >
> >
> > как получить желаемый результат с nginx'ом?
> >>
> >
> > Расскажите, пожалуста, по-подробнее - а для чего такая инфа нужна\полезна?
> > может, эту вашу задачу окажется возможным решить каким-то другим способом?
> >
> 
>  Необходимо определять объём исходящего трафика в разрезе по server'ам и
> IP-адресам посетителей в name-based-схеме, когда много server'ов слушают
> одну пару IP:port.
>  В идеале - с учётом всего overhead'а, но достаточно хотя бы учесть SSL. И
> хотелось бы эти цифры видеть в логе nginx'а для дальнейшей аналитики в
> любых других разрезах.

объем ssl оверхеда на хоть сколько-нибудь крупных запросах (больше 130К) 
существенно
меньше tcp/ip оверхеда и почти весь содержится в начале сессии
https://stackoverflow.com/questions/1615882/how-much-network-overhead-does-tls-add-compared-to-a-non-encrypted-connection
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

[Slawa Olhovchenkov]

On Sat, Nov 25, 2017 at 04:21:44PM +0200, Gena Makhomed wrote:

> On 24.11.2017 21:43, Maxim Dounin wrote:
> 
> > Давайте, всё-таки, опеределимся: мы за всё хорошее против всего
> > плохого (== чтобы демоны писали pid-файлы до выхода запущенного
> > процесса, потому что по другому - плохо), или вопрос исключительно
> > в том, чтобы systemd не ругался в логи?
> 
>  Так ведь systemd и ругается в логи потому что по другому - плохо.
>  Например, команда "/etc/init.d/nginx start ; /etc/init.d/nginx stop"
>  будет глючить на системах, где nginx запускается в виде SysV сервиса.
> 
> >>> То есть боремся за всё хорошее против всего плохого, правильно я
> >>> понял ответ?
> 
> >> Есть спецификация на запуск сервисов под управлением systemd.
> >> Вопрос лишь в том, соответствует nginx этой спецификации или нет.
> 
> > Нет.  Вопрос в том, соответствует ли эта "спецификация",
> > придуманная авторами systemd, тому, как пишутся и работают демоны
> > последние 25+ лет.  И ответ - не соответствует.
> 
> А как быть с тем, что гугл выдает примерно 51500 страниц,
> если в строке поиска задать:
> 
> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
> 
> ?
> 
> Ведь это всё отрицательным образом сказывается на имидже nginx.

я уже не первый раз читаю про имидж nginx и отрицательный
образ. и как-то не могу никак понять о чем речь-то?

обычно для того, что бы имидж программы не портился его принято класть
на нормальные, не помойные hdd/sdd, ну или если уж брать помойные
носители, то собирать их в RAID (I -- Inexpensive). причем тут
systemd? или поттеринг теперь занялся еще и тем, что стал портить
имиджи програм? (это конечно странно, но с него станется). ну значит
надо поставить флаг immutable на имидж. шоб неповадно было.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru