Быстрый и автоматический запуск 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 выбрать Applications, Tools, то в конце списка вы сможете увидеть новые приложения: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project:

    clip_image006[12]

    Blank Django Project — это простое “Hello, World!”-приложение, которое используется для установки всех зависимостей необходимых для запуска Django-приложения и собственно, пустой Django-проект. Для установки нажимайте “Add” и “Install”, появится форма со списком зависимостей:

    clip_image008[12]

    Что бы принять лицензии и начать загрузку и установку нажмите “I Accept”. После установки и загрузки всех зависимостей, установленный проект можно запустить, кликнув на “Launch application in browser”:

    clip_image010[12]

    Такое окошко означает что на вашем компьютере только что был установлен 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-проекта, получим такую структуру директорий:

    clip_image012[12]

    /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. Настройки везде по умолчанию, т.к. цель протестировать именно наиболее типичные конфигурации. Итак, результаты (в запросах в секунду):

    clip_image014[12]

    Тут все более менее понятно и стабильно. Uwsgi впереди, видимо за счет более тесной интеграции с кодом Django — нужно будет его покурить… PyISAPIe сильно отстает, что и понятно.

    clip_image016[12]

    А вот с базой данных результат не столь стабилен. Почему 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 проектов.
    Microsoft
    120.51
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Share post

    Comments 16

      0
      С MS SQL Django из коробки работал или что-то дополнительно нужно ставить?
        0
        Из коробки python и django не умеет работать с MS SQL Server.
        Нужно поставить питоний драйвер pyodbc и django драйвер django-pyodbc.
        +1
        Интересно, когда Django заработает на IronPython? Очень хотелось бы иметь нативную поддержку IIS, писать питоновские модули на C# + полный доступ к .NET. Есть ли какие-нибудь подвижки в этом направлении? В плане производительности будет намного выигрышней, на мой взгляд
          0
          только не выкладывайте их в паблик, пожалуйста.
            +4
            IronPython и поддержка его в Django — это не к нам. Как будет поддержка, так и добавим. Пока помоему и с обычным питоном неплохо получилось. К тому же чем больше таких Windows клиентов и хостингов, тем больше вероятность что разработки пойдут в этом направлении.

            phasma: Кого не выкладывать и почему?
              –3
              > phasma: Кого не выкладывать и почему?

              > питоновские модули на C#

              попахивает маразмом.
          +1
          1. «писать питоновские модули на C# + полный доступ к .NET.» — можно мне преемущества этого рассказать?

          и простите я все еще не понимаю зачем джангу запускать с иис — уже с ним столько тут писали и говорили. работая под иис вы ограничиваете себя платформами.
            +1
            1. У нас системы на .NET + Win Server 2008 + MSSQL
            2. Я люблю Питон
            3. Мне нравится Джанго
            4. IronPython быстр и в нем нет GIL, поддерживает многопоточность
            5. К нему можно писать модули на C# (может понадобится в работе со строками, где IronPython не очень быстр, а также для более сложной компонентой ООП архитектуры где имеют преимущество языки со строгой типизацией)
            6. Разворачивать на существующей инфраструктуре. Не понадобится ставить *NIX со всеми вытекающими чтобы быстро разворачивать небольшие проекты.
            7. Можно прикручивать к имеющимся БД MS SQL
            8. "— можно мне преемущества этого рассказать?" — Для чего придумали Jython?

            «Вы ограничиваете себя платформами» — это скорее религиозное понятие. Мы всего-лишь вибираем определенные инструменты для определенных задач, и пока нас все устраивает.
              –1
              > Мы всего-лишь вибираем
              > Не понадобится ставить *NIX со всеми вытекающими чтобы быстро разворачивать небольшие проекты.

              Ваш первоначальный выбор резко сузил возможный выбор в будущем (для ваших коллег, например). Установку Linux сервера, кстати, можно автоматизировать так, что сайт будет разворачиваться вместе с системой вобще без участия человека.
            +6
            запуск Django на IIS

            Но зачем?
              +3
              Быстро замените скрин с хромом на ие9 — это ж блог микрософта!
                –2
                > Настройки везде по умолчанию, т.к. цель протестировать именно наиболее типичные конфигурации

                Бредятина какая… Никто не использует настройки MySQL по умолчанию. И вобще конфиги выкладывать положено. И после этого: Ба! Чудеса в решете!

                > Почему Nginx + fcgi + MySQL показал столь странные 175 запросов в секунду – не понятно.


                > Для тестирования Apache и Nginx использовалась Ubuntu 11.04 Server x64. IIS 7 тесты > работали на Windows Server 2008 R2.

                Нет чтобы сравнить nginx на Ubuntu/Windows + IIS Windows.

                > Хочется отдельно отметить способность IIS 7 держать большое число подключений. в то время как Ubuntu, с настройками по умолчанию, с ростом числа подключений быстро пасовала.

                По графикам этого не скажешь… У nginx+ubuntu даже «по умолчанию» графики заметно лучше.

                p.s.
                А пинать апач в наши дни за prefork — дело неблагородное.
                  +3
                  >Бредятина какая… Никто не использует настройки MySQL по умолчанию. И вобще конфиги выкладывать положено. И после этого: Ба! Чудеса в решете!

                  Цель была не померять кто круче, а показать насколько предствленное решение готово или нет к использованию на боевом сервере. А так оптимизировать можно много чего… Нас интересовало как система работает «из коробки».

                  >Нет чтобы сравнить nginx на Ubuntu/Windows + IIS Windows.

                  Хорошая идея! Постараемся добавить еще этот тест.

                  >По графикам этого не скажешь… У nginx+ubuntu даже «по умолчанию» графики заметно лучше.

                  На графиках показано количетсво запросов в секунду. Этот параметр сильно зависит от производительности самого интерпретатора питона, и тут есть куда расти, но видно что уже вполне на уровне.
                  Сейчас для веб приложений важнее даже не количество запросов в секунду, а скорее количество клиентов, которых оно может обслуживать одновременно. Этот параметр по-правильному померять намного сложнее. К сожалению просто не хватает времени на все.

                  >А пинать апач в наши дни за prefork — дело неблагородное.

                  Больше не будем.
                    0
                    > Цель была не померять кто круче, а показать насколько предствленное решение готово или нет к использованию на боевом сервере.

                    Вот представим картину. «из коробки» буфферы настроены из расчета 512 мб ОЗУ. При вашем кол-ве запросов, многоядерном цпу и предполагаемых 512 мб нафиг летит оптимизационная схема, выбранная планировщиком БД. Причем она летит по-разному под Lin и под Win. Любой, кто работает с БД, скажет вам, что мерять надо «не виртуальное что-то там», а конкретный реальный сервис.

                    Лично мои ожидания от такого рода статей: адекватная одинаковая оптимизация + конфиги в паблик.

                    Ну и АБ, имхо, не очень подходит для тестирования в вашем случае, поскольку нужно не кол-во запросов, а эмулировать клиента. Теоретически я бы даже мог помочь вам с написанием таких тестов, но ваш выбор технологий явно не для меня.
                      +2
                      Я абсолютно и полностью с вами согласен! Но проводить такое тестирование в разы сложнее. К сожалению у нас маленькая команда и мы физически не успеваем столько сделать. Нужно же еще программировать, доводить продукт, внедрять его у хостингов. Сейчас работаем над поддержкой node.js, Sinatra, Tornado, Chicago Boss, почти доделали асинхронность (comet) в рельсах 3.0, работаем над интеграцией с хостинг панелями. При этом ни производители платформ, ни open source коммюнити и пальцем не пошевелят чтобы как-то поучаствовать. Твитнуть разок в своей ленте — большее на что мы можем расчитывать. Одни хостинги готовы сотрудничать, потому что сразу видят свою выгоду. Но что с них взять — разьве что платформу для тестирования…

                      Цель тестирования была на скорую руку показать что данное решение находится «примерно на уровне» и его можно использовать. Подавляющее большинство тестов в сети вообще меряют Hello World-ы и ничего.
                      Более полное тестирование возможно будет позже. Много позже…
                  +2
                  Я абсолютно и полностью с вами согласен! Но проводить такое тестирование в разы сложнее. К сожалению у нас маленькая команда и мы физически не успеваем столько сделать. Нужно же еще программировать, доводить продукт, внедрять его у хостингов. Сейчас работаем над поддержкой node.js, Sinatra, Tornado, Chicago Boss, почти доделали асинхронность (comet) в рельсах 3.0, работаем над интеграцией с хостинг панелями. При этом ни производители платформ, ни open source коммюнити и пальцем не пошевелят чтобы как-то поучаствовать. Твитнуть разок в своей ленте — большее на что мы можем расчитывать. Одни хостинги готовы сотрудничать, потому что сразу видят свою выгоду. Но что с них взять — разьве что платформу для тестирования…

                  Цель тестирования была на скорую руку показать что данное решение находится «примерно на уровне» и его можно использовать. Подавляющее большинство тестов в сети вообще меряют Hello World-ы и ничего.
                  Более полное тестирование возможно будет позже. Много позже…

                  Only users with full accounts can post comments. Log in, please.