Re: nginxQuic: скорость загрузки при активации kTLS
чт, 4 янв. 2024 г. в 22:21, :
> Добрый вечер, Илья.
>
>
> Благодарю за рекомендации!
>
> По логам для 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:izor...@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
Re: nginxQuic: скорость загрузки при активации kTLS
чт, 4 янв. 2024 г. в 22:21, : > Добрый вечер, Илья. > > > Благодарю за рекомендации! > > По логам для 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:izor...@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
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый вечер, Илья. Благодарю за рекомендации! По логам для 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:izor...@gmail.com___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
чт, 4 янв. 2024 г. в 20:37, : > Добрый вечер, Илья. > > > "Использовать у себя" - можете поделиться, где именно вы используете, если > не секрет? > > > Использую на домашнем сервере, почта, микроблог 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:izor...@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
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый вечер, Илья. > "Использовать у себя" - можете поделиться, где именно вы используете, если не > секрет? Использую на домашнем сервере, почта, микроблог Mastodon (Fediverse) и другие сервисы :) Ну и в других местах, если надо кому-то что-то по мелочи настроить, но это не часто требуется. -- С уважением, Izorkin mailto:izor...@gmail.com___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
On Thu, Jan 4, 2024, 20:07 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:izor...@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
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый вечер, Илья. Вы писали 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:izor...@gmail.com___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
чт, 4 янв. 2024 г. в 18:56, : > Добрый вечер, Илья. > > > > Вы писали 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:izor...@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
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый вечер, Илья. Вы писали 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:izor...@gmail.com___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
чт, 4 янв. 2024 г. в 17:04, : > Добрый вечер, Илья. > > > > Замерил тесты на физическом сервере, пока без без поддержки 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 - это протоколы
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый вечер, Илья. Замерил тесты на физическом сервере, пока без без поддержки 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:izor...@gmail.com___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
на вашей виртуальной машине производительность уперлась в особенности реализации QUIC, вы просто выгребли 100% процессора. скажем, вы замеряли "сколько можно получить байт в сек на данном цпу для разных реализаций" в QUIC Interop тесты весьма и весьма ресурсоемкие, там кроме передачи шифрованного трафика еще дешифруется трафик, захваченный через tshark. в тестах, где меньше, чем 9700 - уперлись в особенности реализации, а 9700 - это выглядит как потолок для того железа чем замечательны http/2 и http/3 - это протоколы и реализации очень качественно покрытые тестами, что-то совершенно невообразимое для http/1.1 чт, 4 янв. 2024 г. в 13:24, : > Добрый день, Илья. > > > По результатам видно, что скорость явно больше, чем у меня выходит на > > виртуальной машине. Но скорость не превышает ~9700 кбит/сек. Там у них > > не упираются тесты в ограничения сетевой карты? > > Надо наверное попробовать протестировать на физическом сервере. > > > > Вы писали 4 января 2024 г., 14:24:21: > > > кстати, у QUIC Interop есть замеры быстродействия (Measurement result) > > https://interop.seemann.io/ > > > -- > С уважением, > Izorkin mailto:izor...@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
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый день, Илья. По результатам видно, что скорость явно больше, чем у меня выходит на виртуальной машине. Но скорость не превышает ~9700 кбит/сек. Там у них не упираются тесты в ограничения сетевой карты? Надо наверное попробовать протестировать на физическом сервере. Вы писали 4 января 2024 г., 14:24:21: > кстати, у QUIC Interop есть замеры быстродействия (Measurement result) > https://interop.seemann.io/ -- С уважением, Izorkin mailto:izor...@gmail.com___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
кстати, у QUIC Interop есть замеры быстродействия (Measurement result) https://interop.seemann.io/ вт, 2 янв. 2024 г. в 21:50, : > Здравствуйте. > > Сравнил скорость загрузки большого файла на тестовой виртуальной машине > разными протоколами: > - 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:izor...@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
