2009-10-28 15 views
7

Estoy desarrollando un sitio de Django. Estoy haciendo todos mis cambios en el servidor en vivo, simplemente porque es más fácil de esa manera. El problema es que, de vez en cuando, parece querer almacenar en caché uno de los archivos * .py en los que estoy trabajando. A veces, si pulso actualizar mucho, cambiará entre una versión anterior de la página y una versión más nueva.Django + WSGI: ¿Cuestiones refrescantes?

Mi puesta a punto es más o menos como las que se describen en los tutoriales de Django: http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/#howto-deployment-modwsgi

estoy adivinando que está haciendo esto porque está disparando varias instancias de del controlador WSGI, y dependiendo de qué controlador a la que se envía la solicitud http, puedo recibir diferentes versiones de la página. Reiniciar apache parece solucionar el problema, pero es molesto.

Realmente no sé mucho sobre WSGI o "MiddleWare" o cualquiera de esas solicitudes para manejar cosas. Vengo de un fondo de PHP, donde todo simplemente funciona :)

De todos modos, ¿cuál es una buena manera de resolver este problema? ¿Se ejecutará el controlador WSGI es "modo daemon" alivia el problema? Si es así, ¿cómo hago para que se ejecute en modo daemon?

Respuesta

2

puede resolver este problema por no editar el código en el servidor en vivo. En serio, no hay excusa para eso. Desarrolla localmente usando el control de versiones, y si es necesario, ejecuta tu servidor desde un proceso de pago en vivo, con un enganche post-commit que verifica tu última versión y reinicia Apache.

+1

sí, pero a veces prod environnement se comporta de manera diferente que el servidor de desarrollo integrado, por lo que no hay opción :) – jujule

+0

@jujule: puede configurar un dominio de prueba en el servidor de prod para que pueda probar lo que desarrolla localmente. No puedo pensar en ninguna excusa que pueda justificar la edición de código en el servidor de prod. – shanyu

+0

¡sin embargo, es tanto trabajo para replicar el entorno del servidor! mi servidor ejecuta ubuntu/apache2/postgres, y la computadora de mi casa usa win7 ... y ni siquiera he intentado instalar los otros dos. Suponiendo que lo obtuviera, ¿cómo migraría el DB a producción? – mpen

4

Dado que está utilizando mod_wsgi en modo incrustado, sus cambios no se ven automáticamente. Los ve de vez en cuando porque Apache inicia nuevas instancias de controlador a veces, que captan las actualizaciones.

Puede resolver esto utilizando el modo daemon, como se describe here. En concreto, tendrá que añadir las siguientes directivas de configuración de Apache:

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

No necesito hosts virtuales para hacer este trabajo, ¿verdad? – mpen

+1

Supongo que puede simplemente poner las declaraciones en el mismo contexto que WSGIScriptAlias. –

+0

Esto parece no tener ningún efecto en absoluto, por cierto. – mpen

5

Lea la documentación de mod_wsgi en lugar de confiar en la información mínima para el alojamiento de mod_wsgi que se encuentra en el sitio de Django. En partcular, debe decir:

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

Esto le indica exactamente cómo funciona el código fuente de recarga en mod_wsgi, incluyendo un monitor que puede utilizar para implementar mismo tipo de código fuente de recarga que Django hace de ejecución del servidor. También vea qué habla sobre cómo aplicar eso 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

16

La ejecución del proceso en modo demonio no ayudará. Esto es lo que está sucediendo:

mod_wsgi está generando múltiples procesos idénticos para manejar las solicitudes entrantes para su sitio Django. Cada uno de estos procesos es su propio intérprete de Python y puede manejar una solicitud web entrante. Estos procesos son persistentes (no se abren y se eliminan para cada solicitud), por lo que un solo proceso puede manejar miles de solicitudes una detrás de la otra. mod_wsgi es capaz de manejar múltiples solicitudes web simultáneamente ya que hay múltiples procesos.

El intérprete de Python de cada proceso cargará sus módulos (sus archivos personalizados de Python) siempre que se ejecute un "módulo de importación". En el contexto de django, esto ocurrirá cuando se necesite una nueva view.py debido a una solicitud web.Una vez que el módulo está cargado, reside en la memoria, por lo que los cambios que realice en el archivo no se reflejarán en ese proceso. A medida que ingresen más solicitudes web, el intérprete de Python del proceso simplemente usará la versión del módulo que ya está cargada en la memoria. Está viendo inconsistencias entre las actualizaciones ya que cada solicitud web que está realizando puede ser manejada por diferentes procesos. Es posible que algunos procesos hayan cargado sus módulos de Python durante las revisiones anteriores de su código, mientras que otros pueden haberlos cargado más adelante (ya que esos procesos no habían recibido una solicitud web).

La solución simple: cada vez que modifique su código, reinicie el proceso de Apache. La mayoría de las veces es tan simple como ejecutar como root desde el shell "/etc/init.d/apache2 restart". Creo que también funciona una recarga simple, que es más rápida, "/etc/init.d/apache2 reload"

La solución daemon: si está utilizando mod_wsgi en modo daemon, todo lo que tiene que hacer es tocar (comando Unix) o modifique su archivo de script wsgi. Para aclarar la publicación de scrompt.com, las modificaciones a su código fuente de Python no darán como resultado que mod_wsgi vuelva a cargar su código. La recarga solo ocurre cuando el archivo de script wsgi ha sido modificado.

Último punto a tener en cuenta: solo hablé sobre wsgi como el uso de procesos para simplificar. wsgi realmente usa grupos de hilos dentro de cada proceso. No creo que este detalle sea relevante para esta respuesta, pero puede obtener más información al leer acerca de mod_wsgi.

+0

¡Buena explicación! Gracias. ¿Es esta agrupación de subprocesos ventajosa/más rápida que lo que PHP está haciendo entonces? – mpen

+0

Al usar subprocesamiento múltiple, debe lidiar con Python GIL. Por lo tanto, para el código de controlador de solicitud intensivo de cómputo, puede sufrir un poco por no ser capaz de aprovechar múltiples CPU/núcleos en un proceso. Si el código está accediendo a bases de datos y otros módulos que liberan el GIL, no es tanto un problema. De todos modos, mucho más complicado que eso. Te sugiero que leas "http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html". –

+0

Por cierto, el modo daemon puede ayudar, ya que le permite ejecutar el monitor de código como se describe en la documentación mod_wsgi a la que se hace referencia en otra respuesta. De esta forma, cualquier cambio en el código de Python, no solo en el archivo de script de WSGI, puede desencadenar automáticamente un reinicio del grupo de procesos de daemon. –

Cuestiones relacionadas