Devhands.io провели очередное нагрузочное тестирование балансировщиков, и надеюсь, сделали в этот раз всё правильно: не просто взяли готовый докер, но сравнили и поставили одинаковыми все наиболее критичные конфигурационные параметры. После проведения тестов мы сделали стрим, в котором поделились результатами. Видео этой часовой встречи можно посмотреть на Youtube, а ниже публикуем расшифровку со слайдами и всеми исходниками.
Алексей Рыбак: Привет еще раз. Сегодня интересное событие, сегодня в гостях у меня Коля Лавлинский. Коля, привет!
Николай Лавлинский: Привет.
Алексей Рыбак: Коля занимается очень долго перформанс-тестированием, перформанс-тюнингом и преподаванием (у нас есть совместный курс по балансировке трафика, тюнингу конфигов и, в том числе, тюнингу фронта). И сегодня мы поговорим в целом о проблеме перформанс-тестирования балансировщиков. Покажем результаты тестирования балансировщиков, которые Николай провел не так давно, перепроверяя некоторые – странные, на наш взгляд – результаты, которые были опубликованы на Хабре весной. Коль, тебе слово.
Николай Лавлинский: Это был действительно сравнительный бенчмарк для нескольких прокси-серверов, на самом деле они в основном балансировщики, но у нас работали как прокси, с той задачей, чтобы посмотреть, как это происходит по сравнению с тестом, который был на Хабре.
Идея была в том, что там было немного странное соотношение и, вообще, абсолютные результаты по RPS для разных серверов. А это про меня страничка.
Теперь от чего мы отталкивались. Кстати говоря, не только от этой статьи, наверное, еще можно здесь про другие бенчмарки говорить. В YouTube есть блогер Антон Путра, он проводил много бенчмарков, и там тоже были, кстати, проблемки, он тоже делал “перетесты”. В общем, как ни странно, но бенчмарков довольно мало можно найти, но в целом почему-то бенчмарки не очень принято проводить. Какие-то, находишь, а они древние, например, или чего-то там не хватает. Поэтому кажется, что бенчмарк это вообще полезный процесс, в том числе, для тех кто его проводит, много чего всплывает по ходу дела.
Мы посмотрели на эту статью. Что интересно, было все в виртуальной среде, насколько она стабильна, не очень понятно. Допустим, что все в порядке, и там было три машины по 32 процессора, то есть довольно мощные, по крайней мере, здесь две машины по 128 гигов оперативки и одна – 32.
То есть было три теста. Один нагрузочный, второй – сам прокси-сервер, третий – это бэкенд для него. Причем бэкэнд был реализован в виде Hello World приложения, по-моему, на Go, и он выдавал там что-то совсем маленькое, то есть ответ был меньше килобайта. 60 байт, по-моему, я считал, в среднем у них получилось. Довольно странный вариант, но довольно много ресурсов на каждую машину, то есть, если это сложить, получится прилично.
И там использовались эти сервера, которые мы сегодня тоже посмотрим. Запускались они в докер-контейнерах. Про сеть ничего не сказано. Возможно, дефолтная докер-сеть, то есть как он дает по умолчанию, потому что там были докер-композы, я там не увидел указаний на какой-то другой режим. Тоже не совсем точно. Причем, что интересно, у них бэкэнд был заранее ограничен, они его протестировали. То есть при этой конфигурации, восемь процессоров, 32 гигабайта, он выдавал в районе 50 000 RPS этого Hello World. И больше не мог. Причем, что интересно, при тестах у них многие эти сервера в это число и упирались. То есть там у них была очень разная утилизация процессора в результате. Мы смотрим на число RPS и кажется, что сервера одинаковые. Но при этом утилизация в разы по процессору отличается. То есть как-то, получается, они не дорабатывали в этом плане, им просто не хватало бэкенда. То есть бэкенд, очевидно, нужен был побыстрее, и при этом ответ, 60 байт, – сам по себе довольно крайний случай, это же очень маленький ответ. Также использовался HTTPS при тестировании, но про сжатие там не было ни слова, про текстовую компрессию, хотя она тоже важна. В-общем как-то не очень реалистично.
Что получилось у них в результате? Эти пресловутые 50 000 RPS, разные latency, абсолютный лидер был HAProxy – 1 мс latency по какому-то перцентилю. Эти же 50 000 RPS. Но при этом он потреблял очень мало процессора, то есть, опять же, тяжело сравнивать эти цифры, потому что не было полной утилизации.
Nginx резко был хуже, тоже в контейнере, тоже актуальная версия. В общем, здесь было все более-менее. Причем они вроде как пытались его тюнинговать как-то базово, но не слишком сильно. То есть там идеология теста была «тестируем из коробки, не вносим никаких изменений». Latency уже в секундах, то есть это совсем плохо, это тот же самый перцентиль у всех.
Envoy тоже справился, но он был больше по потреблению процессора. Опять же, тяжело сравнивать, вроде бы по этим цифрам похож на HAProxy.
Caddy там провалился, причем обратите внимание на абсолютное число RPS – 3000 RPS. Напомню, что машина, где работала только прокси, имела 32 ядра, 128 памяти, но память там не принципиальна, а вот 32 ядра почему-то на некоторых серверах были нагружены. При этом вот эти цифры. То есть бэкенд точно никак не влияет, потому что свои 50 000 RPS он вроде как выдает, и прокси вроде бы тоже должен это выдавать, но ничего подобного.
Caddy – 3000 RPS, причем там еще были какие-то ошибки, таймауты и все остальное. И Traefik – что-то на предпоследнем месте, 4600-4700 RPS, тоже с дикими выбросами по latency. Они говорили сразу, что настройки из коробки, про TLS. Не было попыток выровнять сервера. С Nginx была жесткая проблема с логированием, он просто в диск упирался, но там дальше подсказали в комментариях. И про сжатие тоже ни слова. Хотя, может быть, сжатие при ответе в 60 байт – тоже особо бы мы там ничего не увидели нормального.
Но в результате бэкэнд не давал утилизацию виртуалки с прокси. Размер ответа – вот эти 62 байта. Непонятно, что происходит с TLS. И в целом, как сравнивать полученные результаты довольно сложно. То есть надо сопоставлять RPS с утилизацией процессора, еще параллельно смотреть, что там было с трафиком. В общем, что-то было непонятное.
Что мы сделали? Мы взяли этот же набор, для того чтобы приблизиться, мы тоже взяли контейнер. По крайней мере, я взял. Алексей собирал, но Алексей расскажет там, он взял другой подход, чтобы как-то сопоставить в других условиях. Я же взял тоже виртуальную среду, причем виртуалку гораздо слабее – 8 процессоров, 8 гигабайт RAM тоже хватало с запасом. Ubuntu 24, все в докер-контейнерах. Чтобы не тормозить на докеровской сети, сеть была хостовая. Соответственно, по очереди поднимаются контейнеры из композа. Вот здесь есть репозиторий со всеми конфигами. То есть вы можете, в принципе у себя воспроизвести.
И второй тест проводил Алексей на железке, на 48 виртуальных процессоров, 128 гигов RAM. Там, понятно, абсолютные значения будут повыше.
У нас было такое ограничение, скажем, упрощение не совсем честное, что прокси и бэкенд жили в одной виртуалке либо на одной железке, зависит от теста. Но, в принципе, бэкенд отъедает свои ресурсы, но гораздо меньше, чем сам прокси в данном случае, то есть, в принципе, тоже было нормально, мы подстроили. Бэкэнд был заведомо быстрый. Максимальное, что мы могли придумать – это Nginx, выдающий статику с использованием сент-файла, то есть без сжатия, без компрессии, с keepalive-подключениями, как он и должен работать. Причем в качестве ответа у нас было два варианта – это 2 и 100 килобайт. Настоящий HTML-код, чтобы мы адекватно могли сравнивать компрессию. В целом, чтобы это было приближено. То есть это было два разных значения. Два килобайта – это маленький ответ. 100 килобайт – это более-менее нормальный.
Нагрузку мы подавали через wrk для моего результата, где мы считали RPS и замеряли latency, и wrx – для распределения времен, уже latency, который можно получить на железке. Вот то, что Алексей использовал.
Николай Лавлинский: Ну да, надо поправить. Так вот, подавалась нагрузка извне виртуалки. По крайней мере, эта часть нагрузки была на других процессорах, потому что виртуалка часть процессора использовала, часть на wrk отдавалась, но там был запас. То есть в wrk мы не упирались.
Что самое главное нужно было сделать для нас, чтобы мы тестировали более-менее то, что мы считаем справедливыми условиями для серверов? Мы выровняли настройки по шифрам в TLS. Напоминаю, что у нас в TLS есть две фазы – симметричное шифрование и асимметричное. Так как у нас keepalive-подключение, то мы не обращаем внимания на асимметричное, хотя у всех серверов были одни и те же сертификаты ECDSA, то есть хендшейки достаточно быстрые, но нам главное было выровнять симметричное шифрование мы везде добились TLS 1.3, естественно, и AES-128-GCM как такой быстрый, хороший вариант. Из коробки у нас одинаковые шифты не получались. Надо было отдельно это добивать.
И естественно, мы делали большое количество keepalive-соединений к бэкэндам, иначе мы бы тормозили даже на локальных хэндшейках к Nginx.
Также что важно, особенно это важно для больших 100-килобайтных запросов, – это сжатие. Так как мы использовали TLS, то мы считали, что это реальное подключение до браузера, до клиента. Соответственно, мы будем использовать сжатие. Но сжатия мы использовали различные, потому что у нас не все удалось выровнять.
Основной вариант был Zstandard, потому что это быстрый, хороший вариант кодека, у него тотальная поддержка в браузерах. В общем, абсолютно рабочий вариант. Но его не использовали для HAProxy, HAProxy его не поддерживает, пока не реализовано, и Traefik при использовании Zstandard просто жестко тёк по памяти, нельзя было довести до конца тест, то есть он просто пожирал всю память, и на этом все заканчивалось.
Логирование также у некоторых серверов по умолчанию отключено. В Nginx, в Angie его надо принудительно отключать, иначе будем просто жрать диск и, опять же, это все будет сильно искажать. Это основное, что мы делали.
Понятное дело, мы смотрели, чтобы было достаточно потоков, но сервера в основном неплохо подстраивают количество потоков либо процессов, поэтому в этом плане вроде как все было неплохо. И понятно, мы смотрели, чтобы наши запуски были стабильными, то есть многократный запуск, повторяемость и отсутствие каких-то очевидных аномалий что, в принципе, бывает иногда видно, что какие-то показатели совсем жестко отличаются и не должны быть такими. Поэтому все конфиги доступны, можно позапускать там композ. Единственное, что вам нужно будет, это сертификаты добавить, их там нет в репозитории.
Что получилось? У нас первый вариант – это ответ размером 2 Кб, то есть условно компактный ответ, но не такой компактный, как был в статье, не 60 В. Это все-таки ближе к жизни. Восемь процессоров виртуальных. Первое – это RPS, такая диаграмма. И второе – это время ответа, latency.
Здесь жесткий отрыв HAProxy и Angie, они находятся где-то на одном уровне, но здесь конкретно Angie получился лучше. Даже заметно лучше, но здесь может быть, я допускаю, что просто HAProxy можно было еще дальше тюнинговать. В общем, будем считать, что они находятся на этом своем топовом уровне по эффективности для маленьких ответов. И дальше идут все остальные. То есть у нас, как ни странно, Traefik находится на втором месте по этому распределению, по RPS. Кстати говоря, по latency он находится тоже на третьем месте. То есть Traefik на самом деле неплохо себя показал.
И что интересно, опять же, возвращаясь, от чего мы отталкивались, абсолютные цифры тоже важны. Мы используем HTTPS, мы используем текстовую компрессию, она здесь везде работает, и мы получаем в районе 80-90 тысяч RPS для быстрых серверов и где-то в районе 30-40 для всех остальных. Но не 3000, а 30 000 RPS, более тяжелых по определению. А еще у нас и бэкенд отъедает ресурсы. Если вернемся назад, у Caddy для Hello World было 3000 RPS, то есть это совсем другой порядок цифр. То есть получается, что они работают намного лучше, если мы бы по тесту планировали мощности, например, и думали, кто чего может.
По задержкам здесь хорошо оторвался Angie. Напомню, кто, может, не слышал. Angie – это форк Nginx. То есть мы здесь под Angie можем также понимать Nginx в основном, просто Angie – это условно доработанный Nginx. В основном-то ядро у них одинаковое. Здесь latency намного лучше, что странно. А вот у HAProxy здесь похуже. Но это среднее значение, это latency average, среднее между тестами, то есть усредненное еще по нескольким прогонам. Здесь тоже можно думать, смотреть, почему так, но работает так.
Дальше по RPS все более-менее понятно. Как ни странно, здесь Envoy и Caddy находятся на одном уровне. Практически разницы нет – в районе 30 000 RPS.
Что по этому тесту можно сказать? Мы здесь, конечно, довольно много ресурсов тратили в ядре, как ни странно, то есть при включенном компрессе, при включенном TLS все равно ядро в районе половины потребляет. Если он будет время, если нужно, можно погонять с мониторингом в реальном времени, посмотреть, как это выглядит.
Но если мы посмотрим 100-килобайтный тест, то там влияние что шифрования, что компрессии гораздо выше, то есть там меньше накладные расходы на один запрос и больше времени на шифрование контента и на его сжатие. То есть эти две вещи, которые в основном будет потреблять процессор.
И в этом плане расстановка меняется, причем довольно заметно. Angie все еще впереди, но уже не так заметно. Примерно похоже на HAProxy, они ближе стали. И на второе место вырывается Envoy, прямо с отрывом от остальных, и Traefik становится последним, то есть распределение меняется, но опять же, напомню, что Traefik не смог Zstandard здесь доработать до конца. Возможно, это тоже надо как-то отдельно его заставлять под нагрузкой работать. Caddy, в общем-то, остался у нас на предпоследнем месте.
Абсолютные цифры. Здесь мы уже тратим процессор заметно. То есть это именно юзерспейс. И в районе 14000 RPS из 8 ядер получаем, еще с бэкендом. Бэкэнд, условно, вычитаем одно ядро или даже 2 ядра можно, наверное, вычесть из этой виртуалки и получится чистая нагрузка на прокси.
Что касается задержек, здесь тоже все более-менее ровно. То есть Angie чуть лучше, чем HAProxy, примерно одинаково. И дальше идет Envoy, то есть пропорционально RPS. Хуже всего Traefik. Он здесь уже немного приуныл. Вот такие краткие результаты.
Мы прогоняли много итераций. То есть это не первый вариант того, что получилось. Мы работали не только над конфигами, но сейчас расскажу еще, что мы выяснили. Алексей, хочешь рассказать свои варианты? Или я сейчас к выводам подойду?
Алексей Рыбак: Моя цель была такая. Вообще, нас тут ругали, я там кое-что уже публиковал, и нас вообще ругали, меня в первую очередь ругали, что, ребят, вы определитесь, пожалуйста, вы «Формулу-1» пытаетесь сделать – тогда давайте все параметры ядра тюнить и все такое прочее. Или вы пытаетесь на, условно говоря, не очень дорогой виртуалке выжать максимум, и тогда это просто немножко другой сегмент. То, что делал Николай, во многом напоминало, – мне не нравится сравнение с дешевой виртуалкой, но это действительно какие-то недорогие, вполне себе такие простенькие инсталляции, не огромные он-прем железки. И фактически этот кейс был максимально приближен к цели, которую ставила первоначальная статья: тоже взять готовые какие-то докер-образы, взять готовые конфигурации, почти ничего не тюнить, и на каких-то виртуалках, хотя там, правда, взяты были достаточно мощные виртуалки, провести эти тесты. А я просто-напросто, у нас в тестировании много чего тестируем, в том числе у нас в тестировании есть такое железо не супермощное, но достаточно веселое – ксеоны с 24 физическими ядрами и 48 виртуальными. И там достаточно много памяти, 128 гигов. Соответственно, можно наплодить много всякого интересного, но это в первую очередь, когда мы тестируем базы данных, потому что здесь это, в общем, нам не обязательно. Грубо говоря, для того чтобы нагрузить большим количеством RPS Postgres и создавать большое количество воркеров и при этом не упереться в память – вот для этого память нужна. Здесь нам память особо не нужна. Здесь нужен в первую очередь проц, потому что почти все нормально мультиплексирует и обрабатывает большое количество соединений, одновременно при этом рождая не так много тредов, процессов и так далее.
И моя цель заключалась в том, чтобы просто чекнуть между собой еще раз с такими же конфигурациями HAProxy и Angie и просто убедиться, что там нет того самого отличия, которое было в оригинальной статье, что там паритет, что, в общем-то, я и проверил.
Я действительно все собирал из сорцов, взял, по-моему, самые последние на тот момент версии Angie и HAProxy. До Caddy, Envoy, Traefik руки у меня не дошли. Может быть, дойдут когда-нибудь.
Кстати говоря, что я хотел бы перепроверить, просто как некое домашнее задание из того, что показал Николай, мне показалось странным, что Envoy для маленьких файлов выступил заметно хуже, чем HAProxy и Angie, потому что я как раз ожидал, что эта троица, HAProxy, Angie и Envoy, что они будут вместе, поскольку известно, что Angie, что HAProxy, они в cloud native окружении не очень хорошо себя ведут, потому что многих cloud native функций, в общем, просто нет. А вот эти новые современные сервера, они все нужные ручки динамического управления конфигурацией через API – они все поддерживают, но Traefik и Caddy, кажется, оба на чем-то типа Golang, на каком-то языке чуть помедленнее. А Envoy, я не помню, на С или на С++. Короче говоря, там технологии с точки зрения скорости такие же, что у HAProxy, у Angie. Я ожидал, что будет вровень, но проверю.
Далее, тестировал не wrk, который нагружает сколько можно, а на нашей сборкой wrkx. Ввзял Angie и HAProxy, и они абсолютно одинаково себя вели, какая-то разница была, может быть, даже еще меньше, чем что получилось у Николая. И единственное, где было заметное отличие, – все-таки на тех значениях, на которых я тестировал в тот момент, когда мы находились уже в некой зоне деградации перфоманса, – заметно у HAProxy увеличивалось latency, но при этом latency было не фатальное. То есть мы говорим о разнице типа 10 мс и 20 мс, что, в принципе, с точки зрения user experience, наверное, все-таки ни о чем.
Такие дела. Основную, самую главную вещь, которую я перепроверял, – это паритет Angie с HAProxy, вместо безоговорочного лидерства HAProxy, который каким образом взялся в первом исследовании и выглядел как досадное недоразумение с конфигурацией nginx.
Думаю, что в большей степени это была проблема того, что для того чтобы выключить логи, в Nginx и Angie нельзя просто взять и убрать конфигурацию, там необходимо явно это прописать. И мне кажется, это была основная фатальная ошибка ребят из MeshLab. А если бóльшую часть таких проблем, в первую очередь, эту и остальные, тоже пофиксить, то у проектов паритет. Здесь мы просто на on-prem инсталляции, на собственном железе, на совершенно другом подходе, то есть и инструмент тестирования другой, и бинари берем не Docker, а просто собираем последние стабильные версии, в общем-то, просто перепроверили, что все то же самое.
Но при этом, конечно, там уже сотни тысяч RPS, под 300000, с https и сжатием.
Николай Лавлинский: Я тогда сейчас тоже перейду к тому, что мы выяснили. Это к вопросу о том, что бенчмарки полезно и надо проводить. Хотя мне кажется, их недостаточно даже. Пусть будут они даже немного ошибочны. Главное, чтобы была понятна методология. Так вот что мы нашли. Например, эта проблема с zstandard в Traefik. Здесь, опять же, надо разбираться, но просто не могли закончить даже короткий тест, сжирается память. Возможно, это что-то с уборкой мусора связанное, с работой, так как он на Go, что-то из этого.
У HAProxy, опять же, что интересно, почему он неплохо себя показывает во многих тестах, особенно без всяких настроек, я уже раньше проводил сравнение, у меня был отдельный ролик, Angie с HAProxy, тоже я закопался в эту тему. И там выяснилось, что в HAProxy есть библиотека, которая занимается сжатием в формате zip, но она сжимает хуже, но гораздо быстрее, чем обычный zlib, который стандартно стоит и в Nginx, в Angie, из коробки, и то есть даже гораздо быстрее, чем единица, самый низкий коэффициент сжатия. Причем HAProxy делает это еще таким образом, что при нагрузке он может отключать это сжатие вообще. И если мы посмотрим на трафик, а трафик мы тоже снимали при тестах, и при том что RPS примерно одинаковый, допустим, в 100-килобайтом тесте трафик у HAProxy был заметно больше. То есть, с одной стороны, иногда почему-то я видел в некоторых тестах трафик от прокси, величину трафика, воспринимают как положительное такой параметр, то есть чем больше трафик, тем больше он трафика отдал. Это, конечно, хорошо, что он его отдал, но если у нас сжатие, значит, он хуже сжимает, значит, клиенту надо будет больше получать. Мы больше грузим каналы и все остальное. То есть трафик для нас ни в коем случае не является позитивным критерием для сравнения. Наоборот, чем больше трафик при тех же RPS такого же содержания, тем хуже. Поэтому здесь у HAProxy минус.
Мы в данном случае сетью не были ограничены, у нас в районе 10 гигабит точно спокойно эта программная сеть давала на этой машине без вопросов. Поэтому сеть нас не ограничивала.
Касательно лидеров, Angie и HAProxy, они где-то рядом с разными соотношениями по задержкам, по RPS. Но сразу скажу, что у HAProxy при тестах, даже при этих показателях, слегка не хватает утилизации процессора. То есть такое ощущение, что он может больше, но, как ни странно, он почему-то где-то в четыре потока на этой виртуалке себя ограничивает. Даже если ему принудительно сказать: больше потоков, все равно почему-то в районе 400% процессора потребляет, хотя мог бы, в принципе, побольше. Но это тоже, в общем, некая задача его дожать, добить. Хотя по умолчанию он должен автоматически определять количество процессоров и, собственно, с ними работать.
Третье место. Здесь по-разному, сильно меняется соотношение. Это опять же в пользу того, что надо делать разные сценарии. Желательно, чтобы они были более-менее приближенные к реальности и более-менее разнообразные. Вот, например, здесь для нас очевидно, будет влиять размер ответа. А если вдруг мы захотим, например, ответ в пару мегабайт, то, может быть расклад будет еще третьим по вариантам, если мы видео будем раздавать. То есть здесь размер ответа – это была правильная гипотеза, что надо ввести разные типы запросов и на них замерять. Опять же, тестировать на 60 байтах, на некоем вырожденном ответе, кажется, нет смысла, потому что непонятно, что мы тестируем, какие-то там внутренние механизмы, только какой-то микробенчмарк, получается, уже.
И что самое интересное, когда мы тестировали Angie, мы первоначально увидели провал в производительности, не такой, как в исходной статье, но все-таки в районе 40% Angie отставал от HAProxy. И здесь имеется в виду 40% по отношению с тем, что мы сейчас получили. Оказалось, проблема была в том, что дефолтный образ, мы брали Angie latest, новейший просто дефолтный образ, из их же репозитория, и он оказался медленнее примерно на 40%, чем Angie на базе Debian или Ubunta. По-моему, там Ubunta была. То есть, казалось бы, всем известно, что контейнеры должны работать достаточно быстро. Мы считаем, что накладные расходы в контейнерах минимальные, что, в принципе, вроде бы и так. Но забавный вариант, что мы, подключая контейнер, по сравнению, например, с хостовым Angie или с другим образом теряем очень заметно в производительности. Пока причина до конца не известна, но есть предположение, что это библиотека musl: https://en.wikipedia.org/wiki/Musl, которая в Alpine есть. Но Alpine – это рекомендованный дистрибутив для сборки образов докера. Такой всем известный хороший вариант.
То есть такие вещи можно найти, казалось бы, при бенчмарке, когда мы совсем другие вещи смотрим.
Дальше можно, собственно, в процессе бенчмарка смотреть на утилизацию процессора, ресурсов, всего остального. Здесь нет данных по памяти, но по памяти там, в общем, все довольно-таки компактно было, кроме выброса с трафиком. Если надо, если есть конкретный интерес, мы можем сейчас тоже позапускать, что-то посмотреть.
Про домашнее задание. Алексей говорил, я себе тоже выписал, что можно еще поковырять. Во-первых, TLS-библиотеки. Вот здесь есть статья на блоге HAProxy про разные SSL-библиотеки, и там довольно грустный вывод, что современный open ssl сильно деградировал в производительности, поэтому форки сильно вперед вырываются. И конкретно для HAProxy там есть benchmark как раз библиотек. А вот интересно, как это будет влиять, например, на Angie, на другие сервера, наверное, тоже заметно будет влиять. То есть сейчас целые варианты. По-моему, лидером теперь стал AWS-LC библиотека. Это такой топ, это что-то типа форка BoringSSL, который еще доработан для работы на железе AWS и плюс еще свои низкоуровневые оптимизации, она там просто всех рвет. По крайней мере, в хендшейках.
Мы не тестировали хендшейки. То есть хендшейки – это отдельная задача, но это будет, по сути, показывать возможность выброса новых подключений, если будут такие пикообразные нагрузки, разные шифры их влияния, так как мы опять же практически всегда с TLS работаем. Мы выбрали достаточно быстро шифр и его выровняли, а можно использовать разные и посмотреть. Опять же, это, наверное, как-то пересекается вместе еще с библиотеками, как они там будут работать.
Мы не говорили про HTTP2 и HTTP3, потому что wrk работает с HTTP1.1. То есть мы такой олдскуль тестировали. Но HTTP2 тоже можно погонять, он у нас формально настроен в серверах, но он не был задействован с точки зрения wrk как клиент.
Это тоже может влиять, потому что протокол тяжелый, что этот, что другой и HTTP3 еще на udp работает, то есть там могут быть интересные вещи. И опять же, это будет ближе к браузерам, потому что браузеры сегодня их будут использовать.
Варианты сжатия. Мы взяли доступный, быстрый вариант для всех, а можно на другие смотреть, на какой-то баланс между скоростью и эффективностью сжатия. Но это уже будет, скажем, ближе в сторону оптимизации для клиентов, чем серверная оптимизация, потому что серверная, естественно, мы ставим на минимум компрессию.
Размеры ответов сильно влияют. И опять же, можно взять другой диапазон – тоже посмотреть, что это будет.
Можно из этого сделать сравнение, которое тоже почему-то редко проводят. Я видел лично вот одну такую бумажку научную, где сравнивается производительность на хостовой системе против докера, разные варианты сетей, и, например, ту же виртуалку можно с хостом сравнить, растянутой примерно на такое же количество процессоров. В общем, вот эти варианты тоже – это как прикладная задача тоже довольно популярна.
Просто я сталкиваюсь с тем, что многие, когда рассказываешь про что-нибудь, возникает вопрос: а что быстрее? И люди вот так по слухам передают вот такие вот данные: кто-то сказал где-то, что вроде как так, и все начинают верить. Потом слух распространяется, и эта легенда так живет. А вот реально протестировать, как это вообще сделать, как привести конфиги, как посмотреть на результаты, об этом довольно мало говорят. Это считается просто как некоторая такая закрытая тема, что не надо туда лезть.
Понятно, что бенчмарк сложно проводить, у всех, естественно, могут быть какие-то сбои, неполнота учета факторов, но все-таки считаю, надо их делать, продвигать, это лично мне всегда интересно.
Для удобства читателей мы исключили ответы на вопросы, и без них статья получилось длинной. Вопросы и ответы можно посмотреть в записи трансляции: https://www.youtube.com/watch?v=LYzrxkSZ8Cs. Надеюсь, эта статья снимает многие вопросы производительности балансеров. Будем рады ответить на ваши вопросы в комментариях.