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
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru