Django + WSGI: problemi di aggiornamento?

Question

Sto sviluppando un sito Django. Sto facendo tutte le mie modifiche sul server live, solo perché è più semplice in questo modo. Il problema è che ogni tanto sembra che mi piaccia mettere in cache uno dei file * .py su cui sto lavorando. A volte se clicco molto per aggiornare, passerà avanti e indietro tra una versione precedente della pagina e una versione più recente.

Il mio set up è più o meno come quello che sta descritto nel tutorial Django: http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/#howto-deployment-modwsgi

sto indovinando che sta facendo questo perché è sparare su più istanze del gestore WSGI, ed a seconda di quale gestore la richiesta http viene inviata a, potrei ricevere diverse versioni della pagina. Il riavvio di apache sembra risolvere il problema, ma è fastidioso.

Non so davvero molto su WSGI o "MiddleWare" o su qualsiasi altra richiesta di gestione delle richieste. Vengo da uno sfondo PHP, dove tutto funziona solo :)

In ogni caso, qual è un buon modo per risolvere questo problema? L'esecuzione del gestore WSGI sarà "demone mode" per alleviare il problema? In tal caso, come posso farlo funzionare in modalità daemon?

Answer 1

è possibile risolvere questo problema, non modificare il codice sul server di vivere. Seriamente, non ci sono scuse per questo. Sviluppa localmente usando il controllo della versione e, se necessario, esegui il tuo server da un checkout live, con un hook post-commit che controlla la tua ultima versione e riavvia Apache.

Answer 2

Poiché stai utilizzando mod_wsgi in modalità incorporata, le modifiche non vengono visualizzate automaticamente. Li vedi ogni tanto perché Apache avvia a volte nuove istanze di gestori che catturano gli aggiornamenti.

È possibile risolvere questo problema utilizzando la modalità daemon, come descritto in here. In particolare, ti consigliamo di aggiungere le seguenti direttive per la configurazione di Apache:

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

Answer 3

Leggere la documentazione di mod_wsgi piuttosto che fare affidamento sulle informazioni minime per l'hosting mod_wsgi contenuto nel sito Django. In partcular, leggi:

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

Questo ti dice esattamente come il codice sorgente di ricaricare opere in mod_wsgi, tra cui un monitor è possibile utilizzare per implementare stesso tipo di codice sorgente ricarico che Django runserver fa. Vedi anche quali discorsi su come applicarlo a 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

Answer 4

L'esecuzione del processo in modalità demone non aiuterà. Ecco cosa sta succedendo:

mod_wsgi sta generando più processi identici per gestire le richieste in arrivo per il tuo sito Django. Ognuno di questi processi è il suo Interprete Python e può gestire una richiesta web in entrata. Questi processi sono persistenti (non vengono richiamati e abbattuti per ogni richiesta), quindi un singolo processo può gestire migliaia di richieste una dopo l'altra. mod_wsgi è in grado di gestire più richieste Web contemporaneamente poiché ci sono più processi.

L'interprete Python di ogni processo carica i moduli (i file Python personalizzati) ogni volta che viene eseguito un "modulo di importazione". Nel contesto di django, ciò avverrà quando un nuovo view.py è necessario a causa di una richiesta web.Una volta che il modulo è stato caricato, risiede in memoria, quindi eventuali modifiche apportate al file non si rifletteranno in tale processo. Con l'arrivo di più richieste web, l'interprete Python del processo utilizzerà semplicemente la versione del modulo che è già stata caricata in memoria. Stai vedendo incongruenze tra gli aggiornamenti poiché ogni richiesta web che stai facendo può essere gestita da processi diversi. Alcuni processi potrebbero aver caricato i moduli Python durante le revisioni precedenti del codice, mentre altri potrebbero averli caricati successivamente (poiché tali processi non avevano ricevuto una richiesta web).

La soluzione semplice: ogni volta che si modifica il codice, riavviare il processo Apache. La maggior parte delle volte è semplice come eseguire il root dalla shell "/etc/init.d/apache2 restart". Credo che funzioni anche una semplice ricarica, che è più veloce, "/etc/init.d/apache2 reload"

La soluzione daemon: se si utilizza mod_wsgi in modalità demone, tutto ciò che occorre fare è toccare (comando unix) o modificare il file di script wsgi. Per chiarire il post di scrompt.com, le modifiche al tuo codice sorgente Python non daranno luogo a mod_wsgi che ricarica il tuo codice. Il ricaricamento si verifica solo quando il file di script wsgi è stato modificato.

Ultimo punto da notare: ho parlato solo di wsgi come dell'uso dei processi per semplicità. wsgi utilizza effettivamente pool di thread all'interno di ogni processo. Non ho ritenuto che questo dettaglio fosse rilevante per questa risposta, ma puoi saperne di più leggendo il mod_wsgi.