Быстрый и автоматический запуск Django на IIS 7.x в production-среде (+ тесты производительности)

Django — популярный фреймоворк для создания веб-приложений на языке Python. Его популярность постоянно растет благодаря наличию средств быстрой разработки, встроенного административного интерфейса и высокой скорости работы. Существует простой и надежный способ разворачивания и запуска django-приложений на веб-сервере IIS с помощью Web Platform Installer и репозитория пакетов Helicon Zoo.

Helicon Zoo — это репозиторий популярных веб-фремоворков и приложений для Microsoft IIS. Он использует технологии Microsoft Web Platform Installer (WebPI) для развертывания приложений. С их помощью обрабатываются различные зависимости и происходит сам процесс установки нужных компонентов, как то Python, Django, различные драйвера баз данных и модули. Ну и сам модуль Helicon Zoo, который все это дело склеивает с MS IIS 7.

Как использовать

В веб разработке существуют две, довольно независимые среды – development и production. Helicon Zoo можно использовать как в production, так и на машине разработчика, либо и там и там одновременно. В любом случае последовательность действий примерно такая:

Для начала нужно скачать и установить Web Platform Installer с сайта Microsoft — (http://www.microsoft.com/web/downloads/platform.aspx). WebPI уже содержит большое количество таких фреймворков и приложений для IIS, как PHP, ASP.NET, Wordpress, Drupal, phpBB. Что бы подключить Helicon Zoo нужно добавить в WebPI новый feed:

• Запускаем WebPI и жмем Option
  
  
• В поле «Display additional scenarios» вставляем http://www.helicontech.com/zoo/feed и кликаем Add feed
  
  
  

Теперь, если в интерфейсе 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>

Вот важные моменты:

• scriptProcess="python.2.7.pipe" — ссылка на FastCGI-движок определенный в applicationHost.config;
• переменная окружения PYTHONPATH — путь, по которым python ищет свои модули; в нашем случае мы добавляем в PYTHONPATH путь к нашему django-приложению;
• переменная окружения DJANGO_SETTINGS_MODULE — питоний путь к конфигурационному файлу settings.py Django-приложения, например, ‘mysite.settings’
• переменная окружения ‘DEPLOY_FILE’ — путь к файлу внутри приложения, который будет запускаться перед выполнением первого запросу к приложению после рестарта IIS-приложения. В этом файле нужно выполнять, например, команды для синхронизации БД: ‘manage.py syncdb –noinput’;
• переменная окружения ‘DEPLOY_LOG’ — путь внутри приложения к файлу, в который будет записываться вывод команды DEPLOY_FILE для отладочных целей. Директория, в которой находится этот лог-файл, должна иметь права на запись для пользователя, от которого работает IIS-приложение (обычно группа IIS_IUSRS).

Статический контент

Фреймворк 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 — собственно сам сайт с шаблонами, статикой, urls.py и settings.py
• blog
• store

Статические файлы, расположенные в 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 проектов.