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

[Илья Шипицин]

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 было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240105/ed09bfd6/attachment-0001.htm>