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

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

2024-02-05 Пенетрантность izorkin

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

Ясно, благодарю за пояснение :)

Вы писали 5 февраля 2024 г., 11:40:55:

> Hello!

> Это какая-то внутренняя история curl'а про борьбу с неэффективным 
> демультиплексингом, к nginx'у не имеет отношения примерно 
> никакого, да и в самом curl'е относится только к случаю получения 
> нескольких файлов одновременно по одному соединению.


-- 
С уважением,
 Izorkin  mailto:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-02-05 Пенетрантность Maxim Dounin

Hello!

On Sun, Feb 04, 2024 at 10:03:56AM +0300, izor...@gmail.com wrote:

> Добрый день, Максим.
> 
> Сегодня увидел, что разработчики избавились от буферов приёма и
> создали новый способ разгрузки для протокола HTTP/2:
> https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md
> https://github.com/curl/curl/pull/12828
> 
> Реализации аналогичного варианты в Nginx как-то поможет для ускорения
> работы с протоколом HTTP/2?

Это какая-то внутренняя история curl'а про борьбу с неэффективным 
демультиплексингом, к nginx'у не имеет отношения примерно 
никакого, да и в самом curl'е относится только к случаю получения 
нескольких файлов одновременно по одному соединению.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-02-03 Пенетрантность izorkin

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

Сегодня увидел, что разработчики избавились от буферов приёма и
создали новый способ разгрузки для протокола HTTP/2:
https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md
https://github.com/curl/curl/pull/12828

Реализации аналогичного варианты в Nginx как-то поможет для ускорения
работы с протоколом HTTP/2?


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

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


-- 
С уважением,
 Izorkin  mailto:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-12 Пенетрантность izorkin

Добрый вечер, Илья.
 
При условии в 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
      28.6%  59.8%      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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-12 Пенетрантность Илья Шипицин

пт, 12 янв. 2024 г. в 15:16, :

> Добрый день, Илья.
>
>
> Этот метод будет работать при много-поточной загрузке, когда запрашивается
>
> сразу несколько разных файлов?
>
>
>
> Запустил тест в 2 потока, (запущен только 1 воркер) в итоге
>
> количество вызовов sendmmsg() увеличилось до 27 (без дополнительного
> патча).
>
> 1361  33.4%  33.4%1361  33.4% __sendmsg
>
>   27.3%  60.8%  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: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

2024-01-12 Пенетрантность izorkin

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

Этот метод будет работать при много-поточной загрузке, когда запрашивается
сразу несколько разных файлов?
 
Запустил тест в 2 потока, (запущен только 1 воркер) в итоге
количество вызовов sendmmsg() увеличилось до 27 (без дополнительного патча).
    1361  33.4%  33.4%    1361  33.4% __sendmsg
      27.3%  60.8%      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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-12 Пенетрантность Илья Шипицин

On Fri, Jan 12, 2024, 12:03  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: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

2024-01-12 Пенетрантность izorkin

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

Первый вариант патча оказывается не рабочий, забыл применить:
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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-12 Пенетрантность Илья Шипицин

On Fri, Jan 12, 2024, 11:29  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: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

2024-01-12 Пенетрантность izorkin

Добрый день, Илья.
 
Применил такой патч:
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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-12 Пенетрантность Илья Шипицин

пт, 12 янв. 2024 г. в 08:13, :

> Добрый день, Илья.
>
>
> Может требуется ещё и поддержка 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: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

2024-01-11 Пенетрантность izorkin

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

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

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-11 Пенетрантность izorkin

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

Судя по логам все попытки успешны.
Там все сообщения идентичны:
[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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-11 Пенетрантность Илья Шипицин

чт, 11 янв. 2024 г. в 20:25, :

> Добрый вечер, Илья.
>
>
> В логах не обнаружил сообщений 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(>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: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

2024-01-11 Пенетрантность izorkin

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

В логах не обнаружил сообщений 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(>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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-11 Пенетрантность Илья Шипицин

чт, 11 янв. 2024 г. в 20:00, :

> Добрый вечер, Илья.
>
>
> Да, только 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(>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
> 0001a00183bd407243b7f2011ca86733
>
> 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 6741DE771C80
>
> 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

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

2024-01-11 Пенетрантность izorkin

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

Да, только 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 
0001a00183bd407243b7f2011ca86733
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 6741DE771C80
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:6
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

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

2024-01-11 Пенетрантность Илья Шипицин

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

пн, 8 янв. 2024 г. в 14:18, :

> Добрый день, Роман.
>
> В среднем чуть-чуть лучше результат, скорость иногда выше на
> 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: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

2024-01-08 Пенетрантность izorkin

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

Забыл добавить текущий анализ профиля без использования патча:
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% 0x09ac4576189c
   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% 0x09ac4572bb22
   3   0.1%  89.3%3   0.1% 0x09ac45781bc4
   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:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-08 Пенетрантность izorkin

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

В среднем чуть-чуть лучше результат, скорость иногда выше на
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:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-08 Пенетрантность Roman Arutyunyan

Добрый день,

On Thu, Jan 04, 2024 at 07:04:31PM +0300, izor...@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 
# 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 
+  #include "
+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

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

2024-01-08 Пенетрантность Slawa Olhovchenkov

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

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

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

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

2024-01-08 Пенетрантность izorkin

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

Да, я уже разобрался, что 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:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-08 Пенетрантность Roman Arutyunyan

Добрый день,

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

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

--
Roman Arutyunyan
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-07 Пенетрантность izorkin

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

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

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

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-07 Пенетрантность Илья Шипицин

On Sun, Jan 7, 2024, 11:02  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: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

2024-01-07 Пенетрантность izorkin

Добрый день, Илья.
 
Добрался ещё до 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-06 Пенетрантность izorkin

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

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

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

-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-06 Пенетрантность Илья Шипицин

сб, 6 янв. 2024 г. в 20:48, :

> Добрый вечер, Максим.
>
> Теперь ясно, благодарю :)
>
> Вы писали 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: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

2024-01-06 Пенетрантность izorkin

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

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

Вы писали 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:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-06 Пенетрантность Maxim Dounin

Hello!

On Sat, Jan 06, 2024 at 08:20:59PM +0300, izor...@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/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-06 Пенетрантность izorkin

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

Да, он влияет как и на 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-06 Пенетрантность Илья Шипицин

сб, 6 янв. 2024 г. в 14:25, :

> Добрый день, Илья.
>
>
>
> Обычно в 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: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

2024-01-06 Пенетрантность izorkin

Добрый день, Илья.
 
Обычно в 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-06 Пенетрантность Илья Шипицин

сб, 6 янв. 2024 г. в 07:33, :

> Добрый утро, Илья.
>
>
> Изначально я предполагал, что 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: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

2024-01-05 Пенетрантность izorkin

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

Изначально я предполагал, что 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-05 Пенетрантность Илья Шипицин

On Fri, Jan 5, 2024, 20:18  wrote:

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

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

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

После тестов хотябы разобрался для себя немного как работает kTLS и как
> влияет на скорость обработки :)
>
> А то сперва думал, что kTLS поддерживает и UDP протокол 
>
>
>
>
>
> Вы писали 5 января 2024 г., 21:53:45:
>
>
> С некоторой непонятностью, что именно означают проценты, но выглядит так,
> что процессор (при выбранном типе нагрузки) нагружается не SSL -ным. Для
> такой нагрузки даже, если бы kTLS умело в UDP, оно бы не повлияло.
> 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

2024-01-05 Пенетрантность izorkin

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

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

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

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-05 Пенетрантность Илья Шипицин

On Fri, Jan 5, 2024, 18:46  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: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

2024-01-05 Пенетрантность izorkin

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

Разобрался в чём была проблема - медленная дисковая подсистема. Скопировал 
тестовый файл в 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-05 Пенетрантность Slawa Olhovchenkov

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

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

да

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

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

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

2024-01-05 Пенетрантность Илья Шипицин

On Fri, Jan 5, 2024, 12:00 Slawa Olhovchenkov  wrote:

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

Про 2 соединения?

>
Фронтендеры говорили, я им верил

https://savvy.co.il/en/blog/wordpress-speed/speed-optimzations-http2-era/

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

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

2024-01-05 Пенетрантность Slawa Olhovchenkov

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

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

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

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

2024-01-04 Пенетрантность Илья Шипицин

чт, 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

2024-01-04 Пенетрантность Илья Шипицин

чт, 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

2024-01-04 Пенетрантность izorkin

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

Благодарю за рекомендации!
По логам для 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

2024-01-04 Пенетрантность Илья Шипицин

чт, 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

2024-01-04 Пенетрантность izorkin

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

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

Использую на домашнем сервере, почта, микроблог 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

2024-01-04 Пенетрантность Илья Шипицин

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

2024-01-04 Пенетрантность izorkin

Добрый вечер, Илья.
 
Вы писали 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

2024-01-04 Пенетрантность Илья Шипицин

чт, 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

2024-01-04 Пенетрантность izorkin

Добрый вечер, Илья.
 
Вы писали 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

2024-01-04 Пенетрантность Илья Шипицин

чт, 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

2024-01-04 Пенетрантность izorkin

Добрый вечер, Илья.
 
Замерил тесты на физическом сервере, пока без без поддержки 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

2024-01-04 Пенетрантность Илья Шипицин

на вашей виртуальной машине производительность уперлась в особенности
реализации 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

2024-01-04 Пенетрантность izorkin

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

По результатам видно, что скорость явно больше, чем у меня выходит на
виртуальной машине. Но скорость не превышает ~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

2024-01-04 Пенетрантность Илья Шипицин

кстати, у 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

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

2024-01-03 Пенетрантность izorkin

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

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

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

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

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

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

-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность Илья Шипицин

ср, 3 янв. 2024 г. в 16:38, :

> Добрый вечер, Илья.
>
>
>
> Не уверен, что хватит свободного времени, чтобы углубиться в тестирование
> с помощью 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: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

2024-01-03 Пенетрантность izorkin

Добрый вечер, Илья.
 
Не уверен, что хватит свободного времени, чтобы углубиться в тестирование с 
помощью 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность Илья Шипицин

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

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

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

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

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

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

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

ср, 3 янв. 2024 г. в 16:01, :

> Здравствуйте, Илья.
>
>
> Ну для меня это самый простой способ проверить скорость, в лоб :)
>
>
>
> Вы писали 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: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

2024-01-03 Пенетрантность izorkin

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

Ну для меня это самый простой способ проверить скорость, в лоб :)
 
Вы писали 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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность izorkin

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

С параметром 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:izor...@gmail.com
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность Vladimir Homutov via nginx-ru

On Wed, Jan 03, 2024 at 05:12:19PM +0300, izor...@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) включён ?
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность izorkin

Здравствуйте, Илья.
Результат анализа дампа:
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:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность Илья Шипицин

ср, 3 янв. 2024 г. в 14:25, :

> Добрый день, Илья.
>
>>
> Я использую версию 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: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

2024-01-03 Пенетрантность izorkin

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

Я использую версию quictls 3.1.4. Попробовал версию 3.0.4, скорость
чуть-чуть только увеличилась.
При тестировании по протоколу HTTP/1.1 общая нагрузка system составляет
около 45%, а user около 5%. При тестировании по протоколу HTTP/3 общая
нагрузка system уже составляет около 40%, а user увеличивается до 12%.
 
Собрал nginx с поддержкой gperftools и собрал данные во время теста.
Как их дальше проанализировать? Или лучше куда-нибудь выложить их?
 
 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-03 Пенетрантность Илья Шипицин

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

On Wed, Jan 3, 2024, 05:44  wrote:

> Добрый день, Илья.
>
>
> Запустить на виртуальной машине kcachegrind не получилось, там нет
>
> поддержки GUI.
>
> Выложил файл perf.out на pastebin:
>
> https://pastebin.com/FKqvPL7r
>
>
>
> --
> С уважением,
>  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

2024-01-02 Пенетрантность izorkin

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

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

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-02 Пенетрантность Slawa Olhovchenkov


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

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

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

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

2024-01-02 Пенетрантность Илья Шипицин

вт, 2 янв. 2024 г. в 22:20, :

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

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



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

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

perf record -g 

под  имеется в виду, что это будет 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: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

2024-01-02 Пенетрантность izorkin

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

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

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

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-02 Пенетрантность izorkin

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

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

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

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

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

 
-- 
С уважением,
 Izorkin                          mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2024-01-02 Пенетрантность Илья Шипицин

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

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

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

вт, 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

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

2024-01-02 Пенетрантность Alex Domoradov

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

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

On Tue, Jan 2, 2024 at 10:50 PM  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: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

75 matches

Mail list logo