Быстрый и автоматический запуск Django на IIS 7.x в production-среде (+ тесты производительности)Django — популярный фреймоворк для создания веб-приложений на языке Python. Его популярность постоянно растет благодаря наличию средств быстрой разработки, встроенного административного интерфейса и высокой скорости работы. Существует простой и надежный способ разворачивания и запуска django-приложений на веб-сервере IIS с помощью Web Platform Installer и репозитория пакетов Helicon Zoo. Как использоватьВ веб разработке существуют две, довольно независимые среды – development и production. Helicon Zoo можно использовать как в production, так и на машине разработчика, либо и там и там одновременно. В любом случае последовательность действий примерно такая:
Теперь, если в интерфейсе WebPI выбрать Applications, Tools, то в конце списка вы сможете увидеть новые приложения: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project: Blank Django Project — это простое “Hello, World!”-приложение, которое используется для установки всех зависимостей необходимых для запуска Django-приложения и собственно, пустой Django-проект. Для установки нажимайте “Add” и “Install”, появится форма со списком зависимостей: Что бы принять лицензии и начать загрузку и установку нажмите “I Accept”. После установки и загрузки всех зависимостей, установленный проект можно запустить, кликнув на “Launch application in browser”: Такое окошко означает что на вашем компьютере только что был установлен Python, Django и все необходимое для запуска самих приложений. Теперь, в случае если это машина для разработки вы можете начать разработку с этого пустого “Hello Worls” приложения. После того как вы что то сделаете с этим приложением, его можно загрузить на продакшн сервер со всеми файлами, директориями, обязательно с файлом web.config, и, если на сервере предварительно был установлен Blank Django Project (неважно в какую директорию, нужны только его зависимости), приложение должно там заработать. Каждый раз когда вы загружаете свои изменения на сервер, нужно перезапускать Application Pool. Это особенность Django (и Rails), для других фреймворков перезапуск возможно и не понадобится. При перезапуске будет автоматически выполнена миграция данных —manage.py syncdb. Это позволяет использовать решение на shared хостингах, где у пользователя нет доступа к консоли. Под капотомЯдром Helicon Zoo является native IIS модуль, по сути, играющий роль моста между веб-сервером IIS и фреймворками на Ruby, Python, Perl и др. Модуль работает по протоколу FastCGI, который уже зарекомендовал себя как надежный и быстрый метод взаимодействия веб-приложений с веб-сервером. Взаимодействие между ними происходит асинхронно, используя технологию I/O Completion Port. В качестве транспорта используются либо именованные каналы либо tcp-сокеты. Поддерживаются IIS 7, IIS 7.5, а также IIS Express. Базовая конфигурация модуля Helicon Zoo находится в секции <heliconZooServer> файла applicationHost.config. В этой секции описываются все FastCGI-движки, с которыми будут работать через Zoo. Вот пример описания движка для запуска python wsgi-приложений (Django-приложений в частности), zoofcgi.py — это воркер на питоне, который реализует транспорт на именованных каналах (named pipes): <engine name="python.2.7.pipe" fullPath="c:\python27\python.exe" arguments="-O %SystemDrive%\Zoo\Workers\python\zoofcgi.py" transport="pipe" /> Web.configКонфигурация веб-приложений, работающих через Zoo осуществляется через файл web.config. Вот пример такого файла для конфигурирования Django-приложения для работы в 32-битном пуле: <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <heliconZoo> <application name="django.project.x86" > <environmentVariables> <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" /> <add name="DJANGO_SETTINGS_MODULE" value="settings" /> <add name="DEPLOY_FILE" value="deploy.py" /> <add name="DEPLOY_LOG" value="log\deploy.log" /> </environmentVariables> </application> </heliconZoo> <handlers> <add name="django.project.x86" scriptProcessor="python.2.7.pipe" path="*" verb="*" modules="HeliconZoo_x86" preCondition="bitness32" resourceType="Unspecified" requireAccess="Script" /> </handlers> </system.webServer> </configuration>Вот важные моменты:
Статический контенторк Django не годится для быстрой и безопасной обработки статических файлов (изображений, скриптов, файлов стилей). Статику должен обрабатывать веб-сервер напрямую. Для этого нужно сложить все статические файлы в директорию и выключить в ней обработчик запросов в django-приложение: <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <handlers> <remove name="django.project.x86" /> </handlers> </system.webServer> </configuration>Пример Django-проекта на IIS 7Предположим наш django-проект состоит из трех приложений:
Статические файлы, расположенные в site/media будут доступны через виртуальную директорию /media/ (т.е. MEDIA_URL='/media/'). После установки Blank Django Project в корень сайта и копирования нашего django-проекта, получим такую структуру директорий: /media/ — это виртуальная директория, которая указывает на site/media; в ней отключен Zoo модуль как описано выше. В корневом web.config PYTHONPATH указывает на корень сайта и DJANGO_SETTINGS_MODULE установлен в ‘site.settings’: ... <heliconZoo> <application name="django.project.x86" > <environmentVariables> <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" /> <add name="DJANGO_SETTINGS_MODULE" value="site.settings" /> </environmentVariables>ПроизводительностьИ напоследок самое интересное – тестирование производительности. Развернутое тестирование будет позже, сейчас пока «на скорую руку», но и по этим результатам вполне можно судить. Тестовая машина в качестве сервера — Core 2 Quad 2.4 Ghz, 8 Gb RAM, гигабитная сеть. Для генерации нагрузки использовался более мощный компьютер с Apache Benchmark. Для тестирования Apache и Nginx использовалась Ubuntu 11.04 Server x64. IIS 7 тесты работали на Windows Server 2008 R2. Никаких виртуалок — честное железо. В качестве транспорта на Nginx использовали самый продвинутый uwsgi, а также wsgi и fast_cgi для сравнения. Еще на IIS 7 сравнили с PyISAPIе. В качестве тестовых страниц написали два небольших скрипта. Первый выводит текущее время с высоким разрешением – это сделано для того, чтобы была уверенность что, страницы не берутся из кеша. Второй делает то же самое, но предварительно сохраняет результат в базе данных. Все это через шаблон, чтобы задействовать реальную инфраструктуру Django, база данных – MySQL. Настройки везде по умолчанию, т.к. цель протестировать именно наиболее типичные конфигурации. Итак, результаты (в запросах в секунду): Тут все более менее понятно и стабильно. Uwsgi впереди, видимо за счет более тесной интеграции с кодом Django — нужно будет его покурить… PyISAPIe сильно отстает, что и понятно. А вот с базой данных результат не столь стабилен. Почему Nginx + fcgi + MySQL показал столь странные 175 запросов в секунду – не понятно. Результат MySQL на Windows тоже удручает, хотя на shared хостинге проблема возможно и не будет такой критичной. Дело в том что производительность падает в основном из-за каких-то внутренних блокировок в MySQL, сам же сервер практически не нагружен, пока генерирует эти 104 запроса. Можно предположить, что с ростом количества сайтов на сервере, и соответственно ростом количества баз данных, если они не будут блокироваться между собой, суммарная мощность сервера будет достаточной. Так что мы решили добавить MS SQL Express к тестам. Его результат тоже понятен – все упирается в сам Python и драйвера базы данных к нему, однако в целом выглядит вполне прилично. PyISAPIe с MS SQL Express не заработал. Хочется отдельно отметить способность IIS 7 держать большое число подключений. Так IIS 7 + Helicon Zoo с легкостью выдерживал тысячи одновременных подключений (больше нам просто нечем было генерировать), в то время как Ubuntu, с настройками по умолчанию, с ростом числа подключений быстро пасовала. А Apache еще и оказался весьма прожорливым на память. Так с ростом числа подключений Apache потребил около 3-х Гб памяти за 20 секунд теста — дальше не проверяли. ВыводыПредставленное решение показывает стабильную работу и приличную производительность. Оно вполне готово для использования как в качестве среды разработки так и в продакшене. Особенно важной является возможность использования Helicon Zoo различными Windows хостингами, с целью предоставления сервисов Django своим клиентам. Хочется надеяться, что с ростом числа Django серверов на Windows, ее разработчики станут уделять больше внимания отладке и оптимизации своего кода под Windows платформу. Да и армия существующих Windows-разработчиков может стать неплохим подспорьем для нынешних open-source проектов. Автор статьи:Владимир Юнев |