На прошлой неделе был опубликован перевод статьи двухлетней давности Анализ производительности WSGI-серверов: Часть вторая, где незаслужено был обделен славой uWSGI.

Необходимо срочно перепроверить тесты!

Цели

Изначально, я просто хотел воспроизвести тесты, и разобраться, что не так с uWSGI.
В коде отсутствуют версии используемых пакетов и модулей.

Поэтому, запустить тесты и получить аналогичные результаты — не получиться.
Далее мой квест, по запуску тестов и сравнение результатов на графиках.

Шаги

wrk 4.1.0

Найти спеки, пропатчить, собрать
Информация добавлена в readme.rd.

docker stats

За 2 года изменился вывод статистики.

Была добавлена вторая колонка NAME, и это сломало парсер статистики.

Что бы через два года не встретить подобную проблему, будем использовать форматированный вывод:

- docker stats > "$BASE/$1.$2.stats" &
+ docker stats --format "{{.CPUPerc}} {{.MemUsage}}" > "$BASE/$1.$2.stats" &

И соответственно, немного упростим код парсера.

debian

Сейчас latest образ debian соответствует версии 9.5, отобразим это в Dokerfile:

- FROM debian
+ FROM debian:9.5

В апреле 2016 latest соответствовал версии 8.4

Тем не менеее, Аpache остался почти тем-же: сейчас версия Apache 2.4.25, а в 2016 это был Apache 2.4.10.

cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi

Даже нет смысла говорить о том, что модули изменились.
Укажем текущие версии:

- RUN pip install cherrypy tornado uwsgi gunicorn bjoern meinheld mod_wsgi
+ RUN pip install cherrypy==17.4.0 
+                 tornado==5.1.1 
+                 uwsgi==2.0.17.1 
+                 gunicorn==19.9.0 
+                 bjoern=2.2.3 
+                 meinheld==0.6.1 
+                 mod_wsgi==4.6.5

Было бы не плохо вынести это в отдельный requirements.txt, но пока оставим так.

cherrypy -> cheroot.wsgi

Как было показно выше, актуальная версия 17.4.0.
В апреле 2016 вероятно использовалась версия v5.1.0.
А в 2017 году, в версии 9.0 произошли изменения, что отразилось на импорте сервера:

- from cherrypy import wsgiserver
- server = wsgiserver.CherryPyWSGIServer(
+ from cheroot.wsgi import Server as WSGIServer
+ server = WSGIServer(

Socket errors: read 100500

После описанных выше правок был запущен первый полноценный тест.
Результаты были хороши: uwsgi выдавал не 3...200, а 7500...5000 запросов в секунду.
Но при детальном рассмотрении полученных графиков, оказалось, что все ответы wrk детектил как ошибки чтения.

После проверки десятка ключей запуска uwsgi, выяснилось, что ошибок нет при включении http1.1: --http-keepalive и --http11-socket.
Причем, первый дает 7500...5000 запросов в секунду, а второй стабильные 29 тысяч!

что же изменилось в uWSGI на данный момент

Наиболее вероятно, что в августе 2016 использовалась версия uWSGI 2.0.12 (20151230).
После, в мае, вышла uWSGI 2.0.13.

Это было знаковое событие, но проблему производительности по версии wrk это не решало вплоть до 2018 года, выходом uWSGI 2.0.16:

Back-ported HTTP/1.1 support (--http11-socket) from 2.1

Вот почему uWSGI рекомендовали использовать с NginX,
А почему это важно в рамках статьи, можно понять из этого тикета 2012 года.

Почему тогда были такие результаты

Я пробовал такие версии:

• 2.0.12 для debian 8.4, на девятке она не собирается из-за свежей openssl.
• 2.0.13...2.0.17 для debian 8.4 и 9.5

Но таких плохих результатов, как 3...200 запросов в секунду, мне получить не удалось.
Внимание привлекла строка запуска приложения:

uwsgi --http :9808 --plugin python2 --wsgi-file app.py --processes ...

Указание подключаемого плагина, говорит об установке uwsgi из репозитория, а не pip.
Это может свидетельствовать об отсутствии у автора необходимого опыта работы с данным стеком.

Поэтому, допускаю несколько возможностей:

• тест каждого из uwsgi-серверов производился по отдельности, в разное время.
• имел место какой-то конфликт системной версии uwsgi, и установленой через pip.
• версия wrk автора в 2016, имела какие-то особенности для работы по http1.0
• uwsgi запускался с другим набором параметров
• заказная статья, цифры с потолка.

Какие результаты сейчас

uWSGI на графиках несколько:
Первый uWSGI (v2.0.17.1), выполнялся в долгом тесте, со своими конкурентами, с параметрами:
--http11 :9808 --processes 5 --threads 2 --enable-threads.

Потом отдельно был протестирован без тредов:
uWSGIbase (v2.0.17.1), без threads: --http11 :9808 --processes 5.

И, отдельно, версиии uWSGI 2016 года:
uWSGI-v2.0.12th-old и uWSGI-v2.0.12nt-old — соответственно v2.0.12 с тредами и без в контейнере debian 8.4.

uWSGI занимает 2е место, не снижая результатов при увеличении нагрузки.

В low-сегменте uWSGI-v2.0.12 лучше всех, даже при увеличении нагрузки.

uWSGI и CherryPy несомненные победители по latency.

Эта картинка аналогична 2016-му году.

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

А новый uWSGI "держит планку", и это о многом говорит.

Cтарые uWSGI начинают резко набирать ошибки уже после 300 открытых соединений.

Bjoern начинает сдавать с 1000 соединений.

А вот с новым uWSGI странности, начиная 200 соединений, мы получаем 50 ошибок, и число больше не увеличивается. Этот момент требует детального рассмотрения.

Все данные собраны тут

Выводы

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

Автор: BOPOHA

Источник