From izorkin на gmail.com  Tue Jan  2 20:50:08 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Tue, 2 Jan 2024 23:50:08 +0300
Subject: =?windows-1251?B?bmdpbnhRdWljOiDx6u7w7vHy/CDn4OPw8+fq6CDv8Ogg4Ory6OLg9ujoIGtUTFM=?=
Message-ID: <582023013.20240102235008@gmail.com>

Здравствуйте.

Сравнил скорость загрузки большого файла на тестовой виртуальной машине
разными протоколами:
 - 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?


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From alex.hha на gmail.com  Tue Jan  2 21:06:00 2024
From: alex.hha на gmail.com (Alex Domoradov)
Date: Tue, 2 Jan 2024 23:06:00 +0200
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <582023013.20240102235008@gmail.com>
References: <582023013.20240102235008@gmail.com>
Message-ID: <CAK90gp6xwxr46mdb2b5kbCgqJH52t8+yPTY=yQegf8bj3gOE7g@mail.gmail.com>

> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
разными протоколами:

просто ради интереса, скачивали в один поток ?

On Tue, Jan 2, 2024 at 10:50 PM <izorkin на 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?
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240102/497e7b81/attachment.htm>

From chipitsine на gmail.com  Tue Jan  2 21:08:45 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 2 Jan 2024 22:08:45 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <582023013.20240102235008@gmail.com>
References: <582023013.20240102235008@gmail.com>
Message-ID: <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>

было бы интересно посмотреть на "perf record" или gperftools.
на какие функции это все декомпозирукется в каждом из случаев.

начнем с простых вопросов

1) включена ли компрессия
2) насколько утилизируется CPU на виртуалке

вт, 2 янв. 2024 г. в 21:50, <izorkin на gmail.com>:

> Здравствуйте.
>
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> разными протоколами:
>  - 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?
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240102/ce3d5f3d/attachment.htm>

From izorkin на gmail.com  Tue Jan  2 21:19:47 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 00:19:47 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
Message-ID: <1704604593.20240103001947@gmail.com>

Добрый вечер, Илья.

Проверял в один поток с использованием утилиты curl? файл записывал
в /dev/null.
 
В настройках отключил сжатие gzip и brotli.
 
На виртуальной машине используется 4 ядра, при тесте нагружалось 1
ядро практически под 100%.
 
Утилитами perf record или gperftools не пользовался, подсказать
сейчас не смогу. Надо с ними ещё разобраться.
 
 
Вы писали 3 января 2024 г., 0:08:45:

> было бы интересно посмотреть на "perf record" или gperftools.
> на какие функции это все декомпозирукется в каждом из случаев.

> начнем с простых вопросов

> 1) включена ли компрессия
> 2) насколько утилизируется CPU на виртуалке

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/208e785e/attachment-0001.htm>

From izorkin на gmail.com  Tue Jan  2 21:26:46 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 00:26:46 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAK90gp6xwxr46mdb2b5kbCgqJH52t8+yPTY=yQegf8bj3gOE7g@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAK90gp6xwxr46mdb2b5kbCgqJH52t8+yPTY=yQegf8bj3gOE7g@mail.gmail.com>
Message-ID: <707485183.20240103002646@gmail.com>

Добрый вечер, Алекс.

Да, проверял в один поток с использованием утилиты curl, файл записывал
в /dev/null.
 
Вы писали 3 января 2024 г., 0:06:00:

> просто ради интереса, скачивали в один поток ?

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/5bba0105/attachment.htm>

From chipitsine на gmail.com  Tue Jan  2 21:32:58 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 2 Jan 2024 22:32:58 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1704604593.20240103001947@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
Message-ID: <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>

вт, 2 янв. 2024 г. в 22:20, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
> Проверял в один поток с использованием утилиты curl? файл записывал
>
> в /dev/null.
>
>
>
> В настройках отключил сжатие gzip и brotli.
>
>
>
> На виртуальной машине используется 4 ядра, при тесте нагружалось 1
>
> ядро практически под 100%.
>

100% утилизация ядра на виртуалке означает, что вы уперлись в мощности
виртуалки (это был не единственный вариант. могли упереться во что-то на
стороне клиента).



>
>
> Утилитами perf record или gperftools не пользовался, подсказать
>
> сейчас не смогу. Надо с ними ещё разобраться.
>

можно попробовать

perf record -g <nginx>

под <nginx> имеется в виду, что это будет nginx, запущенный через perf.
потом даете нагрузку, и завершаете процесс через SIGINT для nginx.

должен появиться perf.data


его можно смотреть через "perf report".
или взять вот такой конвертер
https://phabricator.kde.org/file/download/wjpg6dvpl4hnan54uawb/PHID-FILE-fznujhizsstxg6toixmd/converters_perf2calltree_python3.py


и сконвертировать в callgrind

perf script -s converters_perf2calltree_python3.py > perf.out

далее утилитой kcachegrind смотреть perf.out



>
>
>
>
> Вы писали 3 января 2024 г., 0:08:45:
>
>
> было бы интересно посмотреть на "perf record" или gperftools.
> на какие функции это все декомпозирукется в каждом из случаев.
>
> начнем с простых вопросов
>
> 1) включена ли компрессия
> 2) насколько утилизируется CPU на виртуалке
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240102/fc5cdbcf/attachment.htm>

From slw на zxy.spb.ru  Tue Jan  2 21:27:47 2024
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 3 Jan 2024 00:27:47 +0300
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB?=
 =?utf-8?B?0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YDQuCDQsNC60YLQuNCy0LDRhtC4?=
 =?utf-8?B?0Lg=?= kTLS
In-Reply-To: <582023013.20240102235008@gmail.com>
References: <582023013.20240102235008@gmail.com>
Message-ID: <20240102212747.GB76331@zxy.spb.ru>


On Tue, Jan 02, 2024 at 11:50:08PM +0300, izorkin на 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?

From izorkin на gmail.com  Wed Jan  3 04:44:14 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 07:44:14 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
Message-ID: <994372619.20240103074414@gmail.com>

Добрый день, Илья.

Запустить на виртуальной машине kcachegrind не получилось, там нет
поддержки GUI.
Выложил файл perf.out на pastebin:
https://pastebin.com/FKqvPL7r 

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/f57daaa8/attachment-0001.htm>

From chipitsine на gmail.com  Wed Jan  3 09:02:31 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 10:02:31 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <994372619.20240103074414@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
Message-ID: <CAFHpkQGGCL1dofmtMLFOH-itMzvmRof2o6qrH5XNuORwNBecZw@mail.gmail.com>

Ещё интересный момент, 100% CPU в какой пропорции складывается из sys и
user? perf показывает только user

On Wed, Jan 3, 2024, 05:44 <izorkin на gmail.com> wrote:

> Добрый день, Илья.
>
>
> Запустить на виртуальной машине kcachegrind не получилось, там нет
>
> поддержки GUI.
>
> Выложил файл perf.out на pastebin:
>
> https://pastebin.com/FKqvPL7r
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/39e107a5/attachment.htm>

From chipitsine на gmail.com  Wed Jan  3 09:38:07 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 10:38:07 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <994372619.20240103074414@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
Message-ID: <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>

если у вас windows, попробуйте
https://sourceforge.net/projects/qcachegrindwin/



[image: Screenshot from 2024-01-03 10-36-28.png]




ср, 3 янв. 2024 г. в 05:44, <izorkin на gmail.com>:

> Добрый день, Илья.
>
>
> Запустить на виртуальной машине kcachegrind не получилось, там нет
>
> поддержки GUI.
>
> Выложил файл perf.out на pastebin:
>
> https://pastebin.com/FKqvPL7r
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/70b4e3ad/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 10-36-28.png
Тип: image/png
Размер: 410710 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/70b4e3ad/attachment-0001.png>

From chipitsine на gmail.com  Wed Jan  3 09:44:52 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 10:44:52 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
Message-ID: <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>

непонятно, откуда мог взяться __libc_pread

а такой вопрос, судя по 81-й версии, у вас QuicTLS, верно ? а какой версии,
3.X или 1.1.1 ?

попробуйте обе ?

ср, 3 янв. 2024 г. в 10:38, Илья Шипицин <chipitsine на gmail.com>:

> если у вас windows, попробуйте
> https://sourceforge.net/projects/qcachegrindwin/
>
>
>
> [image: Screenshot from 2024-01-03 10-36-28.png]
>
>
>
>
> ср, 3 янв. 2024 г. в 05:44, <izorkin на gmail.com>:
>
>> Добрый день, Илья.
>>
>>
>> Запустить на виртуальной машине kcachegrind не получилось, там нет
>>
>> поддержки GUI.
>>
>> Выложил файл perf.out на pastebin:
>>
>> https://pastebin.com/FKqvPL7r
>>
>>
>>
>> --
>> С уважением,
>>  Izorkin                          mailto:izorkin на gmail.com
>> <izorkin на gmail.com>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/e4ba524c/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 10-36-28.png
Тип: image/png
Размер: 410710 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/e4ba524c/attachment-0001.png>

From chipitsine на gmail.com  Wed Jan  3 09:59:46 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 10:59:46 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
Message-ID: <CAFHpkQEWr1XVu6=KG+pfXUJnovWx31c2-aESCsjtxLnXFx1O=w@mail.gmail.com>

openssl-3.x (и его вариант quictls) страдает от проблем производительности

https://github.com/openssl/openssl/issues/17627#issuecomment-1060123659

ср, 3 янв. 2024 г. в 10:44, Илья Шипицин <chipitsine на gmail.com>:

> непонятно, откуда мог взяться __libc_pread
>
> а такой вопрос, судя по 81-й версии, у вас QuicTLS, верно ? а какой
> версии, 3.X или 1.1.1 ?
>
> попробуйте обе ?
>
> ср, 3 янв. 2024 г. в 10:38, Илья Шипицин <chipitsine на gmail.com>:
>
>> если у вас windows, попробуйте
>> https://sourceforge.net/projects/qcachegrindwin/
>>
>>
>>
>> [image: Screenshot from 2024-01-03 10-36-28.png]
>>
>>
>>
>>
>> ср, 3 янв. 2024 г. в 05:44, <izorkin на gmail.com>:
>>
>>> Добрый день, Илья.
>>>
>>>
>>> Запустить на виртуальной машине kcachegrind не получилось, там нет
>>>
>>> поддержки GUI.
>>>
>>> Выложил файл perf.out на pastebin:
>>>
>>> https://pastebin.com/FKqvPL7r
>>>
>>>
>>>
>>> --
>>> С уважением,
>>>  Izorkin                          mailto:izorkin на gmail.com
>>> <izorkin на gmail.com>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org
>>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/de8ef0e0/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 10-36-28.png
Тип: image/png
Размер: 410710 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/de8ef0e0/attachment-0001.png>

From chipitsine на gmail.com  Wed Jan  3 12:36:47 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 13:36:47 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
Message-ID: <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>

pread, кстати, есть в исходниках

http://hg.nginx.org/nginx/file/tip/src/os/unix/ngx_files.c#l40

однако в perf непонятно, кто его вызывает.
надо или чинить perf или пробовать gperftools

[image: Screenshot from 2024-01-03 13-36-29.png]


ср, 3 янв. 2024 г. в 10:44, Илья Шипицин <chipitsine на gmail.com>:

> непонятно, откуда мог взяться __libc_pread
>
> а такой вопрос, судя по 81-й версии, у вас QuicTLS, верно ? а какой
> версии, 3.X или 1.1.1 ?
>
> попробуйте обе ?
>
> ср, 3 янв. 2024 г. в 10:38, Илья Шипицин <chipitsine на gmail.com>:
>
>> если у вас windows, попробуйте
>> https://sourceforge.net/projects/qcachegrindwin/
>>
>>
>>
>> [image: Screenshot from 2024-01-03 10-36-28.png]
>>
>>
>>
>>
>> ср, 3 янв. 2024 г. в 05:44, <izorkin на gmail.com>:
>>
>>> Добрый день, Илья.
>>>
>>>
>>> Запустить на виртуальной машине kcachegrind не получилось, там нет
>>>
>>> поддержки GUI.
>>>
>>> Выложил файл perf.out на pastebin:
>>>
>>> https://pastebin.com/FKqvPL7r
>>>
>>>
>>>
>>> --
>>> С уважением,
>>>  Izorkin                          mailto:izorkin на gmail.com
>>> <izorkin на gmail.com>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org
>>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/49762441/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 10-36-28.png
Тип: image/png
Размер: 410710 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/49762441/attachment-0002.png>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 13-36-29.png
Тип: image/png
Размер: 110524 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/49762441/attachment-0003.png>

From izorkin на gmail.com  Wed Jan  3 13:25:22 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 16:25:22 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
Message-ID: <637302114.20240103162522@gmail.com>

Добрый день, Илья.

Я использую версию quictls 3.1.4. Попробовал версию 3.0.4, скорость
чуть-чуть только увеличилась.
При тестировании по протоколу HTTP/1.1 общая нагрузка system составляет
около 45%, а user около 5%. При тестировании по протоколу HTTP/3 общая
нагрузка system уже составляет около 40%, а user увеличивается до 12%.
 
Собрал nginx с поддержкой gperftools и собрал данные во время теста.
Как их дальше проанализировать? Или лучше куда-нибудь выложить их?
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/73a8731e/attachment.htm>

From chipitsine на gmail.com  Wed Jan  3 13:51:42 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 14:51:42 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <637302114.20240103162522@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
Message-ID: <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>

ср, 3 янв. 2024 г. в 14:25, <izorkin на gmail.com>:

> Добрый день, Илья.
>
>>
> Я использую версию quictls 3.1.4. Попробовал версию 3.0.4, скорость
>
> чуть-чуть только увеличилась.
>

попробуйте вот эту ветку

https://github.com/quictls/openssl/tree/OpenSSL_1_1_1p%2Bquic


> При тестировании по протоколу HTTP/1.1 общая нагрузка system составляет
>
> около 45%, а user около 5%. При тестировании по протоколу HTTP/3 общая
>
> нагрузка system уже составляет около 40%, а user увеличивается до 12%.
>


"system" не видно на perf-е.

"общая" нагрузка это видимо, по всем доступным ядрам. но если у вас
однопоточная нагрузка, вы увидите максимум 1 ядро


>
>
> Собрал nginx с поддержкой gperftools и собрал данные во время теста.
>
> Как их дальше проанализировать? Или лучше куда-нибудь выложить их?
>

можно так же kcachegrind-ом

https://gperftools.github.io/gperftools/cpuprofile.html

[image: Screenshot from 2024-01-03 14-50-33.png]



>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/3be9ce31/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 14-50-33.png
Тип: image/png
Размер: 50523 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/3be9ce31/attachment-0001.png>

From izorkin на gmail.com  Wed Jan  3 14:12:19 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 17:12:19 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
Message-ID: <175599485.20240103171219@gmail.com>

Здравствуйте, Илья.
Результат анализа дампа:
Using local file /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
Argument "MSWin32" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
Argument "linux" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
Using local file /var/www/test/profile/ktls.7743.
Warning: address  128f35:      eb ae                  jmp    128ee5 is longer than address length 16
Total: 3431 samples
    1225  35.7%  35.7%    1225  35.7% epoll_wait
    875  25.5%  61.2%      880  25.6% __sendmsg
    477  13.9%  75.1%      477  13.9% _aesni_ctr32_ghash_6x
    146  4.3%  79.4%      146  4.3% pthread_cond_signal@@GLIBC_2.3.2
    127  3.7%  83.1%      127  3.7% __memmove_avx_unaligned_erms
    123  3.6%  86.7%      127  3.7% __recvmsg
      58  1.7%  88.3%      58  1.7% __lll_lock_wake
      16  0.5%  88.8%      16  0.5% __strcmp_avx2
      15  0.4%  89.2%    1867  54.4% ngx_epoll_process_events
      15  0.4%  89.7%      51  1.5% ngx_quic_create_frame
      14  0.4%  90.1%      14  0.4% aesni_ctr32_encrypt_blocks
      14  0.4%  90.5%      255  7.4% ngx_quic_recvmsg
      13  0.4%  90.9%      14  0.4% evp_cipher_init_internal
      13  0.4%  91.3%    1540  44.9% ngx_quic_output
      11  0.3%  91.6%      11  0.3% gcm_ghash_avx
      10  0.3%  91.9%      10  0.3% ngx_quic_parse_frame
      8  0.2%  92.1%        8  0.2% __pthread_disable_asynccancel
      7  0.2%  92.3%        7  0.2% ngx_quic_commit_send
      6  0.2%  92.5%        6  0.2% aesni_encrypt
      6  0.2%  92.7%      506  14.7% generic_aes_gcm_cipher_update
      6  0.2%  92.8%      114  3.3% ngx_http_write_filter
      6  0.2%  93.0%      598  17.4% ngx_quic_crypto_common
...
 
Если использовать протокол HTTP/1.1
Using local file /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
Argument "MSWin32" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
Argument "linux" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
Using local file /var/www/test/profile/ktls.9140.
Warning: address  128f35:      eb ae                  jmp    128ee5 is longer than address length 16
Total: 2354 samples
    2329  98.9%  98.9%    2329  98.9% sendfile64
      7  0.3%  99.2%        7  0.3% __sched_yield
      5  0.2%  99.4%        5  0.2% epoll_wait
      2  0.1%  99.5%    2335  99.2% ngx_http_sub_body_filter
      2  0.1%  99.6%    2339  99.4% ngx_http_writer
      1  0.0%  99.7%        1  0.0% CRYPTO_free
      1  0.0%  99.7%    2330  99.0% SSL_sendfile
      1  0.0%  99.7%        1  0.0% __GI___clock_gettime
      1  0.0%  99.8%        7  0.3% ngx_epoll_process_events
      1  0.0%  99.8%    2336  99.2% ngx_http_copy_filter
      1  0.0%  99.9%    2337  99.3% ngx_http_range_body_filter
      1  0.0%  99.9%    2333  99.1% ngx_http_xslt_body_filter
      1  0.0% 100.0%    2332  99.1% ngx_ssl_send_chain
      1  0.0% 100.0%        1  0.0% xmlMutexLock
      0  0.0% 100.0%        1  0.0% ERR_clear_error
      0  0.0% 100.0%    2354 100.0% __libc_start_call_main
      0  0.0% 100.0%    2354 100.0% __libc_start_main_impl
      0  0.0% 100.0%    2354 100.0% _start
      0  0.0% 100.0%    2354 100.0% main
...
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/949483ef/attachment.htm>

From vl на inspert.ru  Wed Jan  3 14:24:41 2024
From: vl на inspert.ru (Vladimir Homutov)
Date: Wed, 3 Jan 2024 17:24:41 +0300
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB?=
 =?utf-8?B?0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YDQuCDQsNC60YLQuNCy0LDRhtC4?=
 =?utf-8?B?0Lg=?= kTLS
In-Reply-To: <175599485.20240103171219@gmail.com>
References: <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
Message-ID: <ZZVuKVXKJ-_N3BUq@vl.krasnogorsk.ru>

On Wed, Jan 03, 2024 at 05:12:19PM +0300, izorkin на gmail.com wrote:
> Здравствуйте, Илья.
> Результат анализа дампа:
> Using local file /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
> Argument "MSWin32" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
> Argument "linux" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
> Using local file /var/www/test/profile/ktls.7743.
> Warning: address  128f35:      eb ae                  jmp    128ee5 is longer than address length 16
> Total: 3431 samples
>     1225  35.7%  35.7%    1225  35.7% epoll_wait
>     875  25.5%  61.2%      880  25.6% __sendmsg
>     477  13.9%  75.1%      477  13.9% _aesni_ctr32_ghash_6x
>     146  4.3%  79.4%      146  4.3% pthread_cond_signal@@GLIBC_2.3.2
>     127  3.7%  83.1%      127  3.7% __memmove_avx_unaligned_erms
>     123  3.6%  86.7%      127  3.7% __recvmsg
>       58  1.7%  88.3%      58  1.7% __lll_lock_wake
>       16  0.5%  88.8%      16  0.5% __strcmp_avx2
>       15  0.4%  89.2%    1867  54.4% ngx_epoll_process_events
>       15  0.4%  89.7%      51  1.5% ngx_quic_create_frame
>       14  0.4%  90.1%      14  0.4% aesni_ctr32_encrypt_blocks
>       14  0.4%  90.5%      255  7.4% ngx_quic_recvmsg
>       13  0.4%  90.9%      14  0.4% evp_cipher_init_internal
>       13  0.4%  91.3%    1540  44.9% ngx_quic_output
>       11  0.3%  91.6%      11  0.3% gcm_ghash_avx
>       10  0.3%  91.9%      10  0.3% ngx_quic_parse_frame
>       8  0.2%  92.1%        8  0.2% __pthread_disable_asynccancel
>       7  0.2%  92.3%        7  0.2% ngx_quic_commit_send
>       6  0.2%  92.5%        6  0.2% aesni_encrypt
>       6  0.2%  92.7%      506  14.7% generic_aes_gcm_cipher_update
>       6  0.2%  92.8%      114  3.3% ngx_http_write_filter
>       6  0.2%  93.0%      598  17.4% ngx_quic_crypto_common
> ...
>  
> Если использовать протокол HTTP/1.1
> Using local file /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
> Argument "MSWin32" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
> Argument "linux" isn't numeric in numeric eq (==) at /run/current-system/sw/bin/pprof line 5047.
> Using local file /var/www/test/profile/ktls.9140.
> Warning: address  128f35:      eb ae                  jmp    128ee5 is longer than address length 16
> Total: 2354 samples
>     2329  98.9%  98.9%    2329  98.9% sendfile64
>       7  0.3%  99.2%        7  0.3% __sched_yield
>       5  0.2%  99.4%        5  0.2% epoll_wait
>       2  0.1%  99.5%    2335  99.2% ngx_http_sub_body_filter
>       2  0.1%  99.6%    2339  99.4% ngx_http_writer
>       1  0.0%  99.7%        1  0.0% CRYPTO_free
>       1  0.0%  99.7%    2330  99.0% SSL_sendfile
>       1  0.0%  99.7%        1  0.0% __GI___clock_gettime
>       1  0.0%  99.8%        7  0.3% ngx_epoll_process_events
>       1  0.0%  99.8%    2336  99.2% ngx_http_copy_filter
>       1  0.0%  99.9%    2337  99.3% ngx_http_range_body_filter
>       1  0.0%  99.9%    2333  99.1% ngx_http_xslt_body_filter
>       1  0.0% 100.0%    2332  99.1% ngx_ssl_send_chain
>       1  0.0% 100.0%        1  0.0% xmlMutexLock
>       0  0.0% 100.0%        1  0.0% ERR_clear_error
>       0  0.0% 100.0%    2354 100.0% __libc_start_call_main
>       0  0.0% 100.0%    2354 100.0% __libc_start_main_impl
>       0  0.0% 100.0%    2354 100.0% _start
>       0  0.0% 100.0%    2354 100.0% main
> ...

quic_gso (nginx.org/r/quic_gso) включён ?

From chipitsine на gmail.com  Wed Jan  3 14:26:36 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 15:26:36 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <175599485.20240103171219@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
Message-ID: <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>

из того, что бросается в глаза, на http/3 не видно sendfile.

из того, что интересно, там два столбца с процентами, непонятно, что из них
что.
обычно это в каком-то порядке "self", т.е. собственное время функции, и
"incl", кумулятивное время со всеми вызываемыми функциями

но по приведенной легенде не видно, кто есть кто

вот пример с self и incl


[image: Screenshot from 2024-01-03 15-23-04.png]


ср, 3 янв. 2024 г. в 15:12, <izorkin на gmail.com>:

> Здравствуйте, Илья.
>
> Результат анализа дампа:
>
> Using local file
> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>
> Argument "MSWin32" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Argument "linux" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Using local file /var/www/test/profile/ktls.7743.
>
> Warning: address  128f35:      eb ae                  jmp    128ee5 is
> longer than address length 16
>
> Total: 3431 samples
>
>     1225  35.7%  35.7%    1225  35.7% epoll_wait
>
>     875  25.5%  61.2%      880  25.6% __sendmsg
>
>     477  13.9%  75.1%      477  13.9% _aesni_ctr32_ghash_6x
>
>     146  4.3%  79.4%      146  4.3% pthread_cond_signal@@GLIBC_2.3.2
>
>     127  3.7%  83.1%      127  3.7% __memmove_avx_unaligned_erms
>
>     123  3.6%  86.7%      127  3.7% __recvmsg
>
>       58  1.7%  88.3%      58  1.7% __lll_lock_wake
>
>       16  0.5%  88.8%      16  0.5% __strcmp_avx2
>
>       15  0.4%  89.2%    1867  54.4% ngx_epoll_process_events
>
>       15  0.4%  89.7%      51  1.5% ngx_quic_create_frame
>
>       14  0.4%  90.1%      14  0.4% aesni_ctr32_encrypt_blocks
>
>       14  0.4%  90.5%      255  7.4% ngx_quic_recvmsg
>
>       13  0.4%  90.9%      14  0.4% evp_cipher_init_internal
>
>       13  0.4%  91.3%    1540  44.9% ngx_quic_output
>
>       11  0.3%  91.6%      11  0.3% gcm_ghash_avx
>
>       10  0.3%  91.9%      10  0.3% ngx_quic_parse_frame
>
>       8  0.2%  92.1%        8  0.2% __pthread_disable_asynccancel
>
>       7  0.2%  92.3%        7  0.2% ngx_quic_commit_send
>
>       6  0.2%  92.5%        6  0.2% aesni_encrypt
>
>       6  0.2%  92.7%      506  14.7% generic_aes_gcm_cipher_update
>
>       6  0.2%  92.8%      114  3.3% ngx_http_write_filter
>
>       6  0.2%  93.0%      598  17.4% ngx_quic_crypto_common
>
> ...
>
>
>
> Если использовать протокол HTTP/1.1
>
> Using local file
> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>
> Argument "MSWin32" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Argument "linux" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Using local file /var/www/test/profile/ktls.9140.
>
> Warning: address  128f35:      eb ae                  jmp    128ee5 is
> longer than address length 16
>
> Total: 2354 samples
>
>     2329  98.9%  98.9%    2329  98.9% sendfile64
>
>       7  0.3%  99.2%        7  0.3% __sched_yield
>
>       5  0.2%  99.4%        5  0.2% epoll_wait
>
>       2  0.1%  99.5%    2335  99.2% ngx_http_sub_body_filter
>
>       2  0.1%  99.6%    2339  99.4% ngx_http_writer
>
>       1  0.0%  99.7%        1  0.0% CRYPTO_free
>
>       1  0.0%  99.7%    2330  99.0% SSL_sendfile
>
>       1  0.0%  99.7%        1  0.0% __GI___clock_gettime
>
>       1  0.0%  99.8%        7  0.3% ngx_epoll_process_events
>
>       1  0.0%  99.8%    2336  99.2% ngx_http_copy_filter
>
>       1  0.0%  99.9%    2337  99.3% ngx_http_range_body_filter
>
>       1  0.0%  99.9%    2333  99.1% ngx_http_xslt_body_filter
>
>       1  0.0% 100.0%    2332  99.1% ngx_ssl_send_chain
>
>       1  0.0% 100.0%        1  0.0% xmlMutexLock
>
>       0  0.0% 100.0%        1  0.0% ERR_clear_error
>
>       0  0.0% 100.0%    2354 100.0% __libc_start_call_main
>
>       0  0.0% 100.0%    2354 100.0% __libc_start_main_impl
>
>       0  0.0% 100.0%    2354 100.0% _start
>
>       0  0.0% 100.0%    2354 100.0% main
>
> ...
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/9382c8d5/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 15-23-04.png
Тип: image/png
Размер: 179189 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/9382c8d5/attachment-0001.png>

From chipitsine на gmail.com  Wed Jan  3 14:31:43 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 15:31:43 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
Message-ID: <CAFHpkQFRN71=9_9o=gT2isEVtefgEj+n82Rg_bnoczyLwUSh7w@mail.gmail.com>

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

ср, 3 янв. 2024 г. в 15:26, Илья Шипицин <chipitsine на gmail.com>:

> из того, что бросается в глаза, на http/3 не видно sendfile.
>
> из того, что интересно, там два столбца с процентами, непонятно, что из
> них что.
> обычно это в каком-то порядке "self", т.е. собственное время функции, и
> "incl", кумулятивное время со всеми вызываемыми функциями
>
> но по приведенной легенде не видно, кто есть кто
>
> вот пример с self и incl
>
>
> [image: Screenshot from 2024-01-03 15-23-04.png]
>
>
> ср, 3 янв. 2024 г. в 15:12, <izorkin на gmail.com>:
>
>> Здравствуйте, Илья.
>>
>> Результат анализа дампа:
>>
>> Using local file
>> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>>
>> Argument "MSWin32" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Argument "linux" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Using local file /var/www/test/profile/ktls.7743.
>>
>> Warning: address  128f35:      eb ae                  jmp    128ee5 is
>> longer than address length 16
>>
>> Total: 3431 samples
>>
>>     1225  35.7%  35.7%    1225  35.7% epoll_wait
>>
>>     875  25.5%  61.2%      880  25.6% __sendmsg
>>
>>     477  13.9%  75.1%      477  13.9% _aesni_ctr32_ghash_6x
>>
>>     146  4.3%  79.4%      146  4.3% pthread_cond_signal@@GLIBC_2.3.2
>>
>>     127  3.7%  83.1%      127  3.7% __memmove_avx_unaligned_erms
>>
>>     123  3.6%  86.7%      127  3.7% __recvmsg
>>
>>       58  1.7%  88.3%      58  1.7% __lll_lock_wake
>>
>>       16  0.5%  88.8%      16  0.5% __strcmp_avx2
>>
>>       15  0.4%  89.2%    1867  54.4% ngx_epoll_process_events
>>
>>       15  0.4%  89.7%      51  1.5% ngx_quic_create_frame
>>
>>       14  0.4%  90.1%      14  0.4% aesni_ctr32_encrypt_blocks
>>
>>       14  0.4%  90.5%      255  7.4% ngx_quic_recvmsg
>>
>>       13  0.4%  90.9%      14  0.4% evp_cipher_init_internal
>>
>>       13  0.4%  91.3%    1540  44.9% ngx_quic_output
>>
>>       11  0.3%  91.6%      11  0.3% gcm_ghash_avx
>>
>>       10  0.3%  91.9%      10  0.3% ngx_quic_parse_frame
>>
>>       8  0.2%  92.1%        8  0.2% __pthread_disable_asynccancel
>>
>>       7  0.2%  92.3%        7  0.2% ngx_quic_commit_send
>>
>>       6  0.2%  92.5%        6  0.2% aesni_encrypt
>>
>>       6  0.2%  92.7%      506  14.7% generic_aes_gcm_cipher_update
>>
>>       6  0.2%  92.8%      114  3.3% ngx_http_write_filter
>>
>>       6  0.2%  93.0%      598  17.4% ngx_quic_crypto_common
>>
>> ...
>>
>>
>>
>> Если использовать протокол HTTP/1.1
>>
>> Using local file
>> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>>
>> Argument "MSWin32" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Argument "linux" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Using local file /var/www/test/profile/ktls.9140.
>>
>> Warning: address  128f35:      eb ae                  jmp    128ee5 is
>> longer than address length 16
>>
>> Total: 2354 samples
>>
>>     2329  98.9%  98.9%    2329  98.9% sendfile64
>>
>>       7  0.3%  99.2%        7  0.3% __sched_yield
>>
>>       5  0.2%  99.4%        5  0.2% epoll_wait
>>
>>       2  0.1%  99.5%    2335  99.2% ngx_http_sub_body_filter
>>
>>       2  0.1%  99.6%    2339  99.4% ngx_http_writer
>>
>>       1  0.0%  99.7%        1  0.0% CRYPTO_free
>>
>>       1  0.0%  99.7%    2330  99.0% SSL_sendfile
>>
>>       1  0.0%  99.7%        1  0.0% __GI___clock_gettime
>>
>>       1  0.0%  99.8%        7  0.3% ngx_epoll_process_events
>>
>>       1  0.0%  99.8%    2336  99.2% ngx_http_copy_filter
>>
>>       1  0.0%  99.9%    2337  99.3% ngx_http_range_body_filter
>>
>>       1  0.0%  99.9%    2333  99.1% ngx_http_xslt_body_filter
>>
>>       1  0.0% 100.0%    2332  99.1% ngx_ssl_send_chain
>>
>>       1  0.0% 100.0%        1  0.0% xmlMutexLock
>>
>>       0  0.0% 100.0%        1  0.0% ERR_clear_error
>>
>>       0  0.0% 100.0%    2354 100.0% __libc_start_call_main
>>
>>       0  0.0% 100.0%    2354 100.0% __libc_start_main_impl
>>
>>       0  0.0% 100.0%    2354 100.0% _start
>>
>>       0  0.0% 100.0%    2354 100.0% main
>>
>> ...
>>
>>
>> --
>> С уважением,
>>  Izorkin                          mailto:izorkin на gmail.com
>> <izorkin на gmail.com>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/5ad265f9/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 15-23-04.png
Тип: image/png
Размер: 179189 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/5ad265f9/attachment-0001.png>

From chipitsine на gmail.com  Wed Jan  3 14:38:39 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 15:38:39 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
Message-ID: <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>

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

я видел что-то типа "средний размер ответа 12.5 килобайт и 100 abbreviated
handshakes на 1 full handshake".


ср, 3 янв. 2024 г. в 15:26, Илья Шипицин <chipitsine на gmail.com>:

> из того, что бросается в глаза, на http/3 не видно sendfile.
>
> из того, что интересно, там два столбца с процентами, непонятно, что из
> них что.
> обычно это в каком-то порядке "self", т.е. собственное время функции, и
> "incl", кумулятивное время со всеми вызываемыми функциями
>
> но по приведенной легенде не видно, кто есть кто
>
> вот пример с self и incl
>
>
> [image: Screenshot from 2024-01-03 15-23-04.png]
>
>
> ср, 3 янв. 2024 г. в 15:12, <izorkin на gmail.com>:
>
>> Здравствуйте, Илья.
>>
>> Результат анализа дампа:
>>
>> Using local file
>> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>>
>> Argument "MSWin32" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Argument "linux" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Using local file /var/www/test/profile/ktls.7743.
>>
>> Warning: address  128f35:      eb ae                  jmp    128ee5 is
>> longer than address length 16
>>
>> Total: 3431 samples
>>
>>     1225  35.7%  35.7%    1225  35.7% epoll_wait
>>
>>     875  25.5%  61.2%      880  25.6% __sendmsg
>>
>>     477  13.9%  75.1%      477  13.9% _aesni_ctr32_ghash_6x
>>
>>     146  4.3%  79.4%      146  4.3% pthread_cond_signal@@GLIBC_2.3.2
>>
>>     127  3.7%  83.1%      127  3.7% __memmove_avx_unaligned_erms
>>
>>     123  3.6%  86.7%      127  3.7% __recvmsg
>>
>>       58  1.7%  88.3%      58  1.7% __lll_lock_wake
>>
>>       16  0.5%  88.8%      16  0.5% __strcmp_avx2
>>
>>       15  0.4%  89.2%    1867  54.4% ngx_epoll_process_events
>>
>>       15  0.4%  89.7%      51  1.5% ngx_quic_create_frame
>>
>>       14  0.4%  90.1%      14  0.4% aesni_ctr32_encrypt_blocks
>>
>>       14  0.4%  90.5%      255  7.4% ngx_quic_recvmsg
>>
>>       13  0.4%  90.9%      14  0.4% evp_cipher_init_internal
>>
>>       13  0.4%  91.3%    1540  44.9% ngx_quic_output
>>
>>       11  0.3%  91.6%      11  0.3% gcm_ghash_avx
>>
>>       10  0.3%  91.9%      10  0.3% ngx_quic_parse_frame
>>
>>       8  0.2%  92.1%        8  0.2% __pthread_disable_asynccancel
>>
>>       7  0.2%  92.3%        7  0.2% ngx_quic_commit_send
>>
>>       6  0.2%  92.5%        6  0.2% aesni_encrypt
>>
>>       6  0.2%  92.7%      506  14.7% generic_aes_gcm_cipher_update
>>
>>       6  0.2%  92.8%      114  3.3% ngx_http_write_filter
>>
>>       6  0.2%  93.0%      598  17.4% ngx_quic_crypto_common
>>
>> ...
>>
>>
>>
>> Если использовать протокол HTTP/1.1
>>
>> Using local file
>> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>>
>> Argument "MSWin32" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Argument "linux" isn't numeric in numeric eq (==) at
>> /run/current-system/sw/bin/pprof line 5047.
>>
>> Using local file /var/www/test/profile/ktls.9140.
>>
>> Warning: address  128f35:      eb ae                  jmp    128ee5 is
>> longer than address length 16
>>
>> Total: 2354 samples
>>
>>     2329  98.9%  98.9%    2329  98.9% sendfile64
>>
>>       7  0.3%  99.2%        7  0.3% __sched_yield
>>
>>       5  0.2%  99.4%        5  0.2% epoll_wait
>>
>>       2  0.1%  99.5%    2335  99.2% ngx_http_sub_body_filter
>>
>>       2  0.1%  99.6%    2339  99.4% ngx_http_writer
>>
>>       1  0.0%  99.7%        1  0.0% CRYPTO_free
>>
>>       1  0.0%  99.7%    2330  99.0% SSL_sendfile
>>
>>       1  0.0%  99.7%        1  0.0% __GI___clock_gettime
>>
>>       1  0.0%  99.8%        7  0.3% ngx_epoll_process_events
>>
>>       1  0.0%  99.8%    2336  99.2% ngx_http_copy_filter
>>
>>       1  0.0%  99.9%    2337  99.3% ngx_http_range_body_filter
>>
>>       1  0.0%  99.9%    2333  99.1% ngx_http_xslt_body_filter
>>
>>       1  0.0% 100.0%    2332  99.1% ngx_ssl_send_chain
>>
>>       1  0.0% 100.0%        1  0.0% xmlMutexLock
>>
>>       0  0.0% 100.0%        1  0.0% ERR_clear_error
>>
>>       0  0.0% 100.0%    2354 100.0% __libc_start_call_main
>>
>>       0  0.0% 100.0%    2354 100.0% __libc_start_main_impl
>>
>>       0  0.0% 100.0%    2354 100.0% _start
>>
>>       0  0.0% 100.0%    2354 100.0% main
>>
>> ...
>>
>>
>> --
>> С уважением,
>>  Izorkin                          mailto:izorkin на gmail.com
>> <izorkin на gmail.com>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/5279023c/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 15-23-04.png
Тип: image/png
Размер: 179189 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/5279023c/attachment-0001.png>

From izorkin на gmail.com  Wed Jan  3 14:39:33 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 17:39:33 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <ZZVuKVXKJ-_N3BUq@vl.krasnogorsk.ru>
References: <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com> 
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com> <ZZVuKVXKJ-_N3BUq@vl.krasnogorsk.ru>
Message-ID: <1058605616.20240103173933@gmail.com>

Добрый день, Владимир.

С параметром quic_gso скорость увеличилась на ~10 Мбит/сек.

Вы писали 3 января 2024 г., 17:24:41:

> quic_gso (nginx.org/r/quic_gso) включён ?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From chipitsine на gmail.com  Wed Jan  3 14:45:15 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 15:45:15 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <175599485.20240103171219@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
Message-ID: <CAFHpkQGvCWvPXsPMHrdf6NG-nHPxMN5xAo90SG-hyJ7-DwmN-Q@mail.gmail.com>

+в какие проценты смотреть )) ?

[image: Screenshot from 2024-01-03 15-43-29.png]


ср, 3 янв. 2024 г. в 15:12, <izorkin на gmail.com>:

> Здравствуйте, Илья.
>
> Результат анализа дампа:
>
> Using local file
> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>
> Argument "MSWin32" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Argument "linux" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Using local file /var/www/test/profile/ktls.7743.
>
> Warning: address  128f35:      eb ae                  jmp    128ee5 is
> longer than address length 16
>
> Total: 3431 samples
>
>     1225  35.7%  35.7%    1225  35.7% epoll_wait
>
>     875  25.5%  61.2%      880  25.6% __sendmsg
>
>     477  13.9%  75.1%      477  13.9% _aesni_ctr32_ghash_6x
>
>     146  4.3%  79.4%      146  4.3% pthread_cond_signal@@GLIBC_2.3.2
>
>     127  3.7%  83.1%      127  3.7% __memmove_avx_unaligned_erms
>
>     123  3.6%  86.7%      127  3.7% __recvmsg
>
>       58  1.7%  88.3%      58  1.7% __lll_lock_wake
>
>       16  0.5%  88.8%      16  0.5% __strcmp_avx2
>
>       15  0.4%  89.2%    1867  54.4% ngx_epoll_process_events
>
>       15  0.4%  89.7%      51  1.5% ngx_quic_create_frame
>
>       14  0.4%  90.1%      14  0.4% aesni_ctr32_encrypt_blocks
>
>       14  0.4%  90.5%      255  7.4% ngx_quic_recvmsg
>
>       13  0.4%  90.9%      14  0.4% evp_cipher_init_internal
>
>       13  0.4%  91.3%    1540  44.9% ngx_quic_output
>
>       11  0.3%  91.6%      11  0.3% gcm_ghash_avx
>
>       10  0.3%  91.9%      10  0.3% ngx_quic_parse_frame
>
>       8  0.2%  92.1%        8  0.2% __pthread_disable_asynccancel
>
>       7  0.2%  92.3%        7  0.2% ngx_quic_commit_send
>
>       6  0.2%  92.5%        6  0.2% aesni_encrypt
>
>       6  0.2%  92.7%      506  14.7% generic_aes_gcm_cipher_update
>
>       6  0.2%  92.8%      114  3.3% ngx_http_write_filter
>
>       6  0.2%  93.0%      598  17.4% ngx_quic_crypto_common
>
> ...
>
>
>
> Если использовать протокол HTTP/1.1
>
> Using local file
> /nix/store/dd7van8jrcmnxmwdsbkyyzhd98myzg2j-nginxQuic-1.25.3/bin/nginx.
>
> Argument "MSWin32" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Argument "linux" isn't numeric in numeric eq (==) at
> /run/current-system/sw/bin/pprof line 5047.
>
> Using local file /var/www/test/profile/ktls.9140.
>
> Warning: address  128f35:      eb ae                  jmp    128ee5 is
> longer than address length 16
>
> Total: 2354 samples
>
>     2329  98.9%  98.9%    2329  98.9% sendfile64
>
>       7  0.3%  99.2%        7  0.3% __sched_yield
>
>       5  0.2%  99.4%        5  0.2% epoll_wait
>
>       2  0.1%  99.5%    2335  99.2% ngx_http_sub_body_filter
>
>       2  0.1%  99.6%    2339  99.4% ngx_http_writer
>
>       1  0.0%  99.7%        1  0.0% CRYPTO_free
>
>       1  0.0%  99.7%    2330  99.0% SSL_sendfile
>
>       1  0.0%  99.7%        1  0.0% __GI___clock_gettime
>
>       1  0.0%  99.8%        7  0.3% ngx_epoll_process_events
>
>       1  0.0%  99.8%    2336  99.2% ngx_http_copy_filter
>
>       1  0.0%  99.9%    2337  99.3% ngx_http_range_body_filter
>
>       1  0.0%  99.9%    2333  99.1% ngx_http_xslt_body_filter
>
>       1  0.0% 100.0%    2332  99.1% ngx_ssl_send_chain
>
>       1  0.0% 100.0%        1  0.0% xmlMutexLock
>
>       0  0.0% 100.0%        1  0.0% ERR_clear_error
>
>       0  0.0% 100.0%    2354 100.0% __libc_start_call_main
>
>       0  0.0% 100.0%    2354 100.0% __libc_start_main_impl
>
>       0  0.0% 100.0%    2354 100.0% _start
>
>       0  0.0% 100.0%    2354 100.0% main
>
> ...
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/34efdea9/attachment-0001.htm>
----------- следующая часть -----------
Вложение не в текстовом формате было извлечено&hellip;
Имя: Screenshot from 2024-01-03 15-43-29.png
Тип: image/png
Размер: 134685 байтов
Описание: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/34efdea9/attachment-0001.png>

From izorkin на gmail.com  Wed Jan  3 15:01:16 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 18:01:16 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
 <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>
Message-ID: <762327650.20240103180116@gmail.com>

Здравствуйте, Илья.

Ну для меня это самый простой способ проверить скорость, в лоб :)
 
Вы писали 3 января 2024 г., 17:38:39:

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

> я видел что-то типа "средний размер ответа 12.5 килобайт и 100 abbreviated handshakes на 1 full handshake".
Возможно ли это сделать с gperftools.
 
Вы писали 3 января 2024 г., 17:26:36:

> из того, что бросается в глаза, на http/3 не видно sendfile.

> из того, что интересно, там два столбца с процентами, непонятно, что из них что.
> обычно это в каком-то порядке "self", т.е. собственное время функции, и "incl", кумулятивное время со всеми вызываемыми функциями

> но по приведенной легенде не видно, кто есть кто
Это надо уже настраивать ещё одну виртуальную машину для теста.
 
Вы писали 3 января 2024 г., 17:31:43:

> насколько я понимаю, sendfile это отдача локальной статики.один из возможных случаев, но было бы интересно посмотреть на реверс прокси
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/7091e218/attachment.htm>

From chipitsine на gmail.com  Wed Jan  3 15:10:06 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 16:10:06 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <762327650.20240103180116@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
 <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>
 <762327650.20240103180116@gmail.com>
Message-ID: <CAFHpkQGbKcnk6x0M7mvTSAeHjh1ERg2Vc7TFaxYTc1y9v8qvMw@mail.gmail.com>

ну какбы нет универсальной https нагрузки.

я в проде видел такое

1) контекстная реклама. клиент приходит ровно 1 раз. делает полный ssl
хендшейк, делает маленький запрос.
2) приложение на react, с примерно 100 asset-ами, которые генерировали
запросы на js, css, png

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

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

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

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

ср, 3 янв. 2024 г. в 16:01, <izorkin на gmail.com>:

> Здравствуйте, Илья.
>
>
> Ну для меня это самый простой способ проверить скорость, в лоб :)
>
>
>
> Вы писали 3 января 2024 г., 17:38:39:
>
>
> на самом деле, нагрузка вида "один SSL хендшейк и скачивание локального
> файла в терабайт" - непохожа ни на одну, которую я видел в проде.
> возможно, это что-то первое пришедшее в голову. как вариант поиграться -
> почему нет.
>
> я видел что-то типа "средний размер ответа 12.5 килобайт и 100 abbreviated
> handshakes на 1 full handshake".
>
> Возможно ли это сделать с gperftools.
>
>
>
> Вы писали 3 января 2024 г., 17:26:36:
>
>
> из того, что бросается в глаза, на http/3 не видно sendfile.
>
> из того, что интересно, там два столбца с процентами, непонятно, что из
> них что.
> обычно это в каком-то порядке "self", т.е. собственное время функции, и
> "incl", кумулятивное время со всеми вызываемыми функциями
>
> но по приведенной легенде не видно, кто есть кто
>
> Это надо уже настраивать ещё одну виртуальную машину для теста.
>

не, это вопрос к интерпретации снятых данных. вы что-то сняли, вопрос что
именно.


>
>
> Вы писали 3 января 2024 г., 17:31:43:
>
>
> насколько я понимаю, sendfile это отдача локальной статики.
> один из возможных случаев, но было бы интересно посмотреть на реверс прокси
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/362132d4/attachment-0001.htm>

From izorkin на gmail.com  Wed Jan  3 15:37:42 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 18:37:42 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQGbKcnk6x0M7mvTSAeHjh1ERg2Vc7TFaxYTc1y9v8qvMw@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
 <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>
 <762327650.20240103180116@gmail.com>
 <CAFHpkQGbKcnk6x0M7mvTSAeHjh1ERg2Vc7TFaxYTc1y9v8qvMw@mail.gmail.com>
Message-ID: <1645162257.20240103183742@gmail.com>

Добрый вечер, Илья.
 
Не уверен, что хватит свободного времени, чтобы углубиться в тестирование с помощью jmeter-а. Я на практике
практически не сталкиваюсь с такими высокими нагрузками. Хотелось просто провести простое сравнение
производительности с Kernel TLS, предполагал, что и для QUIC протокола будет заметный прирост скорости.

 
Вы писали 3 января 2024 г., 18:10:06:

> ну какбы нет универсальной https нагрузки.

> я в проде видел такое

> 1) контекстная реклама. клиент приходит ровно 1 раз. делает полный ssl хендшейк, делает маленький запрос.
> 2) приложение на react, с примерно 100 asset-ами, которые генерировали запросы на js, css, png

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

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

> я бы попробовал jmeter-ом описать разные профили и пострелять. серверный профиль во всех случаях одинаково снимается gperftool-ом

> ну и интересный вопрос, может ли и должен ли быть sendfile в случае http/3 (это из того, что вы сняли, бросается в глаза).

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/6372f080/attachment.htm>

From chipitsine на gmail.com  Wed Jan  3 15:44:29 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 3 Jan 2024 16:44:29 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1645162257.20240103183742@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
 <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>
 <762327650.20240103180116@gmail.com>
 <CAFHpkQGbKcnk6x0M7mvTSAeHjh1ERg2Vc7TFaxYTc1y9v8qvMw@mail.gmail.com>
 <1645162257.20240103183742@gmail.com>
Message-ID: <CAFHpkQEV6B64PLM_JX04xGrbvxEe4tpRkEwibEOtnXZrWgUJxQ@mail.gmail.com>

ср, 3 янв. 2024 г. в 16:38, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
>
> Не уверен, что хватит свободного времени, чтобы углубиться в тестирование
> с помощью jmeter-а. Я на практике
>
> практически не сталкиваюсь с такими высокими нагрузками. Хотелось просто
> провести простое сравнение
>
> производительности с Kernel TLS, предполагал, что и для QUIC протокола
> будет заметный прирост скорости.
>

у QUIC область применимости - плохого качества интернет 3G и браузерная
нагрузка.
там, где tcp будет тормозить на своих хендшейках, у QUIC-а нет
tcp-хендшейков, там, где tcp будет снижать размер окна
из-за потерь, у QUIC-а с этим лучше.

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

из простого, можно попробовать добавить 30% потерь пакетов и замерить
скорость в вашем случае.

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


>
>
>
> Вы писали 3 января 2024 г., 18:10:06:
>
>
> ну какбы нет универсальной https нагрузки.
>
> я в проде видел такое
>
> 1) контекстная реклама. клиент приходит ровно 1 раз. делает полный ssl
> хендшейк, делает маленький запрос.
> 2) приложение на react, с примерно 100 asset-ами, которые генерировали
> запросы на js, css, png
>
> соотношение количества полных ssl хендшейков к сокращенным было разное. и
> оно довольно сильно отличается от продакшена к продакшену.
>
> замерять так, как вы замеряли - да, прикольно. но стоит иметь в виду, что
> возможны и другие кейсы.
>
> я бы попробовал jmeter-ом описать разные профили и пострелять. серверный
> профиль во всех случаях одинаково снимается gperftool-ом
>
> ну и интересный вопрос, может ли и должен ли быть sendfile в случае http/3
> (это из того, что вы сняли, бросается в глаза).
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/2e0b0f34/attachment-0001.htm>

From izorkin на gmail.com  Wed Jan  3 17:08:53 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 20:08:53 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQEV6B64PLM_JX04xGrbvxEe4tpRkEwibEOtnXZrWgUJxQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEUwWkqyYb5_wqY8Cr8dn2MrKu5QDUbhqpOU5p7anU61Q@mail.gmail.com>
 <1704604593.20240103001947@gmail.com>
 <CAFHpkQF4MR2H_X=6vk8JW70BzXYqZ=NEVqmLTifyU_OFkp-_3Q@mail.gmail.com>
 <994372619.20240103074414@gmail.com>
 <CAFHpkQGYndyVz=ZzbR_5PxWdOVj1sqjjEMGJGanwQx3qu2LPCQ@mail.gmail.com>
 <CAFHpkQHdt1XkV7oLiMPkgmqJksn9hAsDxkNRjFY+JXROcAVfbA@mail.gmail.com>
 <CAFHpkQH6PWa1WP4Qndh8FH8O=EXPnuQYJW0prY_=VC5yUf=6BA@mail.gmail.com>
 <637302114.20240103162522@gmail.com>
 <CAFHpkQGoS2gg9iZfg3KUznq_rRNfwA+4J+PeK+OS858oZyHUcA@mail.gmail.com>
 <175599485.20240103171219@gmail.com>
 <CAFHpkQEr1ps8t6QX5PdZScBOfytJAvRF7FefMfdjvSQedFJORQ@mail.gmail.com>
 <CAFHpkQFtO6x0YjrE6hi1n+NffYcf_v39msswV3aF=zQzgjJEYA@mail.gmail.com>
 <762327650.20240103180116@gmail.com>
 <CAFHpkQGbKcnk6x0M7mvTSAeHjh1ERg2Vc7TFaxYTc1y9v8qvMw@mail.gmail.com>
 <1645162257.20240103183742@gmail.com>
 <CAFHpkQEV6B64PLM_JX04xGrbvxEe4tpRkEwibEOtnXZrWgUJxQ@mail.gmail.com>
Message-ID: <1089725993.20240103200853@gmail.com>

Добрый вечер, Илья.

Через браузер у меня не получается замерить скорость с эмуляцией потерь, не хочет активировать подключения
внутри локальной сети по HTTP/3 протоколу с само-подписными сертификатами, хотя тестовый корневой сертификат
добавлен в систему и все необходимые параметры прописаны.
 
К тому же аналогичная нагрузка должна быть у сервисов стриминга видео, разве что там видео отдаётся частями
поменьше.
 
 
Вы писали 3 января 2024 г., 18:44:29:

> у QUIC область применимости - плохого качества интернет 3G и браузерная нагрузка.
> там, где tcp будет тормозить на своих хендшейках, у QUIC-а нет tcp-хендшейков, там, где tcp будет снижать размер окна
> из-за потерь, у QUIC-а с этим лучше.

> на синтетической нагрузке типа вашей - результат интересный, но не совсем то, подо что проектировался QUIC

> из простого, можно попробовать добавить 30% потерь пакетов и замерить скорость в вашем случае.

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

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240103/061ceb68/attachment.htm>

From izorkin на gmail.com  Wed Jan  3 19:17:37 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Wed, 3 Jan 2024 22:17:37 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L3QtSDQv9C+0LTQtNC10YDQttC40LLQsNC10LzRi9C1INC+0L8=?=
 =?utf-8?B?0YbQuNC4IGJhY2tsb2csZGVmZXJyZWQg0LggZmFzdG9wZW4=?=
In-Reply-To: <B20F1C73-7498-4511-8B31-C0406F85C979@nginx.com>
References: <767484501.20231211130145@gmail.com>
 <B20F1C73-7498-4511-8B31-C0406F85C979@nginx.com>
Message-ID: <45659296.20240103221737@gmail.com>

Добрый вечер, Сергей.

Благодарю, патч проверил, работает.

Вы писали 20 декабря 2023 г., 18:05:18:

> Значение параметра backlog передаётся в вызов listen().  Для сокетов
> типа SOCK_DGRAM, используемых в QUIC, listen() не поддерживается и в
> nginx не вызывается, посему для них параметр backlog не имеет смысла.
> Добавил в список запрещённых параметров, см. патч.


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From chipitsine на gmail.com  Thu Jan  4 11:24:21 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 12:24:21 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <582023013.20240102235008@gmail.com>
References: <582023013.20240102235008@gmail.com>
Message-ID: <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>

кстати, у QUIC Interop есть замеры быстродействия (Measurement result)

https://interop.seemann.io/

вт, 2 янв. 2024 г. в 21:50, <izorkin на gmail.com>:

> Здравствуйте.
>
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> разными протоколами:
>  - 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?
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/fa779ec4/attachment-0001.htm>

From izorkin на gmail.com  Thu Jan  4 12:24:19 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 4 Jan 2024 15:24:19 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
Message-ID: <344095917.20240104152419@gmail.com>

Добрый день, Илья.

По результатам видно, что скорость явно больше, чем у меня выходит на
виртуальной машине. Но скорость не превышает ~9700 кбит/сек. Там у них
не упираются тесты в ограничения сетевой карты?
Надо наверное попробовать протестировать на физическом сервере.
 
Вы писали 4 января 2024 г., 14:24:21:

> кстати, у QUIC Interop есть замеры быстродействия (Measurement result)

> https://interop.seemann.io/

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/b0603819/attachment.htm>

From chipitsine на gmail.com  Thu Jan  4 12:40:06 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 13:40:06 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <344095917.20240104152419@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
Message-ID: <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>

на вашей виртуальной машине производительность уперлась в особенности
реализации QUIC, вы просто выгребли 100% процессора.
скажем, вы замеряли "сколько можно получить байт в сек на данном цпу для
разных реализаций"

в QUIC Interop тесты весьма и весьма ресурсоемкие, там кроме передачи
шифрованного трафика еще дешифруется трафик, захваченный через tshark.
в тестах, где меньше, чем 9700 - уперлись в особенности реализации, а 9700
- это выглядит как потолок для того железа

чем замечательны http/2 и http/3 - это протоколы и реализации очень
качественно покрытые тестами, что-то совершенно невообразимое для http/1.1


чт, 4 янв. 2024 г. в 13:24, <izorkin на gmail.com>:

> Добрый день, Илья.
>
>
> По результатам видно, что скорость явно больше, чем у меня выходит на
>
> виртуальной машине. Но скорость не превышает ~9700 кбит/сек. Там у них
>
> не упираются тесты в ограничения сетевой карты?
>
> Надо наверное попробовать протестировать на физическом сервере.
>
>
>
> Вы писали 4 января 2024 г., 14:24:21:
>
>
> кстати, у QUIC Interop есть замеры быстродействия (Measurement result)
>
> https://interop.seemann.io/
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/570ed8be/attachment.htm>

From izorkin на gmail.com  Thu Jan  4 16:04:31 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 4 Jan 2024 19:04:31 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
Message-ID: <1368454677.20240104190431@gmail.com>

Добрый вечер, Илья.
 
Замерил тесты на физическом сервере, пока без без поддержки kTLS.
Оказывается в тестах на виртуальной машине я неправильно интерпретировал интерпретировал скорости,
которые выводила утилита curl. Вместо МБит/сек там идёт МБайт/сек.
 
Результаты тестов при скачивании файла с самого сервера:
 - HTTP/1.1 - ~3 504,14 МБит/сек (CPU load 100%)
 - HTTP/2 - ~3 568,57 МБит/сек (CPU load 100%)
 - HTTP/3 - ~2 872,09 МБит/сек (CPU load 58-62%)
 
Результаты тестов при скачивании файла по локальной сети:
 - HTTP/1.1 - ~2 325,03 МБит/сек (CPU load 45-50%)
 - HTTP/2 - ~2 333,56 МБит/сек (CPU load 45-50%)
 - HTTP/3 - ~1 350,26 МБит/сек (CPU load 50-55%)

Анализ профиля для протокола HTTP/3 при скачивании файла с самого сервера:
    482  27.1%  27.1%      482  27.1% __sendmsg
    473  26.6%  53.7%      473  26.6% __libc_pread64
    367  20.6%  74.4%      367  20.6% _aesni_ctr32_ghash_6x
    151  8.5%  82.8%      151  8.5% __memmove_avx_unaligned_erms
      58  3.3%  86.1%      58  3.3% epoll_wait
      31  1.7%  87.9%      31  1.7% __recvmsg
      10  0.6%  88.4%      93  5.2% ngx_quic_write_buffer
      8  0.4%  88.9%      100  5.6% ngx_quic_recvmsg
      7  0.4%  89.3%        7  0.4% __strcmp_avx2
      7  0.4%  89.7%        7  0.4% ngx_quic_read_buffer
      6  0.3%  90.0%      115  6.5% ngx_http_charset_body_filter
      6  0.3%  90.3%      108  6.1% ngx_http_write_filter
      6  0.3%  90.7%      82  4.6% ngx_quic_create_frame
      6  0.3%  91.0%        8  0.4% ossl_gcm_set_ctx_params
      5  0.3%  91.3%      19  1.1% EVP_CIPHER_CTX_ctrl
      5  0.3%  91.6%        5  0.3% aesni_ctr32_encrypt_blocks
      5  0.3%  91.8%        5  0.3% ngx_quic_alloc_buf
      5  0.3%  92.1%      15  0.8% ngx_quic_handle_ack_frame_range
      5  0.3%  92.4%      59  3.3% ngx_quic_handle_datagram
      4  0.2%  92.6%      10  0.6% CRYPTO_gcm128_encrypt_ctr32
 
Анализ профиля для протокола HTTP/3 при скачивании файла по локальной сети:
    953  33.5%  33.5%      953  33.5% __sendmsg
    516  18.1%  51.6%      516  18.1% __libc_pread64
    388  13.6%  65.2%      388  13.6% _aesni_ctr32_ghash_6x
    128  4.5%  69.7%      128  4.5% __memmove_avx_unaligned_erms
    128  4.5%  74.2%      128  4.5% epoll_wait
    101  3.5%  77.7%      101  3.5% __recvmsg
      24  0.8%  78.6%      306  10.7% ngx_quic_recvmsg
      21  0.7%  79.3%      21  0.7% __strcmp_avx2
      20  0.7%  80.0%      76  2.7% ngx_quic_create_frame
      19  0.7%  80.7%      122  4.3% ngx_http_write_filter
      18  0.6%  81.3%      18  0.6% aesni_encrypt
      15  0.5%  81.8%      413  14.5% aesni_gcm_encrypt
      14  0.5%  82.3%      56  2.0% EVP_CIPHER_CTX_ctrl
      14  0.5%  82.8%    1690  59.3% ngx_quic_output
      13  0.5%  83.3%      23  0.8% ossl_gcm_set_ctx_params
      12  0.4%  83.7%      13  0.5% aesni_ctr32_encrypt_blocks
      12  0.4%  84.1%      627  22.0% ngx_quic_crypto_common
      12  0.4%  84.6%      16  0.6% ngx_quic_read_buffer
      11  0.4%  84.9%      678  23.8% ngx_output_chain
      11  0.4%  85.3%      695  24.4% ngx_quic_output_packet
 
По итогу результаты значительно отличаются от тестов на виртуальной машине. На виртуальной машине при обработке
протокола QUIC процесс упирался в 100% и выдавал скорость больше, чем при обработке протокола HTTP 1.1, а на
реальном физическом месте держится в районе 60%, и просадка скорости значительная.
Может быть где-то быть узкое место в обработке QUIC, из-за которого проявляется более низкая скорость?
 
 
Вы писали 4 января 2024 г., 15:40:06:

> на вашей виртуальной машине производительность уперлась в особенности реализации QUIC, вы просто выгребли 100% процессора.
> скажем, вы замеряли "сколько можно получить байт в сек на данном цпу для разных реализаций"

> в QUIC Interop тесты весьма и весьма ресурсоемкие, там кроме передачи шифрованного трафика еще дешифруется трафик, захваченный через tshark.
> в тестах, где меньше, чем 9700 - уперлись в особенности реализации, а 9700 - это выглядит как потолок для того железа

> чем замечательны http/2 и http/3 - это протоколы и реализации очень качественно покрытые тестами, что-то совершенно невообразимое для http/1.1

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/126a677e/attachment-0001.htm>

From chipitsine на gmail.com  Thu Jan  4 16:44:26 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 17:44:26 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1368454677.20240104190431@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
Message-ID: <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>

чт, 4 янв. 2024 г. в 17:04, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
>
> Замерил тесты на физическом сервере, пока без без поддержки kTLS.
>
> Оказывается в тестах на виртуальной машине я неправильно интерпретировал
> интерпретировал скорости,
>
> которые выводила утилита curl. Вместо МБит/сек там идёт МБайт/сек.
>
>
>
> Результаты тестов при скачивании файла с самого сервера:
>
>  - HTTP/1.1 - ~3 504,14 МБит/сек (CPU load 100%)
>
>  - HTTP/2 - ~3 568,57 МБит/сек (CPU load 100%)
>
>  - HTTP/3 - ~2 872,09 МБит/сек (CPU load 58-62%)
>
>
>
> Результаты тестов при скачивании файла по локальной сети:
>
>  - HTTP/1.1 - ~2 325,03 МБит/сек (CPU load 45-50%)
>
>  - HTTP/2 - ~2 333,56 МБит/сек (CPU load 45-50%)
>
>  - HTTP/3 - ~1 350,26 МБит/сек (CPU load 50-55%)
>
>
> Анализ профиля для протокола HTTP/3 при скачивании файла с самого сервера:
>
>     482  27.1%  27.1%      482  27.1% __sendmsg
>
>     473  26.6%  53.7%      473  26.6% __libc_pread64
>
>     367  20.6%  74.4%      367  20.6% _aesni_ctr32_ghash_6x
>
>     151  8.5%  82.8%      151  8.5% __memmove_avx_unaligned_erms
>
>       58  3.3%  86.1%      58  3.3% epoll_wait
>
>       31  1.7%  87.9%      31  1.7% __recvmsg
>
>       10  0.6%  88.4%      93  5.2% ngx_quic_write_buffer
>
>       8  0.4%  88.9%      100  5.6% ngx_quic_recvmsg
>
>       7  0.4%  89.3%        7  0.4% __strcmp_avx2
>
>       7  0.4%  89.7%        7  0.4% ngx_quic_read_buffer
>
>       6  0.3%  90.0%      115  6.5% ngx_http_charset_body_filter
>
>       6  0.3%  90.3%      108  6.1% ngx_http_write_filter
>
>       6  0.3%  90.7%      82  4.6% ngx_quic_create_frame
>
>       6  0.3%  91.0%        8  0.4% ossl_gcm_set_ctx_params
>
>       5  0.3%  91.3%      19  1.1% EVP_CIPHER_CTX_ctrl
>
>       5  0.3%  91.6%        5  0.3% aesni_ctr32_encrypt_blocks
>
>       5  0.3%  91.8%        5  0.3% ngx_quic_alloc_buf
>
>       5  0.3%  92.1%      15  0.8% ngx_quic_handle_ack_frame_range
>
>       5  0.3%  92.4%      59  3.3% ngx_quic_handle_datagram
>
>       4  0.2%  92.6%      10  0.6% CRYPTO_gcm128_encrypt_ctr32
>


не совсем понятно, что означают эти проценты.
например " 482  27.1%  27.1%      482  27.1% __sendmsg" - что в первом и
что во втором столбце


>
>
> Анализ профиля для протокола HTTP/3 при скачивании файла по локальной сети:
>
>     953  33.5%  33.5%      953  33.5% __sendmsg
>
>     516  18.1%  51.6%      516  18.1% __libc_pread64
>
>     388  13.6%  65.2%      388  13.6% _aesni_ctr32_ghash_6x
>
>     128  4.5%  69.7%      128  4.5% __memmove_avx_unaligned_erms
>
>     128  4.5%  74.2%      128  4.5% epoll_wait
>
>     101  3.5%  77.7%      101  3.5% __recvmsg
>
>       24  0.8%  78.6%      306  10.7% ngx_quic_recvmsg
>
>       21  0.7%  79.3%      21  0.7% __strcmp_avx2
>
>       20  0.7%  80.0%      76  2.7% ngx_quic_create_frame
>
>       19  0.7%  80.7%      122  4.3% ngx_http_write_filter
>
>       18  0.6%  81.3%      18  0.6% aesni_encrypt
>
>       15  0.5%  81.8%      413  14.5% aesni_gcm_encrypt
>
>       14  0.5%  82.3%      56  2.0% EVP_CIPHER_CTX_ctrl
>
>       14  0.5%  82.8%    1690  59.3% ngx_quic_output
>
>       13  0.5%  83.3%      23  0.8% ossl_gcm_set_ctx_params
>
>       12  0.4%  83.7%      13  0.5% aesni_ctr32_encrypt_blocks
>
>       12  0.4%  84.1%      627  22.0% ngx_quic_crypto_common
>
>       12  0.4%  84.6%      16  0.6% ngx_quic_read_buffer
>
>       11  0.4%  84.9%      678  23.8% ngx_output_chain
>
>       11  0.4%  85.3%      695  24.4% ngx_quic_output_packet
>
>
>
> По итогу результаты значительно отличаются от тестов на виртуальной
> машине. На виртуальной машине при обработке
>
> протокола QUIC процесс упирался в 100% и выдавал скорость больше, чем при
> обработке протокола HTTP 1.1, а на
>
> реальном физическом месте держится в районе 60%, и просадка скорости
> значительная.
>
> Может быть где-то быть узкое место в обработке QUIC, из-за которого
> проявляется более низкая скорость?
>

смотрите. я предлагал потестировать quictls-1.1.1, вы проигнорировали.
более того, вы сняли профиль для http/1.1 - там видно, что использууется
sendfile, для http/3 используются совсем другие функции

т.е. вы буквально видите, что механизмы отдачи для http/1.1 и http/3 разные.

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

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


>
>
>
>
> Вы писали 4 января 2024 г., 15:40:06:
>
>
> на вашей виртуальной машине производительность уперлась в особенности
> реализации QUIC, вы просто выгребли 100% процессора.
> скажем, вы замеряли "сколько можно получить байт в сек на данном цпу для
> разных реализаций"
>
> в QUIC Interop тесты весьма и весьма ресурсоемкие, там кроме передачи
> шифрованного трафика еще дешифруется трафик, захваченный через tshark.
> в тестах, где меньше, чем 9700 - уперлись в особенности реализации, а 9700
> - это выглядит как потолок для того железа
>
> чем замечательны http/2 и http/3 - это протоколы и реализации очень
> качественно покрытые тестами, что-то совершенно невообразимое для http/1.1
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/4357ddef/attachment.htm>

From izorkin на gmail.com  Thu Jan  4 17:56:45 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 4 Jan 2024 20:56:45 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
Message-ID: <1934360562.20240104205645@gmail.com>

Добрый вечер, Илья.
 
Вы писали 4 января 2024 г., 19:44:26:

> смотрите. я предлагал потестировать quictls-1.1.1, вы проигнорировали.
Я пробовал использовать quictls-1.1.1, но там прирост скорости незначительный был. Сейчас ещё раз проверил, изменений
в скорости практически нет
 
 
> более того, вы сняли профиль для http/1.1 - там видно, что использууется sendfile, для http/3 используются совсем другие функции
> т.е. вы буквально видите, что механизмы отдачи для http/1.1 и http/3 разные.

> возможно, что в этом различии заключается то самое узкое место, про которое вы говорите.

> вы ожидаете прямого ответа "да, там где-то есть узкое место".
> ок, вы его услышали. на этом исследование закончено )) ?
Думал, может есть какой-то волшебный метод ускорения :)
И ещё видно, что при тесте на виртуальной машине высокое значение у epoll_wait для HTTP/3 протокола (35.7%, против 0.2% для
протокола HTTP 1.1), поэтому у меня тест на физической машине значительно отличается.
 
 
> не совсем понятно, что означают эти проценты.например " 482  27.1%  27.1%      482  27.1% __sendmsg" - что в первом и что во втором столбце
Может из-за того, что я забыл включить epoll во время тестов...
Перезапустил тесты для HTTP/3 протокола.
 
Тест на сервере:
Total: 1804 samples
    476  26.4%  26.4%      476  26.4% __libc_pread64
    468  25.9%  52.3%      468  25.9% __sendmsg
    393  21.8%  74.1%      393  21.8% _aesni_ctr32_ghash_6x
    148  8.2%  82.3%      148  8.2% __memmove_avx_unaligned_erms
      41  2.3%  84.6%      41  2.3% epoll_wait
      33  1.8%  86.4%      33  1.8% __recvmsg
      14  0.8%  87.2%      87  4.8% ngx_quic_create_frame
      9  0.5%  87.7%      10  0.6% aesni_ctr32_encrypt_blocks
 
Тест по локальной сети:
    934  32.8%  32.8%      934  32.8% __sendmsg
    531  18.6%  51.4%      531  18.6% __libc_pread64
    462  16.2%  67.7%      462  16.2% _aesni_ctr32_ghash_6x
    126  4.4%  72.1%      126  4.4% __memmove_avx_unaligned_erms
    116  4.1%  76.2%      116  4.1% epoll_wait
      68  2.4%  78.5%      68  2.4% __recvmsg
      27  0.9%  79.5%      257  9.0% ngx_quic_recvmsg
      21  0.7%  80.2%      21  0.7% __strcmp_avx2
      20  0.7%  80.9%      20  0.7% aesni_encrypt
 
  
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/7f505cba/attachment-0001.htm>

From chipitsine на gmail.com  Thu Jan  4 18:04:48 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 19:04:48 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1934360562.20240104205645@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
Message-ID: <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>

чт, 4 янв. 2024 г. в 18:56, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
>
> Вы писали 4 января 2024 г., 19:44:26:
>
>
> смотрите. я предлагал потестировать quictls-1.1.1, вы проигнорировали.
>
> Я пробовал использовать quictls-1.1.1, но там прирост скорости
> незначительный был. Сейчас ещё раз проверил, изменений
>
> в скорости практически нет
>

ну, выглядело так, будто проигнорировали. приношу извинения


>
>
>
>
> более того, вы сняли профиль для http/1.1 - там видно, что использууется
> sendfile, для http/3 используются совсем другие функции
>
>
> т.е. вы буквально видите, что механизмы отдачи для http/1.1 и http/3
> разные.
>
> возможно, что в этом различии заключается то самое узкое место, про
> которое вы говорите.
>
> вы ожидаете прямого ответа "да, там где-то есть узкое место".
> ок, вы его услышали. на этом исследование закончено )) ?
>
> Думал, может есть какой-то волшебный метод ускорения :)
>

выглядит так, будто вас интересует что-то конкретное. а остальное вы
игнорируете.

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


> И ещё видно, что при тесте на виртуальной машине высокое значение у epoll_wait
> для HTTP/3 протокола (35.7%, против 0.2% для
>
> протокола HTTP 1.1), поэтому у меня тест на физической машине значительно
> отличается.
>
>
>
>
>
> не совсем понятно, что означают эти проценты.
> например " 482  27.1%  27.1%      482  27.1% __sendmsg" - что в первом и
> что во втором столбце
>
> Может из-за того, что я забыл включить epoll во время тестов...
>
> Перезапустил тесты для HTTP/3 протокола.
>


нет. нет. и опять нет.
epoll на линуксе автоматически по дефолту.

вопрос в том, что за проценты в ваших столбцах, у вас в каждой строке 3
раза упоминаются проценты. что каждый из них означает (и навряд ли забытый
epoll как-то
даст ответ на вопрос, что это за проценты)

еще раз, вы живете в своей картине мира. мои вопросы, судя по всему, не
очень понятны и интересны.

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


>
>
> Тест на сервере:
>
> Total: 1804 samples
>
>     476  26.4%  26.4%      476  26.4% __libc_pread64
>
>     468  25.9%  52.3%      468  25.9% __sendmsg
>
>     393  21.8%  74.1%      393  21.8% _aesni_ctr32_ghash_6x
>
>     148  8.2%  82.3%      148  8.2% __memmove_avx_unaligned_erms
>
>       41  2.3%  84.6%      41  2.3% epoll_wait
>
>       33  1.8%  86.4%      33  1.8% __recvmsg
>
>       14  0.8%  87.2%      87  4.8% ngx_quic_create_frame
>
>       9  0.5%  87.7%      10  0.6% aesni_ctr32_encrypt_blocks
>
>
>
> Тест по локальной сети:
>
>     934  32.8%  32.8%      934  32.8% __sendmsg
>
>     531  18.6%  51.4%      531  18.6% __libc_pread64
>
>     462  16.2%  67.7%      462  16.2% _aesni_ctr32_ghash_6x
>
>     126  4.4%  72.1%      126  4.4% __memmove_avx_unaligned_erms
>
>     116  4.1%  76.2%      116  4.1% epoll_wait
>
>       68  2.4%  78.5%      68  2.4% __recvmsg
>
>       27  0.9%  79.5%      257  9.0% ngx_quic_recvmsg
>
>       21  0.7%  80.2%      21  0.7% __strcmp_avx2
>
>       20  0.7%  80.9%      20  0.7% aesni_encrypt
>
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/844e6040/attachment.htm>

From izorkin на gmail.com  Thu Jan  4 19:07:02 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 4 Jan 2024 22:07:02 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
Message-ID: <638048961.20240104220702@gmail.com>

Добрый вечер, Илья.
 
Вы писали 4 января 2024 г., 21:04:48:

> выглядит так, будто вас интересует что-то конкретное. а остальное вы игнорируете.
> давайте отталкиваться от ваших ожиданий. что бы для вас было интересным результатом в рамках данного исследования ?
В рамках данного исследования хотел сравнить как влияет активация поддержки kTLS на производительность.
 
В ходе тестирования для меня было не понятно, почему для HTTP/3 на основе UDP протокола скорость ниже, чем
для HTTP/1.1 на основе TCP протокола в режиме работы с использованием kTLS. Без этого режима видно,
что HTTP/3 быстрее, чем HTTP/1.1 на виртуальной машине.
А вот при тестировании на физическом сервере результаты сильно отличаются. В обоих случаях,с использованием kTLS и
без него, HTTP 1/1 быстрее.
Вот это путаница в результатах мне и не понятна.
> вопрос в том, что за проценты в ваших столбцах, у вас в каждой строке 3 раза упоминаются проценты. что каждый из них означает (и навряд ли забытый epoll как-то
> даст ответ на вопрос, что это за проценты)

> еще раз, вы живете в своей картине мира. мои вопросы, судя по всему, не очень понятны и интересны.
Вот пытаюсь разобраться, надо разгрести кашу в голове :)
 
Профилирование процессов для меня неизведанная область, поэтому я мало понимаю в результатах
вывода google performance tools. Поэтому точно не могу сказать что значат эти проценты. Возможно,
что это проценты использования пользовательского и системного окружения.
 
Из того, что понял в попытке анализа профиля, так это то, что при использовании протокола HTTP/1.1
в основном используется метод sendfile64, что позволяет добиться высокой скорости обработки. А вот
при обработке протокола HTTP/3 задействованы другие методы, по итогу скорость обработки медленнее.
 
Ещё не могу понять, так это почему у меня в тестах на виртуальной машине высокое значение epoll_wait
для протокола HTTP/3, а в остальных тестах оно минимально, как и на физическом сервере. Если бы была
проблема со скоростью чтения файла, то и для протокола HTTP/1.1 значение epoll_wait было бы примерно
одинаковым.
 
 
Также тесты дают задуматься о том, стоит ли вообще использовать у себя протокол HTTP/2, результаты
с использованием kTLS низкие.
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/10560189/attachment-0001.htm>

From chipitsine на gmail.com  Thu Jan  4 19:28:16 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 20:28:16 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <638048961.20240104220702@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
Message-ID: <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>

On Thu, Jan 4, 2024, 20:07 <izorkin на gmail.com> wrote:

> Добрый вечер, Илья.
>
>
>
> Вы писали 4 января 2024 г., 21:04:48:
>
>
> выглядит так, будто вас интересует что-то конкретное. а остальное вы
> игнорируете.
>
> давайте отталкиваться от ваших ожиданий. что бы для вас было интересным
> результатом в рамках данного исследования ?
>
> В рамках данного исследования хотел сравнить как влияет активация
> поддержки kTLS на производительность.
>
>
>
> В ходе тестирования для меня было не понятно, почему для HTTP/3 на основе
> UDP протокола скорость ниже, чем
>
> для HTTP/1.1 на основе TCP протокола в режиме работы с использованием
> kTLS. Без этого режима видно,
>
> что HTTP/3 быстрее, чем HTTP/1.1 на виртуальной машине.
>
> А вот при тестировании на физическом сервере результаты сильно отличаются.
> В обоих случаях,с использованием kTLS и
>
> без него, HTTP 1/1 быстрее.
>
> Вот это путаница в результатах мне и не понятна.
>
> вопрос в том, что за проценты в ваших столбцах, у вас в каждой строке 3
> раза упоминаются проценты. что каждый из них означает (и навряд ли забытый
> epoll как-то
> даст ответ на вопрос, что это за проценты)
>
> еще раз, вы живете в своей картине мира. мои вопросы, судя по всему, не
> очень понятны и интересны.
>
> Вот пытаюсь разобраться, надо разгрести кашу в голове :)
>
>
>
> Профилирование процессов для меня неизведанная область, поэтому я мало
> понимаю в результатах
>
> вывода google performance tools. Поэтому точно не могу сказать что значат
> эти проценты. Возможно,
>
> что это проценты использования пользовательского и системного окружения.
>
>
>
> Из того, что понял в попытке анализа профиля, так это то, что при
> использовании протокола HTTP/1.1
>
> в основном используется метод sendfile64, что позволяет добиться высокой
> скорости обработки. А вот
>
> при обработке протокола HTTP/3 задействованы другие методы, по итогу
> скорость обработки медленнее.
>
>
>
> Ещё не могу понять, так это почему у меня в тестах на виртуальной машине
> высокое значение epoll_wait
>
> для протокола HTTP/3, а в остальных тестах оно минимально, как и на
> физическом сервере. Если бы была
>
> проблема со скоростью чтения файла, то и для протокола HTTP/1.1 значение epoll_wait
> было бы примерно
>
> одинаковым.
>
>
>
>
>
> Также тесты дают задуматься о том, стоит ли вообще использовать у себя
> протокол HTTP/2, результаты
>
> с использованием kTLS низкие.
>

"Использовать у себя" - можете поделиться, где именно вы используете, если
не секрет?


>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/508c25c1/attachment.htm>

From izorkin на gmail.com  Thu Jan  4 19:37:05 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 4 Jan 2024 22:37:05 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
Message-ID: <51936101.20240104223705@gmail.com>

Добрый вечер, Илья.

> "Использовать у себя" - можете поделиться, где именно вы используете, если не секрет?

Использую на домашнем сервере, почта, микроблог Mastodon (Fediverse) и другие сервисы :)
Ну и в других местах, если надо кому-то что-то по мелочи настроить, но это не часто требуется.
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/2d0704ba/attachment-0001.htm>

From chipitsine на gmail.com  Thu Jan  4 20:25:28 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 21:25:28 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <51936101.20240104223705@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
Message-ID: <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>

чт, 4 янв. 2024 г. в 20:37, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
> "Использовать у себя" - можете поделиться, где именно вы используете, если
> не секрет?
>
>
> Использую на домашнем сервере, почта, микроблог Mastodon (Fediverse) и
> другие сервисы :)
>

как можно поступить в данном случае.

Mastodon - судя по описанию

1) written using ruby
2) туда ходят браузеры

из первого я бы предположил, что в конфиге есть proxy_pass (или аналог), а
значит нагрузка будет не sendfile-овая
из второго - в общих чертах, если есть браузеры, то примерно в 100% ответ
"да" для http/2 и http/3

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

еще http/2 более кайфово для браузера сжимает трафик за счет дедупликации
хедеров и подобных мелочей (что тоже немного увеличивает расход процессора)

если у вас что-то, куда ходит браузер (вы говорите, блог на Mastodon), то
вопрос включения или не включения http/2 обычно - насколько браузеру будет
кайфовее, а не
насколько вырастет расход процессора.

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

1) https://pagespeed.web.dev/ (с включенным и выключенным http/2)
2) сертификаты EC
3) 0-RTT (early data)



> Ну и в других местах, если надо кому-то что-то по мелочи настроить, но это
> не часто требуется.
>
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/cf83f6ef/attachment.htm>

From izorkin на gmail.com  Thu Jan  4 21:20:42 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 5 Jan 2024 00:20:42 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
Message-ID: <795430305.20240105002042@gmail.com>

Добрый вечер, Илья.

Благодарю за рекомендации!
По логам для Mastodon запросы идут в основном по протоколу HTTP/1.1, а по HTTP/2 протоколу
раз в 10 меньше, если сравнить сегодняшний лог.
 
Для Mastodon сейчас пытаюсь разобраться и оптимизировать конфигурацию для него:
https://github.com/mastodon/mastodon/pull/19644
 
Вполне возможно, что мог что-то упустить :)
 
Вы писали 4 января 2024 г., 23:25:28:
 
> как можно поступить в данном случае.

> Mastodon - судя по описанию

> 1) written using ruby
> 2) туда ходят браузеры

> из первого я бы предположил, что в конфиге есть proxy_pass (или аналог), а значит нагрузка будет не sendfile-овая
> из второго - в общих чертах, если есть браузеры, то примерно в 100% ответ "да" для http/2 и http/3

> http2 и http/3 делают для браузера более кайфово. ценой некоторого доп расхода цпу. браузер себя лимитирует 2-мя tcp
> сессиями, в рамках http/1.1 браузер может скачивать одновременно 2 объекта. современная верстка предполагает несколько десятков css, js, png файлов,
> в http/2 есть мультиплексирование запросов внутри одной сессии, за счет чего браузер может одновременно качать все файлы, не дожидаясь каждого отдельно.
Для оптимизации я ещё настроил автоматическое предварительное сжатие статических файлов в brotli и gzip форматы присутствующих в пакетах Mastodon/Peertube в NixOS.
 
> еще http/2 более кайфово для браузера сжимает трафик за счет дедупликации хедеров и подобных мелочей (что тоже немного увеличивает расход процессора)
> если у вас что-то, куда ходит браузер (вы говорите, блог на Mastodon), то вопрос включения или не включения http/2 обычно - насколько браузеру будет кайфовее, а не
> насколько вырастет расход процессора.
Ну до 2-го пункта врядли дойдёт дело. Параметр для0-RTT использую в HTTP/3 протоколе :). Протестировать сайт с 
помощью pagespeed надо как-нибудь протестировать, не забыть.
> я бы посоветовался с каким-нибудь SEO из вебстудии, но то, что навскидку приходит в голову ...

> 1) https://pagespeed.web.dev/ (с включенным и выключенным http/2)
> 2) сертификаты EC
> 3) 0-RTT (early data)

А вот с разницей в противоположных результатах скорости между виртуальным и физическим сервером надо
бы как-то разобраться, хотя бы понять почему так происходит :)
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/2a53e966/attachment-0001.htm>

From chipitsine на gmail.com  Thu Jan  4 21:37:11 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 22:37:11 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <795430305.20240105002042@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
Message-ID: <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>

чт, 4 янв. 2024 г. в 22:21, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
> Благодарю за рекомендации!
>
> По логам для Mastodon запросы идут в основном по протоколу HTTP/1.1, а по
> HTTP/2 протоколу
>
> раз в 10 меньше, если сравнить сегодняшний лог.
>
>
>
> Для Mastodon сейчас пытаюсь разобраться и оптимизировать конфигурацию для
> него:
>
> https://github.com/mastodon/mastodon/pull/19644
>
>
>
> Вполне возможно, что мог что-то упустить :)
>
>
>
> Вы писали 4 января 2024 г., 23:25:28:
>
>
>
> как можно поступить в данном случае.
>
> Mastodon - судя по описанию
>
> 1) written using ruby
> 2) туда ходят браузеры
>
> из первого я бы предположил, что в конфиге есть proxy_pass (или аналог), а
> значит нагрузка будет не sendfile-овая
> из второго - в общих чертах, если есть браузеры, то примерно в 100% ответ
> "да" для http/2 и http/3
>
> http2 и http/3 делают для браузера более кайфово. ценой некоторого доп
> расхода цпу. браузер себя лимитирует 2-мя tcp
> сессиями, в рамках http/1.1 браузер может скачивать одновременно 2
> объекта. современная верстка предполагает несколько десятков css, js, png
> файлов,
> в http/2 есть мультиплексирование запросов внутри одной сессии, за счет
> чего браузер может одновременно качать все файлы, не дожидаясь каждого
> отдельно.
>
> Для оптимизации я ещё настроил автоматическое предварительное сжатие
> статических файлов в brotli и gzip форматы присутствующих в пакетах
> Mastodon/Peertube в NixOS.
>
>
>
> еще http/2 более кайфово для браузера сжимает трафик за счет дедупликации
> хедеров и подобных мелочей (что тоже немного увеличивает расход процессора)
>
> если у вас что-то, куда ходит браузер (вы говорите, блог на Mastodon), то
> вопрос включения или не включения http/2 обычно - насколько браузеру будет
> кайфовее, а не
> насколько вырастет расход процессора.
>
> Ну до 2-го пункта врядли дойдёт дело. Параметр для0-RTT использую в HTTP/3
> протоколе :). Протестировать сайт с
>
> помощью pagespeed надо как-нибудь протестировать, не забыть.
>
> я бы посоветовался с каким-нибудь SEO из вебстудии, но то, что навскидку
> приходит в голову ...
>
> 1) https://pagespeed.web.dev/ (с включенным и выключенным http/2)
> 2) сертификаты EC
> 3) 0-RTT (early data)
>
>
> А вот с разницей в противоположных результатах скорости между виртуальным
> и физическим сервером надо
>
> бы как-то разобраться, хотя бы понять почему так происходит :)
>

осторожно предположу, что в случае 100% утилизации cpu epoll себя так ведет.
попробуйте донагрузить процессор чем-то типа "md5sum /dev/zero", чтобы
максимально занять ядра, во всех ли случаях профили покажут epoll_wait ?


>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/a1ed640e/attachment.htm>

From chipitsine на gmail.com  Thu Jan  4 21:46:49 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 4 Jan 2024 22:46:49 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <795430305.20240105002042@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
Message-ID: <CAFHpkQHOBQw0F+xgYafWMWcRcYhTSMK=3HgdGV_oxyJvG+4e0Q@mail.gmail.com>

чт, 4 янв. 2024 г. в 22:21, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
> Благодарю за рекомендации!
>
> По логам для Mastodon запросы идут в основном по протоколу HTTP/1.1, а по
> HTTP/2 протоколу
>
> раз в 10 меньше, если сравнить сегодняшний лог.
>

возможно, часть запросов проксируется через инфраструктуру Mastodon, и для
вас выглядит как http/1.1

риторический вопрос, если к вам 90% трафика приходит как http/1.1, и вы с
этим ничего не можете поделать судя по всему, в чем смысл вопроса "включать
или на включать http/{2,3}" ?


>
>
> Для Mastodon сейчас пытаюсь разобраться и оптимизировать конфигурацию для
> него:
>
> https://github.com/mastodon/mastodon/pull/19644
>
>
>
> Вполне возможно, что мог что-то упустить :)
>
>
>
> Вы писали 4 января 2024 г., 23:25:28:
>
>
>
> как можно поступить в данном случае.
>
> Mastodon - судя по описанию
>
> 1) written using ruby
> 2) туда ходят браузеры
>
> из первого я бы предположил, что в конфиге есть proxy_pass (или аналог), а
> значит нагрузка будет не sendfile-овая
> из второго - в общих чертах, если есть браузеры, то примерно в 100% ответ
> "да" для http/2 и http/3
>
> http2 и http/3 делают для браузера более кайфово. ценой некоторого доп
> расхода цпу. браузер себя лимитирует 2-мя tcp
> сессиями, в рамках http/1.1 браузер может скачивать одновременно 2
> объекта. современная верстка предполагает несколько десятков css, js, png
> файлов,
> в http/2 есть мультиплексирование запросов внутри одной сессии, за счет
> чего браузер может одновременно качать все файлы, не дожидаясь каждого
> отдельно.
>
> Для оптимизации я ещё настроил автоматическое предварительное сжатие
> статических файлов в brotli и gzip форматы присутствующих в пакетах
> Mastodon/Peertube в NixOS.
>
>
>
> еще http/2 более кайфово для браузера сжимает трафик за счет дедупликации
> хедеров и подобных мелочей (что тоже немного увеличивает расход процессора)
>
> если у вас что-то, куда ходит браузер (вы говорите, блог на Mastodon), то
> вопрос включения или не включения http/2 обычно - насколько браузеру будет
> кайфовее, а не
> насколько вырастет расход процессора.
>
> Ну до 2-го пункта врядли дойдёт дело. Параметр для0-RTT использую в HTTP/3
> протоколе :). Протестировать сайт с
>
> помощью pagespeed надо как-нибудь протестировать, не забыть.
>
> я бы посоветовался с каким-нибудь SEO из вебстудии, но то, что навскидку
> приходит в голову ...
>
> 1) https://pagespeed.web.dev/ (с включенным и выключенным http/2)
> 2) сертификаты EC
> 3) 0-RTT (early data)
>
>
> А вот с разницей в противоположных результатах скорости между виртуальным
> и физическим сервером надо
>
> бы как-то разобраться, хотя бы понять почему так происходит :)
>
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240104/61e4509c/attachment-0001.htm>

From slw на zxy.spb.ru  Fri Jan  5 11:00:08 2024
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 5 Jan 2024 14:00:08 +0300
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB?=
 =?utf-8?B?0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YDQuCDQsNC60YLQuNCy0LDRhtC4?=
 =?utf-8?B?0Lg=?= kTLS
In-Reply-To: <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
References: <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
Message-ID: <20240105110008.GC76331@zxy.spb.ru>

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

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

откуда такая фантазия?

From chipitsine на gmail.com  Fri Jan  5 11:08:36 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 5 Jan 2024 12:08:36 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <20240105110008.GC76331@zxy.spb.ru>
References: <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <20240105110008.GC76331@zxy.spb.ru>
Message-ID: <CAFHpkQEFyKg3eO+BXTQp0u5LTWGO0unkDDmSBQC1vJWrK4ipvQ@mail.gmail.com>

On Fri, Jan 5, 2024, 12:00 Slawa Olhovchenkov <slw на zxy.spb.ru> 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
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/46240e74/attachment.htm>

From slw на zxy.spb.ru  Fri Jan  5 11:33:54 2024
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 5 Jan 2024 14:33:54 +0300
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB?=
 =?utf-8?B?0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YDQuCDQsNC60YLQuNCy0LDRhtC4?=
 =?utf-8?B?0Lg=?= kTLS
In-Reply-To: <CAFHpkQEFyKg3eO+BXTQp0u5LTWGO0unkDDmSBQC1vJWrK4ipvQ@mail.gmail.com>
References: <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <20240105110008.GC76331@zxy.spb.ru>
 <CAFHpkQEFyKg3eO+BXTQp0u5LTWGO0unkDDmSBQC1vJWrK4ipvQ@mail.gmail.com>
Message-ID: <20240105113354.GD76331@zxy.spb.ru>

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

> On Fri, Jan 5, 2024, 12:00 Slawa Olhovchenkov <slw на zxy.spb.ru> 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/

в интернетах пишут иное.

From izorkin на gmail.com  Fri Jan  5 17:46:20 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 5 Jan 2024 20:46:20 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
Message-ID: <472646211.20240105204620@gmail.com>

Добрый вечер, Илья.

Разобрался в чём была проблема - медленная дисковая подсистема. Скопировал тестовый файл в tmpfs, результаты
стали пропорционально результатам на физическом сервере.
 
Результаты без поддержки kTLS:
- HTTP/1.1 - ~251 Мбайт/сек (CPU load 100%)
- HTTP/2 - ~207 Мбайт/сек (CPU load 100%)
- HTTP/3 - ~259 Мбайт/сек (CPU load ~90%)

Результаты c поддержкой kTLS:
- HTTP/1.1 - ~603 Мбайт/сек (CPU load 100%)
- HTTP/2 - ~171 Мбайт/сек (CPU load 100%)
- HTTP/3 - ~260 Мбайт/сек (CPU load ~90%)
 
Анализ профиля для протокола HTTP/3 без поддержки kTLS:
Total: 2406 samples
    843  35.0%  35.0%      843  35.0% __sendmsg
    425  17.7%  52.7%      425  17.7% _aesni_ctr32_ghash_6x
    406  16.9%  69.6%      406  16.9% pthread_cond_signal@@GLIBC_2.3.2
    296  12.3%  81.9%      296  12.3% epoll_wait
      91  3.8%  85.7%      91  3.8% __memmove_avx_unaligned_erms
      55  2.3%  87.9%      55  2.3% __lll_lock_wake
      29  1.2%  89.2%      29  1.2% __recvmsg
      9  0.4%  89.5%      527  21.9% ngx_quic_output_packet
      8  0.3%  89.9%        8  0.3% _init на 39000
      8  0.3%  90.2%      74  3.1% ngx_quic_write_buffer
      7  0.3%  90.5%      112  4.7% ngx_http_trailers_filter
      6  0.2%  90.7%      16  0.7% EVP_CIPHER_CTX_ctrl
...
 
Анализ профиля для протокола HTTP/3 с поддержкой kTLS:
Total: 2392 samples
    834  34.9%  34.9%      836  34.9% __sendmsg
    457  19.1%  54.0%      457  19.1% pthread_cond_signal@@GLIBC_2.3.2
    360  15.1%  69.0%      360  15.1% _aesni_ctr32_ghash_6x
    278  11.6%  80.6%      278  11.6% epoll_wait
    104  4.3%  85.0%      104  4.3% __memmove_avx_unaligned_erms
      65  2.7%  87.7%      65  2.7% __lll_lock_wake
      49  2.0%  89.8%      49  2.0% __recvmsg
      12  0.5%  90.3%      634  26.5% ngx_output_chain
      8  0.3%  90.6%        8  0.3% gcm_ghash_avx
      7  0.3%  90.9%        7  0.3% __strcmp_avx2
      6  0.3%  91.1%        6  0.3% aesni_encrypt
      6  0.3%  91.4%        7  0.3% evp_cipher_init_internal
      6  0.3%  91.6%      398  16.6% gcm_cipher_internal
      5  0.2%  91.8%        8  0.3% __GI___clock_gettime
...
 
Получается, что для HTTP/3 активация kTLS не ускоряет работу (например, если файлы находятся в кэше nginx). Ех...
 
 
Вы писали 5 января 2024 г., 0:37:11:
 
> осторожно предположу, что в случае 100% утилизации cpu epoll себя так ведет.
> попробуйте донагрузить процессор чем-то типа "md5sum /dev/zero", чтобы максимально занять ядра, во всех ли случаях профили покажут epoll_wait ?
 
Инфраструктура Fideverse, в которую входит микро-блог Mastodon работает немного по другому. Это можно представить как большое количество
почтовых ящиков, которые работают на различном ПО и обмениваются между собой сообщениями. Большинство запросов выполняются по HTTP/1.1
протоколу.
Любой желающий может поднять инстанс и ощаться с остальной сетью. Там есть и представители разных ПО :)
 
 
Вы писали 5 января 2024 г., 0:46:49:
 
> возможно, часть запросов проксируется через инфраструктуру Mastodon, и для вас выглядит как http/1.1
Если так подумать, то смысла выключать скорее всего нет.
 
> риторический вопрос, если к вам 90% трафика приходит как http/1.1, и вы с этим ничего не можете поделать судя по всему, в чем смысл вопроса "включать или на включать http/{2,3}" ?
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/4e650070/attachment.htm>

From chipitsine на gmail.com  Fri Jan  5 18:53:45 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 5 Jan 2024 19:53:45 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <472646211.20240105204620@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
Message-ID: <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>

On Fri, Jan 5, 2024, 18:46 <izorkin на gmail.com> wrote:

> Добрый вечер, Илья.
>
>
> Разобрался в чём была проблема - медленная дисковая подсистема. Скопировал
> тестовый файл в tmpfs, результаты
>
> стали пропорционально результатам на физическом сервере.
>
>
>
> Результаты без поддержки kTLS:
>
> - HTTP/1.1 - ~251 Мбайт/сек (CPU load 100%)
>
> - HTTP/2 - ~207 Мбайт/сек (CPU load 100%)
>
> - HTTP/3 - ~259 Мбайт/сек (CPU load ~90%)
>
>
> Результаты c поддержкой kTLS:
>
> - HTTP/1.1 - ~603 Мбайт/сек (CPU load 100%)
>
> - HTTP/2 - ~171 Мбайт/сек (CPU load 100%)
>
> - HTTP/3 - ~260 Мбайт/сек (CPU load ~90%)
>
>
>
> Анализ профиля для протокола HTTP/3 без поддержки kTLS:
>
> Total: 2406 samples
>
>     843  35.0%  35.0%      843  35.0% __sendmsg
>
>     425  17.7%  52.7%      425  17.7% _aesni_ctr32_ghash_6x
>
>     406  16.9%  69.6%      406  16.9% pthread_cond_signal@@GLIBC_2.3.2
>
>     296  12.3%  81.9%      296  12.3% epoll_wait
>
>       91  3.8%  85.7%      91  3.8% __memmove_avx_unaligned_erms
>
>       55  2.3%  87.9%      55  2.3% __lll_lock_wake
>
>       29  1.2%  89.2%      29  1.2% __recvmsg
>
>       9  0.4%  89.5%      527  21.9% ngx_quic_output_packet
>
>       8  0.3%  89.9%        8  0.3% _init на 39000
>
>       8  0.3%  90.2%      74  3.1% ngx_quic_write_buffer
>
>       7  0.3%  90.5%      112  4.7% ngx_http_trailers_filter
>
>       6  0.2%  90.7%      16  0.7% EVP_CIPHER_CTX_ctrl
>
> ...
>
>
>
> Анализ профиля для протокола HTTP/3 с поддержкой kTLS:
>
> Total: 2392 samples
>
>     834  34.9%  34.9%      836  34.9% __sendmsg
>
>     457  19.1%  54.0%      457  19.1% pthread_cond_signal@@GLIBC_2.3.2
>
>     360  15.1%  69.0%      360  15.1% _aesni_ctr32_ghash_6x
>
>     278  11.6%  80.6%      278  11.6% epoll_wait
>
>     104  4.3%  85.0%      104  4.3% __memmove_avx_unaligned_erms
>
>       65  2.7%  87.7%      65  2.7% __lll_lock_wake
>
>       49  2.0%  89.8%      49  2.0% __recvmsg
>
>       12  0.5%  90.3%      634  26.5% ngx_output_chain
>
>       8  0.3%  90.6%        8  0.3% gcm_ghash_avx
>
>       7  0.3%  90.9%        7  0.3% __strcmp_avx2
>
>       6  0.3%  91.1%        6  0.3% aesni_encrypt
>
>       6  0.3%  91.4%        7  0.3% evp_cipher_init_internal
>
>       6  0.3%  91.6%      398  16.6% gcm_cipher_internal
>
>       5  0.2%  91.8%        8  0.3% __GI___clock_gettime
>
> ...
>
>
>
> Получается, что для HTTP/3 активация kTLS не ускоряет работу (например,
> если файлы находятся в кэше nginx). Ех...
>
>
>
С некоторой непонятностью, что именно означают проценты, но выглядит так,
что процессор (при выбранном типе нагрузки) нагружается не SSL -ным. Для
такой нагрузки даже, если бы kTLS умело в UDP, оно бы не повлияло.
epoll_wait оно бы ускорило? Сомневаюсь




>
> Вы писали 5 января 2024 г., 0:37:11:
>
>
>
> осторожно предположу, что в случае 100% утилизации cpu epoll себя так
> ведет.
> попробуйте донагрузить процессор чем-то типа "md5sum /dev/zero", чтобы
> максимально занять ядра, во всех ли случаях профили покажут epoll_wait ?
>
>
>
> Инфраструктура Fideverse, в которую входит микро-блог Mastodon работает
> немного по другому. Это можно представить как большое количество
>
> почтовых ящиков, которые работают на различном ПО и обмениваются между
> собой сообщениями. Большинство запросов выполняются по HTTP/1.1
>
> протоколу.
>
> Любой желающий может поднять инстанс и ощаться с остальной сетью. Там есть
> и представители разных ПО :)
>
>
>
>
>
> Вы писали 5 января 2024 г., 0:46:49:
>
>
>
> возможно, часть запросов проксируется через инфраструктуру Mastodon, и для
> вас выглядит как http/1.1
>
> Если так подумать, то смысла выключать скорее всего нет.
>
>
>
> риторический вопрос, если к вам 90% трафика приходит как http/1.1, и вы с
> этим ничего не можете поделать судя по всему, в чем смысл вопроса "включать
> или на включать http/{2,3}" ?
>
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/ed09bfd6/attachment-0001.htm>

From izorkin на gmail.com  Fri Jan  5 19:17:55 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 5 Jan 2024 22:17:55 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
Message-ID: <1859693144.20240105221755@gmail.com>

Добрый вечер, Илья.

Я тут уже не знаю почему процессор полностью не утилизируется, как при работе с протоколами HTTP/1.1 и HTTP/2.
После тестов хотябы разобрался для себя немного как работает kTLS и как влияет на скорость обработки :)
А то сперва думал, что kTLS поддерживает и UDP протокол ))))
 
 
Вы писали 5 января 2024 г., 21:53:45:

> С некоторой непонятностью, что именно означают проценты, но выглядит так, что процессор (при выбранном типе нагрузки) нагружается не SSL -ным. Для такой нагрузки даже, если бы kTLS умело в UDP, оно бы не повлияло. epoll_wait оно бы ускорило? Сомневаюсь 

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/c72c6242/attachment.htm>

From chipitsine на gmail.com  Fri Jan  5 22:22:05 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 5 Jan 2024 23:22:05 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1859693144.20240105221755@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
Message-ID: <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>

On Fri, Jan 5, 2024, 20:18 <izorkin на gmail.com> wrote:

> Добрый вечер, Илья.
>
>
> Я тут уже не знаю почему процессор полностью не утилизируется, как при
> работе с протоколами HTTP/1.1 и HTTP/2.
>

Вот тут, честно, логическую нить потерял. Вы хотели установить, влияет ли
включение kTLS на быстродействие http/3.

Есть какая-то связь неполной утилизации процессора с этим вопросом?

После тестов хотябы разобрался для себя немного как работает kTLS и как
> влияет на скорость обработки :)
>
> А то сперва думал, что kTLS поддерживает и UDP протокол ))))
>
>
>
>
>
> Вы писали 5 января 2024 г., 21:53:45:
>
>
> С некоторой непонятностью, что именно означают проценты, но выглядит так,
> что процессор (при выбранном типе нагрузки) нагружается не SSL -ным. Для
> такой нагрузки даже, если бы kTLS умело в UDP, оно бы не повлияло.
> epoll_wait оно бы ускорило? Сомневаюсь
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/02a2193b/attachment.htm>

From izorkin на gmail.com  Sat Jan  6 06:33:03 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 6 Jan 2024 09:33:03 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
Message-ID: <577341570.20240106093303@gmail.com>

Добрый утро, Илья.

Изначально я предполагал, что kTLS влияет на производительность HTTP/3 протокола,
так как изначальные тесты показали небольшой прирост производительности и я хотел
узнать, можно ли добиться ещё большей производительности как у HTTP/1.1 протокола.
Вот и хотел в начале узнать, как можно добиться оптимизации обработки HTTP/3
протокола с использованием kTLS и увеличить скорость.
 
После дополнительных тестов, в том числе и на физической машине, убедился, что kTLS
не используется в протоколе HTTP/3, да и в документации к ядру нет упоминания о
поддержке UDP протокола. Хотелось бы, чтобы разработчики ядра в будущем внедрили
поддержку UDP протокола.
 
А после всех тестов стало видно, что при обработке HTTP/3 протокола ядро процессора
утилизируется не полностью, на физическом сервере нагрузка доходит всего лишь до
60%, а на виртуальной машине до 90%.
Из-за чего так происходит не знаю, может это из-за особенностей обработки протокола
HTTP/3 или где-то ещё можно оптимизировать процесс обработки. В тестах с OpenSSL
версии 1.1.1 практического увеличения скорости не заметил, тогда, вероятно, из-за
чего-то другого происходит не полная загрузка процессора.
 
В итоге вопрос становится другим - можно ли как-то оптимизировать процесс обработки
HTTP/3 протокола, чтобы добиться увеличения скорости при максимальной нагрузке
процессора, когда нет ограничений в скорости предоставления данных со стороны
файловой системы.
 
Вы писали 6 января 2024 г., 1:22:05:
 
> Вот тут, честно, логическую нить потерял. Вы хотели установить, влияет ли включение kTLS на быстродействие http/3.

> Есть какая-то связь неполной утилизации процессора с этим вопросом?

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/d2c5015b/attachment-0001.htm>

From chipitsine на gmail.com  Sat Jan  6 12:28:25 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 6 Jan 2024 13:28:25 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <577341570.20240106093303@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
Message-ID: <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>

сб, 6 янв. 2024 г. в 07:33, <izorkin на gmail.com>:

> Добрый утро, Илья.
>
>
> Изначально я предполагал, что kTLS влияет на производительность HTTP/3
> протокола,
>
> так как изначальные тесты показали небольшой прирост производительности и
> я хотел
>
> узнать, можно ли добиться ещё большей производительности как у HTTP/1.1
> протокола.
>
> Вот и хотел в начале узнать, как можно добиться оптимизации обработки
> HTTP/3
>
> протокола с использованием kTLS и увеличить скорость.
>
>
>
> После дополнительных тестов, в том числе и на физической машине, убедился,
> что kTLS
>
> не используется в протоколе HTTP/3, да и в документации к ядру нет
> упоминания о
>
> поддержке UDP протокола. Хотелось бы, чтобы разработчики ядра в будущем
> внедрили
>
> поддержку UDP протокола.
>
>
>
> А после всех тестов стало видно, что при обработке HTTP/3 протокола ядро
> процессора
>
> утилизируется не полностью, на физическом сервере нагрузка доходит всего
> лишь до
>
> 60%, а на виртуальной машине до 90%.
>

пока идет такая пьянка, вы каким компилятором собирали nginx (и библиотеки)
?
попробуйте подняться до последних версий gcc и clang ?


> Из-за чего так происходит не знаю, может это из-за особенностей обработки
> протокола
>
> HTTP/3 или где-то ещё можно оптимизировать процесс обработки. В тестах с
> OpenSSL
>
> версии 1.1.1 практического увеличения скорости не заметил, тогда,
> вероятно, из-за
>

собственно, по записанному Вами gperftool, ssl-ная часть у вас в районе 17%
на aesni.
aesni реализуется в процессоре, в этом 1.1.1 не отличается от 3.X

на высококонкурентных запросах отличие обычно есть в пользу 1.1.1


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


тут надо смотреть в метрики, не упирается ли сервер в какие-то лимиты по
диску или сети. не упирается ли клиент


>
>
> Вы писали 6 января 2024 г., 1:22:05:
>
>
>
> Вот тут, честно, логическую нить потерял. Вы хотели установить, влияет ли
> включение kTLS на быстродействие http/3.
>
> Есть какая-то связь неполной утилизации процессора с этим вопросом?
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/d96b59ea/attachment.htm>

From izorkin на gmail.com  Sat Jan  6 13:25:14 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 6 Jan 2024 16:25:14 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
Message-ID: <1656995827.20240106162514@gmail.com>

Добрый день, Илья.
 
Обычно в NixOS Unstable используются последние версии библиотек. Сейчас пере-собрал Nginx
с помощью GCC 13.2.0, но результат не изменился.

Вы писали 6 января 2024 г., 15:28:25:
 
> пока идет такая пьянка, вы каким компилятором собирали nginx (и библиотеки) ?
> попробуйте подняться до последних версий gcc и clang ?
 
 
Вполне может быть, что проблема может быть и в Curl, он загружает процессор до 50%. Превышения
каких-либо лимитов не заметил по мониторингу.
 
 
> тут надо смотреть в метрики, не упирается ли сервер в какие-то лимиты по диску или сети. не упирается ли клиент

 
Тут ещё возник дополнительный вопрос.
Теоретически возможно сделать дополнительный параметр, который проверяет, используется ли в
текущем соединение HTTP/1.1 протокол, если да, то перенаправлять шифрование в ядро системы.
А если будет протокол HTTP/2, тогда уже шифровать траффик самому процессу nginx.
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/ec8f5887/attachment-0001.htm>

From chipitsine на gmail.com  Sat Jan  6 15:53:36 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 6 Jan 2024 16:53:36 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1656995827.20240106162514@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <1656995827.20240106162514@gmail.com>
Message-ID: <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>

сб, 6 янв. 2024 г. в 14:25, <izorkin на gmail.com>:

> Добрый день, Илья.
>
>
>
> Обычно в NixOS Unstable используются последние версии библиотек. Сейчас
> пере-собрал Nginx
>
> с помощью GCC 13.2.0, но результат не изменился.
>
>
> Вы писали 6 января 2024 г., 15:28:25:
>
>
>
> пока идет такая пьянка, вы каким компилятором собирали nginx (и
> библиотеки) ?
> попробуйте подняться до последних версий gcc и clang ?
>
>
>
>
>
> Вполне может быть, что проблема может быть и в Curl, он загружает
> процессор до 50%. Превышения
>
> каких-либо лимитов не заметил по мониторингу.
>
>
>
>
>
> тут надо смотреть в метрики, не упирается ли сервер в какие-то лимиты по
> диску или сети. не упирается ли клиент
>
>
>
>
> Тут ещё возник дополнительный вопрос.
>
> Теоретически возможно сделать дополнительный параметр, который проверяет,
> используется ли в
>
> текущем соединение HTTP/1.1 протокол, если да, то перенаправлять
> шифрование в ядро системы.
>
> А если будет протокол HTTP/2, тогда уже шифровать траффик самому процессу
> nginx.
>


насколько я понимаю, сейчас ровно так и получается, вы включаете ktls, то,
что может быть им обработано, обрабатывается:

ssl_conf_command Options KTLS;



>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/087ebe30/attachment.htm>

From izorkin на gmail.com  Sat Jan  6 17:20:59 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 6 Jan 2024 20:20:59 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <1656995827.20240106162514@gmail.com>
 <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>
Message-ID: <1759520254.20240106202059@gmail.com>

Добрый вечер, Илья.

Да, он влияет как и на HTTP/1.1 и на HTTP/2 протоколы. Ещё бы добавить опцию, например, disable_ktls_for_protocol.
В итоге получится примерно такой вариант:
  server {
    listen 0.0.0.0:443 quic reuseport ;
    listen 0.0.0.0:443 ssl reuseport ;
    http2 on;
    http3 on;
    ssl_conf_command Options KTLS;
    disable_ktls_for_protocol http2;
 
По итогу при активации kTLS не будет просадки в производительности для HTTP/2 протокола, т.к. обработкой
шифрованием будет заниматься сам процесс nginx :)
 
 
Вы писали 6 января 2024 г., 18:53:36:
 
> насколько я понимаю, сейчас ровно так и получается, вы включаете ktls, то, что может быть им обработано, обрабатывается:

> ssl_conf_command Options KTLS;

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/61954703/attachment.htm>

From mdounin на mdounin.ru  Sat Jan  6 18:27:52 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 6 Jan 2024 21:27:52 +0300
Subject: nginxQuic: =?koi8-r?B?08vP0s/T1Ngg2sHH?=
 =?koi8-r?B?0tXay8kg0NLJIMHL1MnXwcPJyQ==?= kTLS
In-Reply-To: <1759520254.20240106202059@gmail.com>
References: <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <1656995827.20240106162514@gmail.com>
 <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>
 <1759520254.20240106202059@gmail.com>
Message-ID: <ZZmbqJi/Q/4pzhKL@mdounin.ru>

Hello!

On Sat, Jan 06, 2024 at 08:20:59PM +0300, izorkin на gmail.com wrote:

> Добрый вечер, Илья.
> 
> Да, он влияет как и на HTTP/1.1 и на HTTP/2 протоколы. Ещё бы добавить опцию, например, disable_ktls_for_protocol.
> В итоге получится примерно такой вариант:
>   server {
>     listen 0.0.0.0:443 quic reuseport ;
>     listen 0.0.0.0:443 ssl reuseport ;
>     http2 on;
>     http3 on;
>     ssl_conf_command Options KTLS;
>     disable_ktls_for_protocol http2;
>  
> По итогу при активации kTLS не будет просадки в производительности для HTTP/2 протокола, т.к. обработкой
> шифрованием будет заниматься сам процесс nginx :)

Просадка производительности, которую вы наблюдаете для HTTP/2 при 
включённом kTLS - не собственно из-за kTLS, а из-за того, что у 
вас включён sendfile, и при включённом kTLS становится возможным 
его использование.  А в случае HTTP/2 это выливается в большое 
количество syscall'ов из-за HTTP/2-фрейминга.

Если очень хочется получить включённый sendfile и kTLS в случае 
HTTP/1.x, и выключенный в случае HTTP/2, то можно сделать как-то 
так (слегка адаптировано из 
https://mailman.nginx.org/pipermail/nginx-devel/2022-September/NSHDCLL2TY3Q536CO5MAKXSC3HCIMUNF.html):

    server {
        listen 443 ssl;

        http2 on;

        location / {
            if ($server_protocol != 'HTTP/2.0') {
                rewrite ^(.*) /sendfile$1 last;
            }

            sendfile off;
        }

        location /sendfile/ {
            alias html/;
            sendfile on;
        }
    }

Но смысла в этом не очень много, так как при включённом HTTP/2 
рассчитывать на клиентов, которые придут по HTTP/1.x, не имеет 
особого смысла, таких клиентов будет исчезающе мало.  Если хочется 
получить высокую производительность при скачивании больших файлов, 
и при этом использовать HTTP/2 (и/или HTTP/3), то имеет смысл 
заводить отдельный виртуальный сервер, в котором разрешать только 
HTTP/1.x (а также sendfile и kTLS), и раздавать файлы с него.

Для HTTP/3 не работают ни kTLS, ни sendfile, соответственно 
влияния на производительность HTTP/3 от включения kTLS не будет.

-- 
Maxim Dounin
http://mdounin.ru/

From izorkin на gmail.com  Sat Jan  6 19:47:16 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 6 Jan 2024 22:47:16 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <ZZmbqJi/Q/4pzhKL@mdounin.ru>
References: <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com> 
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <1656995827.20240106162514@gmail.com>
 <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>
 <1759520254.20240106202059@gmail.com> <ZZmbqJi/Q/4pzhKL@mdounin.ru>
Message-ID: <1394407478.20240106224716@gmail.com>

Добрый вечер, Максим.

Теперь ясно, благодарю :)

Вы писали 6 января 2024 г., 21:27:52:

> Просадка производительности, которую вы наблюдаете для HTTP/2 при 
> включённом kTLS - не собственно из-за kTLS, а из-за того, что у 
> вас включён sendfile, и при включённом kTLS становится возможным 
> его использование.  А в случае HTTP/2 это выливается в большое 
> количество syscall'ов из-за HTTP/2-фрейминга.

> Если очень хочется получить включённый sendfile и kTLS в случае 
> HTTP/1.x, и выключенный в случае HTTP/2, то можно сделать как-то 
> так (слегка адаптировано из 
> https://mailman.nginx.org/pipermail/nginx-devel/2022-September/NSHDCLL2TY3Q536CO5MAKXSC3HCIMUNF.html):

>     server {
>         listen 443 ssl;

>         http2 on;

>         location / {
>             if ($server_protocol != 'HTTP/2.0') {
>                 rewrite ^(.*) /sendfile$1 last;
>             }

>             sendfile off;
>         }

>         location /sendfile/ {
>             alias html/;
>             sendfile on;
>         }
>     }

Да, были предположения после тестов, что для статики лучше делать
отдельный домен и активировать на нём HTTP/1.1 и kTLS. Но такой
вариант сработает только с теми web-сервисами, которые позволяют
выводить статику в отдельный домен.
К примеру, есть сервис Peertube для видео-хостинга. У него сложная
конфигурация nginx, и такой вариант конфигурации применить сложно,
спокойно можно что-то упустить, особенно пользователю, который
глубоко не разбирается в Nginx. Видеоплатформа позволяет выводить
статику в отдельные домен, но только с использованием S3 хранилища.
Получается, что для Peertube, лучшим вариантом будет отключить
протокол HTTP/2, активировать кTLS и использовать только протоколы
HTTP/1.1 и HTTP/3.

> Но смысла в этом не очень много, так как при включённом HTTP/2 
> рассчитывать на клиентов, которые придут по HTTP/1.x, не имеет 
> особого смысла, таких клиентов будет исчезающе мало.  Если хочется 
> получить высокую производительность при скачивании больших файлов, 
> и при этом использовать HTTP/2 (и/или HTTP/3), то имеет смысл 
> заводить отдельный виртуальный сервер, в котором разрешать только 
> HTTP/1.x (а также sendfile и kTLS), и раздавать файлы с него.

> Для HTTP/3 не работают ни kTLS, ни sendfile, соответственно 
> влияния на производительность HTTP/3 от включения kTLS не будет.


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From chipitsine на gmail.com  Sat Jan  6 20:24:47 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 6 Jan 2024 21:24:47 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1394407478.20240106224716@gmail.com>
References: <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <1656995827.20240106162514@gmail.com>
 <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>
 <1759520254.20240106202059@gmail.com> <ZZmbqJi/Q/4pzhKL@mdounin.ru>
 <1394407478.20240106224716@gmail.com>
Message-ID: <CAFHpkQG8NURNPfQ4sENk0S+2qEp+kXPcHk70aYoE-vUjRB8OXA@mail.gmail.com>

сб, 6 янв. 2024 г. в 20:48, <izorkin на gmail.com>:

> Добрый вечер, Максим.
>
> Теперь ясно, благодарю :)
>
> Вы писали 6 января 2024 г., 21:27:52:
>
> > Просадка производительности, которую вы наблюдаете для HTTP/2 при
> > включённом kTLS - не собственно из-за kTLS, а из-за того, что у
> > вас включён sendfile, и при включённом kTLS становится возможным
> > его использование.  А в случае HTTP/2 это выливается в большое
> > количество syscall'ов из-за HTTP/2-фрейминга.
>
> > Если очень хочется получить включённый sendfile и kTLS в случае
> > HTTP/1.x, и выключенный в случае HTTP/2, то можно сделать как-то
> > так (слегка адаптировано из
> >
> https://mailman.nginx.org/pipermail/nginx-devel/2022-September/NSHDCLL2TY3Q536CO5MAKXSC3HCIMUNF.html
> ):
>
> >     server {
> >         listen 443 ssl;
>
> >         http2 on;
>
> >         location / {
> >             if ($server_protocol != 'HTTP/2.0') {
> >                 rewrite ^(.*) /sendfile$1 last;
> >             }
>
> >             sendfile off;
> >         }
>
> >         location /sendfile/ {
> >             alias html/;
> >             sendfile on;
> >         }
> >     }
>
> Да, были предположения после тестов, что для статики лучше делать
> отдельный домен и активировать на нём HTTP/1.1 и kTLS. Но такой
> вариант сработает только с теми web-сервисами, которые позволяют
> выводить статику в отдельный домен.
> К примеру, есть сервис Peertube для видео-хостинга. У него сложная
>

складывается ощущение, что перескакивание с "а вот есть еще PeerTube",
заставляет как-то пытаться связать
новый вопрос с предыдущим тредом, и связь неочевидна.

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


> конфигурация nginx, и такой вариант конфигурации применить сложно,
> спокойно можно что-то упустить, особенно пользователю, который
> глубоко не разбирается в Nginx. Видеоплатформа позволяет выводить
> статику в отдельные домен, но только с использованием S3 хранилища.
> Получается, что для Peertube, лучшим вариантом будет отключить
> протокол HTTP/2, активировать кTLS и использовать только протоколы
> HTTP/1.1 и HTTP/3.
>
> > Но смысла в этом не очень много, так как при включённом HTTP/2
> > рассчитывать на клиентов, которые придут по HTTP/1.x, не имеет
> > особого смысла, таких клиентов будет исчезающе мало.  Если хочется
> > получить высокую производительность при скачивании больших файлов,
> > и при этом использовать HTTP/2 (и/или HTTP/3), то имеет смысл
> > заводить отдельный виртуальный сервер, в котором разрешать только
> > HTTP/1.x (а также sendfile и kTLS), и раздавать файлы с него.
>
> > Для HTTP/3 не работают ни kTLS, ни sendfile, соответственно
> > влияния на производительность HTTP/3 от включения kTLS не будет.
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/1aa3c623/attachment-0001.htm>

From izorkin на gmail.com  Sat Jan  6 20:33:32 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 6 Jan 2024 23:33:32 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQG8NURNPfQ4sENk0S+2qEp+kXPcHk70aYoE-vUjRB8OXA@mail.gmail.com>
References: <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com> 
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <1656995827.20240106162514@gmail.com>
 <CAFHpkQFYNEMO8Mj3WP0bpLYykbppguTKiJZ2OpzgwiuD1MULJQ@mail.gmail.com>
 <1759520254.20240106202059@gmail.com> <ZZmbqJi/Q/4pzhKL@mdounin.ru>
 <1394407478.20240106224716@gmail.com>
 <CAFHpkQG8NURNPfQ4sENk0S+2qEp+kXPcHk70aYoE-vUjRB8OXA@mail.gmail.com>
Message-ID: <767381487.20240106233332@gmail.com>

Добрый вечер, Илья.

Думаю, да :)
 
Вы писали 6 января 2024 г., 23:24:47:
 
> складывается ощущение, что перескакивание с "а вот есть еще PeerTube", заставляет как-то пытаться связать
> новый вопрос с предыдущим тредом, и связь неочевидна.

> выскажу осторожное предположение, что может стоит лимитировать один вопрос на тред

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240106/ddfc518f/attachment.htm>

From izorkin на gmail.com  Sun Jan  7 06:57:45 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sun, 7 Jan 2024 09:57:45 +0300
Subject: =?utf-8?B?UmU6INCf0LDRgtGHIEVUYWdzINCyIE5peE9T?=
In-Reply-To: <ZVrLBNBCrKdfI9tU@mdounin.ru>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
Message-ID: <994095771.20240107095745@gmail.com>

Добрый утро, Максим.

Обнаружилась ещё одна ошибка с текущим вариантом патча:
https://github.com/NixOS/nixpkgs/pull/278380

Некорректно кэшируются файлы, которые предварительно сжаты в формат
gzip и/или brotli форматы.

Может получится найти какое-то альтернативный вариант решения генерации
Etags для файлов, которые имеют фиксированную дату? 

Сейчас, Etags генерируется на основе размера файла + даты изменения.
Поможет ли добавление ещё одного параметра, например полного пути к
файлу? Получится такой вариант:
размер файла + дата изменения + полный путь к файлу


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From izorkin на gmail.com  Sun Jan  7 07:39:00 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sun, 7 Jan 2024 10:39:00 +0300
Subject: =?windows-1251?Q?nginx:_HTTP/2_=E8_kTLS?=
Message-ID: <184230688.20240107103900@gmail.com>

Доброе утро.

При использовании kTLS и sendfile наблюдается просадка производительности
при отдаче статических файлов, например при видео-стриминге. Одним из
вариантов решения является перенести статический файлы на другой хост и
использовать там только протоколы HTTP/1.1 и/или HTTP/3. Либо усложнять
логику работы в блоке location.

Не все сервисы позволяют выводить статику на отдельный хост, либо могут
иметь сложную конфигурацию nginx. Например web-сервис Peertube имеет
множество блоков location и использует различные условия if:
https://github.com/Chocobozzz/PeerTube/blob/develop/support/nginx/peertube

Обычному пользователю будет сложнее с этим разобраться и добавить
дополнительные блоки для исключения работы протокола HTTP/2 через kTLS.
Вполне легко можно запутаться и нарушить логику работы сайта.

Хотелось бы иметь более простой и универсальный способ отключения
обработки протокола HTTP/2 через kTLS.

Предполагаю, что перед передачей шифрования ядру системы сейчас nginx
проверяет наличие ssl и параметра sendfile. Можно ли добавить дополнительное
условие, которое проверяет дополнительный параметр, который указывает
какой протокол исключить из обработки шифрования ядром?

По итогу получится примерно такой вариант конфигурации:
  server {
    listen 0.0.0.0:443 quic reuseport ;
    listen 0.0.0.0:443 ssl reuseport ;
    http2 on;
    http3 on;
    ssl_conf_command Options KTLS;
    disable_ktls_for_protocol http2;
...

Мне кажется, что такой вариант эффективнее, чем добавлять условие if с
rewrite и дополнительный блок location.


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From izorkin на gmail.com  Sun Jan  7 10:02:03 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sun, 7 Jan 2024 13:02:03 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
Message-ID: <872252462.20240107130203@gmail.com>

Добрый день, Илья.
 
Добрался ещё до VPS на Ubuntu 22.04.3 LTS для тестов.
Прописал для Nginx официальный репозиторий и заменил текущую версию на nginxMainline.
 
По тестам для протокола HTTP/1.1 скорость скачет около 340-396 МБайт/сек при
нагрузке процессор до 100%.
Для протокола HTTP/3 скорость выходит только около 256-273 МБайт/сек при нагрузке на
процессор до 60-75%.

 
Вы писали 6 января 2024 г., 15:28:25:
 
> пока идет такая пьянка, вы каким компилятором собирали nginx (и библиотеки) ?
> попробуйте подняться до последних версий gcc и clang ?

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240107/0f29bd64/attachment-0001.htm>

From chipitsine на gmail.com  Sun Jan  7 12:54:05 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 7 Jan 2024 13:54:05 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <872252462.20240107130203@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <872252462.20240107130203@gmail.com>
Message-ID: <CAFHpkQHKKKFVTE71aOeqMKkJ0a59Wi9gYvr93x+SCbMsKRB6KQ@mail.gmail.com>

On Sun, Jan 7, 2024, 11:02 <izorkin на gmail.com> wrote:

> Добрый день, Илья.
>
>
>
> Добрался ещё до VPS на Ubuntu 22.04.3 LTS для тестов.
>
> Прописал для Nginx официальный репозиторий и заменил текущую версию на
> nginxMainline.
>
>
>
> По тестам для протокола HTTP/1.1 скорость скачет около 340-396 МБайт/сек
> при
>
> нагрузке процессор до 100%.
>
> Для протокола HTTP/3 скорость выходит только около 256-273 МБайт/сек при
> нагрузке на
>
> процессор до 60-75%.
>

Выглядит так, что curl на http/3 потребляет больше процессора и это
является лимитирующим фактором.

Когда я игрался с http/3, у curl, помнится, было аж 3 варианта реализации -
попробуйте?


>
>
> Вы писали 6 января 2024 г., 15:28:25:
>
>
>
> пока идет такая пьянка, вы каким компилятором собирали nginx (и
> библиотеки) ?
> попробуйте подняться до последних версий gcc и clang ?
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240107/c8a3a754/attachment.htm>

From izorkin на gmail.com  Sun Jan  7 21:24:39 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Mon, 8 Jan 2024 00:24:39 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQHKKKFVTE71aOeqMKkJ0a59Wi9gYvr93x+SCbMsKRB6KQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <CAFHpkQHZ7VX9Lq7CJWmyO3JDn8u62CMchzAE17B3RExe2KePyQ@mail.gmail.com>
 <1934360562.20240104205645@gmail.com>
 <CAFHpkQFa-3OpSByHhYiB2MRqbwr0tRU7on8Z=r82A9SJjVmNgg@mail.gmail.com>
 <638048961.20240104220702@gmail.com>
 <CAFHpkQEsygq1UxCF4kzgPSYX3K1sorTjT-6d41ue-MKkUzfMAg@mail.gmail.com>
 <51936101.20240104223705@gmail.com>
 <CAFHpkQF-8wm5G-2wXO4=iT8J6KsKQ76EQ0NTqkoKjQO818O+zw@mail.gmail.com>
 <795430305.20240105002042@gmail.com>
 <CAFHpkQFOujiP1NKKWB8AV4BqypKYn8WbYMnHzrq2suyNjji=Xg@mail.gmail.com>
 <472646211.20240105204620@gmail.com>
 <CAFHpkQG9sRLEZE47ELXJ8mN=m8Q2NaCgoWbbhZoiFWMXbtF+dQ@mail.gmail.com>
 <1859693144.20240105221755@gmail.com>
 <CAFHpkQGuBUSxUyb6jEtJeqf4O_LzTQ+J-GRGy4xtQtO9A1YS-w@mail.gmail.com>
 <577341570.20240106093303@gmail.com>
 <CAFHpkQE_8fCadDTZPp3SKBSMrVzj4B=RtShJBwVOE6HGSCkdQQ@mail.gmail.com>
 <872252462.20240107130203@gmail.com>
 <CAFHpkQHKKKFVTE71aOeqMKkJ0a59Wi9gYvr93x+SCbMsKRB6KQ@mail.gmail.com>
Message-ID: <1164789131.20240108002439@gmail.com>

Добрый вечер, Илья.

Удалось пересобрал curl использованием gnutls, скорость увеличилась где-то на
5-10 Мбайт/сек. Уже лучше :)
 
 
Вы писали 7 января 2024 г., 15:54:05:
> Выглядит так, что curl на http/3 потребляет больше процессора и это является лимитирующим фактором. 

> Когда я игрался с http/3, у curl, помнится, было аж 3 варианта реализации - попробуйте?

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240108/3ade4c9e/attachment.htm>

From arut на nginx.com  Mon Jan  8 10:46:32 2024
From: arut на nginx.com (Roman Arutyunyan)
Date: Mon, 8 Jan 2024 14:46:32 +0400
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0Lc=?=
 =?utf-8?B?0LrQuCDQv9GA0Lgg0LDQutGC0LjQstCw0YbQuNC4?= kTLS
In-Reply-To: <582023013.20240102235008@gmail.com>
References: <582023013.20240102235008@gmail.com>
Message-ID: <20240108104632.uhkpbw7tv44j54qk@N00W24XTQX>

Добрый день,

On Tue, Jan 02, 2024 at 11:50:08PM +0300, izorkin на 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, учитывая
сложность протокола.

--
Roman Arutyunyan

From izorkin на gmail.com  Mon Jan  8 11:07:06 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Mon, 8 Jan 2024 14:07:06 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <20240108104632.uhkpbw7tv44j54qk@N00W24XTQX>
References: <582023013.20240102235008@gmail.com>
 <20240108104632.uhkpbw7tv44j54qk@N00W24XTQX>
Message-ID: <1112713180.20240108140706@gmail.com>

Добрый день, Роман.

Да, я уже разобрался, что kTLS не поддерживает HTTP/3 протокол. Первые тесты
я неправильно замерял, в итоге и сложилось неправильное предположение.
Думал, что как-то можно добиться более высокой скорости.


Вы писали 8 января 2024 г., 13:46:32:

> kTLS не работает для HTTP/3.  Шифрование QUIC-пакетов производится вручную в
> коде nginx.  Не очень понятно, как kTLS может помочь в случае QUIC, учитывая
> сложность протокола.

> --
> Roman Arutyunyan
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From slw на zxy.spb.ru  Mon Jan  8 11:13:12 2024
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 8 Jan 2024 14:13:12 +0300
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB?=
 =?utf-8?B?0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YDQuCDQsNC60YLQuNCy0LDRhtC4?=
 =?utf-8?B?0Lg=?= kTLS
In-Reply-To: <20240108104632.uhkpbw7tv44j54qk@N00W24XTQX>
References: <582023013.20240102235008@gmail.com>
 <20240108104632.uhkpbw7tv44j54qk@N00W24XTQX>
Message-ID: <20240108111312.GE76331@zxy.spb.ru>

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

> Добрый день,
> 
> On Tue, Jan 02, 2024 at 11:50:08PM +0300, izorkin на 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, учитывая
> сложность протокола.

а так же изначально постулируемую цель иметь не-ядерную реализацию,
определяемую приложением

From arut на nginx.com  Mon Jan  8 12:18:45 2024
From: arut на nginx.com (Roman Arutyunyan)
Date: Mon, 8 Jan 2024 16:18:45 +0400
Subject: nginxQuic: =?utf-8?B?0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0Lc=?=
 =?utf-8?B?0LrQuCDQv9GA0Lgg0LDQutGC0LjQstCw0YbQuNC4?= kTLS
In-Reply-To: <1368454677.20240104190431@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
Message-ID: <20240108120818.mpipvt56ab6myjku@N00W24XTQX>

Добрый день,

On Thu, Jan 04, 2024 at 07:04:31PM +0300, izorkin на gmail.com wrote:
> Добрый вечер, Илья.
>  
> Замерил тесты на физическом сервере, пока без без поддержки kTLS.
> Оказывается в тестах на виртуальной машине я неправильно интерпретировал интерпретировал скорости,
> которые выводила утилита curl. Вместо МБит/сек там идёт МБайт/сек.
>  
> Результаты тестов при скачивании файла с самого сервера:
>  - HTTP/1.1 - ~3 504,14 МБит/сек (CPU load 100%)
>  - HTTP/2 - ~3 568,57 МБит/сек (CPU load 100%)
>  - HTTP/3 - ~2 872,09 МБит/сек (CPU load 58-62%)
>  
> Результаты тестов при скачивании файла по локальной сети:
>  - HTTP/1.1 - ~2 325,03 МБит/сек (CPU load 45-50%)
>  - HTTP/2 - ~2 333,56 МБит/сек (CPU load 45-50%)
>  - HTTP/3 - ~1 350,26 МБит/сек (CPU load 50-55%)
> 
> Анализ профиля для протокола HTTP/3 при скачивании файла с самого сервера:
>     482  27.1%  27.1%      482  27.1% __sendmsg

У вас quic_gso включен?  Если нет, попробуйте включить:

  quic_gso on;

Также попробуйте приаттаченный патч, добавляющий поддержку sendmmsg()
(quic_gso при этом оставьте включенным).  nginx будет надо переконфигурить
перед сборкой.

Интересно посмотреть, как изменятся цифры.

>     473  26.6%  53.7%      473  26.6% __libc_pread64
>     367  20.6%  74.4%      367  20.6% _aesni_ctr32_ghash_6x
>     151  8.5%  82.8%      151  8.5% __memmove_avx_unaligned_erms
>       58  3.3%  86.1%      58  3.3% epoll_wait
>       31  1.7%  87.9%      31  1.7% __recvmsg
>       10  0.6%  88.4%      93  5.2% ngx_quic_write_buffer
>       8  0.4%  88.9%      100  5.6% ngx_quic_recvmsg
>       7  0.4%  89.3%        7  0.4% __strcmp_avx2
>       7  0.4%  89.7%        7  0.4% ngx_quic_read_buffer
>       6  0.3%  90.0%      115  6.5% ngx_http_charset_body_filter
>       6  0.3%  90.3%      108  6.1% ngx_http_write_filter
>       6  0.3%  90.7%      82  4.6% ngx_quic_create_frame
>       6  0.3%  91.0%        8  0.4% ossl_gcm_set_ctx_params
>       5  0.3%  91.3%      19  1.1% EVP_CIPHER_CTX_ctrl
>       5  0.3%  91.6%        5  0.3% aesni_ctr32_encrypt_blocks
>       5  0.3%  91.8%        5  0.3% ngx_quic_alloc_buf
>       5  0.3%  92.1%      15  0.8% ngx_quic_handle_ack_frame_range
>       5  0.3%  92.4%      59  3.3% ngx_quic_handle_datagram
>       4  0.2%  92.6%      10  0.6% CRYPTO_gcm128_encrypt_ctr32

[..]

--
Roman Arutyunyan
----------- следующая часть -----------
# HG changeset patch
# User Roman Arutyunyan <arut на nginx.com>
# Date 1692075843 -14400
#      Tue Aug 15 09:04:03 2023 +0400
# Node ID 0f7b91d0fea6d132f877ff25992a457a2fe437e6
# Parent  6c8595b77e667bd58fd28186939ed820f2e55e0e
QUIC: use sendmmsg() with UDP segmentation instead of sendmsg().

The syscall allows to send more datagrams with a single call.

Using sendmmsg() will not introduce compatibility issues since this syscall was
added in Linux kernel 3.0, while UDP segmentation was added in 4.18.

diff --git a/auto/os/linux b/auto/os/linux
--- a/auto/os/linux
+++ b/auto/os/linux
@@ -291,4 +291,16 @@ ngx_feature_test="socklen_t optlen = siz
 . auto/feature
 
 
+ngx_feature="sendmmsg()"
+ngx_feature_name="NGX_HAVE_SENDMMSG"
+ngx_feature_run=no
+ngx_feature_incs="#include <sys/socket.h>
+                  #include <sys/uio.h>"
+ngx_feature_path=
+ngx_feature_libs=
+ngx_feature_test="struct mmsghdr msg[UIO_MAXIOV];
+                  sendmmsg(0, msg, UIO_MAXIOV, 0);"
+. auto/feature
+
+
 CC_AUX_FLAGS="$cc_aux_flags -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64"
diff --git a/src/event/quic/ngx_event_quic_output.c b/src/event/quic/ngx_event_quic_output.c
--- a/src/event/quic/ngx_event_quic_output.c
+++ b/src/event/quic/ngx_event_quic_output.c
@@ -48,11 +48,9 @@ static ngx_int_t ngx_quic_create_datagra
 static void ngx_quic_commit_send(ngx_connection_t *c, ngx_quic_send_ctx_t *ctx);
 static void ngx_quic_revert_send(ngx_connection_t *c, ngx_quic_send_ctx_t *ctx,
     uint64_t pnum);
-#if ((NGX_HAVE_UDP_SEGMENT) && (NGX_HAVE_MSGHDR_MSG_CONTROL))
+#if (NGX_HAVE_UDP_SEGMENT && NGX_HAVE_MSGHDR_MSG_CONTROL && NGX_HAVE_SENDMMSG)
 static ngx_uint_t ngx_quic_allow_segmentation(ngx_connection_t *c);
 static ngx_int_t ngx_quic_create_segments(ngx_connection_t *c);
-static ssize_t ngx_quic_send_segments(ngx_connection_t *c, u_char *buf,
-    size_t len, struct sockaddr *sockaddr, socklen_t socklen, size_t segment);
 #endif
 static ssize_t ngx_quic_output_packet(ngx_connection_t *c,
     ngx_quic_send_ctx_t *ctx, u_char *data, size_t max, size_t min);
@@ -80,7 +78,7 @@ ngx_quic_output(ngx_connection_t *c)
 
     in_flight = cg->in_flight;
 
-#if ((NGX_HAVE_UDP_SEGMENT) && (NGX_HAVE_MSGHDR_MSG_CONTROL))
+#if (NGX_HAVE_UDP_SEGMENT && NGX_HAVE_MSGHDR_MSG_CONTROL && NGX_HAVE_SENDMMSG)
     if (ngx_quic_allow_segmentation(c)) {
         rc = ngx_quic_create_segments(c);
     } else
@@ -250,7 +248,7 @@ ngx_quic_revert_send(ngx_connection_t *c
 }
 
 
-#if ((NGX_HAVE_UDP_SEGMENT) && (NGX_HAVE_MSGHDR_MSG_CONTROL))
+#if (NGX_HAVE_UDP_SEGMENT && NGX_HAVE_MSGHDR_MSG_CONTROL && NGX_HAVE_SENDMMSG)
 
 static ngx_uint_t
 ngx_quic_allow_segmentation(ngx_connection_t *c)
@@ -308,16 +306,28 @@ ngx_quic_allow_segmentation(ngx_connecti
 static ngx_int_t
 ngx_quic_create_segments(ngx_connection_t *c)
 {
-    size_t                  len, segsize;
+    size_t                  len, segsize, clen;
     ssize_t                 n;
-    u_char                 *p, *end;
+    u_char                 *p, *start, *end;
+    uint16_t               *valp;
     uint64_t                preserved_pnum;
-    ngx_uint_t              nseg;
+    ngx_err_t               err;
+    ngx_uint_t              nseg, nmsg;
+    struct msghdr           msg;
+    struct cmsghdr         *cmsg;
     ngx_quic_path_t        *path;
     ngx_quic_send_ctx_t    *ctx;
     ngx_quic_congestion_t  *cg;
     ngx_quic_connection_t  *qc;
-    static u_char           dst[NGX_QUIC_MAX_UDP_SEGMENT_BUF];
+#if (NGX_HAVE_ADDRINFO_CMSG)
+    char                    msg_control[CMSG_SPACE(sizeof(uint16_t))
+                                        + CMSG_SPACE(sizeof(ngx_addrinfo_t))];
+#else
+    char                    msg_control[CMSG_SPACE(sizeof(uint16_t))];
+#endif
+    struct iovec            iovs[UIO_MAXIOV];
+    static u_char           dst[UIO_MAXIOV * NGX_QUIC_MAX_UDP_SEGMENT_BUF];
+    struct mmsghdr          msgs[UIO_MAXIOV];
 
     qc = ngx_quic_get_connection(c);
     cg = &qc->congestion;
@@ -330,94 +340,12 @@ ngx_quic_create_segments(ngx_connection_
     }
 
     segsize = ngx_min(path->mtu, NGX_QUIC_MAX_UDP_SEGMENT_BUF);
-    p = dst;
-    end = dst + sizeof(dst);
-
-    nseg = 0;
-
-    preserved_pnum = ctx->pnum;
-
-    for ( ;; ) {
-
-        len = ngx_min(segsize, (size_t) (end - p));
-
-        if (len && cg->in_flight + (p - dst) < cg->window) {
-
-            n = ngx_quic_output_packet(c, ctx, p, len, len);
-            if (n == NGX_ERROR) {
-                return NGX_ERROR;
-            }
-
-            if (n) {
-                p += n;
-                nseg++;
-            }
-
-        } else {
-            n = 0;
-        }
-
-        if (p == dst) {
-            break;
-        }
-
-        if (n == 0 || nseg == NGX_QUIC_MAX_SEGMENTS) {
-            n = ngx_quic_send_segments(c, dst, p - dst, path->sockaddr,
-                                       path->socklen, segsize);
-            if (n == NGX_ERROR) {
-                return NGX_ERROR;
-            }
-
-            if (n == NGX_AGAIN) {
-                ngx_quic_revert_send(c, ctx, preserved_pnum);
-
-                ngx_add_timer(&qc->push, NGX_QUIC_SOCKET_RETRY_DELAY);
-                break;
-            }
-
-            ngx_quic_commit_send(c, ctx);
-
-            path->sent += n;
-
-            p = dst;
-            nseg = 0;
-            preserved_pnum = ctx->pnum;
-        }
-    }
-
-    return NGX_OK;
-}
-
-
-static ssize_t
-ngx_quic_send_segments(ngx_connection_t *c, u_char *buf, size_t len,
-    struct sockaddr *sockaddr, socklen_t socklen, size_t segment)
-{
-    size_t           clen;
-    ssize_t          n;
-    uint16_t        *valp;
-    struct iovec     iov;
-    struct msghdr    msg;
-    struct cmsghdr  *cmsg;
-
-#if (NGX_HAVE_ADDRINFO_CMSG)
-    char             msg_control[CMSG_SPACE(sizeof(uint16_t))
-                             + CMSG_SPACE(sizeof(ngx_addrinfo_t))];
-#else
-    char             msg_control[CMSG_SPACE(sizeof(uint16_t))];
-#endif
 
     ngx_memzero(&msg, sizeof(struct msghdr));
     ngx_memzero(msg_control, sizeof(msg_control));
 
-    iov.iov_len = len;
-    iov.iov_base = buf;
-
-    msg.msg_iov = &iov;
-    msg.msg_iovlen = 1;
-
-    msg.msg_name = sockaddr;
-    msg.msg_namelen = socklen;
+    msg.msg_name = path->sockaddr;
+    msg.msg_namelen = path->socklen;
 
     msg.msg_control = msg_control;
     msg.msg_controllen = sizeof(msg_control);
@@ -431,7 +359,7 @@ ngx_quic_send_segments(ngx_connection_t 
     clen = CMSG_SPACE(sizeof(uint16_t));
 
     valp = (void *) CMSG_DATA(cmsg);
-    *valp = segment;
+    *valp = segsize;
 
 #if (NGX_HAVE_ADDRINFO_CMSG)
     if (c->listening && c->listening->wildcard && c->local_sockaddr) {
@@ -442,14 +370,100 @@ ngx_quic_send_segments(ngx_connection_t 
 
     msg.msg_controllen = clen;
 
-    n = ngx_sendmsg(c, &msg, 0);
-    if (n < 0) {
-        return n;
+    for ( ;; ) {
+
+        preserved_pnum = ctx->pnum;
+
+        p = dst;
+
+        for (nmsg = 0; nmsg < UIO_MAXIOV; nmsg++) {
+
+            start = p;
+            end = p + NGX_QUIC_MAX_UDP_SEGMENT_BUF;
+
+            for (nseg = 0; nseg < NGX_QUIC_MAX_SEGMENTS; nseg++) {
+
+                if (cg->in_flight + (p - dst) >= cg->window) {
+                    break;
+                }
+
+                len = ngx_min(segsize, (size_t) (end - p));
+                if (len == 0) {
+                    break;
+                }
+
+                n = ngx_quic_output_packet(c, ctx, p, len, len);
+
+                if (n == NGX_ERROR) {
+                    return NGX_ERROR;
+                }
+
+                if (n == 0) {
+                    break;
+                }
+
+                p += n;
+            }
+
+            if (nseg == 0) {
+                break;
+            }
+
+            iovs[nmsg].iov_base = start;
+            iovs[nmsg].iov_len = p - start;
+
+            msgs[nmsg].msg_hdr = msg;
+            msgs[nmsg].msg_hdr.msg_iov = &iovs[nmsg];
+            msgs[nmsg].msg_hdr.msg_iovlen = 1;
+            msgs[nmsg].msg_len = 0;
+        }
+
+        if (nmsg == 0) {
+            break;
+        }
+
+    eintr:
+
+        n = sendmmsg(c->fd, msgs, nmsg, 0);
+
+        if (n == -1) {
+            err = ngx_errno;
+
+            switch (err) {
+            case NGX_EAGAIN:
+                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
+                               "sendmmsg() not ready");
+
+                ngx_quic_revert_send(c, ctx, preserved_pnum);
+
+                ngx_add_timer(&qc->push, NGX_QUIC_SOCKET_RETRY_DELAY);
+                return NGX_OK;
+
+            case NGX_EINTR:
+                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
+                               "sendmmsg() was interrupted");
+                goto eintr;
+
+            default:
+                c->write->error = 1;
+                ngx_connection_error(c, err, "sendmsg() failed");
+                return NGX_ERROR;
+            }
+        }
+
+        len = p - dst;
+
+        ngx_log_debug3(NGX_LOG_DEBUG_EVENT, c->log, 0,
+                       "sendmmsg: %z of %ui msg of size %uz", n, nmsg, len);
+
+        c->sent += len;
+
+        ngx_quic_commit_send(c, ctx);
+
+        path->sent += len;
     }
 
-    c->sent += n;
-
-    return n;
+    return NGX_OK;
 }
 
 #endif

From izorkin на gmail.com  Mon Jan  8 13:17:51 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Mon, 8 Jan 2024 16:17:51 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
Message-ID: <10410669466.20240108161751@gmail.com>

Добрый день, Роман.

В среднем чуть-чуть лучше результат, скорость иногда выше на
5-10 МБайт/сек. Иногда на одном уровне держится.

По профилю видно, что sendmmsg()практически не используется:
     626  31.3%  31.3%      626  31.3% __sendmsg
     546  27.3%  58.7%      546  27.3% _aesni_ctr32_ghash_6x
     279  14.0%  72.7%      279  14.0% __libc_pread64
     174   8.7%  81.4%      174   8.7% __memmove_avx_unaligned_erms
      64   3.2%  84.6%       64   3.2% epoll_wait
      42   2.1%  86.7%       42   2.1% __recvmsg
      11   0.6%  87.2%      115   5.8% ngx_quic_write_buffer
      10   0.5%  87.7%      116   5.8% ngx_quic_recvmsg
       9   0.5%  88.2%        9   0.5% __sendmmsg
       9   0.5%  88.6%        9   0.5% ngx_quic_alloc_buf
       9   0.5%  89.1%       92   4.6% ngx_quic_create_frame
       8   0.4%  89.5%        8   0.4% aesni_ctr32_encrypt_blocks
       8   0.4%  89.9%        8   0.4% ngx_quic_free_chain
       7   0.4%  90.2%        7   0.4% __strcmp_avx2
       7   0.4%  90.6%     1360  68.1% ngx_quic_output
       7   0.4%  90.9%        7   0.4% ngx_quic_parse_frame
       6   0.3%  91.2%        6   0.3% aesni_encrypt
       6   0.3%  91.5%        6   0.3% evp_cipher_init_internal
       6   0.3%  91.8%      431  21.6% ngx_output_chain
       5   0.3%  92.1%      581  29.1% gcm_cipher_internal
       5   0.3%  92.3%        5   0.3% gcm_ghash_avx
       5   0.3%  92.6%      573  28.7% generic_aes_gcm_cipher_update
       5   0.3%  92.8%        5   0.3% ngx_alloc_chain_link
       5   0.3%  93.1%      141   7.1% ngx_http_image_body_filter
       4   0.2%  93.3%       17   0.9% EVP_CIPHER_CTX_ctrl
       4   0.2%  93.5%        9   0.5% EVP_EncryptFinal_ex
       4   0.2%  93.7%        4   0.2% _init


Вы писали 8 января 2024 г., 15:18:45:

> У вас quic_gso включен?  Если нет, попробуйте включить:

>   quic_gso on;

> Также попробуйте приаттаченный патч, добавляющий поддержку sendmmsg()
> (quic_gso при этом оставьте включенным).  nginx будет надо переконфигурить
> перед сборкой.

> Интересно посмотреть, как изменятся цифры.

> --
> Roman Arutyunyan



-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From izorkin на gmail.com  Mon Jan  8 13:25:19 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Mon, 8 Jan 2024 16:25:19 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
Message-ID: <91283338.20240108162519@gmail.com>

Добрый день, Роман.

Забыл добавить текущий анализ профиля без использования патча:
    670  32.1%  32.1%      670  32.1% __sendmsg
     538  25.8%  58.0%      538  25.8% _aesni_ctr32_ghash_6x
     269  12.9%  70.9%      269  12.9% __libc_pread64
     176   8.4%  79.3%      176   8.4% __memmove_avx_unaligned_erms
      71   3.4%  82.7%       71   3.4% epoll_wait
      47   2.3%  85.0%       47   2.3% __recvmsg
      16   0.8%  85.7%       16   0.8% __strcmp_avx2
      12   0.6%  86.3%       12   0.6% gcm_ghash_avx
       8   0.4%  86.7%        9   0.4% aesni_ctr32_encrypt_blocks
       7   0.3%  87.0%        7   0.3% aesni_encrypt
       7   0.3%  87.4%        7   0.3% evp_cipher_init_internal
       6   0.3%  87.7%       17   0.8% CRYPTO_gcm128_encrypt_ctr32
       6   0.3%  88.0%       29   1.4% EVP_CIPHER_CTX_ctrl
       5   0.2%  88.2%        6   0.3% CRYPTO_gcm128_decrypt_ctr32
       5   0.2%  88.4%        9   0.4% CRYPTO_gcm128_setiv
       4   0.2%  88.6%        4   0.2% 0x000009ac4576189c
       4   0.2%  88.8%       10   0.5% CRYPTO_gcm128_tag
       4   0.2%  89.0%       15   0.7% EVP_EncryptFinal_ex
       3   0.1%  89.2%        3   0.1% 0x000009ac4572bb22
       3   0.1%  89.3%        3   0.1% 0x000009ac45781bc4
       3   0.1%  89.4%        9   0.4% CRYPTO_gcm128_finish
       3   0.1%  89.6%      579  27.8% EVP_EncryptUpdate
       3   0.1%  89.7%        3   0.1% __memset_avx2_unaligned_erms
       3   0.1%  89.9%        3   0.1% _init




-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From mdounin на mdounin.ru  Mon Jan  8 21:04:16 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 9 Jan 2024 00:04:16 +0300
Subject: nginx: HTTP/2 =?koi8-r?Q?=C9?= kTLS
In-Reply-To: <184230688.20240107103900@gmail.com>
References: <184230688.20240107103900@gmail.com>
Message-ID: <ZZxjUEXOLXKTuH1q@mdounin.ru>

Hello!

On Sun, Jan 07, 2024 at 10:39:00AM +0300, izorkin на gmail.com wrote:

> Доброе утро.
> 
> При использовании kTLS и sendfile наблюдается просадка производительности
> при отдаче статических файлов, например при видео-стриминге. Одним из
> вариантов решения является перенести статический файлы на другой хост и
> использовать там только протоколы HTTP/1.1 и/или HTTP/3. Либо усложнять
> логику работы в блоке location.
> 
> Не все сервисы позволяют выводить статику на отдельный хост, либо могут
> иметь сложную конфигурацию nginx. Например web-сервис Peertube имеет
> множество блоков location и использует различные условия if:
> https://github.com/Chocobozzz/PeerTube/blob/develop/support/nginx/peertube
> 
> Обычному пользователю будет сложнее с этим разобраться и добавить
> дополнительные блоки для исключения работы протокола HTTP/2 через kTLS.
> Вполне легко можно запутаться и нарушить логику работы сайта.
> 
> Хотелось бы иметь более простой и универсальный способ отключения
> обработки протокола HTTP/2 через kTLS.
> 
> Предполагаю, что перед передачей шифрования ядру системы сейчас nginx
> проверяет наличие ssl и параметра sendfile. Можно ли добавить дополнительное
> условие, которое проверяет дополнительный параметр, который указывает
> какой протокол исключить из обработки шифрования ядром?
> 
> По итогу получится примерно такой вариант конфигурации:
>   server {
>     listen 0.0.0.0:443 quic reuseport ;
>     listen 0.0.0.0:443 ssl reuseport ;
>     http2 on;
>     http3 on;
>     ssl_conf_command Options KTLS;
>     disable_ktls_for_protocol http2;
> ...
> 
> Мне кажется, что такой вариант эффективнее, чем добавлять условие if с
> rewrite и дополнительный блок location.

Как я уже писал ранее,

1. Дело не в kTLS, kTLS работает для HTTP/2 точно так же, как и 
для HTTP/1.x.  Просто в отсутствии акселераторов - kTLS сам по 
себе не даёт примерно ничего.  Дело в sendfile(), который при 
включённом kTLS начинает работать в том числе для HTTP/2, но для 
HTTP/2 он работает плохо из-за фрейминга.

2. Смысла в таком решении примерно ноль, потому что типичный 
браузер всё равно соединится по HTTP/2 (или по HTTP/3).  То есть с 
тем же успехом можно просто выключить sendfile (и/или kTLS), 
результат не будет отличаться.

Если хочется, чтобы было быстро - надо выносить (большую) статику в 
отдельный домен, где разрешать только HTTP/1.x, и соответственно 
включать sendfile и kTLS.

Впрочем, насколько быстро - это отдельный вопрос.  Скорее всего на 
линуксе примерно те же результаты можно получить, просто подняв 
размер output_buffers (http://nginx.org/r/output_buffers).

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Tue Jan  9 02:26:08 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 9 Jan 2024 05:26:08 +0300
Subject: =?koi8-r?B?8MHU3iBFVGFncyDX?= NixOS
In-Reply-To: <994095771.20240107095745@gmail.com>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com>
Message-ID: <ZZyuwP78wlw8KIxM@mdounin.ru>

Hello!

On Sun, Jan 07, 2024 at 09:57:45AM +0300, izorkin на gmail.com wrote:

> Обнаружилась ещё одна ошибка с текущим вариантом патча:
> https://github.com/NixOS/nixpkgs/pull/278380
> 
> Некорректно кэшируются файлы, которые предварительно сжаты в формат
> gzip и/или brotli форматы.
> 
> Может получится найти какое-то альтернативный вариант решения генерации
> Etags для файлов, которые имеют фиксированную дату? 
> 
> Сейчас, Etags генерируется на основе размера файла + даты изменения.

ETag на основе размера файла и даты модификации файла - кажется 
вполне достаточным для уникальности в рамках требований к strong 
entity tags.  Тем более, что даже при совпадении ETag'ов между 
различными представлениями одного ресурса - сломаться что-либо 
может скорее теоретически, если вдруг меняются правила выбора 
представлений (e.g., включают или выключают gzip_static, а клиент 
в это время пытается делать range-запрос и комбинировать его с 
ранее полученными от другой конфигурации ответами).

Что либо менять в nginx'е я тут смысла не вижу, ETag сейчас 
содержит достаточно информации, чтобы проблем не возникало.

Что до nix store, то кажется, что возвращение размера в ETag также 
должно проблему решить.

> Поможет ли добавление ещё одного параметра, например полного пути к
> файлу? Получится такой вариант:
> размер файла + дата изменения + полный путь к файлу

Полный путь к файлу в ETag точно не имеет смысла.  Более того, его 
там быть точно не должно: если вдруг ресурс обслуживается двумя 
разными origin-серверами, это приведёт к требованию совпадения 
путей к файлу на этих серверах, а при их несовпадении - 
соответственно к полным ответам вместе 304, то есть сломает 
кэширование там, где оно сейчас работает.

Теоретически, наверное, можно пытаться в ETag вставлять какой-то 
идентификатор представления, то если для gzip_static добавлять в 
ETag что-нибудь вроде "...-gz".  Но при наличии размера в том же 
ETag'е смысла в этом исчезающие мало.

-- 
Maxim Dounin
http://mdounin.ru/

From izorkin на gmail.com  Tue Jan  9 18:47:48 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Tue, 9 Jan 2024 21:47:48 +0300
Subject: =?utf-8?Q?Re:_nginx:_HTTP/2_=D0=B8_kTLS?=
In-Reply-To: <ZZxjUEXOLXKTuH1q@mdounin.ru>
References: <184230688.20240107103900@gmail.com> <ZZxjUEXOLXKTuH1q@mdounin.ru>
Message-ID: <1839762991.20240109214748@gmail.com>

Здравствуйте, Maxim.

Понятно, в прошлый раз не полностью разобрался, извините.

Тут возникла идея добавить заголовок Alt-Svc, как это делается
для протокола HTTP/3, но на практике не сработало:
  add_header Alt-Svc 'http/1.1=":443"';

Вариант с поднятием размера output_buffers тоже не сработал.

Вы писали 9 января 2024 г., 0:04:16:

> Как я уже писал ранее,

> 1. Дело не в kTLS, kTLS работает для HTTP/2 точно так же, как и 
> для HTTP/1.x.  Просто в отсутствии акселераторов - kTLS сам по 
> себе не даёт примерно ничего.  Дело в sendfile(), который при 
> включённом kTLS начинает работать в том числе для HTTP/2, но для 
> HTTP/2 он работает плохо из-за фрейминга.

> 2. Смысла в таком решении примерно ноль, потому что типичный 
> браузер всё равно соединится по HTTP/2 (или по HTTP/3).  То есть с 
> тем же успехом можно просто выключить sendfile (и/или kTLS), 
> результат не будет отличаться.

> Если хочется, чтобы было быстро - надо выносить (большую) статику в 
> отдельный домен, где разрешать только HTTP/1.x, и соответственно 
> включать sendfile и kTLS.

> Впрочем, насколько быстро - это отдельный вопрос.  Скорее всего на 
> линуксе примерно те же результаты можно получить, просто подняв 
> размер output_buffers (http://nginx.org/r/output_buffers).




-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From chipitsine на gmail.com  Thu Jan 11 13:59:54 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 11 Jan 2024 14:59:54 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <10410669466.20240108161751@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
Message-ID: <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>

из интересного, в openssl master есть вот такое
https://github.com/openssl/openssl/blob/master/doc/designs/quic-design/dgram-api.md

пн, 8 янв. 2024 г. в 14:18, <izorkin на gmail.com>:

> Добрый день, Роман.
>
> В среднем чуть-чуть лучше результат, скорость иногда выше на
> 5-10 МБайт/сек. Иногда на одном уровне держится.
>
> По профилю видно, что sendmmsg()практически не используется:
>      626  31.3%  31.3%      626  31.3% __sendmsg
>      546  27.3%  58.7%      546  27.3% _aesni_ctr32_ghash_6x
>      279  14.0%  72.7%      279  14.0% __libc_pread64
>      174   8.7%  81.4%      174   8.7% __memmove_avx_unaligned_erms
>       64   3.2%  84.6%       64   3.2% epoll_wait
>       42   2.1%  86.7%       42   2.1% __recvmsg
>       11   0.6%  87.2%      115   5.8% ngx_quic_write_buffer
>       10   0.5%  87.7%      116   5.8% ngx_quic_recvmsg
>        9   0.5%  88.2%        9   0.5% __sendmmsg
>


9 раз вызвался ?
есть подозрение, что произошла ошибка и перешли на sendmsg.
попробуйте в дебаге, в прилагаемом патче есть ngx_log_debug0(...)


>        9   0.5%  88.6%        9   0.5% ngx_quic_alloc_buf
>        9   0.5%  89.1%       92   4.6% ngx_quic_create_frame
>        8   0.4%  89.5%        8   0.4% aesni_ctr32_encrypt_blocks
>        8   0.4%  89.9%        8   0.4% ngx_quic_free_chain
>        7   0.4%  90.2%        7   0.4% __strcmp_avx2
>        7   0.4%  90.6%     1360  68.1% ngx_quic_output
>        7   0.4%  90.9%        7   0.4% ngx_quic_parse_frame
>        6   0.3%  91.2%        6   0.3% aesni_encrypt
>        6   0.3%  91.5%        6   0.3% evp_cipher_init_internal
>        6   0.3%  91.8%      431  21.6% ngx_output_chain
>        5   0.3%  92.1%      581  29.1% gcm_cipher_internal
>        5   0.3%  92.3%        5   0.3% gcm_ghash_avx
>        5   0.3%  92.6%      573  28.7% generic_aes_gcm_cipher_update
>        5   0.3%  92.8%        5   0.3% ngx_alloc_chain_link
>        5   0.3%  93.1%      141   7.1% ngx_http_image_body_filter
>        4   0.2%  93.3%       17   0.9% EVP_CIPHER_CTX_ctrl
>        4   0.2%  93.5%        9   0.5% EVP_EncryptFinal_ex
>        4   0.2%  93.7%        4   0.2% _init
>
>
> Вы писали 8 января 2024 г., 15:18:45:
>
> > У вас quic_gso включен?  Если нет, попробуйте включить:
>
> >   quic_gso on;
>
> > Также попробуйте приаттаченный патч, добавляющий поддержку sendmmsg()
> > (quic_gso при этом оставьте включенным).  nginx будет надо
> переконфигурить
> > перед сборкой.
>
> > Интересно посмотреть, как изменятся цифры.
>
> > --
> > Roman Arutyunyan
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240111/0c0ed4ca/attachment.htm>

From izorkin на gmail.com  Thu Jan 11 18:59:53 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 11 Jan 2024 21:59:53 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
Message-ID: <1648601044.20240111215953@gmail.com>

Добрый вечер, Илья.

Да, только 9 раз. Сейчас в тестах вообще только 3 раза был вызов. И в debug режиме
чаще используется __libc_write вызов.
 
    6965  69.8%  69.8%    6965  69.8% __libc_write
    654  6.6%  76.3%      654  6.6% __sendmsg
    357  3.6%  79.9%      357  3.6% _aesni_ctr32_ghash_6x
    322  3.2%  83.1%      536  5.4% ngx_vslprintf
    300  3.0%  86.1%      300  3.0% syscall
    277  2.8%  88.9%      277  2.8% __libc_pread64
    226  2.3%  91.2%      226  2.3% __memmove_avx_unaligned_erms
    142  1.4%  92.6%      190  1.9% ngx_sprintf_num
      93  0.9%  93.5%    7911  79.2% ngx_log_error_core
      63  0.6%  94.1%      63  0.6% epoll_wait
      55  0.6%  94.7%      55  0.6% __recvmsg
      35  0.4%  95.0%      300  3.0% ngx_slprintf
      19  0.2%  95.2%      19  0.2% __strcmp_avx2
      17  0.2%  95.4%      89  0.9% ngx_quic_create_frame
      16  0.2%  95.6%      16  0.2% _init на 39000
...
       3   0.0%  98.6%        3   0.0% __sendmmsg 
...
 
Размер лог-файла получился очень большим, около 1.5 Gb. В нём около нескольких сотен
упоминаний sendmmsg. Что там искать, на что обратить внимание?
 
cat /tmp/nginx/debug.log| grep 'sendmmsg' 
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 69087
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 69087
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 69087
...
Часть лога с sendmmsg:
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx app STREAM id:0x0 off:3145389 len:339
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx app bytes:1162 need_ack:1 number:2784 encoded nl:1 trunc:0xe0
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 69087
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:69087
2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer: 9, old: 863483412, new: 863483521
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic lost timer pto:48
2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9: 48:863423569
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic state: send:59891 pto:48
2024/01/11 21:32:36 [debug] 33853#33853: quic recvmsg on [::]:443, ready: 0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic recvmsg: fd:9 n:51
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic input handler
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx short flags:42
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx dcid len:20 000000000001a00183bd407243b7f2011ca86733
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx clearflags:40
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx number:52 len:1
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet len:51 via sock seq:0 path seq:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic path seq:0 status tx:3319325 rx:7668 valid:1 st:2 mtu:1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame rx app ACK n:0 delay:15 2784-2669
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_handle_ack_frame level:3
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion slow start win:3379951 ss:-1 if:67887
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic stream id:0x0 ack len:1152 fin:0 unacked:64384
2024/01/11 21:32:36 [debug] 33853#33853: *6 post event 00006741DE771C80
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion slow start win:3381151 ss:-1 if:66687
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic stream id:0x0 ack len:1152 fin:0 unacked:63232
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion slow start win:3382351 ss:-1 if:65487
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic stream id:0x0 ack len:1152 fin:0 unacked:62080
 
Ещё часть лога с sendmsg:
024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_add_handshake_data
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic SSL_get_peer_quic_transport_params(): params_len:74
2024/01/11 21:32:36 [info] 33853#33853: *1 quic unknown transport param id:0x11, skipped while handling frames, client: ::1, server: [::]:443
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic transport parameters parsed ok
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp disable active migration: 0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp idle_timeout:60000
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_udp_payload_size:65527
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_data:1310720
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_stream_data_bidi_local:131072
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_stream_data_bidi_remote:131072
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_stream_data_uni:131072
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp initial_max_streams_bidi:262144
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp initial_max_streams_uni:262144
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp ack_delay_exponent:3
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_ack_delay:25
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp active_connection_id_limit:2
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp initial source_connection_id len:20 de1e73dcd4e6a4fdc6ecfb38ac840a34922b8517
2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign: 00006741DE627800:512 @16
2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE650000:4096
2024/01/11 21:32:36 [debug] 33853#33853: *1 post event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_set_encryption_secrets() level:2
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_add_handshake_data
2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE651000:4096
2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign: 00006741DE627A00:512 @16
2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_add_handshake_data
2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE652000:4096
2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_add_handshake_data
2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE653000:4096
2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign: 00006741DE627C00:512 @16
2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_add_handshake_data
2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE654000:4096
2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_flush_flight()
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_set_encryption_secrets() level:3
2024/01/11 21:32:36 [debug] 33853#33853: *1 SSL_do_handshake: -1
2024/01/11 21:32:36 [debug] 33853#33853: *1 SSL_get_error: 2
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame rx init PADDING
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_ack_packet pn:0 largest -1 fr:0 nranges:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet done rc:0 level:init decr:1 pn:0 perr:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9: 60000:863483412
2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9: 60000:863483412
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic state: read:60000 close:60000
2024/01/11 21:32:36 [debug] 33853#33853: *1 delete posted event 00006741DE6D5608
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic push handler
2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign: 00006741DE627E00:512 @16
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output init packet max:1200 min:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx init ACK n:0 delay:0 0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx init CRYPTO len:123 off:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx init bytes:132 need_ack:1 number:0 encoded nl:1 trunc:0x0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output hs packet max:1001 min:1001
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:163 off:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic split frame now:1403 need:768 shrink:635
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:763 off:163
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx hs bytes:935 need_ack:1 number:0 encoded nl:1 trunc:0x0
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmsg: 1200 of 1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:199
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output hs packet max:1200 min:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:635 off:926
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic split frame now:525 need:494 shrink:31
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:489 off:1561
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx hs bytes:1134 need_ack:1 number:1 encoded nl:1 trunc:0x1
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmsg: 1200 of 1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2400
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2400
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output hs packet max:1200 min:0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:31 off:2050
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:36 off:2081
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx hs bytes:75 need_ack:1 number:2 encoded nl:1 trunc:0x2
2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmsg: 141 of 141
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2400
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2541
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2541
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic path limit 1200 - 1059
2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer: 9, old: 863483412, new: 863483412
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic lost timer pto:997
2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9: 997:863424409
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic state: send:60000 pto:997 close:60000
2024/01/11 21:32:36 [debug] 33853#33853: quic recvmsg on [::]:443, ready: 0
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic recvmsg: fd:9 n:1200
2024/01/11 21:32:36 [debug] 33853#33853: *1 quic input handler
 
 
Вы писали 11 января 2024 г., 16:59:54:
 
> 9 раз вызвался ?
> есть подозрение, что произошла ошибка и перешли на sendmsg.
> попробуйте в дебаге, в прилагаемом патче есть ngx_log_debug0(...)

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240111/061f56e8/attachment-0001.htm>

From chipitsine на gmail.com  Thu Jan 11 19:11:56 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 11 Jan 2024 20:11:56 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1648601044.20240111215953@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
Message-ID: <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>

чт, 11 янв. 2024 г. в 20:00, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
> Да, только 9 раз. Сейчас в тестах вообще только 3 раза был вызов. И в
> debug режиме
>
> чаще используется __libc_write вызов.
>
>
>
>     6965  69.8%  69.8%    6965  69.8% __libc_write
>
>     654  6.6%  76.3%      654  6.6% __sendmsg
>
>     357  3.6%  79.9%      357  3.6% _aesni_ctr32_ghash_6x
>
>     322  3.2%  83.1%      536  5.4% ngx_vslprintf
>
>     300  3.0%  86.1%      300  3.0% syscall
>
>     277  2.8%  88.9%      277  2.8% __libc_pread64
>
>     226  2.3%  91.2%      226  2.3% __memmove_avx_unaligned_erms
>
>     142  1.4%  92.6%      190  1.9% ngx_sprintf_num
>
>       93  0.9%  93.5%    7911  79.2% ngx_log_error_core
>
>       63  0.6%  94.1%      63  0.6% epoll_wait
>
>       55  0.6%  94.7%      55  0.6% __recvmsg
>
>       35  0.4%  95.0%      300  3.0% ngx_slprintf
>
>       19  0.2%  95.2%      19  0.2% __strcmp_avx2
>
>       17  0.2%  95.4%      89  0.9% ngx_quic_create_frame
>
>       16  0.2%  95.6%      16  0.2% _init на 39000
>
> ...
>
>        3   0.0%  98.6%        3   0.0% __sendmmsg
>
> ...
>
>
>
> Размер лог-файла получился очень большим, около 1.5 Gb. В нём около
> нескольких сотен
>
> упоминаний sendmmsg. Что там искать, на что обратить внимание?
>


я имею в виду вот этот код

+        if (n == -1) {
+            err = ngx_errno;
+
+            switch (err) {
+            case NGX_EAGAIN:
+                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
+                               "sendmmsg() not ready");
+
+                ngx_quic_revert_send(c, ctx, preserved_pnum);
+
+                ngx_add_timer(&qc->push, NGX_QUIC_SOCKET_RETRY_DELAY);
+                return NGX_OK;
+
+            case NGX_EINTR:
+                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
+                               "sendmmsg() was interrupted");
+                goto eintr;
+
+            default:
+                c->write->error = 1;
+                ngx_connection_error(c, err, "sendmsg() failed");
+                return NGX_ERROR;
+            }
+        }

ну то есть искать либо "sendmmsg()", либо явно поправить ngx_log_debug,
чтобы удобнее было искать

в том, что вы прислали, я не вижу такого патерна


>
>
> cat /tmp/nginx/debug.log| grep 'sendmmsg'
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size
> 69087
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size
> 69087
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size
> 69087
>
> ...
>
> Часть лога с sendmmsg:
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx app STREAM
> id:0x0 off:3145389 len:339
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx app bytes:1162
> need_ack:1 number:2784 encoded nl:1 trunc:0xe0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size
> 69087
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:69087
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer: 9, old:
> 863483412, new: 863483521
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic lost timer pto:48
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9:
> 48:863423569
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic state: send:59891 pto:48
>
> 2024/01/11 21:32:36 [debug] 33853#33853: quic recvmsg on [::]:443, ready: 0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic recvmsg: fd:9 n:51
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic input handler
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx short flags:42
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx dcid len:20
> 000000000001a00183bd407243b7f2011ca86733
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx clearflags:40
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet rx number:52 len:1
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet len:51 via sock
> seq:0 path seq:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic path seq:0 status
> tx:3319325 rx:7668 valid:1 st:2 mtu:1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame rx app ACK n:0
> delay:15 2784-2669
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_handle_ack_frame
> level:3
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion slow start
> win:3379951 ss:-1 if:67887
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic stream id:0x0 ack
> len:1152 fin:0 unacked:64384
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *6 post event 00006741DE771C80
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion slow start
> win:3381151 ss:-1 if:66687
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic stream id:0x0 ack
> len:1152 fin:0 unacked:63232
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion slow start
> win:3382351 ss:-1 if:65487
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic stream id:0x0 ack
> len:1152 fin:0 unacked:62080
>
>
>
> Ещё часть лога с sendmsg:
>
> 024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_add_handshake_data
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> SSL_get_peer_quic_transport_params(): params_len:74
>
> 2024/01/11 21:32:36 [info] 33853#33853: *1 quic unknown transport param
> id:0x11, skipped while handling frames, client: ::1, server: [::]:443
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic transport parameters
> parsed ok
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp disable active
> migration: 0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp idle_timeout:60000
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> max_udp_payload_size:65527
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_data:1310720
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> max_stream_data_bidi_local:131072
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> max_stream_data_bidi_remote:131072
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> max_stream_data_uni:131072
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> initial_max_streams_bidi:262144
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> initial_max_streams_uni:262144
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp ack_delay_exponent:3
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp max_ack_delay:25
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp
> active_connection_id_limit:2
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic tp initial
> source_connection_id len:20 de1e73dcd4e6a4fdc6ecfb38ac840a34922b8517
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign:
> 00006741DE627800:512 @16
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE650000:4096
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 post event 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> ngx_quic_set_encryption_secrets() level:2
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> ngx_quic_add_handshake_data
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE651000:4096
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign:
> 00006741DE627A00:512 @16
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event
> 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> ngx_quic_add_handshake_data
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE652000:4096
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event
> 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> ngx_quic_add_handshake_data
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE653000:4096
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign:
> 00006741DE627C00:512 @16
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event
> 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> ngx_quic_add_handshake_data
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 malloc: 00006741DE654000:4096
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event
> 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_flush_flight()
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic
> ngx_quic_set_encryption_secrets() level:3
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 SSL_do_handshake: -1
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 SSL_get_error: 2
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame rx init PADDING
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic ngx_quic_ack_packet pn:0
> largest -1 fr:0 nranges:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 update posted event
> 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet done rc:0
> level:init decr:1 pn:0 perr:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9:
> 60000:863483412
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9:
> 60000:863483412
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic state: read:60000
> close:60000
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 delete posted event
> 00006741DE6D5608
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic push handler
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 posix_memalign:
> 00006741DE627E00:512 @16
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output init packet
> max:1200 min:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx init ACK n:0
> delay:0 0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx init CRYPTO
> len:123 off:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx init bytes:132
> need_ack:1 number:0 encoded nl:1 trunc:0x0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output hs packet max:1001
> min:1001
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO
> len:163 off:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic split frame now:1403
> need:768 shrink:635
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO
> len:763 off:163
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx hs bytes:935
> need_ack:1 number:0 encoded nl:1 trunc:0x0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmsg: 1200 of 1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:199
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output hs packet max:1200
> min:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO
> len:635 off:926
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic split frame now:525
> need:494 shrink:31
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO
> len:489 off:1561
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx hs bytes:1134
> need_ack:1 number:1 encoded nl:1 trunc:0x1
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmsg: 1200 of 1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2400
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2400
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic output hs packet max:1200
> min:0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:31
> off:2050
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic frame tx hs CRYPTO len:36
> off:2081
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic packet tx hs bytes:75
> need_ack:1 number:2 encoded nl:1 trunc:0x2
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 sendmsg: 141 of 141
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2400
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2541
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic congestion send if:2541
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic path limit 1200 - 1059
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer: 9, old:
> 863483412, new: 863483412
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic lost timer pto:997
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 event timer add: 9:
> 997:863424409
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic state: send:60000 pto:997
> close:60000
>
> 2024/01/11 21:32:36 [debug] 33853#33853: quic recvmsg on [::]:443, ready: 0
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic recvmsg: fd:9 n:1200
>
> 2024/01/11 21:32:36 [debug] 33853#33853: *1 quic input handler
>
>
>
>
>
> Вы писали 11 января 2024 г., 16:59:54:
>
>
>
> 9 раз вызвался ?
> есть подозрение, что произошла ошибка и перешли на sendmsg.
> попробуйте в дебаге, в прилагаемом патче есть ngx_log_debug0(...)
>
>>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240111/41a32a94/attachment-0001.htm>

From izorkin на gmail.com  Thu Jan 11 19:25:21 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 11 Jan 2024 22:25:21 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
Message-ID: <309712388.20240111222521@gmail.com>

Добрый вечер, Илья.

В логах не обнаружил сообщений sendmsg() и sendmmsg().
 
Вы писали 11 января 2024 г., 22:11:56:
 
> я имею в виду вот этот код

> +        if (n == -1) {
> +            err = ngx_errno;
> +
> +            switch (err) {
> +            case NGX_EAGAIN:
> +                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
> +                               "sendmmsg() not ready");
> +
> +                ngx_quic_revert_send(c, ctx, preserved_pnum);
> +
> +                ngx_add_timer(&qc->push, NGX_QUIC_SOCKET_RETRY_DELAY);
> +                return NGX_OK;
> +
> +            case NGX_EINTR:
> +                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
> +                               "sendmmsg() was interrupted");
> +                goto eintr;
> +
> +            default:
+                c->>write->error = 1;
> +                ngx_connection_error(c, err, "sendmsg() failed");
> +                return NGX_ERROR;
> +            }
> +        }

> ну то есть искать либо "sendmmsg()", либо явно поправить ngx_log_debug, чтобы удобнее было искать

> в том, что вы прислали, я не вижу такого патерна

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240111/52a1aa92/attachment.htm>

From chipitsine на gmail.com  Thu Jan 11 20:04:40 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 11 Jan 2024 21:04:40 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <309712388.20240111222521@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
Message-ID: <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>

чт, 11 янв. 2024 г. в 20:25, <izorkin на gmail.com>:

> Добрый вечер, Илья.
>
>
> В логах не обнаружил сообщений sendmsg() и sendmmsg().
>

т.е. все попытки успешны ?
а вот эта часть есть в логах ?

+        ngx_log_debug3(NGX_LOG_DEBUG_EVENT, c->log, 0,
+                       "sendmmsg: %z of %ui msg of size %uz", n, nmsg,
len);


>
>
> Вы писали 11 января 2024 г., 22:11:56:
>
>
>
> я имею в виду вот этот код
>
> +        if (n == -1) {
> +            err = ngx_errno;
> +
> +            switch (err) {
> +            case NGX_EAGAIN:
> +                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
> +                               "sendmmsg() not ready");
> +
> +                ngx_quic_revert_send(c, ctx, preserved_pnum);
> +
> +                ngx_add_timer(&qc->push, NGX_QUIC_SOCKET_RETRY_DELAY);
> +                return NGX_OK;
> +
> +            case NGX_EINTR:
> +                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, err,
> +                               "sendmmsg() was interrupted");
> +                goto eintr;
> +
> +            default:
> +                c->write->error = 1;
> +                ngx_connection_error(c, err, "sendmsg() failed");
> +                return NGX_ERROR;
> +            }
> +        }
>
> ну то есть искать либо "sendmmsg()", либо явно поправить ngx_log_debug,
> чтобы удобнее было искать
>
> в том, что вы прислали, я не вижу такого патерна
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240111/da946c38/attachment.htm>

From izorkin на gmail.com  Thu Jan 11 20:15:14 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Thu, 11 Jan 2024 23:15:14 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
Message-ID: <1173558902.20240111231514@gmail.com>

Добрый вечер, Илья.

Судя по логам все попытки успешны.
Там все сообщения идентичны:
[debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 69087 
...
[debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 70287 
...
[debug] 33853#33853: *1 sendmmsg: 2 of 2 msg of size 84687
...
 
Почти все сообщения sendmmsg: 
Вы писали 11 января 2024 г., 23:04:40:
> т.е. все попытки успешны ?
> а вот эта часть есть в логах ?

> +        ngx_log_debug3(NGX_LOG_DEBUG_EVENT, c->log, 0,
> +                       "sendmmsg: %z of %ui msg of size %uz", n, nmsg, len);

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240111/9dd0bb91/attachment-0001.htm>

From izorkin на gmail.com  Fri Jan 12 07:13:08 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 12 Jan 2024 10:13:08 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
Message-ID: <133525965.20240112101308@gmail.com>

Добрый день, Илья.

Может требуется ещё и поддержка recvmmsg()? Может поэтому
не работает sendmmsg()?

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/e0ec9c10/attachment.htm>

From chipitsine на gmail.com  Fri Jan 12 08:42:43 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 12 Jan 2024 09:42:43 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <133525965.20240112101308@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
Message-ID: <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>

пт, 12 янв. 2024 г. в 08:13, <izorkin на gmail.com>:

> Добрый день, Илья.
>
>
> Может требуется ещё и поддержка recvmmsg()? Может поэтому
>
> не работает sendmmsg()?
>

есть подозрение, что упираетесь вот в это условие (не успевают накопиться 3
пакета)

        if (bytes > len * 3) {
            /* require at least ~3 full packets to batch */
            return 1;
        }


поэтому число вызовов sendmmsg варьируется (то 3, то 9).
попробуйте в это место дебага добавить ?

(еще есть бекдорный вариант, в ngx_quic_allow_segmentation() сделать
безусловный "return 1")


>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/39c7a02c/attachment.htm>

From izorkin на gmail.com  Fri Jan 12 10:29:23 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 12 Jan 2024 13:29:23 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
Message-ID: <17310601316.20240112132923@gmail.com>

Добрый день, Илья.
 
Применил такой патч:
diff --git a/src/event/quic/ngx_event_quic_output.c b/src/event/quic/ngx_event_quic_output.c
index 914d81921..5f3720e7c 100644
--- a/src/event/quic/ngx_event_quic_output.c
+++ b/src/event/quic/ngx_event_quic_output.c
@@ -297,10 +297,7 @@ ngx_quic_allow_segmentation(ngx_connection_t *c)
 
        bytes += f->len;
 
-        if (bytes > len * 3) {
-            /* require at least ~3 full packets to batch */
-            return 1;
-        }
+        return 1;
    }
 
     return 0;
 
Количество вызовов увеличилось до 14:
    615  30.9%  30.9%      615  30.9% __sendmsg
    547  27.5%  58.5%      547  27.5% _aesni_ctr32_ghash_6x
    276  13.9%  72.3%      276  13.9% __libc_pread64
    160  8.0%  80.4%      160  8.0% __memmove_avx_unaligned_erms
      58  2.9%  83.3%      58  2.9% epoll_wait
      39  2.0%  85.3%      39  2.0% __recvmsg
      14  0.7%  86.0%      14  0.7% __sendmmsg
 
Как сделать безусловный "return 1" в ngx_quic_allow_segmentation() не знаю.
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/799997c5/attachment-0001.htm>

From chipitsine на gmail.com  Fri Jan 12 10:34:54 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 12 Jan 2024 11:34:54 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <17310601316.20240112132923@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
 <17310601316.20240112132923@gmail.com>
Message-ID: <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>

On Fri, Jan 12, 2024, 11:29 <izorkin на gmail.com> wrote:

> Добрый день, Илья.
>
>
>
> Применил такой патч:
>
> diff --git a/src/event/quic/ngx_event_quic_output.c
> b/src/event/quic/ngx_event_quic_output.c
>
> index 914d81921..5f3720e7c 100644
>
> --- a/src/event/quic/ngx_event_quic_output.c
>
> +++ b/src/event/quic/ngx_event_quic_output.c
>
> @@ -297,10 +297,7 @@ ngx_quic_allow_segmentation(ngx_connection_t *c)
>
>
>
>         bytes += f->len;
>
>
>
> -        if (bytes > len * 3) {
>
> -            /* require at least ~3 full packets to batch */
>
> -            return 1;
>
> -        }
>
> +        return 1;
>
>     }
>
>
>
>      return 0;
>
>
>
> Количество вызовов увеличилось до 14:
>
>     615  30.9%  30.9%      615  30.9% __sendmsg
>
>     547  27.5%  58.5%      547  27.5% _aesni_ctr32_ghash_6x
>
>     276  13.9%  72.3%      276  13.9% __libc_pread64
>
>     160  8.0%  80.4%      160  8.0% __memmove_avx_unaligned_erms
>
>       58  2.9%  83.3%      58  2.9% epoll_wait
>
>       39  2.0%  85.3%      39  2.0% __recvmsg
>
>       14  0.7%  86.0%      14  0.7% __sendmmsg
>
>
>
> Как сделать безусловный "return 1" в ngx_quic_allow_segmentation() не
> знаю.
>
>
>
"return 1:" первой строчкой в функции




>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/c9d0e913/attachment.htm>

From izorkin на gmail.com  Fri Jan 12 11:03:17 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 12 Jan 2024 14:03:17 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
 <17310601316.20240112132923@gmail.com>
 <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>
Message-ID: <1789065018.20240112140317@gmail.com>

Добрый день, Илья.

Первый вариант патча оказывается не рабочий, забыл применить:
gcc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g  -I src/core -I src/event -I src/event/modules -I src/event/quic -I src/os/unix -I /nix/store/2ysp5ichpc$
        -o objs/src/http/ngx_http_file_cache.o \
        src/http/ngx_http_file_cache.c
src/event/quic/ngx_event_quic_output.c: In function 'ngx_quic_allow_segmentation':
src/event/quic/ngx_event_quic_output.c:249:36: error: variable 'len' set but not used [^[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable$
  249 |     size_t                  bytes, len;
      |                                    ^~~
 
Сработал такой патч:
diff --git a/src/event/quic/ngx_event_quic_output.c b/src/event/quic/ngx_event_quic_output.c
index 914d81921..27efc1950 100644
--- a/src/event/quic/ngx_event_quic_output.c
+++ b/src/event/quic/ngx_event_quic_output.c
@@ -303,7 +303,7 @@ ngx_quic_allow_segmentation(ngx_connection_t *c)
        }
    }
 
-    return 0;
+    return 1;
 }
 
Теперь используется sendmmsg()
    1065  36.0%  36.0%    1065  36.0% _aesni_ctr32_ghash_6x
    1018  34.4%  70.4%    1018  34.4% __sendmmsg
    268  9.1%  79.4%      268  9.1% __libc_pread64
    175  5.9%  85.3%      175  5.9% __memmove_avx_unaligned_erms
      58  2.0%  87.3%      58  2.0% epoll_wait
      48  1.6%  88.9%      48  1.6% __memset_avx2_unaligned_erms
      31  1.0%  90.0%      31  1.0% __recvmsg
      15  0.5%  90.5%      120  4.1% ngx_quic_write_buffer
      12  0.4%  90.9%      12  0.4% aesni_ctr32_encrypt_blocks
      12  0.4%  91.3%      90  3.0% ngx_quic_create_frame
      11  0.4%  91.7%      11  0.4% aesni_encrypt
      8  0.3%  91.9%      24  0.8% EVP_CIPHER_CTX_ctrl
      8  0.3%  92.2%        8  0.3% __strcmp_avx2
 
Но теперь скорость значительно упала, примерно с ~400 Мбайт/сек до ~250.
 
Вроде в настройках сетевой карты gso включен:
tx-gso-robust: off [fixed]
tx-gso-partial: on
tx-gso-list: off [fixed]
 
 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/416de15f/attachment.htm>

From chipitsine на gmail.com  Fri Jan 12 11:59:25 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 12 Jan 2024 12:59:25 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <1789065018.20240112140317@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
 <17310601316.20240112132923@gmail.com>
 <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>
 <1789065018.20240112140317@gmail.com>
Message-ID: <CAFHpkQFDWKo13REH8ekPaDDWxbSqsHHddcL-o5jatrRhATCKCw@mail.gmail.com>

On Fri, Jan 12, 2024, 12:03 <izorkin на gmail.com> wrote:

> Добрый день, Илья.
>
>
> Первый вариант патча оказывается не рабочий, забыл применить:
>
> gcc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror
> -g  -I src/core -I src/event -I src/event/modules -I src/event/quic -I
> src/os/unix -I /nix/store/2ysp5ichpc$
>
>         -o objs/src/http/ngx_http_file_cache.o \
>
>         src/http/ngx_http_file_cache.c
>
> src/event/quic/ngx_event_quic_output.c: In function
> 'ngx_quic_allow_segmentation':
>
> src/event/quic/ngx_event_quic_output.c:249:36: error: variable 'len' set
> but not used [^[]8;;
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable$
>
>   249 |     size_t                  bytes, len;
>
>       |                                    ^~~
>
>
>
> Сработал такой патч:
>
> diff --git a/src/event/quic/ngx_event_quic_output.c
> b/src/event/quic/ngx_event_quic_output.c
>
> index 914d81921..27efc1950 100644
>
> --- a/src/event/quic/ngx_event_quic_output.c
>
> +++ b/src/event/quic/ngx_event_quic_output.c
>
> @@ -303,7 +303,7 @@ ngx_quic_allow_segmentation(ngx_connection_t *c)
>
>         }
>
>     }
>
>
>
> -    return 0;
>
> +    return 1;
>
>  }
>
>
>
> Теперь используется sendmmsg()
>
>     1065  36.0%  36.0%    1065  36.0% _aesni_ctr32_ghash_6x
>
>     1018  34.4%  70.4%    1018  34.4% __sendmmsg
>
>     268  9.1%  79.4%      268  9.1% __libc_pread64
>
>     175  5.9%  85.3%      175  5.9% __memmove_avx_unaligned_erms
>
>       58  2.0%  87.3%      58  2.0% epoll_wait
>
>       48  1.6%  88.9%      48  1.6% __memset_avx2_unaligned_erms
>
>       31  1.0%  90.0%      31  1.0% __recvmsg
>
>       15  0.5%  90.5%      120  4.1% ngx_quic_write_buffer
>
>       12  0.4%  90.9%      12  0.4% aesni_ctr32_encrypt_blocks
>
>       12  0.4%  91.3%      90  3.0% ngx_quic_create_frame
>
>       11  0.4%  91.7%      11  0.4% aesni_encrypt
>
>       8  0.3%  91.9%      24  0.8% EVP_CIPHER_CTX_ctrl
>
>       8  0.3%  92.2%        8  0.3% __strcmp_avx2
>
>
>
> Но теперь скорость значительно упала, примерно с ~400 Мбайт/сек до ~250.
>
>
>

Это ожидаемо, если накапливается 1 пакет, его дорого отправлять через
sendmmsg. Собственно, смысл проверки был в том, чтобы проверить,
действительно ли пакеты (в вашем случае) не успевают накапливаться

Вроде в настройках сетевой карты gso включен:
>
> tx-gso-robust: off [fixed]
>
> tx-gso-partial: on
>
> tx-gso-list: off [fixed]
>
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/d3076215/attachment-0001.htm>

From izorkin на gmail.com  Fri Jan 12 14:16:29 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 12 Jan 2024 17:16:29 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQFDWKo13REH8ekPaDDWxbSqsHHddcL-o5jatrRhATCKCw@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
 <17310601316.20240112132923@gmail.com>
 <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>
 <1789065018.20240112140317@gmail.com>
 <CAFHpkQFDWKo13REH8ekPaDDWxbSqsHHddcL-o5jatrRhATCKCw@mail.gmail.com>
Message-ID: <42263374.20240112171629@gmail.com>

Добрый день, Илья.

Этот метод будет работать при много-поточной загрузке, когда запрашивается
сразу несколько разных файлов?
 
Запустил тест в 2 потока, (запущен только 1 воркер) в итоге
количество вызовов sendmmsg() увеличилось до 27 (без дополнительного патча).
    1361  33.4%  33.4%    1361  33.4% __sendmsg
    1111  27.3%  60.8%    1111  27.3% _aesni_ctr32_ghash_6x
    525  12.9%  73.7%      525  12.9% __libc_pread64
    351  8.6%  82.3%      351  8.6% __memmove_avx_unaligned_erms
      79  1.9%  84.2%      79  1.9% __recvmsg
      38  0.9%  85.2%      239  5.9% ngx_quic_recvmsg
      31  0.8%  85.9%      31  0.8% epoll_wait
      27  0.7%  86.6%      27  0.7% __sendmmsg
 
А вот с протоколом HTTP/1.1 такой трюк не сработал - второй запрос на
скачивание ожидал завершение первого запроса. Не обращал раньше внимания
на эту особенность. При 2-х воркерах тест в 2 потока сработал :)
 
Вы писали 12 января 2024 г., 14:59:25:
 
> Это ожидаемо, если накапливается 1 пакет, его дорого отправлять через sendmmsg. Собственно, смысл проверки был в том, чтобы проверить, действительно ли пакеты (в вашем случае) не успевают накапливаться

 
-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/2ac207cc/attachment.htm>

From chipitsine на gmail.com  Fri Jan 12 15:49:04 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 12 Jan 2024 16:49:04 +0100
Subject: =?UTF-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/?=
 =?UTF-8?B?0YDQuCDQsNC60YLQuNCy0LDRhtC40Lgga1RMUw==?=
In-Reply-To: <42263374.20240112171629@gmail.com>
References: <582023013.20240102235008@gmail.com>
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
 <17310601316.20240112132923@gmail.com>
 <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>
 <1789065018.20240112140317@gmail.com>
 <CAFHpkQFDWKo13REH8ekPaDDWxbSqsHHddcL-o5jatrRhATCKCw@mail.gmail.com>
 <42263374.20240112171629@gmail.com>
Message-ID: <CAFHpkQH24wefpBkUwuArU53H3uLaRwGWO=2pYaXi93DRt1NF6Q@mail.gmail.com>

пт, 12 янв. 2024 г. в 15:16, <izorkin на gmail.com>:

> Добрый день, Илья.
>
>
> Этот метод будет работать при много-поточной загрузке, когда запрашивается
>
> сразу несколько разных файлов?
>
>
>
> Запустил тест в 2 потока, (запущен только 1 воркер) в итоге
>
> количество вызовов sendmmsg() увеличилось до 27 (без дополнительного
> патча).
>
>     1361  33.4%  33.4%    1361  33.4% __sendmsg
>
>     1111  27.3%  60.8%    1111  27.3% _aesni_ctr32_ghash_6x
>
>     525  12.9%  73.7%      525  12.9% __libc_pread64
>
>     351  8.6%  82.3%      351  8.6% __memmove_avx_unaligned_erms
>
>       79  1.9%  84.2%      79  1.9% __recvmsg
>
>       38  0.9%  85.2%      239  5.9% ngx_quic_recvmsg
>
>       31  0.8%  85.9%      31  0.8% epoll_wait
>
>       27  0.7%  86.6%      27  0.7% __sendmmsg
>
>
>
> А вот с протоколом HTTP/1.1 такой трюк не сработал - второй запрос на
>
> скачивание ожидал завершение первого запроса. Не обращал раньше внимания
>
> на эту особенность. При 2-х воркерах тест в 2 потока сработал :)
>

а попробуйте изменить условие на 2 пакета

        if (bytes > len * 3) {
            /* require at least ~3 full packets to batch */
            return 1;
        }


>
>
> Вы писали 12 января 2024 г., 14:59:25:
>
>
>
> Это ожидаемо, если накапливается 1 пакет, его дорого отправлять через
> sendmmsg. Собственно, смысл проверки был в том, чтобы проверить,
> действительно ли пакеты (в вашем случае) не успевают накапливаться
>
>
>
> --
> С уважением,
>  Izorkin                          mailto:izorkin на gmail.com
> <izorkin на gmail.com>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/b1c502ea/attachment.htm>

From izorkin на gmail.com  Fri Jan 12 16:41:25 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 12 Jan 2024 19:41:25 +0300
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?=
 =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?=
In-Reply-To: <CAFHpkQH24wefpBkUwuArU53H3uLaRwGWO=2pYaXi93DRt1NF6Q@mail.gmail.com>
References: <582023013.20240102235008@gmail.com> 
 <CAFHpkQEK3W28A+2nVC2XA+rket8tWJF14imJCTK5kFhsRMKe7w@mail.gmail.com>
 <344095917.20240104152419@gmail.com>
 <CAFHpkQEcj+NCGPrPTZ6DPdD-Ly-SFK==K0Sq7dFp9eRyq7-kCg@mail.gmail.com>
 <1368454677.20240104190431@gmail.com>
 <20240108120818.mpipvt56ab6myjku@N00W24XTQX>
 <10410669466.20240108161751@gmail.com>
 <CAFHpkQHF5r5K8AMawf_wkThwPNDUCTmK8xk_gkLUce=ni-j=3A@mail.gmail.com>
 <1648601044.20240111215953@gmail.com>
 <CAFHpkQEwGMRfZR=v=9jE+SvavqBjw5NABbVi_BM46DTA6r64ug@mail.gmail.com>
 <309712388.20240111222521@gmail.com>
 <CAFHpkQE_=3PAiPjATLX5FZJxQ8ZBDtH8keGGtNZAv+=9vvzaQg@mail.gmail.com>
 <133525965.20240112101308@gmail.com>
 <CAFHpkQGZUhduDTmu9LW4vbSCnwYymx-MUMeFvOaQ8Z6V+fFSwQ@mail.gmail.com>
 <17310601316.20240112132923@gmail.com>
 <CAFHpkQHH61CEsTVXfxmOFoNRid_0yKWf=86omTmNrg03Ehxs+Q@mail.gmail.com>
 <1789065018.20240112140317@gmail.com>
 <CAFHpkQFDWKo13REH8ekPaDDWxbSqsHHddcL-o5jatrRhATCKCw@mail.gmail.com>
 <42263374.20240112171629@gmail.com>
 <CAFHpkQH24wefpBkUwuArU53H3uLaRwGWO=2pYaXi93DRt1NF6Q@mail.gmail.com>
Message-ID: <355362568.20240112194125@gmail.com>

Добрый вечер, Илья.
 
При условии в 2 пакета и 1 скачивание файла:
    614  29.6%  29.6%      614  29.6% __sendmsg
    551  26.6%  56.2%      551  26.6% _aesni_ctr32_ghash_6x
    298  14.4%  70.6%      298  14.4% __libc_pread64
    198  9.6%  80.2%      198  9.6% __memmove_avx_unaligned_erms
      65  3.1%  83.3%      65  3.1% epoll_wait
      39  1.9%  85.2%      39  1.9% __recvmsg
      16  0.8%  86.0%      114  5.5% ngx_quic_create_frame
      12  0.6%  86.5%      133  6.4% ngx_quic_recvmsg
      11  0.5%  87.1%      16  0.8% CRYPTO_gcm128_encrypt_ctr32
      10  0.5%  87.5%      10  0.5% __sendmmsg
 
При условии в 2 пакета и 2 скачивания файла:
    1222  31.9%  31.9%    1222  31.9% __sendmsg
    1072  28.0%  59.9%    1072  28.0% _aesni_ctr32_ghash_6x
    523  13.7%  73.6%      523  13.7% __libc_pread64
    413  10.8%  84.3%      413  10.8% __memmove_avx_unaligned_erms
      66  1.7%  86.1%      66  1.7% __recvmsg
      33  0.9%  86.9%      33  0.9% epoll_wait
      31  0.8%  87.7%      221  5.8% ngx_quic_create_frame
      31  0.8%  88.5%      218  5.7% ngx_quic_recvmsg
      20  0.5%  89.1%      20  0.5% __sendmmsg
 
При условии в 3 пакета и 1 скачивание файла:
    663  31.4%  31.4%      663  31.4% __sendmsg
    556  26.3%  57.7%      556  26.3% _aesni_ctr32_ghash_6x
    278  13.2%  70.9%      278  13.2% __libc_pread64
    205  9.7%  80.6%      205  9.7% __memmove_avx_unaligned_erms
      45  2.1%  82.8%      45  2.1% epoll_wait
      39  1.8%  84.6%      39  1.8% __recvmsg
      16  0.8%  85.4%      16  0.8% aesni_ctr32_encrypt_blocks
      12  0.6%  85.9%      123  5.8% ngx_quic_write_buffer
      11  0.5%  86.5%      11  0.5% __sendmmsg
 
При условии в 3 пакета и 2 скачивания файла:
    1212  31.2%  31.2%    1212  31.2% __sendmsg
    1111  28.6%  59.8%    1111  28.6% _aesni_ctr32_ghash_6x
    572  14.7%  74.5%      572  14.7% __libc_pread64
    361  9.3%  83.8%      361  9.3% __memmove_avx_unaligned_erms
      76  2.0%  85.8%      76  2.0% __recvmsg
      28  0.7%  86.5%      226  5.8% ngx_quic_recvmsg
      24  0.6%  87.1%      24  0.6% epoll_wait
      23  0.6%  87.7%      23  0.6% gcm_ghash_avx
      19  0.5%  88.2%      181  4.7% ngx_quic_create_frame
      18  0.5%  88.6%      18  0.5% __sendmmsg
 

-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240112/3882aab3/attachment-0001.htm>

From izorkin на gmail.com  Fri Jan 12 19:35:38 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Fri, 12 Jan 2024 22:35:38 +0300
Subject: =?utf-8?B?UmU6INCf0LDRgtGHIEVUYWdzINCyIE5peE9T?=
In-Reply-To: <ZZyuwP78wlw8KIxM@mdounin.ru>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com> <ZZyuwP78wlw8KIxM@mdounin.ru>
Message-ID: <433328107.20240112223538@gmail.com>

Добрый вечер, Максим.

Вы писали 9 января 2024 г., 5:26:08:

> Что до nix store, то кажется, что возвращение размера в ETag также 
> должно проблему решить.

В том то и дело, что размер не всегда меняется.


> Полный путь к файлу в ETag точно не имеет смысла.  Более того, его 
> там быть точно не должно: если вдруг ресурс обслуживается двумя 
> разными origin-серверами, это приведёт к требованию совпадения 
> путей к файлу на этих серверах, а при их несовпадении - 
> соответственно к полным ответам вместе 304, то есть сломает 
> кэширование там, где оно сейчас работает.

Не подумал о таком варианте использования.


> Теоретически, наверное, можно пытаться в ETag вставлять какой-то 
> идентификатор представления, то если для gzip_static добавлять в 
> ETag что-нибудь вроде "...-gz".  Но при наличии размера в том же 
> ETag'е смысла в этом исчезающие мало.

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


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From mdounin на mdounin.ru  Sat Jan 13 00:28:36 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 13 Jan 2024 03:28:36 +0300
Subject: =?koi8-r?B?8MHU3iBFVGFncyDX?= NixOS
In-Reply-To: <433328107.20240112223538@gmail.com>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com> <ZZyuwP78wlw8KIxM@mdounin.ru>
 <433328107.20240112223538@gmail.com>
Message-ID: <ZaHZNJ0yCZvmpRG4@mdounin.ru>

Hello!

On Fri, Jan 12, 2024 at 10:35:38PM +0300, izorkin на gmail.com wrote:

> Вы писали 9 января 2024 г., 5:26:08:
> 
> > Что до nix store, то кажется, что возвращение размера в ETag также 
> > должно проблему решить.
> 
> В том то и дело, что размер не всегда меняется.

Дата модификации и размер - на практике достаточная комбинация для 
отслеживания версий файлов и их различных представлений, по 
крайней мере в рамках тех представлений файлов, которые умеет 
возвращать nginx (исходный файл и его gzip-версия).

В nix store, в силу отказа от времени, время надо на что-то заменять, 
как минимум в ситуациях, когда полных путь, включающих store hash, 
не фигурирует в URL'е.  Но это ортогональный вопрос (и скорее 
вопрос к самой концепции, которая получилась не очень совместимой 
с HTTP).

> > Теоретически, наверное, можно пытаться в ETag вставлять какой-то 
> > идентификатор представления, то если для gzip_static добавлять в 
> > ETag что-нибудь вроде "...-gz".  Но при наличии размера в том же 
> > ETag'е смысла в этом исчезающие мало.
> 
> А вариант добавить вычисления простой хэш суммы при условии, что дата
> равно нулю - размер файла + хэш сумма.
> Теоретически на остальное не должно повлиять.

Hash-сумма файла в качестве ETag - в целом отличное решение, 
проблема тут ровно одна: её нужно как-то получить, ибо системный 
вызов fstat() никаких hash-сумм почему-то не возвращает.  Считать 
на лету - очевидно, плохой вариант для нагруженного сервера, так 
как файл придётся на каждый запрос читать дважды.  А получать 
hash-сумму откуда-то ещё, скажем из внешнего файла или 
extended-атрибутов - выглядит в лучшем случае дополнительной фичей 
(смотри https://trac.nginx.org/nginx/ticket/2351 например).

-- 
Maxim Dounin
http://mdounin.ru/

From izorkin на gmail.com  Sat Jan 13 07:34:08 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 13 Jan 2024 10:34:08 +0300
Subject: =?utf-8?B?UmU6INCf0LDRgtGHIEVUYWdzINCyIE5peE9T?=
In-Reply-To: <ZaHZNJ0yCZvmpRG4@mdounin.ru>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com> <ZZyuwP78wlw8KIxM@mdounin.ru>
 <433328107.20240112223538@gmail.com> <ZaHZNJ0yCZvmpRG4@mdounin.ru>
Message-ID: <1524223696.20240113103408@gmail.com>

Добрый день, Максим.

Вы писали 13 января 2024 г., 3:28:36:

> Hello!

> Hash-сумма файла в качестве ETag - в целом отличное решение, 
> проблема тут ровно одна: её нужно как-то получить, ибо системный 
> вызов fstat() никаких hash-сумм почему-то не возвращает.  Считать 
> на лету - очевидно, плохой вариант для нагруженного сервера, так 
> как файл придётся на каждый запрос читать дважды.  А получать 
> hash-сумму откуда-то ещё, скажем из внешнего файла или 
> extended-атрибутов - выглядит в лучшем случае дополнительной фичей 
> (смотри https://trac.nginx.org/nginx/ticket/2351 например).

Теоретически можно было бы сделать предварительное сканирование
файлов и генерация хэш сумм при старте в фоновом режиме, для тех
файлов, которыее расположены только в /nix/store или любой другой
директории, указанной пользователем. А результаты сохранить в кеш.

Если генерировать хэш-сумму на лету, то зачем надо генерировать её
каждый раз при повторном запросе? Можно же в кэше результат сохранить.
Да и это надо делать только для тех файлов, которые имеют нулевую дату.
А файлы в /nix/store меняются не часто, только при обновлении ОС.

Вариант с файлами хэш-сумм выглядит более оптимальным. При генерации
файлов в /nix/store можно дополнительно добавить возможность генерации
хэш-суммы для каждого файла, который требуется для работы сайта. Таким
же способом в некоторых приложениях организована генерация статических
файлов в gzip и brotli форматы.


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From mdounin на mdounin.ru  Sat Jan 13 13:21:12 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 13 Jan 2024 16:21:12 +0300
Subject: =?koi8-r?B?8MHU3iBFVGFncyDX?= NixOS
In-Reply-To: <1524223696.20240113103408@gmail.com>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com> <ZZyuwP78wlw8KIxM@mdounin.ru>
 <433328107.20240112223538@gmail.com> <ZaHZNJ0yCZvmpRG4@mdounin.ru>
 <1524223696.20240113103408@gmail.com>
Message-ID: <ZaKOSCPwkT7IVORE@mdounin.ru>

Hello!

On Sat, Jan 13, 2024 at 10:34:08AM +0300, izorkin на gmail.com wrote:

> Добрый день, Максим.
> 
> Вы писали 13 января 2024 г., 3:28:36:
> 
> > Hello!
> 
> > Hash-сумма файла в качестве ETag - в целом отличное решение, 
> > проблема тут ровно одна: её нужно как-то получить, ибо системный 
> > вызов fstat() никаких hash-сумм почему-то не возвращает.  Считать 
> > на лету - очевидно, плохой вариант для нагруженного сервера, так 
> > как файл придётся на каждый запрос читать дважды.  А получать 
> > hash-сумму откуда-то ещё, скажем из внешнего файла или 
> > extended-атрибутов - выглядит в лучшем случае дополнительной фичей 
> > (смотри https://trac.nginx.org/nginx/ticket/2351 например).
> 
> Теоретически можно было бы сделать предварительное сканирование
> файлов и генерация хэш сумм при старте в фоновом режиме, для тех
> файлов, которыее расположены только в /nix/store или любой другой
> директории, указанной пользователем. А результаты сохранить в кеш.
> 
> Если генерировать хэш-сумму на лету, то зачем надо генерировать её
> каждый раз при повторном запросе? Можно же в кэше результат сохранить.
> Да и это надо делать только для тех файлов, которые имеют нулевую дату.
> А файлы в /nix/store меняются не часто, только при обновлении ОС.

Всё это предполагает какой-то кэш, который надо как-то отдельно 
делать и конфигурировать, и выглядит в лучшем случае 
дополнительной фичей.

> Вариант с файлами хэш-сумм выглядит более оптимальным. При генерации
> файлов в /nix/store можно дополнительно добавить возможность генерации
> хэш-суммы для каждого файла, который требуется для работы сайта. Таким
> же способом в некоторых приложениях организована генерация статических
> файлов в gzip и brotli форматы.

Именно об этом и тикет, да.  Мне тоже вариант с файлами кажется 
более интересным - с extended-атрибутами, возможно, код будет чуть 
проще и, вероятно, быстрее, в силу меньшего количества необходимых 
системных вызовов, но там сразу возникает масса проблем как с 
портабельностью, так и с хранением/синхронизацией (e.g., в том же 
nix store они могут просто не работать).

-- 
Maxim Dounin
http://mdounin.ru/

From izorkin на gmail.com  Sat Jan 13 15:01:26 2024
From: izorkin на gmail.com (izorkin на gmail.com)
Date: Sat, 13 Jan 2024 18:01:26 +0300
Subject: =?utf-8?B?UmU6INCf0LDRgtGHIEVUYWdzINCyIE5peE9T?=
In-Reply-To: <ZaKOSCPwkT7IVORE@mdounin.ru>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com> <ZZyuwP78wlw8KIxM@mdounin.ru>
 <433328107.20240112223538@gmail.com> <ZaHZNJ0yCZvmpRG4@mdounin.ru>
 <1524223696.20240113103408@gmail.com> <ZaKOSCPwkT7IVORE@mdounin.ru>
Message-ID: <167191757.20240113180126@gmail.com>

Добрый день, Максим.

Вы писали 13 января 2024 г., 16:21:12:

> Именно об этом и тикет, да.  Мне тоже вариант с файлами кажется 
> более интересным - с extended-атрибутами, возможно, код будет чуть 
> проще и, вероятно, быстрее, в силу меньшего количества необходимых 
> системных вызовов, но там сразу возникает масса проблем как с 
> портабельностью, так и с хранением/синхронизацией (e.g., в том же 
> nix store они могут просто не работать).

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

Мне предполагается такой вариант, что надо добавить дополнительный
параметр, при включении которого в блоке location Nginx начинает искать
дополнительные файлы по расширению (например .crc) при запросе основного
файла. Если доп. файл отсутствует, то использовать существующую логику
работы с ETags, а если есть - применить на основе доп. файла.
При активном параметре и отсутствии дополнительного файла выводить в
лог предупреждение, чтобы пользователь самостоятельно добавил
необходимые файлы.
А при отключенном параметре вообще игнорировать дополнительные файлы
с crc или ETags.
Можно ещё добавить параметры, которые позволяют указать расширение
для дополнительных файлов и метод использования этих файлов - на основе
hash-суммы (crc, md5, sha и т.п.), либо прямое указание ETags. Но с
последним вариантом мне кажется может возникнуть проблемы, например,
если пользователь обновит основной файл, а дополнительный забудет.


-- 
С уважением,
 Izorkin                          mailto:izorkin на gmail.com

From alexcool на gmail.com  Mon Jan 15 02:00:09 2024
From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=)
Date: Mon, 15 Jan 2024 09:00:09 +0700
Subject: fastcgi/proxy cache disk read size
Message-ID: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>

Приветствую.

Использую fastcgi proxy с кэшом, расположенном на NFS шаре. Кэшируемые
файлы размером около 250К.

Вывод команды mountstats показывает, что операции READ получают в
среднем 54К байт, а операции WRITE отправляют в среднем 220К байт.

Получается, что когда nginx пишет файлы, то делает это за один вызов
write, а когда читает, то за несколько вызовов read. Можно ли сделать
так, чтобы файлы читались за один вызов read.

Это важно в связи с тем что используются HDD диски и каждый IO
приводит к перемещению головки.

Всем добра.

From mdounin на mdounin.ru  Mon Jan 15 17:04:05 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 15 Jan 2024 20:04:05 +0300
Subject: fastcgi/proxy cache disk read size
In-Reply-To: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>
References: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>
Message-ID: <ZaVlhSCqvsGH_yBm@mdounin.ru>

Hello!

On Mon, Jan 15, 2024 at 09:00:09AM +0700, Алексей wrote:

> Приветствую.
> 
> Использую fastcgi proxy с кэшом, расположенном на NFS шаре. Кэшируемые
> файлы размером около 250К.

Традиционно отмечу, что раздавать данные nginx'ом с NFS (а тем 
более держать там кэш) - не лучшая идея.  Если что-либо случится с 
сетью до NFS-сервера и/или NFS-сервером - nginx просто 
заблокируется, пытаясь читать данные с NFS, и не будет обслуживать 
вообще никакие запросы.  Ну и любая операция с NFS-сервером - это 
опять же заблокированный nginx, то есть даже когда всё хорошо - 
любые задержки операций на NFS-сервере будут приводить к 
увеличению latency для всех запросов.  Лучше размещать nginx 
непосредственно там, где диски, не вводя дополнительных точке 
отказа.

> Вывод команды mountstats показывает, что операции READ получают в
> среднем 54К байт, а операции WRITE отправляют в среднем 220К байт.
> 
> Получается, что когда nginx пишет файлы, то делает это за один вызов
> write, а когда читает, то за несколько вызовов read. Можно ли сделать
> так, чтобы файлы читались за один вызов read.
> 
> Это важно в связи с тем что используются HDD диски и каждый IO
> приводит к перемещению головки.

При чтении кэша файлы читаются в два этапа:

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

- Потом тело ответа отдаётся точно так же, как и любой статический 
  файл.

Если файлы всегда отдаются целиком, то в идеале нужно, чтобы 
система при чтении заголовка сразу прочитала и тело, а потом 
вернула это nginx'у из кэша.

Управления желаемым поведением системы есть ручка read_ahead 
(http://nginx.org/r/read_ahead), но полноценно работать она будет 
только на FreeBSD, где есть fcntl(F_READAHEAD), а на линуксе 
выльется в posix_fadvise(POSIX_FADV_SEQUENTIAL) - что, конечно, 
полезно, но в любом случае потребует дополнительного тюнинга 
собственно системы.

Кроме того, можно постараться улучшить работу с телом ответа 
внутри nginx'а.  Если используется sendfile(), то тут особо ничего 
не сделаешь, ибо в этом случае работой с файлами занимается 
система.  Но если sendfile() не используется (или из-за SSL, или 
просто выключен в конфиге nginx'а), то nginx читает файлы с 
помощью output_buffers (http://nginx.org/r/output_buffers).  
Соответственно для того, чтобы операции чтения были большие - 
нужно использовать буфера соответствующего размера.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Mon Jan 15 17:22:56 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 15 Jan 2024 20:22:56 +0300
Subject: =?koi8-r?B?8MHU3iBFVGFncyDX?= NixOS
In-Reply-To: <167191757.20240113180126@gmail.com>
References: <441659217.20231119161542@gmail.com> <ZVrLBNBCrKdfI9tU@mdounin.ru>
 <994095771.20240107095745@gmail.com> <ZZyuwP78wlw8KIxM@mdounin.ru>
 <433328107.20240112223538@gmail.com> <ZaHZNJ0yCZvmpRG4@mdounin.ru>
 <1524223696.20240113103408@gmail.com> <ZaKOSCPwkT7IVORE@mdounin.ru>
 <167191757.20240113180126@gmail.com>
Message-ID: <ZaVp8Is5q-4g2AbW@mdounin.ru>

Hello!

On Sat, Jan 13, 2024 at 06:01:26PM +0300, izorkin на gmail.com wrote:

> Добрый день, Максим.
> 
> Вы писали 13 января 2024 г., 16:21:12:
> 
> > Именно об этом и тикет, да.  Мне тоже вариант с файлами кажется 
> > более интересным - с extended-атрибутами, возможно, код будет чуть 
> > проще и, вероятно, быстрее, в силу меньшего количества необходимых 
> > системных вызовов, но там сразу возникает масса проблем как с 
> > портабельностью, так и с хранением/синхронизацией (e.g., в том же 
> > nix store они могут просто не работать).
> 
> Имеется в виду синхронизация дополнительных файлов между основным
> и кэширующим сервером? Мне кажется, что если основной сервер
> предоставит необходимый ETags, тогда синхронизация не потребуется.

Имеется в виду, что если файловое хранилище копируется и/или 
синхронизируется между серверами, с помощью какого-нибудь scp или 
rsync, или просто перекладывается в соседнюю папку с помощью cp, 
то забыть необходимые флаги для копирования extended-атрибутов - 
куда проще, чем забыть скопировать дополнительные файлы.

В случае полноценного HTTP-кэширования, понятно, никаких проблем 
не будет, так как ETag, полученный от исходного сервера, будет 
сохранён вместе с заголовками ответа.  (Ну а в случае proxy_store, 
где заголовки не сохраняются, проблемы с будут с любыми кастомными 
ETag'ами.)

-- 
Maxim Dounin
http://mdounin.ru/

From alexcool на gmail.com  Tue Jan 16 05:43:47 2024
From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=)
Date: Tue, 16 Jan 2024 12:43:47 +0700
Subject: fastcgi/proxy cache disk read size
In-Reply-To: <ZaVlhSCqvsGH_yBm@mdounin.ru>
References: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>
 <ZaVlhSCqvsGH_yBm@mdounin.ru>
Message-ID: <CAPrvZET0T0GHfgc+3Eirwh51uijZBin7DEOyyDA9AZSz2_Efxw@mail.gmail.com>

Здравствуйте.

Благодарю за подробный ответ. Не знал, что кэш файлы читаются в два этапа.
Что если выставить fastcgi_buffer_size 512k? Весь файл читается в этот
буфер тогда?

С наилучшими пожеланиями.
Алексей.

On Tue, Jan 16, 2024 at 12:04 AM Maxim Dounin <mdounin на mdounin.ru> wrote:
>
> Hello!
>
> On Mon, Jan 15, 2024 at 09:00:09AM +0700, Алексей wrote:
>
> > Приветствую.
> >
> > Использую fastcgi proxy с кэшом, расположенном на NFS шаре. Кэшируемые
> > файлы размером около 250К.
>
> Традиционно отмечу, что раздавать данные nginx'ом с NFS (а тем
> более держать там кэш) - не лучшая идея.  Если что-либо случится с
> сетью до NFS-сервера и/или NFS-сервером - nginx просто
> заблокируется, пытаясь читать данные с NFS, и не будет обслуживать
> вообще никакие запросы.  Ну и любая операция с NFS-сервером - это
> опять же заблокированный nginx, то есть даже когда всё хорошо -
> любые задержки операций на NFS-сервере будут приводить к
> увеличению latency для всех запросов.  Лучше размещать nginx
> непосредственно там, где диски, не вводя дополнительных точке
> отказа.
>
> > Вывод команды mountstats показывает, что операции READ получают в
> > среднем 54К байт, а операции WRITE отправляют в среднем 220К байт.
> >
> > Получается, что когда nginx пишет файлы, то делает это за один вызов
> > write, а когда читает, то за несколько вызовов read. Можно ли сделать
> > так, чтобы файлы читались за один вызов read.
> >
> > Это важно в связи с тем что используются HDD диски и каждый IO
> > приводит к перемещению головки.
>
> При чтении кэша файлы читаются в два этапа:
>
> - Сначала отдельной операцией чтения читается заголовок, в котором
>   хранятся метаданные и заголовок ответа.
>
> - Потом тело ответа отдаётся точно так же, как и любой статический
>   файл.
>
> Если файлы всегда отдаются целиком, то в идеале нужно, чтобы
> система при чтении заголовка сразу прочитала и тело, а потом
> вернула это nginx'у из кэша.
>
> Управления желаемым поведением системы есть ручка read_ahead
> (http://nginx.org/r/read_ahead), но полноценно работать она будет
> только на FreeBSD, где есть fcntl(F_READAHEAD), а на линуксе
> выльется в posix_fadvise(POSIX_FADV_SEQUENTIAL) - что, конечно,
> полезно, но в любом случае потребует дополнительного тюнинга
> собственно системы.
>
> Кроме того, можно постараться улучшить работу с телом ответа
> внутри nginx'а.  Если используется sendfile(), то тут особо ничего
> не сделаешь, ибо в этом случае работой с файлами занимается
> система.  Но если sendfile() не используется (или из-за SSL, или
> просто выключен в конфиге nginx'а), то nginx читает файлы с
> помощью output_buffers (http://nginx.org/r/output_buffers).
> Соответственно для того, чтобы операции чтения были большие -
> нужно использовать буфера соответствующего размера.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin на mdounin.ru  Tue Jan 16 23:13:01 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 17 Jan 2024 02:13:01 +0300
Subject: fastcgi/proxy cache disk read size
In-Reply-To: <CAPrvZET0T0GHfgc+3Eirwh51uijZBin7DEOyyDA9AZSz2_Efxw@mail.gmail.com>
References: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>
 <ZaVlhSCqvsGH_yBm@mdounin.ru>
 <CAPrvZET0T0GHfgc+3Eirwh51uijZBin7DEOyyDA9AZSz2_Efxw@mail.gmail.com>
Message-ID: <ZacNfeTAtVAU1iFR@mdounin.ru>

Hello!

On Tue, Jan 16, 2024 at 12:43:47PM +0700, Алексей wrote:

> Благодарю за подробный ответ. Не знал, что кэш файлы читаются в два этапа.
> Что если выставить fastcgi_buffer_size 512k? Весь файл читается в этот
> буфер тогда?

Нет, nginx отслеживает размер заголовков в элементах кэша и хранит 
эту информацию в keys_zone.  Соответственно при чтении заголовков 
читаются только данные заголовков.

Так сделано, потому как данные тела в общем случае могут быть 
вообще не нужны (или нужны не целиком, или не нужны в 
пользовательской памяти): для HEAD-запросов, для запросов с 
If-Modified-Since, на которые nginx вернёт 304, и так далее.

-- 
Maxim Dounin
http://mdounin.ru/

From alexcool на gmail.com  Wed Jan 17 03:43:10 2024
From: alexcool на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lk=?=)
Date: Wed, 17 Jan 2024 10:43:10 +0700
Subject: fastcgi/proxy cache disk read size
In-Reply-To: <ZacNfeTAtVAU1iFR@mdounin.ru>
References: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>
 <ZaVlhSCqvsGH_yBm@mdounin.ru>
 <CAPrvZET0T0GHfgc+3Eirwh51uijZBin7DEOyyDA9AZSz2_Efxw@mail.gmail.com>
 <ZacNfeTAtVAU1iFR@mdounin.ru>
Message-ID: <CAPrvZESnJ6NxWn6qXLn75Cm-U66M_fMo4jq6AWgGhkN3f7VBbw@mail.gmail.com>

Здравствуйте.

Я все таки попробовал и количество READ запросов по NFS упало вдвое.
Средний размер дискового чтения увеличился где то на 20% и на столько
же уменьшилось количество IO на диске.

Однако, при таком большом размере fastcgi_buffer_size при рестарте
nginxа, на сколько я понимаю, cache loader фактически загрузит все
файлы целиком для заполнения key_zone.

С наилучшими пожеланиями.
Алексей.

On Wed, Jan 17, 2024 at 6:13 AM Maxim Dounin <mdounin на mdounin.ru> wrote:
>
> Hello!
>
> On Tue, Jan 16, 2024 at 12:43:47PM +0700, Алексей wrote:
>
> > Благодарю за подробный ответ. Не знал, что кэш файлы читаются в два этапа.
> > Что если выставить fastcgi_buffer_size 512k? Весь файл читается в этот
> > буфер тогда?
>
> Нет, nginx отслеживает размер заголовков в элементах кэша и хранит
> эту информацию в keys_zone.  Соответственно при чтении заголовков
> читаются только данные заголовков.
>
> Так сделано, потому как данные тела в общем случае могут быть
> вообще не нужны (или нужны не целиком, или не нужны в
> пользовательской памяти): для HEAD-запросов, для запросов с
> If-Modified-Since, на которые nginx вернёт 304, и так далее.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin на mdounin.ru  Wed Jan 17 05:42:47 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 17 Jan 2024 08:42:47 +0300
Subject: fastcgi/proxy cache disk read size
In-Reply-To: <CAPrvZESnJ6NxWn6qXLn75Cm-U66M_fMo4jq6AWgGhkN3f7VBbw@mail.gmail.com>
References: <CAPrvZEQFUcJuXs5GmLdS9f1+FVAnZtMqKh0N7V45gdWhGb586A@mail.gmail.com>
 <ZaVlhSCqvsGH_yBm@mdounin.ru>
 <CAPrvZET0T0GHfgc+3Eirwh51uijZBin7DEOyyDA9AZSz2_Efxw@mail.gmail.com>
 <ZacNfeTAtVAU1iFR@mdounin.ru>
 <CAPrvZESnJ6NxWn6qXLn75Cm-U66M_fMo4jq6AWgGhkN3f7VBbw@mail.gmail.com>
Message-ID: <Zado1xYm6vFh4YKz@mdounin.ru>

Hello!

On Wed, Jan 17, 2024 at 10:43:10AM +0700, Алексей wrote:

> Я все таки попробовал и количество READ запросов по NFS упало вдвое.
> Средний размер дискового чтения увеличился где то на 20% и на столько
> же уменьшилось количество IO на диске.
> 
> Однако, при таком большом размере fastcgi_buffer_size при рестарте
> nginxа, на сколько я понимаю, cache loader фактически загрузит все
> файлы целиком для заполнения key_zone.

Размер fastcgi_buffer_size влияет на размер чтения заголовков из 
файла кэша, если в зоне разделяемой памяти информации о размере 
заголовков нет.  Соответственно после перезапуска nginx'а при 
первом обращении к соответствующему файлу в кэше заголовки будут 
читать с буфером размером fastcgi_buffer_size, а при последующих 
обращениях nginx уже будет знать размер заголовков в файле кэша и 
будет читать только их.

Что до cache loader'а, то он вообще сейчас не читает файлы кэша, 
только составляет их список (до nginx 1.1.0 было по другому, но 
с тех пор прошло уже больше 10 лет).

-- 
Maxim Dounin
http://mdounin.ru/

From anatoliy.melnik на showjet.ru  Wed Jan 17 11:49:30 2024
From: anatoliy.melnik на showjet.ru (Anatoliy Melnik)
Date: Wed, 17 Jan 2024 14:49:30 +0300 (MSK)
Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YHQutC+0LvRjNC60L4g0YHQvtC+0LHRidC1?=
 =?utf-8?B?0L3QuNC5INCyIGxvZyBzeXNsb2cg0LHQtdC3INC/0L7RgtC10YDRjD8=?=
Message-ID: <1085601894.60147583.1705492170913.JavaMail.zimbra@showjet.ru>

Здравствуйте. 
Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам. 
Логи льются в syslog (слив в файлы напрямую из nginx не желателен). 
По косвенным методам контроля вылезла проблема: 
До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog фиксирует меньше событий, чем сумма по бекэндам. 
Чем выше интенсивность запросов, тем больше расходятся данные. 
Сначала грешил на syslog, но детальные разборы полетов говорят, что скорее всего проблема в nginx. 
У кого-то что-то такое наблюдалось или нет? 
При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. скорее всего syslog не виноват. 
Кто-то с таким сталкивался? 
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240117/6232fe8c/attachment.htm>

From chipitsine на gmail.com  Wed Jan 17 12:31:49 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 17 Jan 2024 13:31:49 +0100
Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?=
 =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <1085601894.60147583.1705492170913.JavaMail.zimbra@showjet.ru>
References: <1085601894.60147583.1705492170913.JavaMail.zimbra@showjet.ru>
Message-ID: <CAFHpkQG0iCOiaO5hZv4xwXsL949+5c9JMm9CFTXp2uv7dMqT+A@mail.gmail.com>

ср, 17 янв. 2024 г. в 12:49, Anatoliy Melnik via nginx-ru <
nginx-ru на nginx.org>:

> Здравствуйте.
> Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам.
> Логи льются в syslog (слив в файлы напрямую из nginx не желателен).
> По косвенным методам контроля вылезла проблема:
> До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а
> вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog
> фиксирует меньше событий, чем сумма по бекэндам.
> Чем выше интенсивность запросов, тем больше расходятся данные.
> Сначала грешил на syslog, но детальные разборы полетов говорят, что скорее
> всего проблема в nginx.
>

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


> У кого-то что-то такое наблюдалось или нет?
> При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно
> 100тыс/сек, т.е. скорее всего syslog не виноват.
> Кто-то с таким сталкивался?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240117/3f4f4e3d/attachment.htm>

From mdounin на mdounin.ru  Wed Jan 17 17:02:55 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 17 Jan 2024 20:02:55 +0300
Subject: =?koi8-r?B?9MXT1CBuZ2lueCAtLSDTy8/M?=
 =?koi8-r?B?2MvPINPPz8Ldxc7JyiDXIGxvZyBzeXNsb2cgwsXaINDP1MXS2D8=?=
In-Reply-To: <1085601894.60147583.1705492170913.JavaMail.zimbra@showjet.ru>
References: <1085601894.60147583.1705492170913.JavaMail.zimbra@showjet.ru>
Message-ID: <ZagIP0Iuqie06yVl@mdounin.ru>

Hello!

On Wed, Jan 17, 2024 at 02:49:30PM +0300, Anatoliy Melnik via nginx-ru wrote:

> Здравствуйте.  Есть nginx-ы, несколько разных версий. Проксируют 
> запросы к бекэндам.  Логи льются в syslog (слив в файлы напрямую 
> из nginx не желателен).  По косвенным методам контроля вылезла 
> проблема: До примерно 50 тыс/сек сообщений статистика прокси и 
> бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются 
> расхождения. nginx->syslog фиксирует меньше событий, чем сумма 
> по бекэндам.  Чем выше интенсивность запросов, тем больше 
> расходятся данные.  Сначала грешил на syslog, но детальные 
> разборы полетов говорят, что скорее всего проблема в nginx.  У 
> кого-то что-то такое наблюдалось или нет?  При сливе логов с 2-х 
> nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. 
> скорее всего syslog не виноват.  Кто-то с таким сталкивался? 

Запись логов в syslog - не гарантирует доставку всех сообщений.  
Если syslog-сервер не справляется или есть проблемы с сетью между 
nginx'ом и syslog-сервером - сообщения будут просто осыпаться на 
пол. (Где-то тут должна быть шутка про UDP, но она потерялась.)

Если хочется улучшить ситуацию - я бы начал с тюнинга буферов 
сокета syslog-сервера.

-- 
Maxim Dounin
http://mdounin.ru/

From anatoliy.melnik на showjet.ru  Thu Jan 18 16:13:39 2024
From: anatoliy.melnik на showjet.ru (Anatoliy Melnik)
Date: Thu, 18 Jan 2024 19:13:39 +0300 (MSK)
Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?=
 =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <CAFHpkQG0iCOiaO5hZv4xwXsL949+5c9JMm9CFTXp2uv7dMqT+A@mail.gmail.com>
References: <mailman.4.1705579200.28808.nginx-ru@nginx.org>
Message-ID: <327095632.64215160.1705594419643.JavaMail.zimbra@showjet.ru>

Фиксировал разными средствами. 
Этот "порог" наблюдается и на rsyslog, и на syslog-ng 
Сливал с 2-х nginx в один syslog -- получилось, расхождения в статистике пошли с 100тыс/сек, т.е. вероятнее всего nginx теряет на этапе генерации сообщения, а не на этапе транспортировки или приема rsyslog-ом. 

Результат не зависит от того, идет ли передача по udp или в unixSocket. 
Если сделать 2 записи аccess_log 
access_log syslog:server=unix:/tmp/syslog01,nohostname,facility=local5,severity=debug,tag=nginx_sts02 st01 if=$var0; 
access_log syslog:server=unix:/tmp/syslog02,nohostname,facility=local5,severity=debug,tag=nginx_sts02 st01 if=$var1; 

С условием "if" так, что бы половина уходила в один syslog, а половина в другой (2 независимых rsyslog-а на одном сервере, слив хоть по UDP, хоть по unix:socket в любой комбинации) 
Все равно примерно на уровне 50тыс/сек начинается расхождение в количестве. 


От: "Илья Шипицин" <chipitsine на gmail.com> 
Кому: "nginx-ru" <nginx-ru на nginx.org> 
Отправленные: Среда, 17 Январь 2024 г 15:31:49 
Тема: Re: Тест nginx -- сколько сообщений в log syslog без потерь? 



ср, 17 янв. 2024 г. в 12:49, Anatoliy Melnik via nginx-ru < [ mailto:nginx-ru на nginx.org | nginx-ru на nginx.org ] >: 



Здравствуйте. 
Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам. 
Логи льются в syslog (слив в файлы напрямую из nginx не желателен). 
По косвенным методам контроля вылезла проблема: 
До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog фиксирует меньше событий, чем сумма по бекэндам. 
Чем выше интенсивность запросов, тем больше расходятся данные. 
Сначала грешил на syslog, но детальные разборы полетов говорят, что скорее всего проблема в nginx. 



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

BQ_BEGIN

У кого-то что-то такое наблюдалось или нет? 
При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. скорее всего syslog не виноват. 
Кто-то с таким сталкивался? 
_______________________________________________ 
nginx-ru mailing list 
[ mailto:nginx-ru на nginx.org | nginx-ru на nginx.org ] 
[ https://mailman.nginx.org/mailman/listinfo/nginx-ru | https://mailman.nginx.org/mailman/listinfo/nginx-ru ] 

BQ_END


----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240118/a379e5dd/attachment.htm>

From anatoliy.melnik на showjet.ru  Thu Jan 18 16:15:10 2024
From: anatoliy.melnik на showjet.ru (Anatoliy Melnik)
Date: Thu, 18 Jan 2024 19:15:10 +0300 (MSK)
Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?=
 =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <ZagIP0Iuqie06yVl@mdounin.ru>
References: <mailman.4.1705579200.28808.nginx-ru@nginx.org>
Message-ID: <1477382476.64218734.1705594510617.JavaMail.zimbra@showjet.ru>

Слив в 1 Syslog с 3-х nginx -ов, до суммарно 150тыс/сек все сходится (3х50), расхождение +- 0.1% , на 200 тыс (3х67тыс) расхождение достигает 4-7% (в syslog-е на 4-7% меньше, чем сумма по бекэндам)

Результат не зависит от использования UDP или unixSocket (на локальном сервере).
Не зависит от того, локальный это syslog или на соседнем сервере (для UDP).

Ситуация повторяется как минимум на 2-х версиях nginx
nginx version: nginx/1.18.0
И
nginx version: nginx/1.24.0

Замена syslog сервера на самописную версию, единственная задача которой из unixSocket блок данных записать в файл дает такие же результаты количественные.

Возможно я плохо искал методы тюнинга unixSocket, к сожалению не нашел. 

----- Исходное сообщение -----
От: "Maxim Dounin" <mdounin на mdounin.ru>
Кому: "nginx-ru" <nginx-ru на nginx.org>
Отправленные: Среда, 17 Январь 2024 г 20:02:55
Тема: Re: Тест nginx -- сколько сообщений в log syslog без потерь?

Hello!

On Wed, Jan 17, 2024 at 02:49:30PM +0300, Anatoliy Melnik via nginx-ru wrote:

> Здравствуйте.  Есть nginx-ы, несколько разных версий. Проксируют 
> запросы к бекэндам.  Логи льются в syslog (слив в файлы напрямую 
> из nginx не желателен).  По косвенным методам контроля вылезла 
> проблема: До примерно 50 тыс/сек сообщений статистика прокси и 
> бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются 
> расхождения. nginx->syslog фиксирует меньше событий, чем сумма 
> по бекэндам.  Чем выше интенсивность запросов, тем больше 
> расходятся данные.  Сначала грешил на syslog, но детальные 
> разборы полетов говорят, что скорее всего проблема в nginx.  У 
> кого-то что-то такое наблюдалось или нет?  При сливе логов с 2-х 
> nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. 
> скорее всего syslog не виноват.  Кто-то с таким сталкивался? 

Запись логов в syslog - не гарантирует доставку всех сообщений.  
Если syslog-сервер не справляется или есть проблемы с сетью между 
nginx'ом и syslog-сервером - сообщения будут просто осыпаться на 
пол. (Где-то тут должна быть шутка про UDP, но она потерялась.)

Если хочется улучшить ситуацию - я бы начал с тюнинга буферов 
сокета syslog-сервера.

-- 
Maxim Dounin
http://mdounin.ru/

From bgx на protva.ru  Thu Jan 18 16:45:01 2024
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 18 Jan 2024 19:45:01 +0300
Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YE=?=
 =?utf-8?B?0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9n?=
 =?utf-8?B?INCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <327095632.64215160.1705594419643.JavaMail.zimbra@showjet.ru>
References: <mailman.4.1705579200.28808.nginx-ru@nginx.org>
 <327095632.64215160.1705594419643.JavaMail.zimbra@showjet.ru>
Message-ID: <ZalVjfqUC_peJUum@protva.ru>

On Thu, Jan 18, 2024 at 07:13:39PM +0300, Anatoliy Melnik via nginx-ru wrote:
>    Фиксировал разными средствами.
>    Этот "порог" наблюдается и на rsyslog, и на syslog-ng
>    Сливал с 2-х nginx в один syslog -- получилось, расхождения в статистике
>    пошли с 100тыс/сек, т.е. вероятнее всего nginx теряет на этапе генерации
>    сообщения, а не на этапе транспортировки или приема rsyslog-ом.

 Чем гадать, что "вероятнее всего", возьмите исходники nginx, вставьте
 счётчик передач в syslog, смотрите его и сравнивайте с количеством пакетов,
 пришедших в syslog. Так можно исключить потери в сети.

>   Замена syslog сервера на самописную версию, единственная задача которой
>   из unixSocket блок данных записать в файл дает такие же результаты
>   количественные.

 Здесь тоже желательно сделать свой самописный syslog, который в простейшем
 варианте ничего не делает, лишь считает число пришедших пакетов.

 PS. Интересно также, какая на вашем стенде получается скорость записи
 в файл syslog-ом. Здесь желательно проверить, что в файле нет сообщенией
 "столько-то записей отброшено", это стандартный функционал syslog-ов.
-- 
 Eugene Berdnikov

From anatoliy.melnik на showjet.ru  Thu Jan 18 19:10:14 2024
From: anatoliy.melnik на showjet.ru (Anatoliy Melnik)
Date: Thu, 18 Jan 2024 22:10:14 +0300 (MSK)
Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?=
 =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <ZalVjfqUC_peJUum@protva.ru@php56_jail>
References: <ZalVjfqUC_peJUum@protva.ru@php56_jail>
Message-ID: <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>



> Чем гадать, что "вероятнее всего", возьмите исходники nginx, вставьте
> счётчик передач в syslog, смотрите его и сравнивайте с количеством пакетов,
> пришедших в syslog. Так можно исключить потери в сети.

Вроде при записи в unixSocket сеть отсутствует.
В любом варианте ваш совет трудно реализовать -- моя квалификация как программиста для подобной задачи не достаточна.

> Здесь тоже желательно сделать свой самописный syslog, который в простейшем
> варианте ничего не делает, лишь считает число пришедших пакетов.


> PS.  Интересно также, какая на вашем стенде получается скорость записи
> в файл syslog-ом. Здесь желательно проверить, что в файле нет сообщенией
> "столько-то записей отброшено", это стандартный функционал syslog-ов.

Файл на tmpfs в оперативке, оперативки 512Гб, swap не используется в принципе, дефицита памяти не наблюдается.
Это не стенд, это реальная нагрузка, реальные данные.
Повторюсь, при развертывании 2-х nginx-ов на одном физическом узле на dummy интерфейсах с разными IP и записи логов с обоих nginx-ов в один rsyslog 
вся статистика сходится до нагрузки 100тыс/сек. 
Кстати при 3-х nginx-ах расхождения начинаются со 150тыс/сек.

На пике нагрузки замер производительности, файл - 1 минута статистики:
dd if=/var/ram/counters.log.1 of=/var/ram/test.dd.txt bs=4096
3374724+1 записей получено
3374724+1 записей отправлено
13822870653 байт (14 GB, 13 GiB) скопирован, 13,3657 s, 1,0 GB/s

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

From mdounin на mdounin.ru  Thu Jan 18 19:30:32 2024
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 18 Jan 2024 22:30:32 +0300
Subject: =?koi8-r?B?9MXT1CBuZ2lueCAtLSDTy8/M?=
 =?koi8-r?B?2MvPINPPz8Ldxc7JyiDXIGxvZyBzeXNsb2cgwsXaINDP1MXS2D8=?=
In-Reply-To: <1477382476.64218734.1705594510617.JavaMail.zimbra@showjet.ru>
References: <mailman.4.1705579200.28808.nginx-ru@nginx.org>
 <1477382476.64218734.1705594510617.JavaMail.zimbra@showjet.ru>
Message-ID: <Zal8WBoAGcrZdtGc@mdounin.ru>

Hello!

On Thu, Jan 18, 2024 at 07:15:10PM +0300, Anatoliy Melnik via nginx-ru wrote:

> Слив в 1 Syslog с 3-х nginx -ов, до суммарно 150тыс/сек все 
> сходится (3х50), расхождение +- 0.1% , на 200 тыс (3х67тыс) 
> расхождение достигает 4-7% (в syslog-е на 4-7% меньше, чем сумма 
> по бекэндам)

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

Если хочется сравнивать с бэкендами, то надо либо как-то 
убеждаться, что каждый запрос порождает только один запрос к 
бэкенду (proxy_next_upstream off, keepalive к бэкендам не 
используется, подзапросов нет), либо учитывать все попытки в 
$upstream_addr и $upstream_status (опять же в предположении 
отсутствия подзапросов).

> Результат не зависит от использования UDP или unixSocket (на 
> локальном сервере).
> Не зависит от того, локальный это syslog или на соседнем сервере 
> (для UDP).
> 
> Ситуация повторяется как минимум на 2-х версиях nginx
> nginx version: nginx/1.18.0
> И
> nginx version: nginx/1.24.0
> 
> Замена syslog сервера на самописную версию, единственная задача 
> которой из unixSocket блок данных записать в файл дает такие же 
> результаты количественные.
> 
> Возможно я плохо искал методы тюнинга unixSocket, к сожалению не 
> нашел. 

Тюнинг стандартный: setsockopt(SO_RCVBUF), как и для любых 
сокетов.

Если в syslog-сервере ручки не вынесено, то в системе можно 
настроить с помощью соответствующих sysctl'ей - 
net.inet.udp.recvspace и net.local.dgram.recvspace для FreeBSD, 
net.core.rmem_default (а при необходимости net.ipv4.udp_mem и 
net.ipv4.udp_rmem_min) на Linux.

Для локальных сокетов на Linux'е, судя по всему, нужно ещё крутить 
net.unix.max_dgram_qlen.

-- 
Maxim Dounin
http://mdounin.ru/

From bgx на protva.ru  Thu Jan 18 20:28:27 2024
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 18 Jan 2024 23:28:27 +0300
Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YE=?=
 =?utf-8?B?0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9n?=
 =?utf-8?B?INCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>
References: <ZalVjfqUC_peJUum@protva.ru@php56_jail>
 <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>
Message-ID: <ZamJ67fEZ5QNRaVT@nox.protva.ru>

On Thu, Jan 18, 2024 at 10:10:14PM +0300, Anatoliy Melnik via nginx-ru wrote:
> > Чем гадать, что "вероятнее всего", возьмите исходники nginx, вставьте
> > счётчик передач в syslog, смотрите его и сравнивайте с количеством пакетов,
> > пришедших в syslog. Так можно исключить потери в сети.
> 
> Вроде при записи в unixSocket сеть отсутствует.

 Это "внутренняя" сеть, только с address family = AF_UNIX, а не AF_INET.
 И несколько другими алгоритмами, в частности, исключены потери пакетов
 как для SOCK_STREAM, так и для SOCK_DGRAM. Что, конечно, не мешает
 приложениям дропать пакеты при переполнениях ядерных буферов, приводящим
 к ошибкам на уровне send(), как тут ведёт себя nginx -- не знаю.
 Однако попытаться увеличить всякие буферы однозначно полезно.

> В любом варианте ваш совет трудно реализовать -- моя квалификация как программиста для подобной задачи не достаточна.

 Тогда шансы достичь просветления уменьшаются. :) Ну, попробуйте просто
 измерить пропускную способность syslog-ов каким-либо генератором записей,
 например, сделайте файлик с 10К уникальных сообщений, подобных nginx,
 и скармливайте его в цикле утилите logger. Посмотрите сколько запишется
 на диск и с какой скоростью, не будет ли там пропусков.

 Что касается использования памяти в сокетах, для линукса есть командочка
 "ss -m", она покажет socket memory usage. Расшифровка выдачи в man ss,
 посмотреть выдачу можно как по inet-сокетам, так и по unix-сокетам.
 Для других ОС есть другие погремушки, наверное... Квалификация тут нужна
 сисадминская, а не по части программирования, но по мне так правка кода
 nginx проще.
 
> Пока создается впечатление, что либо у меня что-то не так, либо никому не приходило в голову сравнить эти данные.

 Простой вопрос: зачем писать на диск 100 тыс/с логов, что потом с ними
 предполагается делать? Ведь логи пишутся не просто так, а чтобы их потом
 как-то обрабатывать... Что именно будет нужно из из этого океана байтов?
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Thu Jan 18 21:54:08 2024
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 18 Jan 2024 22:54:08 +0100
Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?=
 =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>
References: <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>
Message-ID: <CAFHpkQG-ng71u-93ETP8B_VFUgkQ7dY7x0Y-kD3GW=guYNCe2w@mail.gmail.com>

On Thu, Jan 18, 2024, 20:10 Anatoliy Melnik via nginx-ru <nginx-ru на nginx.org>
wrote:

>
>
> > Чем гадать, что "вероятнее всего", возьмите исходники nginx, вставьте
> > счётчик передач в syslog, смотрите его и сравнивайте с количеством
> пакетов,
> > пришедших в syslog. Так можно исключить потери в сети.
>


tcpdump с минимальными фильтрами типа

tcpdump -i <iface> -s0 -w file.pcap port 1514

Потом можно file.pcap открыть wireshark-ом, правда, учитывая, что tcpdump
негарантированно записывает пакеты

tcpdump очень нетривиальная утилита, если есть коллега, который с ней "на
ты", можно его попросить


> Вроде при записи в unixSocket сеть отсутствует.
> В любом варианте ваш совет трудно реализовать -- моя квалификация как
> программиста для подобной задачи не достаточна.
>
> > Здесь тоже желательно сделать свой самописный syslog, который в
> простейшем
> > варианте ничего не делает, лишь считает число пришедших пакетов.
>
>
> > PS.  Интересно также, какая на вашем стенде получается скорость записи
> > в файл syslog-ом. Здесь желательно проверить, что в файле нет сообщенией
> > "столько-то записей отброшено", это стандартный функционал syslog-ов.
>
> Файл на tmpfs в оперативке, оперативки 512Гб, swap не используется в
> принципе, дефицита памяти не наблюдается.
> Это не стенд, это реальная нагрузка, реальные данные.
> Повторюсь, при развертывании 2-х nginx-ов на одном физическом узле на
> dummy интерфейсах с разными IP и записи логов с обоих nginx-ов в один
> rsyslog
> вся статистика сходится до нагрузки 100тыс/сек.
> Кстати при 3-х nginx-ах расхождения начинаются со 150тыс/сек.
>
> На пике нагрузки замер производительности, файл - 1 минута статистики:
> dd if=/var/ram/counters.log.1 of=/var/ram/test.dd.txt bs=4096
> 3374724+1 записей получено
> 3374724+1 записей отправлено
> 13822870653 байт (14 GB, 13 GiB) скопирован, 13,3657 s, 1,0 GB/s
>
> Пока создается впечатление, что либо у меня что-то не так, либо никому не
> приходило в голову сравнить эти данные.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240118/f1d0c38d/attachment.htm>

From hac на citycat.ru  Fri Jan 19 08:49:06 2024
From: hac на citycat.ru (Pavel Yakovlev)
Date: Fri, 19 Jan 2024 11:49:06 +0300
Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?=
 =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?=
 =?UTF-8?Q?=3F?=
In-Reply-To: <327095632.64215160.1705594419643.JavaMail.zimbra@showjet.ru>
References: <mailman.4.1705579200.28808.nginx-ru@nginx.org>
 <327095632.64215160.1705594419643.JavaMail.zimbra@showjet.ru>
Message-ID: <44c5247a-9b50-49ba-a32d-585fb32bda0b@citycat.ru>

В конфиг сислога добавлено вот это ?

$SystemLogRateLimitInterval 0
$SystemLogRateLimitBurst 0

Всё точно идёт сразу в  syslog/rsyslog напрямую, а не через 
systemd-journal ?


18.01.2024 19:13, Anatoliy Melnik via nginx-ru пишет:
> Фиксировал разными средствами.
> Этот "порог" наблюдается и на rsyslog, и на syslog-ng
> Сливал с 2-х nginx в один syslog -- получилось, расхождения в статистике 
> пошли с 100тыс/сек, т.е. вероятнее всего nginx теряет на этапе генерации 
> сообщения, а не на этапе транспортировки или приема rsyslog-ом.
> 
> Результат не зависит от того, идет ли передача по udp или в unixSocket.
> Если сделать 2 записи аccess_log
> access_log 
> syslog:server=unix:/tmp/syslog01,nohostname,facility=local5,severity=debug,tag=nginx_sts02 st01 if=$var0;
> access_log 
> syslog:server=unix:/tmp/syslog02,nohostname,facility=local5,severity=debug,tag=nginx_sts02 st01 if=$var1;
> 
> С условием "if" так, что бы половина уходила в один syslog, а половина в 
> другой (2 независимых rsyslog-а на одном сервере, слив хоть по UDP, хоть 
> по unix:socket в любой комбинации)
> Все равно примерно на уровне 50тыс/сек начинается расхождение в количестве.
> 
> ------------------------------------------------------------------------
> *От: *"Илья Шипицин" <chipitsine на gmail.com>
> *Кому: *"nginx-ru" <nginx-ru на nginx.org>
> *Отправленные: *Среда, 17 Январь 2024 г 15:31:49
> *Тема: *Re: Тест nginx -- сколько сообщений в log syslog без потерь?
> 
> 
> 
> ср, 17 янв. 2024 г. в 12:49, Anatoliy Melnik via nginx-ru 
> <nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>>:
> 
>     Здравствуйте.
>     Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам.
>     Логи льются в syslog (слив в файлы напрямую из nginx не желателен).
>     По косвенным методам контроля вылезла проблема:
>     До примерно 50 тыс/сек сообщений статистика прокси и бекэндов
>     сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения.
>     nginx->syslog фиксирует меньше событий, чем сумма по бекэндам.
>     Чем выше интенсивность запросов, тем больше расходятся данные.
>     Сначала грешил на syslog, но детальные разборы полетов говорят, что
>     скорее всего проблема в nginx.
> 
> 
> а можно раскрыть, что имеется в виду под "детальные разборы полетов 
> говорят" ?
> по идее, проведя детальное расследование, которое что-то скажет, вы уже 
> получили ответ
> 
>     У кого-то что-то такое наблюдалось или нет?
>     При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно
>     100тыс/сек, т.е. скорее всего syslog не виноват.
>     Кто-то с таким сталкивался?
>     _______________________________________________
>     nginx-ru mailing list
>     nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>     https://mailman.nginx.org/mailman/listinfo/nginx-ru
>     <https://mailman.nginx.org/mailman/listinfo/nginx-ru>
> 
> 
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Павел

From anatoliy.melnik на showjet.ru  Mon Jan 22 09:10:40 2024
From: anatoliy.melnik на showjet.ru (Anatoliy Melnik)
Date: Mon, 22 Jan 2024 12:10:40 +0300 (MSK)
Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?=
 =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?=
In-Reply-To: <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>
References: <ZalVjfqUC_peJUum@protva.ru@php56_jail>
 <776744131.64598045.1705605014604.JavaMail.zimbra@showjet.ru>
Message-ID: <1092569747.76138008.1705914640934.JavaMail.zimbra@showjet.ru>

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

Попробую подвести итоги по теме:
На вопрос 
"До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения.... 
Кто-то с таким сталкивался? "
Я ожидал ответов в стиле 
"У меня на сервере при нагрузке 70 (80, 90 и т.д.) тыс/сек ничего подобного не наблюдается (или наблюдается что-то подобное)" 
Или что-то близкое по смыслу.
Судя по содержанию данных советов:
Подобную статистику не ведут, т.к. не видят особого смысла.

Зачем мне это нужно:
Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы.
Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются.
Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут.

Регулярно требуется "нестандартная" статистика, например 
"средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки"
"соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час"
"наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..."
"объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)"
и т.д.
нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси.
Сами файлы логов живут максимум 15-20 минут, этого достаточно для извлечения необходимых данных.
Нестыковки стали вылезать, когда один из 3-х фронтов погасили на пару дней, нагрузка на оставшиеся 2 стала выше 50тыс/сек на каждом из них (при этом их предел гораздо выше, каждый может гарантировано "переварить" 200тыс/сек) и пошли расхождения в отчетах по количеству запросов с фронтов и беков.

При снижении количества запросов все снова хорошо согласуется.

Получены советы:
1) Уточнить методику расчета -- не вижу смысла, сколь-нибудь существенные и системные расхождения появляются только когда нагрузка на реверс-прокси выше 50тыс/сек, т.е. 3 х 40 проблем нет,а 2 х 60 уже проблема? при этом когда "железки" 2 шт, а nginx-ов на них 3шт проблема снова исчезает...
2) Тюнинг сокетов -- в процессе, UDP исключен, замер связки unixSocket+rsyslog на один unixSocket пока показал "потолок" 150тыс/сек производительность, но еще не все идеи реализовал-проверил. 
3) Настройки rsyslog-а 
$SystemLogRateLimitInterval 0 
$SystemLogRateLimitBurst 0

$SystemLogRateLimitBurst -- ставился и "0", и "20000000", на конечный результат не повлияло. как и замена на другой syslog.
 
Всё точно идёт сразу в syslog/rsyslog напрямую, а не через
systemd-journal ? 
Точно, в  systemd-journal эти данные не фиксируются и туда вообще не попадают.

Производительности хранилища точно достаточно для 150тыс/сек (один из способов замера -- запуск одновременно 3-х экземпляров rsyslog на одном физическом сервере и заливка в 3 сразу тестового набора в 12млн сообщений на каждый, итог 300-450тыс/сек в совокупности, непрерывно в течении нескольких часов заливка-ротация-удаление)

Все работает на физическом железе, без VPS-ов и контейнеров.

По результатам отпишусь, но врядли скоро, т.к. такая нагрузка не регулярна, а вариантов для проверки не 1 и не 2 :)

Всем спасибо за внимание.

From pluknet на nginx.com  Tue Jan 30 17:14:19 2024
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Tue, 30 Jan 2024 21:14:19 +0400
Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0L3QtSDQv9C+0LTQtNC10YDQttC40LI=?=
 =?utf-8?B?0LDQtdC80YvQtSDQvtC/0YbQuNC4IGJhY2tsb2csZGVmZXJyZWQg0LggZmFz?=
 =?utf-8?B?dG9wZW4=?=
In-Reply-To: <45659296.20240103221737@gmail.com>
References: <767484501.20231211130145@gmail.com>
 <B20F1C73-7498-4511-8B31-C0406F85C979@nginx.com>
 <45659296.20240103221737@gmail.com>
Message-ID: <C86BF5F2-17E2-4E27-A271-910C8C6CCC0D@nginx.com>


> On 3 Jan 2024, at 23:17, izorkin на gmail.com wrote:
> 
> Добрый вечер, Сергей.
> 
> Благодарю, патч проверил, работает.

Спасибо, исправили:
https://hg.nginx.org/nginx/rev/73eb75bee30f

> 
> Вы писали 20 декабря 2023 г., 18:05:18:
> 
>> Значение параметра backlog передаётся в вызов listen().  Для сокетов
>> типа SOCK_DGRAM, используемых в QUIC, listen() не поддерживается и в
>> nginx не вызывается, посему для них параметр backlog не имеет смысла.
>> Добавил в список запрещённых параметров, см. патч.
> 
> 
> -- 
> С уважением,
> Izorkin                          mailto:izorkin на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Sergey Kandaurov