О методике мы рассказывали в первой части статьи, в этой мы тестируем HTTPS, но в более реалистичных сценариях. Для тестирования был получен сертификат Let’s Encrypt, включено сжатие Brotli на 11.
На этот раз попробуем воспроизвести сценарий развертывания сервера на VDS или в качестве виртуальной машины на хосте с типовым процессором. Для этого устанавливали лимит в:
- 25% — Что в пересчете на частоту ~ 1350МГц
- 35% -1890Мгц
- 41% — 2214Мгц
- 65% — 3510Мгц
Количество единовременных подключений сократилось с 500 до 1, 3, 5, 7 и 9,
Результаты:
Задержки:
TTFB специально был вынесен качестве отдельного теста, потому что HTTPD Tools для каждого отдельного запроса создаёт как-бы нового пользователя. Этот тест все еще достаточно оторван от реальности, потому что пару страниц пользователь все равно кликнет, и в реальности главную роль сыграет TTFP.
Первый, вообще самый первый запрос после первого старта виртуальной машины IIS отрабатывает в среднем за 120 мс.
Все последующие запросы показывают TTFP в 1.5 мс. Apache и Nginx в этом отстают. Лично автор считает этот тест самым показательным и выбирал бы победителя только по нему.
Результат не является удивительным, так как IIS кэширует уже сжатый статический контент и не пережимает его каждый раз, как к нему обратились.
Время потраченное на одного клиента
Для оценки производительности достаточно и теста с 1 единовременным подключением.
К примеру, IIS завершил тестирование длинной в 5000 пользователей за 40 секунд, это 123 запроса в секунду.
В графиках ниже приведено время до полной передачи контента сайта. Это доля запросов, выполненных в определенное время. В нашем случае 80% всех запросов было обработано за 8мс на IIS и за 4.5мс на Apache и Nginx, а интервал до 8 миллисекунд выполнились 98% всех запросов на Apache и Nginx.
Время, за которое 5000 запросов были обработаны:
Время, за которое 5000 запросов были обработаны:
Если у вас есть виртуальная машина с 3.5Ггц ЦП и 8 ядрами, то выбирайте то, что хотите. Все веб серверы очень похожи в данном тестировании. О том, какой веб сервер выбрать для каждого хоста поговорим ниже.
Когда речь идет чуть более реальной ситуации, все веб серверы идут нос к носу.
Throughput:
График задержек от количества одновременных подключений. Ровнее и ниже – лучше. Последние 2% были выкинуты из графиков потому, что они сделают их нечитаемыми.
Теперь рассмотрим вариант, где сервер размещается на виртуальном хостинге. Возьмем 4 ядра по 2.2ГГц и одно ядро на 1.8Ггц.
Как масштабируются
Если вы когда-либо видали, как выглядят ВАХ электровакуумных триодов, пентодов и так далее, эти графики будут для вас знакомы. Именно это мы и пытаемся поймать – насыщение. Предел, когда сколько ядер не кидай, рост производительности не будет заметен.
Ранее весь челленж состоял в том, чтобы обработать 98% запросов имея наименьшую задержку по всем запросам, как можно ровнее держать кривую. Теперь с помощью построения другой кривой, найдем оптимальную рабочую точку для каждого из серверов.
Для этого возьмем показатель Requests per second (RPR). По горизонтали частота, по вертикали — количество запросов, обработанных за секунду, линии – количество ядер.
Показана корреляция насколько хорошо Nginx обрабатывает запросы один за другим. 8 ядер в таком тестировании показывают себя лучше.
На этом графике прекрасно видно, насколько лучше (не на много) Nginx работает на одном ядре. Если у вас Nginx, стоит задуматься об уменьшении количества ядер до одного, если вы хостите только статику.
IIS хоть и имеет самый низкий TTFB по мнению DevTools в Chrome, умудряется проиграть и Nginx и Apache в серьезной борьбе со стресс тестом от Apache Foundation.
Вся кривизна графиков воспроизводится железно.
Своего рода вывод:
Да, Apache железно работает хуже на 1 и 8 ядрах, а на 4 работает чуть лучше.
Да, Nginx на 8 ядрах обрабатывает лучше запросы один за другим, на 1 и 4 ядрах и хуже работает, когда соединений много.
Да, IIS предпочитает 4 ядра для многопоточной нагрузки и предпочитает 8 ядер для однопоточной. В конечном итоге IIS оказался чуть быстрее всех на 8 ядрах под высокой нагрузкой, хотя все серверы шли вровень.
Это не ошибка измерения, погрешность тут не более +-1мс. в задержках и не более +- 2-3 запроса в секунду для RPR.
Результаты, когда 8 ядер проявляют себя хуже, вовсе не удивительны, много ядер и SMT/Hyperthreading сильно ухудшают производительность, если у нас есть временные рамки, за которые мы должны завершить весь пайплайн.
Комментарии (13)
scorp13
27.12.2019 18:13Этот тест все еще достаточно оторван от реальности, потому что пару страниц пользователь все равно кликнет
Откуда такая уверенность?
apapacy
27.12.2019 18:32Поддержу тех кто спрашивал параметры конфигурирования ядра и конфиги nginx. По умолчанию эти параметры зажаты до весьма ограничепнных параметров, фактически для десктопа. Даже для разработки иногда не хватает например открытых файлов или watch files.
В противовес этому была взята система IIS Windows Server Core 2019 — то есть явно оптимизирована под серверную рпботу.
Первый, вообще самый первый запрос после первого старта виртуальной машины IIS отрабатывает в среднем за 120 мс.
Все последующие запросы показывают TTFP в 1.5 мс. Apache и Nginx в этом отстают. Лично автор считает этот тест самым показательным и выбирал бы победителя только по немуПоказательный запрос не кажется таким уж показательным. Он действительно был бы показательным, если бы происходило реальное тестирование тысячью независимых девайсов из сети с разными ip адресами. При тестирования стресс-тулзами фактически идет одна сессия и если правильно настроить nginx по сессиям SSL то все будет работать так же быстро.
С другой стороны если бы пользователь присоединялся с другого девайса пока что под вопросом сколько такой запрос проходил на ISS — могу предположить что те же 120мс
ultra_vds Автор
27.12.2019 23:23Все было дефолтным. Был только добавлен модуль для Brotli.
Мы сравниваем стоковый IIS со стоковым Apache и не мене стоковым Nginx.apapacy
27.12.2019 23:30+1Стоковый сконфигурированный как мощный сервер и стоковый сконфигурированный под десктоп
Если уже сравнивать по гамбургскому счету то было бы более справедливо одной команде например Вашей которая специализируется на винсерверах скофигурирывать пусть не стоково сервер на ISS и другой команде специализ рующейся на linux настроить нестоково ядро, apache и nginx.А третьей команде распределенной сетью ботов протестировать те же параметры.
Это было одно было бы обсуждать.
Neveil
28.12.2019 12:00А если бы стоково поставляли феррари на первой передачи и трактор, тоже бы так тестировали? Переключать нельзя, это же настройка!
akhkmed
28.12.2019 12:56Судя по КДПВ, у 6С33С есть вторичный пробой — с ростом напряжения максимальная рассеиваемая на аноде мощность резко снижается. Не ожидал, что вакуумные триоды могут быть недостаточно термостабильны.
Кстати, по току насыщения. Эта лампа является левой, поэтому тока насыщения не видно на семействе характеристик.
vp7
28.12.2019 18:19Разница в поведении nginx на 1 и на 8 ядрах говорит о том, что что-то нахимичено в системе виртуализации, причём сильно.
В настройках по умолчанию nginx использует 1 воркер и может работать только с одним ядром. Хотя… источник конфигов "по умолчанию" неизвестен, возможно там настроено другое количество воркеров.
И теперь вопрос к авторам тестов (если у вас именно умоляательные конфиги) — почему у вас наблюдается явный перекос в производительности одного ядра в одноядерной виртуалке и в многоядерной?
Тестировали на разных машинах с разной нагрузкой физического железа (к примеру, на многоядерной виртуалке соседние VM отжирали L2/L3 кеш)?
p.s. Предлагаю в той же конфигурации прогнать тест производительности виртуалок в однопоточном режиме, чисто прогон математики и скорости работы с RAM и дисковой подсистемой. Подозреваю, что будет сюрприз.
kolu4iy
М-м-м-м… Да. А конфиги где? А то «учёный изнасиловал журналиста» получается…
Поясняю: у nginx можно настроить количество воркеров по ядрам. А можно — не настроить.
Можно настроить backlog, а можно не настроить.
Кстати, на какой ОС? На windows? Там скажем сетевой стек наиболее неоптимален для nginx (если сравнивать с linux/xBSD системами)…
Я не то что горой за nginx — у него тоже есть свои слабые места — но правда, какой-то странный тест. Предыдущий тоже не лучше…
stavinsky
Поддержу. Измерения надо проводить на физ железе, а не на купленной впс с неизвестным гипервизором. Не известно как он ресурсы выдает гостевой машине и тд.
Плюс если ядер 8 с гипертредингом, не важно что за ПО но ядер в нем лучше указать 4, так как при хорошей такой нагрузке на проц, мы от использования гипертрединга можем только потерять.
Плюс настройки действительно важны.
P.S. что мы пытались тестировать? SSL терминацию? Отдачу статики?
Если SSL то наверное не хватает графиков скорости открытия соединения, времени установки ssl сессии тд
Ну и, возможно, стоило бы в таком случае добавить какой-нибудь haproxy в сравнение. Я бы на таких нагрузках все равно промежуточный прокси ставил даже перед nginx.
Ну и мне казалось IIS и Apache больше про сервер приложений, nginx больше про проксирование и отдачу статики
kolu4iy
Также не хватает списка поддерживаемых протоколов, настройки dh_params, алгоритмов шифрования и прочих интересных вещей, которые оказывают влияние конкретно на TTFB. Вопросов таки больше чем ответов…
ultra_vds Автор
В качестве операционной системы для Nginx и Apache выступает Ubuntu 18.04 LTS, для IIS Windows Server Core 2019.
На каждом из веб-серверов крутилась одна и та же страница, бесплатный шаблон для Jekyll от Codrops.
В этой части в методику были внесены изменения, которые и были описаны. Сама методика подробна описана в первой части.
Neveil
Нет ни одного конфигурационного файла и указаний версий софта. Методика явно не полная. Nginx также можно настроить, чтобы он не пережимал статику. В первой статье также этого нет.
Давайте в студию infrastructure as a code.