Django + WSGI: Проблеми с опресняването?

Можете да разрешите този проблем, като не редактирате кода си на живия сървър. Сериозно, няма извинение за това. Разработвайте локално с помощта на контрол на версиите и, ако трябва, стартирайте сървъра си от проверка на живо, с кука след ангажиране, която проверява най-новата ви версия и рестартира Apache.

Изпълнението на процеса в режим на демон няма да помогне. Ето какво се случва:

mod_wsgi ражда множество идентични процеси за обработка на входящи заявки за вашия Django сайт. Всеки от тези процеси е свой собствен интерпретатор на Python и може да обработва входяща уеб заявка. Тези процеси са постоянни (те не се извеждат и премахват за всяка заявка), така че един процес може да обработва хиляди заявки една след друга. mod_wsgi може да обработва множество уеб заявки едновременно, тъй като има множество процеси.

Python интерпретаторът на всеки процес ще зареди вашите модули (вашите персонализирани Python файлове) всеки път, когато се изпълнява „модул за импортиране“. В контекста на django това ще се случи, когато е необходим нов view.py поради уеб заявка. След като модулът бъде зареден, той се намира в паметта и така всички промени, които правите във файла, няма да бъдат отразени в този процес. Тъй като постъпват повече уеб заявки, Python интерпретаторът на процеса просто ще използва версията на модула, която вече е заредена в паметта. Виждате несъответствия между опресняванията, тъй като всяка уеб заявка, която правите, може да се обработва от различни процеси. Някои процеси може да са заредили вашите Python модули по време на по-ранни ревизии на вашия код, докато други може да са ги заредили по-късно (тъй като тези процеси не са получили уеб заявка).

Простото решение: Всеки път, когато промените кода си, рестартирайте процеса на Apache. Повечето пъти това е толкова просто, колкото стартиране като root от обвивката "/etc/init.d/apache2 restart". Вярвам, че обикновеното презареждане също работи, което е по-бързо, "/etc/init.d/apache2 reload"

Решението на демон: Ако използвате mod_wsgi в режим на демон, тогава всичко, което трябва да направите, е да докоснете (unix команда) или да промените вашия wsgi скрипт файл. За да изясним публикацията на scrompt.com, модификациите на вашия изходен код на Python няма да доведат до повторно зареждане на кода от mod_wsgi. Презареждането се извършва само когато файлът на скрипта wsgi е променен.

Последна точка за отбелязване: Говорих само за wsgi като използване на процеси за простота. wsgi всъщност използва пулове от нишки във всеки процес. Не смятам, че тази подробност е подходяща за този отговор, но можете да научите повече, като прочетете за mod_wsgi.

Тъй като използвате mod_wsgi във вграден режим, вашите промени не се виждат автоматично. Виждате ги от време на време, защото Apache стартира понякога нови манипулатори, които улавят актуализациите.

Можете да разрешите това, като използвате режим на демон, както е описано тук. По-конкретно, ще искате да добавите следните директиви към вашата конфигурация на Apache:

WSGIDaemonProcess example.com processes=2 threads=15 display-name=%{GROUP}
WSGIProcessGroup example.com

Прочетете документацията на mod_wsgi, вместо да разчитате на минималната информация за хостинг на mod_wsgi, съдържаща се на сайта на Django. По-специално, прочетете:

http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

Това ви казва как точно работи презареждането на изходния код в mod_wsgi, включително монитор, който можете да използвате, за да приложите същия вид презареждане на изходния код, който прави Django runserver. Вижте също кои говори за това как да приложите това към Django.

http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django.html http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-on.html