Измеряем пропускную способность веб-серверов и каркасов приложений на Python.
Не так давно я набрёл в сети на слайды доклада Брайана МакДоннелла, представленного ещё в 2013-м году на PyCon Ирландия. Доклад назывался «Максимальная пропускная способность: базовые затраты на веб-каркасы».

Мне стало интересно, как изменилась пропускная способность с тех пор (в свете выхода новых версий компонентов) и изменилась ли вообще. И вот я накидал небольшое приложение, позволяющее быстро описывать стенды и веб-каркасы, и удобно замерять пропускную способность на этих стендах.

Так появилось narrow.

Внимание
Здесь и далее стоит смотреть не на конкретные цифры, а на расположение линий друг относительно друга — всё познаётся в сравнении. Кроме того, надобно вам знать, что все компоненты настраивались минимально, то есть, приближены к состоянию «из коробки».

Действие первое


Давайте для разминки на минимальном wsgi-приложении поглядим, какой вариант обращения к нему самый быстрый.

https://c.radikal.ru/c35/1806/a6/9b49aa2848c9.png

Из графика видно, что быстрее всего работает uWSGI без Nginx. Все знали, что так можно?
Далее идут результаты замеров работы по протоколу uwsgi (собственный двоичный протокол uWSGI) через Nginx.
Согласно этим результатам, использование unix-сокета вместо TCP положительно сказывается на скорости. Более того, даже шифрованное соединение по unix-сокету быстрее нешифрованного по TCP.

Вывод 1: рассматриваем целесообразность использования только uWSGI, если нужен Nginx, то используем протокол uwsgi и unix-сокет.


Действие второе


Далее взглянем на то, как показывают себя каркасы на чистом uWSGI.
https://c.radikal.ru/c29/1806/6d/ee0a6c47fdfd.png

На первом месте, минимальное приложение без каркаса, что не удивительно. Далее лёгкий и пустой Bottle — тоже предсказуемо.
А вот дальше почти ноздря в ноздрю идут Django и Flask. Неплохой удар по мифу о том, что Джанго тяжёлый, а Фласк лёгкий, как считаете?
CherryPy в хвосте.

Вывод 2: Django с огромной горой батареек и большущим сообществом по-прежнему хорош и ещё повоюет.

Действие третье


Поглядим, как покажут себя каркасы, если запрос пойдёт через Nginx, который обращается к uWSGI через unix-сокет, используя протокол uwsgi:

https://d.radikal.ru/d17/1806/15/37923936f28d.png

Ну, здесь всё практически также, как и во втором действии.

Вывод 3: Связка Nginx->unix-сокет->uwsgi->uWSGI показывает себя весьма неплохо. Можно брать.


Эпилог


Интерактивный график (возможно даже уже более свежий, чем показанные выше картинки) с более детальной информацией о версиях компонентов доступен здесь — https://idlesign.github.io/narrow/

Если есть желание поучаствовать в narrow — добавить каркас, веб-сервер, подкрутить, починить, улучшить — милости прошу в репозиторий.

Антракт.
На заметку
Зарегистрированные пользователи могут получать еженедельный дайджест обновлений на сайте.