GeezerVison

Содержание:

• Участники тестирования
• Методика тестирования
• Результаты
• Выводы

Участники тестирования

• Aiohttp 0.16.3 -- Асинхронный фреймворк базирующийся на Asyncio;
• Bottle 0.12.8 -- Быстрый, простой и легковесный WSGI микрофреймвок;
• Django 1.8.2 -- Веб-фреймворк для перфекционистов с горящими сроками;
• Falcon 0.3.0 -- Высоко-производительный фреймворк для построения облачных API;
• Flask 0.10.1 -- Микрофреймворк базирующийся на Werkzeug, Jinja2 и хороших намерениях;
• Muffin 0.0.88 -- Асинхронный фреймворк базирующийся на Asyncio и Aiohttp;
• Pyramid 1.5.7 -- Небольшой, быстрый и понятный веб-фреймворк;
• Tornado 4.2 -- Асинхронная сетевая библиотека и веб-фреймворк;

Методика тестирования

Тесты прогонялись на Amazon EC2 t2.medium сервере. Для создания нагрузки использовалась утилита WRK запущенная на том же сервере с параметрами:

wrk -d30s -t12 -c400 [URL]

Все приложения (кроме Tornado) запускались при помощи Gunicorn (2 процесса на каждое). Для синхронных WSGI библиотек использовался Meinheld worker.

Приложение на Tornado запускало 2 процесса, используя средства самого фреймворка.

Все тесты производились с использованием Python 3.4.

Каждое приложение тестировалось по трем основным сценариям:

• JSON-тест -- закодировать небольшой объект в JSON и вернуть клиенту.
• Remote-тест -- требуется загрузить ответ от другого сервера и вернуть его клиенту.
• Complete-тест -- Используя ORM загрузить коллекцию объектов из базы, добавить к ней еще один и отрендерить список в шаблоне.

Первый сценарий это своеобразный «Hello World!» лишь несколько усложненный процессом кодирования в JSON, что практически не влияет на результаты. Показывает именно быстродействие в плане обработке HTTP-запросов.

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

Третий сценарий предпалагается как комплексный тест и имитирует реальную жизнь, а именно использование базы данных, ORM, движка шаблонов.

В качестве базы данных использовался Postgresql с дефолтными настройками.

Исходники приложений можно найти на Github.

Результаты

В первом простом тесте с хорошим отрывом победили синхронные фреймворки. Не считая Django, но в оправдание последнего, можно сказать, что по-умолчанию этот фреймворк делает множество работы (middlewares by default). Асинхронные фреймворки делят места аутсайдеров и неожиданно для меня на последнем месте оказался Tornado. Очень хорошие результаты у Falcon и Bottle.

Для понимания результатов следующего теста необходимо пояснить, что приложения обращались к nginx настроенному на ответ с задержкой 100ms. Из-за этого результаты синхронных фреймворков очень близки, практически вся их работа после определенного момента сводилась к ожиданию. Опять неожиданные результаты от Tornado, я предполагал, что он будет близок к Aiohttp и Muffin. Но тем неменее Tornado в 10 раз эффективнее в этом кейсе чем ближайший синхронный фреймворк.

И последний тест. Результаты Aiohttp можно игнорировать тк к сожалению более двух третей запросов вернули 502 ошибки. На первом месте неожиданно, но приятно, оказался мой фреймворк Muffin достаточно быстро обрабатывающий этот тест. Django значительно проигрывает, лишь подтверждая медлительность стандартного движка шаблонов и ORM.

Выводы

Я предлагаю читателю сделать их самостоятельно. Данное тестирование производилось мой чтобы понять выгоду использования синхронных/асинхронных библиотек и показатели производительности популярных решений.

В дальнейшем планирую проводить данные измерения регулярно.