В моём предыдущем материале речь шла о сравнении производительности ASP.NET Core-приложений, запускаемых в Windows и в среде Linux + Docker, работающих в службе приложений Azure. Эта тема интересна многим — поэтому я решил написать продолжение.
Я снова провёл испытания, используя подход, отличающийся от прежнего лучшей воспроизводимостью, такой, который даёт более надёжные результаты. Теперь я генерирую веб-нагрузку на серверы с помощью облачных инструментов Azure Cloud Agents, применяя Visual Studio и VSTS. И, более того, в то время как ранее я выполнял тесты с использованием HTTP, теперь тестирование проводилось с применением HTTPS.
Благодаря отличной работе, проведённой Microsoft, запуск тестов в облаке — это очень просто. Делается это с помощью инструментов Visual Studio Web Performance, с использованием учётной записи VSTS. Я провёл по две серии нагрузочных тестов для каждого из следующих сценариев:
Вот как были настроены тесты:
Результаты тестов (оригинал)
Среди выходных данных тестов были сводные показатели, имеющие практическую ценность, отчёты об ошибках и о нарушениях ограничений, касающихся ресурсов, выделенных системам (например — слишком большая нагрузка на CPU).
Пример выходных данных теста (оригинал)
Я использовал те же тесты, которые применялись в прошлый раз (найти соответствующий код можно здесь).
Что же у меня получилось теперь?
Полученные в этот раз результаты согласуются с теми, которые были получены в прошлый раз, при использовании клиентской системы, подключённой к интернету по проводной сети. А именно, ASP.NET Core-приложение, развёрнутое в Linux с применением Docker-контейнера, оказывается гораздо быстрее, чем оно же, развёрнутое на Windows-хосте (оба варианта работают в рамках соответствующего плана служб приложений). Результаты новых тестов даже сильнее, чем результаты прежних, указывают на превосходство Linux-варианта, особенно — при работе с запросами, предусматривающими возврат ответов с более объёмными телами.
Вот сводные результаты испытаний, отражающие количество запросов, обработанных в секунду (RPS).
Вот — среднее время ответа (мс).
Запросов в секунду, средний показатель (больше — лучше)
Время, в течение которого обрабатываются 95% запросов (меньше — лучше)
Вот — .xlsx-файл с результатами тестирования, а вот — аналогичный .ods-файл.
Почти все нагрузочные тесты на Linux-хосте приводили к превышению допустимой нагрузки на процессор (Processor\% Processor Time) с выдачей соответствующих предупреждений. При этом ни один из тестов, проводимых на Windows-хосте, не привёл к появлению подобных предупреждений. Я не вполне уверен в том, что правильно понял документацию по этому показателю производительности, по умолчанию включаемому во все новые нагрузочные тесты, создаваемые в Visual Studio. Если кто-то в этом разбирается — буду благодарен за пояснения.
Я обратил внимание на странную закономерность в графиках VSTS, отражающих производительность и пропускную способность систем в ходе нагрузочного тестирования. В случае с Linux-системами эти графики представляют собой довольно-таки плавные линии. А вот Windows-графики напоминают нечто вроде «пил». Вот соответствующие графики для сценария, в котором в теле ответа содержится 10 Кб данных.
Графики производительности и пропускной способности для Linux
Графики производительности и пропускной способности для Windows
Другие графики можно найти здесь. Вот графики (Linux и Windows) для сценария, где в теле ответа содержится 50 Кб данных.
В свете моих предыдущих испытаний учитывая полученные здесь результаты, могу сказать, что, с точки зрения производительности, в Azure оправдано использование конфигурации Linux + Docker.
Мне нет никакой выгоды от того, чтобы представить Linux в более выгодном свете, чем Windows. Я опубликовал все исходные коды моих тестов и инструкции, касающиеся воспроизведения тестового окружения. Если кто-то подозревает, что я где-то что-то «подкрутил», или сделал что-то неправильно — пусть повторит мои тесты и укажет на мою ошибку. И будет неплохо, если кто-нибудь проведёт проверку моих результатов.
Я решил провести эти тесты производительности и опубликовать результаты лишь из-за того, что планирую создать веб-сервис для приложения, написанного мной на Python. Мне было интересно узнать о том, удастся ли мне получить удовлетворительные результаты в среде Azure с использованием Linux-хоста, на котором работает Docker. Для разработки моего сервиса я планирую использовать PyPy 3, Gunicorn, Gevent и Flask. И я полагаю, что проект, основанный на этом стеке технологий, будет работать быстрее аналогичного ASP.NET Core-проекта, использующего сервер Kestrel. Но это — уже совсем другая история, и чтобы говорить об этом с уверенностью — надо провести соответствующие тесты.
Какими стеками технологий вы пользуетесь для разработки веб-сервисов?
Я снова провёл испытания, используя подход, отличающийся от прежнего лучшей воспроизводимостью, такой, который даёт более надёжные результаты. Теперь я генерирую веб-нагрузку на серверы с помощью облачных инструментов Azure Cloud Agents, применяя Visual Studio и VSTS. И, более того, в то время как ранее я выполнял тесты с использованием HTTP, теперь тестирование проводилось с применением HTTPS.
Выполнение тестов в облачной среде
Благодаря отличной работе, проведённой Microsoft, запуск тестов в облаке — это очень просто. Делается это с помощью инструментов Visual Studio Web Performance, с использованием учётной записи VSTS. Я провёл по две серии нагрузочных тестов для каждого из следующих сценариев:
- Ответ, в теле которого содержится текст
Hello Worldи отметка времени. - Ответ с телом в 1 Кб.
- Ответ с телом в 10 Кб.
- Ответ с телом в 50 Кб.
- Ответ с телом в 100 Кб.
Вот как были настроены тесты:
- Тесты выполнялись по 5 минут.
- В начале количество пользователей равнялось 50.
- Каждые 10 секунд количество пользователей увеличивалось на 10.
- Максимальным количеством пользователей было 150.
- Запросы выполнялись из того же региона (Western Europe), где были развёрнуты исследуемые приложения.
Результаты тестов (оригинал)
Среди выходных данных тестов были сводные показатели, имеющие практическую ценность, отчёты об ошибках и о нарушениях ограничений, касающихся ресурсов, выделенных системам (например — слишком большая нагрузка на CPU).
Пример выходных данных теста (оригинал)
Я использовал те же тесты, которые применялись в прошлый раз (найти соответствующий код можно здесь).
Что же у меня получилось теперь?
Анализ результатов
Полученные в этот раз результаты согласуются с теми, которые были получены в прошлый раз, при использовании клиентской системы, подключённой к интернету по проводной сети. А именно, ASP.NET Core-приложение, развёрнутое в Linux с применением Docker-контейнера, оказывается гораздо быстрее, чем оно же, развёрнутое на Windows-хосте (оба варианта работают в рамках соответствующего плана служб приложений). Результаты новых тестов даже сильнее, чем результаты прежних, указывают на превосходство Linux-варианта, особенно — при работе с запросами, предусматривающими возврат ответов с более объёмными телами.
Вот сводные результаты испытаний, отражающие количество запросов, обработанных в секунду (RPS).
| Сценарий | Linux | Windows | Linux +% |
| Hello World | 646,6 | 432,85 | +49,38% |
| Ответ с телом в 1 Кб | 623,05 | 431,95 | +44,24% |
| Ответ с телом в 10 Кб | 573,6 | 361,9 | +58,5% |
| Ответ с телом в 50 Кб | 415,5 | 210,05 | +97,81% |
| Ответ с телом в 100 Кб | 294,35 | 143,25 | +105,48% |
Вот — среднее время ответа (мс).
| Сценарий | Linux | Windows | Linux +% |
| Hello World | 168,85 | 242,2 | -30,28% |
| Ответ с телом в 1 Кб | 171,25 | 249,8 | -31,45% |
| Ответ с телом в 10 Кб | 184,2 | 292,7 | -37,07% |
| Ответ с телом в 50 Кб | 233,3 | 542,85 | -57,02% |
| Ответ с телом в 100 Кб | 365,05 | 817,35 | -55,34% |
Запросов в секунду, средний показатель (больше — лучше)
Время, в течение которого обрабатываются 95% запросов (меньше — лучше)
Вот — .xlsx-файл с результатами тестирования, а вот — аналогичный .ods-файл.
В чём Linux показывает себя хуже Windows (и так ли это на самом деле)?
Почти все нагрузочные тесты на Linux-хосте приводили к превышению допустимой нагрузки на процессор (Processor\% Processor Time) с выдачей соответствующих предупреждений. При этом ни один из тестов, проводимых на Windows-хосте, не привёл к появлению подобных предупреждений. Я не вполне уверен в том, что правильно понял документацию по этому показателю производительности, по умолчанию включаемому во все новые нагрузочные тесты, создаваемые в Visual Studio. Если кто-то в этом разбирается — буду благодарен за пояснения.
Странные графики, касающиеся производительности и пропускной способности Windows-системы
Я обратил внимание на странную закономерность в графиках VSTS, отражающих производительность и пропускную способность систем в ходе нагрузочного тестирования. В случае с Linux-системами эти графики представляют собой довольно-таки плавные линии. А вот Windows-графики напоминают нечто вроде «пил». Вот соответствующие графики для сценария, в котором в теле ответа содержится 10 Кб данных.
Графики производительности и пропускной способности для Linux
Графики производительности и пропускной способности для Windows
Другие графики можно найти здесь. Вот графики (Linux и Windows) для сценария, где в теле ответа содержится 50 Кб данных.
Итоги
В свете моих предыдущих испытаний учитывая полученные здесь результаты, могу сказать, что, с точки зрения производительности, в Azure оправдано использование конфигурации Linux + Docker.
Заключительные замечания
Мне нет никакой выгоды от того, чтобы представить Linux в более выгодном свете, чем Windows. Я опубликовал все исходные коды моих тестов и инструкции, касающиеся воспроизведения тестового окружения. Если кто-то подозревает, что я где-то что-то «подкрутил», или сделал что-то неправильно — пусть повторит мои тесты и укажет на мою ошибку. И будет неплохо, если кто-нибудь проведёт проверку моих результатов.
Я решил провести эти тесты производительности и опубликовать результаты лишь из-за того, что планирую создать веб-сервис для приложения, написанного мной на Python. Мне было интересно узнать о том, удастся ли мне получить удовлетворительные результаты в среде Azure с использованием Linux-хоста, на котором работает Docker. Для разработки моего сервиса я планирую использовать PyPy 3, Gunicorn, Gevent и Flask. И я полагаю, что проект, основанный на этом стеке технологий, будет работать быстрее аналогичного ASP.NET Core-проекта, использующего сервер Kestrel. Но это — уже совсем другая история, и чтобы говорить об этом с уверенностью — надо провести соответствующие тесты.
Какими стеками технологий вы пользуетесь для разработки веб-сервисов?
