Битва 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. Об этом расскажем в следующей статье.

    UltraVDS
    123,87
    Хостинг виртуальных серверов (VDS, VPS)
    Поделиться публикацией

    Похожие публикации

    Комментарии 10

      0
      «около 540ггц на ядро»?
        0
        Большая часть тестов выполнена именно в таком формате, но есть замеры и без ограничений, они идут первыми.
          +1
          КДПВ с коровой (?), натянутой на глобус, подтверждает.
          0
          На серверы устанавливался лимит в 10, 5 и 1 процент от ядра на 8, 4 и одном ядре. В качестве тестового стенда был компьютер с 9900K@5400ггц, что означает, что сервер получивший ограничение в 10%, получает около 540ггц на ядро.

          Так вот оно какое будущее…
            +1
            Возможно, недалёкое. Опечатку, все же, поправили.
            0

            Привет от H2O


            image

              0
              В тесте реально нет смысла. Кому нужна статика? С ней нет проблем.
              Закешировал на NGINX и вперед.
              Создайте приложение, которое делает что-то банальное типа string.replace, и проверьте. И тут уже всем нужен бекенд. NGINX-у апстрим, IIS-у ASP.NET. Вот тут будет интересно посмотреть.
                0

                А для чего ограничивалось цпу? И в чем смысл текста ttfb без кеша?

                  0
                  Мы пытались измерить скорость самого веб сервера, иначе бы мы измеряли железо.
                  На нормальных тактовых частотах разница между ними не так заметна.
                  0

                  Патчи от Spectre, Meltdown и других были? Паритет по патчам между Linux и Windows был, или чего-то недостает?

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

                  Самое читаемое