CC BY
90STUD NET
ИСПОЛЬЗОВАНИЕ СТАНДАРТА WSGI ПРИ РАЗРАБОТКЕ ВЕБ-
ПРИЛОЖЕНИЙ НА PYTHON
USING THE WSGI STANDARD WHEN DEVELOPING WEB APPLICATIONS IN PYTHON
УДК-004
Самородских Илья Леонидович, Бакалавр, Московский Государственный Технический Университет им Н.Э. Баумана, Россия, г. Москва Smorodsky Ilya Leonidovich, ilyasam! 8@gmail.com
Аннотация
В настоящей статье был изучен стандарт вызовов для веб-серверов для пересылки запросов в веб-приложения или фреймворки, написанные на языке программирования Python называемый WSGI. Была проанализирована структура работы компонентов стандарта WSGI и проведено сравнение нескольких серверов WSGI.
Annotation
In this article, we studied the standard for web server calls to forward requests to web applications or frameworks written in the Python programming language called WSGI. The structure of the WSGI standard components was analyzed and several WSGI servers were compared. Ключевые слова: веб-фреймворк, веб-сервер, python, wsgi. Keywords: web framework, web server, python, wsgi.
Разработчики несут ответственность за создание надежных, масштабируемых и поддерживаемых веб-приложений, веб-ресурсов и динамических веб-сайтов через сложные и современные веб-фреймворки. Эти веб-фреймворки поставляются с набором компонентов кодирования и набором базовых инструментов структурирования, которые помогают упростить веб-разработку. Эти структуры могут решать проблемы и задачи с помощью языков программирования, которые соответствуют их потребностям.
Python является одним из таких языков программирования. Основными причинами его успеха являются динамическое поведение, которое помогает многоцелевому языку программирования, универсальность в написании сценариев и его мощная природа. Большинство доступных фреймворков на языке не совместимы.
Python работает на серверах WSGI, которые определяют способ взаимодействия веб-сервера с приложениями. Производительность стека Python сильно зависит от сервера WSGI. 1 Стандарт WSGI
1.1 Исследование создания стандарта WSGI
Раньше традиционный веб-сервер не имел возможности запускать приложения, написанные на языке программирования Python. В конце 1990-х разработчик по имени Гриша Трубецкой предложил модуль для веб-сервера Apache под названием mod_python для выполнения произвольного кода Python. В течение нескольких лет в конце 1990 -х и начале 2000-х Apache, настроенный с помощью mod_python, запускал большинство веб-приложений Python. Были и другие средства для связи веб-сервера, и веб-приложения.
Но в Python-приложениях был один существенный недостаток — отсутствие совместимости. Он был разработан только для одного FastCGI, mod_Python, CGI или других API конкретного веб-сервера, и они не допускали взаимозаменяемости. Модуль Apache mod_Python не был официальной спецификацией, и в нем были проблемы с безопасностью. Здесь и появился WSGI. У него был стандартный интерфейс для маршрутизации веб-приложений и фреймворков на веб-серверы. Фреймворк берет свое начало от CGI, или Common Gateway Interface, и использовался на заре Интернета. Успех CGI был в том, что он мог работать со многими языками, но недостатком было то, что он был медленным и ограниченным.
Стандарт WSGI, созданный Филиппом Дж. Эби и опубликованный 7 декабря 2003 г., представляет собой интерфейс шлюза веб-сервера, который объясняет, как веб-сервер взаимодействует с веб-приложениями и как приложения могут быть объединены в цепочку для генерации запросов.
1.2 Преимущества стандарта WSGI
У стандарта WSGI имеется ряд преимуществ перед предшественниками. Ниже представлен их список с пояснением:
— гибкость. Одним из самых больших преимуществ, которые дает WSGI, является гибкость. Фактически можно изменить компоненты веб -стека, не меняя код и даже не меняя приложение, на котором работают серверы WSGI;
— масштабируемость. Фреймворки не могут обрабатывать слишком много запросов. Но серверы WSGI могут, и они могут одновременно
обрабатывать тысячи запросов и направлять их с веб-сервера наилучшим из возможных способов;
— скорость. Стандарт WSGI помогает ускорить разработку веб -приложений на Python, потому что достаточно знать основы работы интерфейса. Многие веб-фреймворки Python поставляются с адаптером WSGI, а серверные технологии, такие как Apache, mod_python, FastCGI, CGI и т.д., могут запускать WSGI-приложение;
— простота. WSGI прост в изучении, что облегчает его освоение, не требуя настройки или установки. Это одно из самых больших преимуществ WSGI, и разработчики искренне поддерживают его.
— многоразовое ПО. Можно улучшить функциональность WSGI с помощью существующих компонентов промежуточного программного обеспечения, таких как аутентификация/авторизация, кэширование, фильтрация и т.д. Функция повторного использования экономит время.
1.3 Анализ архитектуры стандарта WSGI В структуре WSGI есть две основные стороны:
— приложение WSGI, созданное из скрипта Python;
— сервер/шлюз WSGI, такой как Apache или Nginx.
Будучи вызываемым объектом, приложение-WSGI принимает два параметра. Это:
— среда окружения WSGI;
— название функции, которая запускает ответ.
Каждый раз, когда оно получает запрос от HTTP-клиентов, направленный на приложение, сервер/шлюз вызывает приложение. На рисунке 1 показана диаграмма вызова функции.
+
Вызываемая функция
Приложение WSGI
Рисунок 1 - Диаграмма вызова функции в стандарте WSGI
Шлюз WSGI — это сервер, который запускает веб-приложение и передает соответствующую информацию с помощью функции обратного вызова в приложение. Обработка запроса происходит на стороне приложения, в то время как сервер получает ответ, используя функцию обратного вызова. Фреймворками Python, поддерживающими WSGI, являются Django, web2py, Flask, TurboGears и CherryPy.
Между веб-приложением и веб-сервером может быть несколько промежуточных программ WSGI. Их функция будет заключаться в том, чтобы направлять запросы к различным объектам приложения, предварительной обработке контента, балансировке нагрузки и так далее. В случае для веб-сайта, написанного на языке Python, мы имеет диаграмму последовательности для получения веб-страницы изображенную на рисунке 2.
Рисунок 2 - Диаграмма последовательности для получения вебстраницы по стандарту WSGI
Ниже представлен упрощенный пример конфигурации веб-сервера Nginx. Конфигурация веб-сервера определяет, какие запросы следует передавать на сервер WSGI для обработки. Как только запрос обрабатывается и генерируется сервером WSGI, ответ передается обратно через веб-сервер и в браузер.
Например, конфигурация этого веб-сервера Nginx указывает, что Nginx должен обрабатывать статические ресурсы (такие как изображения, файлы JavaScript и CSS) в каталоге /static и передавать все другие запросы серверу WSGI, работающему на порту 8000:
#указывает на существование WSGI сервера, который работает #на 8000 порту
upstream app_server_djangoapp { server localhost:8000 fail_timeout=0;
}
#Nginx настроен на прослушивание и обработку HTTP запросов #на 80 порту server { listen 80;
#nginx раздает статические файлы из определенной директории #и не отправляет их WSGI серверу location /static { autoindex on; alias /srv/www/assets;
}
#запросы, не попадающие под условие /static передаются WSGI #серверу определенному выше location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off;
if (!-f $request_filename) { uwsgi_pass http://app_server_djangoapp; include uwsgi_params break;
}
}
}
1.4 Сравнительный анализ серверов на основе стандарта WSGI и их сводная характеристика
1.4.1 Сервер uWSGI
Сервер uWSGI был разработан с целью стать полным стеком, способным создавать хостинговые сервисы. API и согласованная настройка конфигурации используются для реализации серверов приложений, которые могут обрабатывать широкий спектр протоколов и языков, менеджеров процессов, прокси-серверов и мониторов. Он назван в честь стандарта WSGI Python и был оригинальным плагином, созданным для проекта. Как правило, uWSGI соединяется с обратным прокси -сервером (таким как Nginx).
1.4.2 Сервер Bjoern
Bjoern — асинхронный сервер WSGI. Он написан на C и очень легкий. Разработанный с нуля, чтобы быть небольшим и быстрым. Размер загружаемого файла составляет всего 18 КБ, он состоит из менее чем 800 строк кода. Он занимает менее 1 МБ памяти и не использует сопрограмм или потоков. Bjoern полностью совместим с WSGI и считается одним из самых эффективных серверов WSGI.
Он поддерживает постоянное соединение и может связываться с сокетами Unix и адресами хоста TCP: портов. Бьёрн считается более быстрым, чем Gunicorn и менее объемным, чем uWSGI и Meinheld.
1.4.3 Сервер mod_wsgi
Модуль для Apache HTTP Server, разработанный Грэмом Дамплтоном, mod_wsgi предоставляет интерфейс WSGI для веб -приложений Python. Созданный в качестве альтернативы другим решениям для интеграции веб-приложений Python, таких как CGI, FastCGI и mod_python, его можно установить, как модуль Apache или через mod_wsgi express. Второй метод облегчает установку для разработчиков Python, которые не так хорошо знакомы с Apache.
1.4.4 Сервер CherryPy
CherryPy отличается от более известных веб-серверов благодаря простоте использования и удобству для разработчиков. Можно начать работу в течение нескольких минут, запустив несколько процессов, используя только один файл с именем server.py. Комбинируя CherryPy с Nginx, мощным обратным прокси-сервером веб-сервера, вы получаете
надежный способ обслуживания веб-приложений Python. Можно так сделать, даже если разрабатывается приложение с использованием CherryPy, Bottle, Flask, Pyramid, Django или другой платформы. CherryPy был создан Реми Делон. Он хотел построить фреймворк, максимально приближенный к руководствам Python.
1.4.5 Сервер Gunicorn
Gunicorn, созданный для использования в UNIX, представляет собой Python WSGI HTTP Server. Название является сокращенной и комбинированной версией слов «Зеленый Единорог». Сам сайт проекта на самом деле имеет зеленый единорог. Gunicorn был перенесен из проекта Unicorn из Ruby. Он относительно быстрый, требует мало ресурсов, прост в реализации и работает с различными веб-фреймворками.
Команда Gunicorn рекомендует вам использовать Nginx. Сервер Gunicorn работает на локальном порте 8000, а Nginx обычно используется в качестве обратного прокси-сервера. Gunicorn не имеет зависимостей.
1.4.6 Сравнение данных о работе WSGI серверов
Для сравнения работы перечисленных WSGI серверов было проведено специально исследование. Чтобы сделать тест максимально объективным, был создан Docker-контейнер для изоляции тестируемого сервера от остальной части системы. Также использование Docker-контейнера гарантировало, что каждый запуск начинается с чистого листа. Также стоит отметить, что для проверки самостоятельной работоспособности всех WSGI серверов uWSGI сервер был подключен напрямую без прокси-сервера Nginx, и для работы использовался HTTP протокол, хотя по умолчанию uWSGI работает через собственный протокол uwsgi. Вероятнее всего это объясняет полученные низкие значения этого сервера в сравнении с остальными.
Тестирование:
— wrk, «современный инструмент HTTP-бенчмаркинга», выполнил тесты;
— серверы тестировались в случайном порядке с увеличением числа одновременных подключений, в диапазоне от 100 до 10000;
— скрипт wrk был ограничен двумя ядрами процессора, не используемыми докером;
— каждое испытание длилось 30 секунд и повторялось 4 раза.
Все результаты сравнения до единого нельзя считать отражающими реальные возможности серверов, однако оно дает полезную информацию
о их работе. Во-первых, существуют подозрения относительно производительности Bjoem между ним и следующим самым лучшим сервером. Во-вторых, как уже было сказано в начале сравнения, uWSGI был специально настроен не соответственно рекомендуемым настройкам, что, скорее всего, привело к таким результатам.
На основе полученной информации о серверах WSGI можно построить сравнительную таблицу, данные которой отображены в таблице 1. В ней сравниваются серверы Bjoem, uWSGI, Guшcom, CherryPy и mod_wsgi по основным параметрам для своего класса ПО.
Таблица 1 — Сравнительная таблица серве
ров WSGI
uWSGI Bjoern Gunicor n CherryP y mod_wsgi
Работа внутри Nginx + - - - -
Работа внутри Apache - - - - +
Многопоточность + 1 поток + + +
Размер дистрибутива ~590КБ ~20КБ ~15КБ ~2МБ ~80КБ
Поддержка Python2/Python3 +/+ +/+ +/+ +/+ +/+
Поддержка Windows - - - + +
Поддержка Linux + + + + +
Поддержка Mac OS + + + + +
Требовательность по оперативной памяти при 5000 одновременных соединений 70МБ 10МБ 25МБ 30МБ 35МБ
Требовательность по оперативной памяти при 10000 одновременных соединений 120МБ 10МБ 25МБ 45МБ 40МБ
Нагрузка на процессор при разрешенных 2 ядрах (200% максимальное значение) при 5000 одновременных соединений ~30% ~100% ~160% ~140% ~200%
Нагрузка на процессор при разрешенных 2 ядрах (200% максимальное значение) при 10000 одновременных соединений ~50% ~100% ~150% ~140% ~200%
Задержка ответа при 5000 одновременных соединений ~1с ~100мс ~150мс ~0мс ~250мс
Задержка ответа при 10000 одновременных соединений ~650мс ~100мс ~150мс ~0мс ~250мс
Количество обрабатываемых запросов в секунду при 5000 одновременных соединений 60000 200 1100 3900 1900
Количество обрабатываемых запросов в секунду при 10000 одновременных соединений 80000 300 800 4000 1900
Литература
1. ГОСТ 7.32-2017 Структура и правила оформления отчета о научно-исследовательской работе
2. Sergey Skryl', Mikhail Sychev, Artem Sychev, Tatyana Mescheryakova, Anna Ushakova, Elvira Abacharaeva, Elena Smirnova Assessing the Response Timeliness to Threats as an Important Element of Cybersecurity: Theoretical Foundations and Research Model — CIT&DS 2019: Creativity in Intelligent Technologies and Data Science pp 258-269
3. Nginx [Электронный ресурс] URL: https://www.fullstackpython.com/nginx.html (Дата обращения 04.05.2020)
4. PEP 3333 — Python Web Server Gateway Interface v1.0.1 [Электронный ресурс] URL: https://www.python.org/dev/peps/pep-3333/ (Дата обращения 01.03.2020)
5. Web Applications & Frameworks [Электронный ресурс] URL: https://docs.python-guide.org/scenarios/web/ (Дата обращения 04.05.2020)
6. wrk [Электронный ресурс] URL: https://github.com/wg/wrk (Дата обращения 04.05.2020)
7. Setting up Django and your web server with uWSGI and nginx [Электронный ресурс] URL: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html (Дата обращения 04.05.2020)
Literature
1. GOST 7.32-2017 Structure and rules of registration of the research report
2. Sergey Skryl', Mikhail Sychev, Artem Sychev, Tatyana Mescheryakova, Anna Ushakova, Elvira Abacharaeva, Elena Smirnova Assessing the Response Timeliness to Threats as an Important Element of Cybersecurity: Theoretical Foundations and Research Model — CIT&DS 2019: Creativity in Intelligent Technologies and Data Science pp 258-269
3. Nginx [Electronic resource] URL: https://www.fullstackpython.com/nginx.html (accessed 04.05.2020)
4. PEP 3333-Python Web Server Gateway Interface v1.0.1 [Electronic resource] URL: https://www.python.org/dev/peps/pep-3333/ (accessed 01.03.2020)
5. Web Applications & Frameworks [Electronic resource] URL: https://docs.python-guide.org/scenarios/web/ (accessed 04.05.2020)
6. wrk [Electronic resource] URL: https://github.com/wg/wrk (accessed 04.05.2020)
7. Setting up Django and your web server with uWSGI and nginx [Electronic resource] URL: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html (accessed 04.05.2020)
