deployng django dans Apache mod_wsgi (mode embarqué)

J’utilise Apache en mode embarqué comme serveur de production.

Chaque fois que j’apporte des modifications à mes fichiers core django ( urls.py , settings.py , views.py , etc.), je touch simplement le fichier project.wsgi et les modifications apparaissent instantanément sur la page Web. Parfois ça marche.

Cependant, parfois, ce n’est pas le cas. Apache se bloque Il ne peut pas servir les demandes et nécessite un redémarrage (en donnant aux utilisateurs pendant 1 à 2 secondes un message “Erreur interne du serveur”). Ensuite, je dois redémarrer (redémarrer, en fait, ne fonctionne pas aussi. Il doit s’arrêter et redémarrer).

Je colle du code de mon httpd.conf

 MaxSpareThreads 3 MinSpareThreads 1 ServerLimit 1 SetEnvIf X-Forwarded-SSL on HTTPS=1 ThreadsPerChild 5 WSGIDaemonProcess myproject processes=4 threads=12 python-path=[...] WSGIProcessGroup myproject WSGIRessortingctEmbedded On 

Pourquoi donc? Est-ce parce que Apache utilise parfois tous les processus en même temps et ne peut pas recharger les fichiers core? (c’est ce que “touch” devrait faire, non?)

EDIT: Je suis désolé. Apache s’exécute en mode intégré. Mon erreur. J’ai mis à jour la question.

EDIT2: Ligne WSGIProcessGroup incluse

Toucher le fichier script WSGI ne fait rien en mode embarqué, donc pas étonnant que cela ne fonctionne pas tout le temps. Lorsque cela apparaît, c’est simplement que la requête a été traitée par un nouveau processus Apache qui n’avait jamais traité de requêtes auparavant.

Pour que le fichier script WSGI fonctionne, vous devez utiliser le mode démon. Votre configuration est à moitié cassée cependant. Vous avez défini WSGIDaemonProcess pour le mode démon, mais vous ne déléguez pas l’application pour s’exécuter sous ce groupe de processus démon à l’aide de WSGIProcessGroup.

Allez lire:

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

http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process

Il est plus facile de supprimer les *.pyc , car cela forcerait une actualisation. Cependant, la véritable réponse à votre problème est une stratégie de déploiement appropriée, afin que vous ne finissiez pas par développer votre serveur de production.

Si vous utilisez ce serveur pour Django uniquement, puis-je suggérer la configuration nginx + uwsgi ou nginx + gunicorn . Cela isole votre environnement Web de votre backend, ce qui vous permet de redémarrer librement les processus wsgi sans affecter votre serveur. Il vous permet également d’afficher une belle page de temps d’arrêt.