Re: Патч ETags в NixOS
Добрый день, Максим. Вы писали 13 января 2024 г., 3:28:36: > Hello! > Hash-сумма файла в качестве ETag - в целом отличное решение, > проблема тут ровно одна: её нужно как-то получить, ибо системный > вызов fstat() никаких hash-сумм почему-то не возвращает. Считать > на лету - очевидно, плохой вариант для нагруженного сервера, так > как файл придётся на каждый запрос читать дважды. А получать > hash-сумму откуда-то ещё, скажем из внешнего файла или > extended-атрибутов - выглядит в лучшем случае дополнительной фичей > (смотри https://trac.nginx.org/nginx/ticket/2351 например). Теоретически можно было бы сделать предварительное сканирование файлов и генерация хэш сумм при старте в фоновом режиме, для тех файлов, которыее расположены только в /nix/store или любой другой директории, указанной пользователем. А результаты сохранить в кеш. Если генерировать хэш-сумму на лету, то зачем надо генерировать её каждый раз при повторном запросе? Можно же в кэше результат сохранить. Да и это надо делать только для тех файлов, которые имеют нулевую дату. А файлы в /nix/store меняются не часто, только при обновлении ОС. Вариант с файлами хэш-сумм выглядит более оптимальным. При генерации файлов в /nix/store можно дополнительно добавить возможность генерации хэш-суммы для каждого файла, который требуется для работы сайта. Таким же способом в некоторых приложениях организована генерация статических файлов в gzip и brotli форматы. -- С уважением, Izorkin mailto:izor...@gmail.com ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Патч ETags в NixOS
Hello! On Fri, Jan 12, 2024 at 10:35:38PM +0300, izor...@gmail.com wrote: > Вы писали 9 января 2024 г., 5:26:08: > > > Что до nix store, то кажется, что возвращение размера в ETag также > > должно проблему решить. > > В том то и дело, что размер не всегда меняется. Дата модификации и размер - на практике достаточная комбинация для отслеживания версий файлов и их различных представлений, по крайней мере в рамках тех представлений файлов, которые умеет возвращать nginx (исходный файл и его gzip-версия). В nix store, в силу отказа от времени, время надо на что-то заменять, как минимум в ситуациях, когда полных путь, включающих store hash, не фигурирует в URL'е. Но это ортогональный вопрос (и скорее вопрос к самой концепции, которая получилась не очень совместимой с HTTP). > > Теоретически, наверное, можно пытаться в ETag вставлять какой-то > > идентификатор представления, то если для gzip_static добавлять в > > ETag что-нибудь вроде "...-gz". Но при наличии размера в том же > > ETag'е смысла в этом исчезающие мало. > > А вариант добавить вычисления простой хэш суммы при условии, что дата > равно нулю - размер файла + хэш сумма. > Теоретически на остальное не должно повлиять. Hash-сумма файла в качестве ETag - в целом отличное решение, проблема тут ровно одна: её нужно как-то получить, ибо системный вызов fstat() никаких hash-сумм почему-то не возвращает. Считать на лету - очевидно, плохой вариант для нагруженного сервера, так как файл придётся на каждый запрос читать дважды. А получать hash-сумму откуда-то ещё, скажем из внешнего файла или extended-атрибутов - выглядит в лучшем случае дополнительной фичей (смотри https://trac.nginx.org/nginx/ticket/2351 например). -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Патч ETags в NixOS
Добрый вечер, Максим. Вы писали 9 января 2024 г., 5:26:08: > Что до nix store, то кажется, что возвращение размера в ETag также > должно проблему решить. В том то и дело, что размер не всегда меняется. > Полный путь к файлу в ETag точно не имеет смысла. Более того, его > там быть точно не должно: если вдруг ресурс обслуживается двумя > разными origin-серверами, это приведёт к требованию совпадения > путей к файлу на этих серверах, а при их несовпадении - > соответственно к полным ответам вместе 304, то есть сломает > кэширование там, где оно сейчас работает. Не подумал о таком варианте использования. > Теоретически, наверное, можно пытаться в ETag вставлять какой-то > идентификатор представления, то если для gzip_static добавлять в > ETag что-нибудь вроде "...-gz". Но при наличии размера в том же > ETag'е смысла в этом исчезающие мало. А вариант добавить вычисления простой хэш суммы при условии, что дата равно нулю - размер файла + хэш сумма. Теоретически на остальное не должно повлиять. -- С уважением, Izorkin mailto:izor...@gmail.com ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginxQuic: скорость загрузки при активации kTLS
Добрый вечер, Илья. При условии в 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
пт, 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
Добрый день, Илья. Этот метод будет работать при много-поточной загрузке, когда запрашивается сразу несколько разных файлов? Запустил тест в 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
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
Добрый день, Илья. Первый вариант патча оказывается не рабочий, забыл применить: 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
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
Добрый день, Илья.
Применил такой патч:
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
пт, 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
