Битва WEB-серверов. Часть 1 – оторванный от реальности HTTP:

В этой статье мы попробуем себя в реверс-инжиниринге, можно сказать. Мы заглянем своими грязными руками под капот каждого из веб-серверов, эксплуатируя их так, как никто бы никогда не эксплуатировал.

Этот тест – замер сферического коня в вакууме, не более чем данные, которые были получены, и мы теперь не знаем, что с ними делать.

Методика

В качестве операционной системы для Nginx и Apache выступает Ubuntu 18.04 LTS, для IIS Windows Server Core 2019. Все операционные системы перед тестами получили последние обновления на состояние 04.12.2019.

Тесты проводились исключительно по HTTP. На каждом из веб-серверов крутилась одна и та же страница, бесплатный шаблон для Jekyll от Codrops. Ссылка. На каждом из веб-серверов было выключено сжатие gzip.

Тест пропускной способности проводился с Httpd-tools с аргументами:

ab -n 50000 -c 500 http://192.168.76.204:80/

На серверы устанавливался лимит в 10, 5 и 1 процент от ядра на 8, 4 и одном ядре. В качестве тестового стенда был компьютер с 9900K@5400мгц, что означает, что сервер получивший ограничение в 10%, получает около 540мгц на ядро.

Тест TTFB проводился при первой загрузке сервера и замерялся с помощью DevTools, после получения результата сервер выключался и откатывался на предыдущую контрольную точку, чтобы исключить появление любого рода кэшей.

Тестировщик и веб-сервер находились на одном и том же хосте и на одном и том же виртуальном свитче.

Чтобы сразу оценить дисковую подсистему, результаты бенчмарка ATTO и CrystalDIskMark, чтобы иметь понятие об узких местах.

Данные сняты с виртуальной машины:

Результаты:

TTFB:

Средний TTFB у IIS меньше всех, 0,5мс, против 1,4мс у Apache и 4мс у Nginx.

Throughput:

Сначала рассмотрим, насколько хорошо каждый из серверов масштабируется по количеству ядер.

На графике представлено количество обращений тестировщика к веб-серверу и латентность. На графике видно, что NGINX отработал 98% всех обращений, отдав сайт за 20мс и меньше. IIS как и Apache последние 5% из всех обращений отработали за 76мс и 14мс соответственно.

На графике показано среднее время обработки одного запроса во время стресс теста.

Как можно заметить из графиков, IIS продул и Apache и Nginx, сильно замедляясь под высокой нагрузкой. 

IIS явно предпочел 4 ядра перед восьмью, показав меньшие задержки на четырёх, но так же не сильно одобрил и одно ядро.

NGINX прекрасно масштабируется на все 8 ядер, а для Apache, судя по всему, одноядерный сценарий кажется наилучшим выбором.

Масштабируемость:

Nginx:

Теперь рассмотрим масштабируемость по частоте и количеству ядер. 

Тесты с ограничением в 1% на 4 и 1 ядра Nginx не прошел, выйдя за 2000 запросов он обрывал соединение с тестировщиком.

Apache:

Apache как Nginx обработав 2500 запросов сдался и разорвал соединение. Apache не прошел тест на 8, 4 и 1 ядрах с лимитом в 1%, но помимо этого не прошел и тест на 5% ограничении на одном ядре, что хуже чем  Nginx

IIS:

IIS по время тестов набрал гигантскую очередь из запросов но обработал каждый из них. Судя по всему, в нем из коробки не установлены таймауты на обработку запроса.

На диаграмме представлено время, за которое был завершен тест. Были отброшены совсем абсурдные конфигурации тестирования. Из диаграммы видно, насколько IIS требователен к железу, и насколько прекрасен NGINX.

Масштабируемость от диска:

Nginx:

Теперь рассмотрим масштабируемость по частоте и количеству ядер и скорости диска. 

На этот раз Nginx не прошел 4 теста, вместо двух.

Apache:

Apache провалил одинаковое количество тестов, как и в прошлый раз.

IIS:

IIS показывает почти идентичный график, будто ограничений на диск и не было. В целом, графики у всех серверов не сильно изменились, а это значит, что каждый из них закэшировал статику в оперативную память и отдавал оттуда. Тут мы видим главное узкое место – сам веб-сервер.

Выводы на основе этого тестирования делать рано, мы еще не протестировали HTTPS, компрессию и HTTP/2 с живым сертификатом от Let’s Encrypt. Об этом расскажем в следующей статье.

Источник: habr.com