Django - IIS 7

Блог за Microsoft Cloud, Azure и уеб технологии

Бързо и автоматично стартиране на Django на IIS 7.x в производствена среда

Django е популярна рамка за изграждане на уеб приложения в Python. Популярността му непрекъснато нараства поради наличието на инструменти за бърза разработка, вграден административен интерфейс и висока скорост. Има прост и надежден начин за внедряване и стартиране на django приложения на IIS уеб сървър с помощта на инсталатора на уеб платформата и хранилището на пакети Helivon Zoo.

Helicon Zoo е хранилище на популярни уеб рамки и приложения за Microsoft IIS. Той използва Microsoft Web Platform Installer (WebPI) технологии за внедряване на приложения. С тяхна помощ се обработват различни зависимости и протича процесът на инсталиране на необходимите компоненти, като Python, Django, различни драйвери и модули за бази данни. Е, самият модул Helicon Zoo, който свързва всичко с MS IIS 7.

Как да използвам

В уеб разработката има две доста независими среди - разработка и производство. Helicon Zoo може да се използва както в производството, така и на машината на разработчика, или и двете едновременно. Във всеки случай последователността от действия е нещо подобно:

Първо трябва да изтеглите и инсталирате програмата за инсталиране на уеб платформа от уебсайта на Microsoft - (http://www.microsoft.com/web/downloads/platform.aspx). WebPI вече съдържа голям брой IIS рамки и приложения като PHP, ASP.NET, WordPress, Drupal, phpBB. За да свържете Helicon Zoo, трябва да добавите нова емисия към WebPI:

Стартирайте WebPI и натиснете Option
В полето „Показване на допълнителни сценарии“ поставете http://www.helicontech.com/zoo/feed и щракнете върху Добавяне на емисия

Сега, ако изберете Приложения, Инструменти в интерфейса WebPI, тогава в края на списъка можете да видите нови приложения: Празен проект Django, Празен проект на Rails, Празен проект Perl, Празен проект Mojolicious:

За да приемете лицензите и да започнете изтеглянето и инсталирането, щракнете върху „Приемам“. След инсталиране и изтегляне на всички зависимости, инсталираният проект може да бъде стартиран чрез щракване върху „Стартиране на приложение в браузъра“:

Този прозорец означава, че Python, Django и всичко необходимо за стартиране на самите приложения току-що са били инсталирани на вашия компютър. Сега, в случай че това е машина за разработка, можете да започнете разработка с това празно приложение „Hello Worlds“. След като направите нещо с това приложение, можете да го качите на производствения сървър с всички файлове, директории, задължително с файла web.config и ако Blank Django Project е бил инсталиран преди това на сървъра (без значение в каква директория, необходими са само нейните зависимости), приложението трябва да работи там. Всеки път, когато качвате вашите промени на сървъра, трябва да рестартирате набора от приложения. Това е функция на Django (и Rails), други рамки може да не се нуждаят от рестартиране. При рестартиране миграцията на данни ще се извърши автоматично -manage.py syncdb. Това ви позволява да използвате решението на споделен хостинг, където потребителят няма достъп до конзолата.

под капака

Ядрото на Helicon Zoo е нативният IIS модул, който всъщност играе ролята на мост между IIS уеб сървъра и фреймворковете в Ruby, Python, Perl и др. Модулът работи с помощта на протокола FastCGI, който вече се е доказал като надежден и бърз метод за взаимодействие между уеб приложения и уеб сървър. Взаимодействието между тях протича асинхронно,използвайки I/O Completion Port технология. Като транспорт се използват или именувани канали, или tcp гнезда. Поддържат се IIS 7, IIS 7.5 и IIS Express.

Основната конфигурация на модула Helicon Zoo се намира в секцията на файла applicationHost.config. Този раздел описва всички FastCGI двигатели, с които ще се работи чрез Zoo. Ето пример за описание на двигателя за изпълнение на приложения на python wsgi (по-специално приложения на Django), zoofcgi.py е работник на python, който реализира транспорт върху наименувани канали (наименувани канали):

Уеб приложенията, работещи през Zoo, се конфигурират чрез файла web.config. Ето пример за такъв файл за конфигуриране на Django приложение за работа в 32-битов пул:

Ето важните точки:

Статично съдържание

Рамката Django не е подходяща за бързо и безопасно обработване на статични файлове (изображения, скриптове, стилови файлове). Статиката трябва да се обработва директно от уеб сървъра. За да направите това, трябва да поставите всички статични файлове в директория и да изключите обработката на заявки в приложението django в нея:

Примерен Django проект на IIS 7

Да предположим, че нашият django проект се състои от три приложения:

сайт - самият сайт с шаблони, статики, urls.py и settings.py
блог
магазин

Статичните файлове, намиращи се в site/media, ще бъдат достъпни чрез виртуалната директория /media/ (т.е. MEDIA_URL='/media/'). След като инсталираме Blank Django Project в корена на сайта и копираме нашия django проект, получаваме следната структура на директорията:

/media/ е виртуална директория, която сочи към сайт/media; той деактивира модула Zoo, както е описано по-горе. В корена web.config, PYTHONPATH сочи към корена на сайта иDJANGO_SETTINGS_MODULE е настроен на 'site.settings':

производителност

И накрая, най-интересното е тестването на производителността. Подробните тестове ще бъдат по-късно, сега засега "набързо", но по тези резултати може да се прецени. Тестова машина като сървър - Core 2 Quad 2.4 Ghz, 8 Gb RAM, гигабитова мрежа. За генериране на товара е използван по-мощен компютър с Apache Benchmark. Apache и Nginx бяха тествани с помощта на Ubuntu 11.04 Server x64. Тестовете на IIS 7 работеха на Windows Server 2008 R2. Без виртуални машини - честен хардуер. Най-модерният uwsgi беше използван като транспорт на Nginx, както и wsgi и fast_cgi за сравнение. Те също го сравниха с PyISAPI на IIS 7.

Написахме два малки скрипта като тестови страници. Първият извежда текущото време във висока резолюция - това се прави, за да сте сигурни, че страниците не се вземат от кеша. Вторият прави същото, но първо съхранява резултата в базата данни. Всичко това чрез шаблон за използване на истинската инфраструктура на Django, базата данни е MySQL. Настройките са по подразбиране навсякъде. целта е да се тестват най-типичните конфигурации. Така че резултатите (в заявки за секунда):

Тук всичко е повече или по-малко ясно и стабилно. Uwsgi е напред, очевидно поради по-тясна интеграция с Django кода - ще трябва да го пушите. PyISAPIe е много назад, което е разбираемо.

Но с базата данни резултатът не е толкова стабилен. Защо Nginx + fcgi + MySQL показа толкова странни 175 заявки в секунда, не е ясно. Резултатът от MySQL на Windows също е депресиращ, въпреки че на споделения хостинг проблемът може да не е толкова критичен. Факт е, че производителността пада главно поради някакви вътрешни ключалки.в MySQL самият сървър практически не се натоварва, докато генерира тези 104 заявки. Може да се предположи, че с увеличаване на броя на сайтовете на сървъра и, съответно, увеличаване на броя на базите данни, ако те не са блокирани помежду си, общият капацитет на сървъра ще бъде достатъчен.

Затова решихме да добавим MS SQL Express към тестовете. Резултатът от него също е разбираем - всичко опира до самия Python и драйверите за базата данни за него, но като цяло изглежда доста прилично. PyISAPIe с MS SQL Express не работи.

Бих искал отделно да отбележа способността на IIS 7 да поддържа голям брой връзки. Така че IIS 7 + Helicon Zoo лесно издържа на хиляди едновременни връзки (просто нямаше какво друго да генерираме), докато Ubuntu с настройки по подразбиране бързо се предаде с увеличаване на броя на връзките. А Apache също се оказа много лаком към паметта. Така че с увеличаване на броя на връзките Apache консумира около 3 GB памет за 20 секунди от теста - те не са проверявали допълнително.

Представеното решение показва стабилна работа и прилична производителност. Той е напълно готов за използване както като среда за разработка, така и в производство. От особено значение е възможността да се използва Helicon Zoo от различни Windows хостове, за да се предоставят услуги на Django на техните клиенти. Да се надяваме, че с нарастването на броя на сървърите на Django в Windows разработчиците ще обърнат повече внимание на отстраняването на грешки и оптимизирането на техния код за платформата на Windows. И армията от съществуващи разработчици на Windows може да бъде добра помощ за текущи проекти с отворен код.