Добрый день, Максим.
Ясно, благодарю за пояснение :)
Вы писали 5 февраля 2024 г., 11:40:55:
> Hello!
> Это какая-то внутренняя история curl'а про борьбу с неэффективным
> демультиплексингом, к nginx'у не имеет отношения примерно
> никакого, да и в самом curl'е относится только к случаю получе
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:
Добрый день, Максим.
Сегодня увидел, что разработчики избавились от буферов приёма и
создали новый способ разгрузки для протокола HTTP/2:
https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md
https://github.com/curl/curl/pull/12828
Реализации аналогичного варианты в Nginx как-то помож
Добрый вечер, Илья.
При условии в 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
пт, 12 янв. 2024 г. в 15:16, :
> Добрый день, Илья.
>
>
> Этот метод будет работать при много-поточной загрузке, когда запрашивается
>
> сразу несколько разных файлов?
>
>
>
> Запустил тест в 2 потока, (запущен только 1 воркер) в итоге
>
> количество вызовов sendmmsg() увеличилось до 27 (без допол
Добрый день, Илья.
Этот метод будет работать при много-поточной загрузке, когда запрашивается
сразу несколько разных файлов?
Запустил тест в 2 потока, (запущен только 1 воркер) в итоге
количество вызовов sendmmsg() увеличилось до 27 (без дополнительного патча).
1361 33.4% 33.4% 1361 33
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/st
Добрый день, Илья.
Первый вариант патча оказывается не рабочий, забыл применить:
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_
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/n
Добрый день, Илья.
Применил такой патч:
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_seg
пт, 12 янв. 2024 г. в 08:13, :
> Добрый день, Илья.
>
>
> Может требуется ещё и поддержка recvmmsg()? Может поэтому
>
> не работает sendmmsg()?
>
есть подозрение, что упираетесь вот в это условие (не успевают накопиться 3
пакета)
if (bytes > len * 3) {
/* require at least ~3
Добрый день, Илья.
Может требуется ещё и поддержка recvmmsg()? Может поэтому
не работает sendmmsg()?
--
С уважением,
Izorkin mailto:izor...@gmail.com___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mail
Добрый вечер, Илья.
Судя по логам все попытки успешны.
Там все сообщения идентичны:
[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
...
Почти все сообщения s
чт, 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,
Добрый вечер, Илья.
В логах не обнаружил сообщений sendmsg() и sendmmsg().
Вы писали 11 января 2024 г., 22:11:56:
> я имею в виду вот этот код
> + if (n == -1) {
> + err = ngx_errno;
> +
> + switch (err) {
> + case NGX_EAGAIN:
> + ngx_log
чт, 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
>
>
Добрый вечер, Илья.
Да, только 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
из интересного, в openssl master есть вот такое
https://github.com/openssl/openssl/blob/master/doc/designs/quic-design/dgram-api.md
пн, 8 янв. 2024 г. в 14:18, :
> Добрый день, Роман.
>
> В среднем чуть-чуть лучше результат, скорость иногда выше на
> 5-10 МБайт/сек. Иногда на одном уровне держитс
Добрый день, Роман.
Забыл добавить текущий анализ профиля без использования патча:
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
Добрый день, Роман.
В среднем чуть-чуть лучше результат, скорость иногда выше на
5-10 МБайт/сек. Иногда на одном уровне держится.
По профилю видно, что sendmmsg()практически не используется:
626 31.3% 31.3% 626 31.3% __sendmsg
546 27.3% 58.7% 546 27.3% _aesni_ctr32_ghash
Добрый день,
On Thu, Jan 04, 2024 at 07:04:31PM +0300, izor...@gmail.com wrote:
> Добрый вечер, Илья.
>
> Замерил тесты на физическом сервере, пока без без поддержки kTLS.
> Оказывается в тестах на виртуальной машине я неправильно интерпретировал
> интерпретировал скорости,
> которые выводила у
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 - ~10
Добрый день, Роман.
Да, я уже разобрался, что kTLS не поддерживает HTTP/3 протокол. Первые тесты
я неправильно замерял, в итоге и сложилось неправильное предположение.
Думал, что как-то можно добиться более высокой скорости.
Вы писали 8 января 2024 г., 13:46:32:
> kTLS не работает для HTTP/3.
Добрый день,
On Tue, Jan 02, 2024 at 11:50:08PM +0300, izor...@gmail.com wrote:
> Здравствуйте.
>
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> разными протоколами:
> - HTTP/1.1 - ~102 МБит/сек
> - HTTP/2 - ~97 МБит/сек
> - HTTP/3 - ~125 МБит/сек
>
> После актива
Добрый вечер, Илья.
Удалось пересобрал curl использованием gnutls, скорость увеличилась где-то на
5-10 Мбайт/сек. Уже лучше :)
Вы писали 7 января 2024 г., 15:54:05:
> Выглядит так, что curl на http/3 потребляет больше процессора и это является
> лимитирующим фактором.
> Когда я игрался с ht
On Sun, Jan 7, 2024, 11:02 wrote:
> Добрый день, Илья.
>
>
>
> Добрался ещё до VPS на Ubuntu 22.04.3 LTS для тестов.
>
> Прописал для Nginx официальный репозиторий и заменил текущую версию на
> nginxMainline.
>
>
>
> По тестам для протокола HTTP/1.1 скорость скачет около 340-396 МБайт/сек
> при
>
Добрый день, Илья.
Добрался ещё до VPS на Ubuntu 22.04.3 LTS для тестов.
Прописал для Nginx официальный репозиторий и заменил текущую версию на
nginxMainline.
По тестам для протокола HTTP/1.1 скорость скачет около 340-396 МБайт/сек при
нагрузке процессор до 100%.
Для протокола HTTP/3 скорость
Добрый вечер, Илья.
Думаю, да :)
Вы писали 6 января 2024 г., 23:24:47:
> складывается ощущение, что перескакивание с "а вот есть еще PeerTube",
> заставляет как-то пытаться связать
> новый вопрос с предыдущим тредом, и связь неочевидна.
> выскажу осторожное предположение, что может стоит лим
сб, 6 янв. 2024 г. в 20:48, :
> Добрый вечер, Максим.
>
> Теперь ясно, благодарю :)
>
> Вы писали 6 января 2024 г., 21:27:52:
>
> > Просадка производительности, которую вы наблюдаете для HTTP/2 при
> > включённом kTLS - не собственно из-за kTLS, а из-за того, что у
> > вас включён sendfile, и при
Добрый вечер, Максим.
Теперь ясно, благодарю :)
Вы писали 6 января 2024 г., 21:27:52:
> Просадка производительности, которую вы наблюдаете для HTTP/2 при
> включённом kTLS - не собственно из-за kTLS, а из-за того, что у
> вас включён sendfile, и при включённом kTLS становится возможным
> его
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:
Добрый вечер, Илья.
Да, он влияет как и на 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;
сб, 6 янв. 2024 г. в 14:25, :
> Добрый день, Илья.
>
>
>
> Обычно в NixOS Unstable используются последние версии библиотек. Сейчас
> пере-собрал Nginx
>
> с помощью GCC 13.2.0, но результат не изменился.
>
>
> Вы писали 6 января 2024 г., 15:28:25:
>
>
>
> пока идет такая пьянка, вы каким компилято
Добрый день, Илья.
Обычно в NixOS Unstable используются последние версии библиотек. Сейчас
пере-собрал Nginx
с помощью GCC 13.2.0, но результат не изменился.
Вы писали 6 января 2024 г., 15:28:25:
> пока идет такая пьянка, вы каким компилятором собирали nginx (и библиотеки) ?
> попробуйте подн
сб, 6 янв. 2024 г. в 07:33, :
> Добрый утро, Илья.
>
>
> Изначально я предполагал, что kTLS влияет на производительность HTTP/3
> протокола,
>
> так как изначальные тесты показали небольшой прирост производительности и
> я хотел
>
> узнать, можно ли добиться ещё большей производительности как у HT
Добрый утро, Илья.
Изначально я предполагал, что kTLS влияет на производительность HTTP/3
протокола,
так как изначальные тесты показали небольшой прирост производительности и я
хотел
узнать, можно ли добиться ещё большей производительности как у HTTP/1.1
протокола.
Вот и хотел в начале узнать,
On Fri, Jan 5, 2024, 20:18 wrote:
> Добрый вечер, Илья.
>
>
> Я тут уже не знаю почему процессор полностью не утилизируется, как при
> работе с протоколами HTTP/1.1 и HTTP/2.
>
Вот тут, честно, логическую нить потерял. Вы хотели установить, влияет ли
включение kTLS на быстродействие http/3.
Ест
Добрый вечер, Илья.
Я тут уже не знаю почему процессор полностью не утилизируется, как при работе с
протоколами HTTP/1.1 и HTTP/2.
После тестов хотябы разобрался для себя немного как работает kTLS и как влияет
на скорость обработки :)
А то сперва думал, что kTLS поддерживает и UDP протокол
On Fri, Jan 5, 2024, 18:46 wrote:
> Добрый вечер, Илья.
>
>
> Разобрался в чём была проблема - медленная дисковая подсистема. Скопировал
> тестовый файл в tmpfs, результаты
>
> стали пропорционально результатам на физическом сервере.
>
>
>
> Результаты без поддержки kTLS:
>
> - HTTP/1.1 - ~251 Мб
Добрый вечер, Илья.
Разобрался в чём была проблема - медленная дисковая подсистема. Скопировал
тестовый файл в tmpfs, результаты
стали пропорционально результатам на физическом сервере.
Результаты без поддержки kTLS:
- HTTP/1.1 - ~251 Мбайт/сек (CPU load 100%)
- HTTP/2 - ~207 Мбайт/сек (CPU loa
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 делают для браузера более кайфово. ценой некоторого доп
> > > расхода цпу. браузер себ
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 браузер может скачива
On Thu, Jan 04, 2024 at 09:25:28PM +0100, Илья Шипицин wrote:
> http2 и http/3 делают для браузера более кайфово. ценой некоторого доп
> расхода цпу. браузер себя лимитирует 2-мя tcp
> сессиями, в рамках http/1.1 браузер может скачивать одновременно 2
> объекта.
откуда такая фантазия?
___
чт, 4 янв. 2024 г. в 22:21, :
> Добрый вечер, Илья.
>
>
> Благодарю за рекомендации!
>
> По логам для Mastodon запросы идут в основном по протоколу HTTP/1.1, а по
> HTTP/2 протоколу
>
> раз в 10 меньше, если сравнить сегодняшний лог.
>
возможно, часть запросов проксируется через инфраструктуру Ma
чт, 4 янв. 2024 г. в 22:21, :
> Добрый вечер, Илья.
>
>
> Благодарю за рекомендации!
>
> По логам для Mastodon запросы идут в основном по протоколу HTTP/1.1, а по
> HTTP/2 протоколу
>
> раз в 10 меньше, если сравнить сегодняшний лог.
>
>
>
> Для Mastodon сейчас пытаюсь разобраться и оптимизировать
Добрый вечер, Илья.
Благодарю за рекомендации!
По логам для Mastodon запросы идут в основном по протоколу HTTP/1.1, а по
HTTP/2 протоколу
раз в 10 меньше, если сравнить сегодняшний лог.
Для Mastodon сейчас пытаюсь разобраться и оптимизировать конфигурацию для него:
https://github.com/mastodon/m
чт, 4 янв. 2024 г. в 20:37, :
> Добрый вечер, Илья.
>
>
> "Использовать у себя" - можете поделиться, где именно вы используете, если
> не секрет?
>
>
> Использую на домашнем сервере, почта, микроблог Mastodon (Fediverse) и
> другие сервисы :)
>
как можно поступить в данном случае.
Mastodon - суд
Добрый вечер, Илья.
> "Использовать у себя" - можете поделиться, где именно вы используете, если не
> секрет?
Использую на домашнем сервере, почта, микроблог Mastodon (Fediverse) и другие
сервисы :)
Ну и в других местах, если надо кому-то что-то по мелочи настроить, но это не
часто требуется.
On Thu, Jan 4, 2024, 20:07 wrote:
> Добрый вечер, Илья.
>
>
>
> Вы писали 4 января 2024 г., 21:04:48:
>
>
> выглядит так, будто вас интересует что-то конкретное. а остальное вы
> игнорируете.
>
> давайте отталкиваться от ваших ожиданий. что бы для вас было интересным
> результатом в рамках данног
Добрый вечер, Илья.
Вы писали 4 января 2024 г., 21:04:48:
> выглядит так, будто вас интересует что-то конкретное. а остальное вы
> игнорируете.
> давайте отталкиваться от ваших ожиданий. что бы для вас было интересным
> результатом в рамках данного исследования ?
В рамках данного исследования
чт, 4 янв. 2024 г. в 18:56, :
> Добрый вечер, Илья.
>
>
>
> Вы писали 4 января 2024 г., 19:44:26:
>
>
> смотрите. я предлагал потестировать quictls-1.1.1, вы проигнорировали.
>
> Я пробовал использовать quictls-1.1.1, но там прирост скорости
> незначительный был. Сейчас ещё раз проверил, изменений
Добрый вечер, Илья.
Вы писали 4 января 2024 г., 19:44:26:
> смотрите. я предлагал потестировать quictls-1.1.1, вы проигнорировали.
Я пробовал использовать quictls-1.1.1, но там прирост скорости незначительный
был. Сейчас ещё раз проверил, изменений
в скорости практически нет
> более того, в
чт, 4 янв. 2024 г. в 17:04, :
> Добрый вечер, Илья.
>
>
>
> Замерил тесты на физическом сервере, пока без без поддержки kTLS.
>
> Оказывается в тестах на виртуальной машине я неправильно интерпретировал
> интерпретировал скорости,
>
> которые выводила утилита curl. Вместо МБит/сек там идёт МБайт/с
Добрый вечер, Илья.
Замерил тесты на физическом сервере, пока без без поддержки kTLS.
Оказывается в тестах на виртуальной машине я неправильно интерпретировал
интерпретировал скорости,
которые выводила утилита curl. Вместо МБит/сек там идёт МБайт/сек.
Результаты тестов при скачивании файла с с
на вашей виртуальной машине производительность уперлась в особенности
реализации QUIC, вы просто выгребли 100% процессора.
скажем, вы замеряли "сколько можно получить байт в сек на данном цпу для
разных реализаций"
в QUIC Interop тесты весьма и весьма ресурсоемкие, там кроме передачи
шифрованного
Добрый день, Илья.
По результатам видно, что скорость явно больше, чем у меня выходит на
виртуальной машине. Но скорость не превышает ~9700 кбит/сек. Там у них
не упираются тесты в ограничения сетевой карты?
Надо наверное попробовать протестировать на физическом сервере.
Вы писали 4 января 2024
кстати, у QUIC Interop есть замеры быстродействия (Measurement result)
https://interop.seemann.io/
вт, 2 янв. 2024 г. в 21:50, :
> Здравствуйте.
>
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> разными протоколами:
> - HTTP/1.1 - ~102 МБит/сек
> - HTTP/2 - ~97 МБит
Добрый вечер, Илья.
Через браузер у меня не получается замерить скорость с эмуляцией потерь, не
хочет активировать подключения
внутри локальной сети по HTTP/3 протоколу с само-подписными сертификатами, хотя
тестовый корневой сертификат
добавлен в систему и все необходимые параметры прописаны.
ср, 3 янв. 2024 г. в 16:38, :
> Добрый вечер, Илья.
>
>
>
> Не уверен, что хватит свободного времени, чтобы углубиться в тестирование
> с помощью jmeter-а. Я на практике
>
> практически не сталкиваюсь с такими высокими нагрузками. Хотелось просто
> провести простое сравнение
>
> производительности
Добрый вечер, Илья.
Не уверен, что хватит свободного времени, чтобы углубиться в тестирование с
помощью jmeter-а. Я на практике
практически не сталкиваюсь с такими высокими нагрузками. Хотелось просто
провести простое сравнение
производительности с Kernel TLS, предполагал, что и для QUIC проток
ну какбы нет универсальной https нагрузки.
я в проде видел такое
1) контекстная реклама. клиент приходит ровно 1 раз. делает полный ssl
хендшейк, делает маленький запрос.
2) приложение на react, с примерно 100 asset-ами, которые генерировали
запросы на js, css, png
соотношение количества полных
Здравствуйте, Илья.
Ну для меня это самый простой способ проверить скорость, в лоб :)
Вы писали 3 января 2024 г., 17:38:39:
> на самом деле, нагрузка вида "один SSL хендшейк и скачивание локального файла
> в терабайт" - непохожа ни на одну, которую я видел в проде.
> возможно, это что-то перво
Добрый день, Владимир.
С параметром 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/
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/pp
Здравствуйте, Илья.
Результат анализа дампа:
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/curre
ср, 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 обща
Добрый день, Илья.
Я использую версию quictls 3.1.4. Попробовал версию 3.0.4, скорость
чуть-чуть только увеличилась.
При тестировании по протоколу HTTP/1.1 общая нагрузка system составляет
около 45%, а user около 5%. При тестировании по протоколу HTTP/3 общая
нагрузка system уже составляет около 4
Ещё интересный момент, 100% CPU в какой пропорции складывается из sys и
user? perf показывает только user
On Wed, Jan 3, 2024, 05:44 wrote:
> Добрый день, Илья.
>
>
> Запустить на виртуальной машине kcachegrind не получилось, там нет
>
> поддержки GUI.
>
> Выложил файл perf.out на pastebin:
>
>
Добрый день, Илья.
Запустить на виртуальной машине kcachegrind не получилось, там нет
поддержки GUI.
Выложил файл perf.out на pastebin:
https://pastebin.com/FKqvPL7r
--
С уважением,
Izorkin mailto:izor...@gmail.com___
nginx
On Tue, Jan 02, 2024 at 11:50:08PM +0300, izor...@gmail.com wrote:
> Здравствуйте.
>
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
> разными протоколами:
> - HTTP/1.1 - ~102 МБит/сек
> - HTTP/2 - ~97 МБит/сек
> - HTTP/3 - ~125 МБит/сек
>
> После активации поддержк
вт, 2 янв. 2024 г. в 22:20, :
> Добрый вечер, Илья.
>
>
> Проверял в один поток с использованием утилиты curl? файл записывал
>
> в /dev/null.
>
>
>
> В настройках отключил сжатие gzip и brotli.
>
>
>
> На виртуальной машине используется 4 ядра, при тесте нагружалось 1
>
> ядро практически под 100
Добрый вечер, Алекс.
Да, проверял в один поток с использованием утилиты curl, файл записывал
в /dev/null.
Вы писали 3 января 2024 г., 0:06:00:
> просто ради интереса, скачивали в один поток ?
--
С уважением,
Izorkin mailto:izor...@gmail.com_
Добрый вечер, Илья.
Проверял в один поток с использованием утилиты curl? файл записывал
в /dev/null.
В настройках отключил сжатие gzip и brotli.
На виртуальной машине используется 4 ядра, при тесте нагружалось 1
ядро практически под 100%.
Утилитами perf record или gperftools не пользовался,
было бы интересно посмотреть на "perf record" или gperftools.
на какие функции это все декомпозирукется в каждом из случаев.
начнем с простых вопросов
1) включена ли компрессия
2) насколько утилизируется CPU на виртуалке
вт, 2 янв. 2024 г. в 21:50, :
> Здравствуйте.
>
> Сравнил скорость загрузк
> Сравнил скорость загрузки большого файла на тестовой виртуальной машине
разными протоколами:
просто ради интереса, скачивали в один поток ?
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 МБит/сек
76 matches
Mail list logo
