Django + WSGI: проблемы с обновлением?

Я разрабатываю сайт Django. Я делаю все свои изменения на живом сервере, просто потому что так проще. Проблема в том, что время от времени мне нравится кэшировать один из файлов *.py, над которыми я работаю. Иногда, если я часто нажимаю «Обновить», он переключается между старой версией страницы и более новой версией.

Моя установка более или менее похожа на то, что описано в руководствах по Django: http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/#howto-deployment-modwsgi

Я предполагаю, это происходит потому, что он запускает несколько экземпляров обработчика WSGI, и в зависимости от того, на какой обработчик отправляется http-запрос, я могу получить разные версии страницы. Перезапуск apache, кажется, решает проблему, но это раздражает.

Я действительно мало что знаю о WSGI или «MiddleWare» или о любых других вещах, связанных с обработкой запросов. Я родом из PHP-фона, где все просто работает :)

В любом случае, какой хороший способ решить эту проблему? Устранит ли проблему запуск обработчика WSGI в «режиме демона»? Если да, то как заставить его работать в режиме демона?


django apache mod-wsgi
person mpen    schedule 28.10.2009    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Вы можете решить эту проблему, не редактируя свой код на рабочем сервере. Серьезно, этому нет оправдания. Разрабатывайте локально, используя систему управления версиями, и, если необходимо, запустите свой сервер из оперативной проверки с помощью перехватчика после фиксации, который проверяет вашу последнюю версию и перезапускает Apache.

person Daniel Roseman    schedule 28.10.2009
comment
да, но иногда среда prod ведет себя не так, как встроенный сервер разработки, так что выбора нет :) - person jujule; 28.10.2009
comment
@jujule: вы можете настроить тестовый домен на рабочем сервере, чтобы вы могли тестировать то, что вы разрабатываете локально. Я не могу придумать никаких оправданий, которые могли бы оправдать редактирование кода на сервере prod. - person shanyu; 28.10.2009
comment
это так много работы, чтобы воспроизвести серверную среду! на моем сервере работает ubuntu/apache2/postgres, а на моем домашнем компьютере используется win7... и я даже не пытался установить два других. Предполагая, что я запустил это, как мне перенести БД в производство? - person mpen; 29.10.2009
comment
Не говоря уже о том, что перезапуск apache вызывает несколько драгоценных секунд простоя. - person Harel; 10.10.2013
comment
Множество причин, по которым люди пишут код на живом сервере. Вы не в том положении, чтобы сказать ему иначе. Пожалуйста, придерживайтесь темы. - person Randy Greencorn; 09.11.2014

arrow_upward
17
arrow_downward

Запуск процесса в режиме демона не поможет. Вот что происходит:

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< /а>.

person BrainCore    schedule 05.12.2009
comment
Хорошее объяснение! Спасибо. Является ли этот пул потоков выгодным/быстрее, чем то, что делает PHP? - person mpen; 05.12.2009
comment
При использовании многопоточности вам приходится бороться с Python GIL. Таким образом, для кода обработчика запросов с интенсивными вычислениями вы можете немного пострадать от невозможности использовать несколько ЦП/ядер в одном процессе. Если код обращается к базам данных и другим модулям, которые выпускают GIL, это не такая большая проблема. Во всяком случае, гораздо сложнее, чем это. Предлагаем вам прочитать 'blog.dscpl.com. au/2007/09/». - person Graham Dumpleton; 07.12.2009
comment
Кстати, режим демона может помочь, поскольку он позволяет вам запускать монитор кода, как описано в документации mod_wsgi, на которую ссылается другой ответ. Таким образом, любое изменение в коде Python, а не только в файле сценария WSGI, может автоматически вызвать перезапуск группы процессов демона. - person Graham Dumpleton; 07.12.2009

arrow_upward
5
arrow_downward

Поскольку вы используете mod_wsgi во встроенном режиме, ваши изменения не отображаются автоматически. Вы видите их время от времени, потому что Apache иногда запускает новые экземпляры обработчика, которые перехватывают обновления.

Вы можете решить эту проблему, используя режим демона, как описано здесь. В частности, вам нужно добавить следующие директивы в конфигурацию Apache:

WSGIDaemonProcess example.com processes=2 threads=15 display-name=%{GROUP}
WSGIProcessGroup example.com
person Edward Dale    schedule 28.10.2009
comment
Я предполагаю, что вы можете просто поместить объявления в тот же контекст, что и WSGIScriptAlias. - person Edward Dale; 29.10.2009
comment
Это, кажется, не имеет никакого эффекта, кстати. - person mpen; 02.11.2009
comment
Вы просто спасете мой день! :) - person Nico Coallier; 16.08.2018

arrow_upward
5
arrow_downward

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

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

Это говорит вам, как именно перезагрузка исходного кода работает в mod_wsgi, включая монитор, который вы можете использовать для реализации того же типа перезагрузки исходного кода, что и сервер запуска Django. Также посмотрите, что говорит о том, как применить это к 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

person Graham Dumpleton    schedule 28.10.2009