Комментарии 13
Поясняю: у nginx можно настроить количество воркеров по ядрам. А можно — не настроить.
Можно настроить backlog, а можно не настроить.
Кстати, на какой ОС? На windows? Там скажем сетевой стек наиболее неоптимален для nginx (если сравнивать с linux/xBSD системами)…
Я не то что горой за nginx — у него тоже есть свои слабые места — но правда, какой-то странный тест. Предыдущий тоже не лучше…
Плюс если ядер 8 с гипертредингом, не важно что за ПО но ядер в нем лучше указать 4, так как при хорошей такой нагрузке на проц, мы от использования гипертрединга можем только потерять.
Плюс настройки действительно важны.
P.S. что мы пытались тестировать? SSL терминацию? Отдачу статики?
Если SSL то наверное не хватает графиков скорости открытия соединения, времени установки ssl сессии тд
Ну и, возможно, стоило бы в таком случае добавить какой-нибудь haproxy в сравнение. Я бы на таких нагрузках все равно промежуточный прокси ставил даже перед nginx.
Ну и мне казалось IIS и Apache больше про сервер приложений, nginx больше про проксирование и отдачу статики
На каждом из веб-серверов крутилась одна и та же страница, бесплатный шаблон для Jekyll от Codrops.
В этой части в методику были внесены изменения, которые и были описаны. Сама методика подробна описана в первой части.
Этот тест все еще достаточно оторван от реальности, потому что пару страниц пользователь все равно кликнет
Откуда такая уверенность?
Поддержу тех кто спрашивал параметры конфигурирования ядра и конфиги nginx. По умолчанию эти параметры зажаты до весьма ограничепнных параметров, фактически для десктопа. Даже для разработки иногда не хватает например открытых файлов или watch files.
В противовес этому была взята система IIS Windows Server Core 2019 — то есть явно оптимизирована под серверную рпботу.
Первый, вообще самый первый запрос после первого старта виртуальной машины IIS отрабатывает в среднем за 120 мс.
Все последующие запросы показывают TTFP в 1.5 мс. Apache и Nginx в этом отстают. Лично автор считает этот тест самым показательным и выбирал бы победителя только по нему
Показательный запрос не кажется таким уж показательным. Он действительно был бы показательным, если бы происходило реальное тестирование тысячью независимых девайсов из сети с разными ip адресами. При тестирования стресс-тулзами фактически идет одна сессия и если правильно настроить nginx по сессиям SSL то все будет работать так же быстро.
С другой стороны если бы пользователь присоединялся с другого девайса пока что под вопросом сколько такой запрос проходил на ISS — могу предположить что те же 120мс
Мы сравниваем стоковый IIS со стоковым Apache и не мене стоковым Nginx.
Стоковый сконфигурированный как мощный сервер и стоковый сконфигурированный под десктоп
Если уже сравнивать по гамбургскому счету то было бы более справедливо одной команде например Вашей которая специализируется на винсерверах скофигурирывать пусть не стоково сервер на ISS и другой команде специализ рующейся на linux настроить нестоково ядро, apache и nginx.А третьей команде распределенной сетью ботов протестировать те же параметры.
Это было одно было бы обсуждать.
А если бы стоково поставляли феррари на первой передачи и трактор, тоже бы так тестировали? Переключать нельзя, это же настройка!
Кстати, по току насыщения. Эта лампа является левой, поэтому тока насыщения не видно на семействе характеристик.
Разница в поведении nginx на 1 и на 8 ядрах говорит о том, что что-то нахимичено в системе виртуализации, причём сильно.
В настройках по умолчанию nginx использует 1 воркер и может работать только с одним ядром. Хотя… источник конфигов "по умолчанию" неизвестен, возможно там настроено другое количество воркеров.
И теперь вопрос к авторам тестов (если у вас именно умоляательные конфиги) — почему у вас наблюдается явный перекос в производительности одного ядра в одноядерной виртуалке и в многоядерной?
Тестировали на разных машинах с разной нагрузкой физического железа (к примеру, на многоядерной виртуалке соседние VM отжирали L2/L3 кеш)?
p.s. Предлагаю в той же конфигурации прогнать тест производительности виртуалок в однопоточном режиме, чисто прогон математики и скорости работы с RAM и дисковой подсистемой. Подозреваю, что будет сюрприз.
Битва WEB серверов. Часть 2 – реалистичный сценарий HTTPS: