Je développe un site Django. Je fais toutes mes modifications sur le serveur Live, juste parce que c'est plus facile de cette façon. Le problème est, de temps en temps, il semble aimer mettre en cache l'un des * fichiers * .PY que je travaille sur. Parfois, si je frappe beaucoup d'actualisation, il va passer et venir entre une ancienne version de la page et une version plus récente.
Ma configuration est plus ou moins comme ce que c'est décrit dans les tutoriels de Django: http://docs.djangoproject.com/fr/dev/howto/Deployment/modwsgi/#howto-Deployment-modwsgi
Je suis deviner Cela fait cela, car il tire plusieurs instances du gestionnaire WSGI et, en fonction du gestionnaire de la requête HTTP, je peux recevoir différentes versions de la page. . Redémarrer Apache semble résoudre le problème, mais c'est ennuyeux.
Je ne sais vraiment pas grand chose à propos de WSGI ou de "middleware" ou de cette des choses de manutention de la demande. Je viens d'un fond de PHP, où tout fonctionne tout simplement :)
Quoi qu'il en soit, qu'est-ce qui est une bonne façon de résoudre ce problème? L'exécution du gestionnaire WSGI est "Mode Daemon" allégera le problème? Si oui, comment puis-je l'obtenir en mode Daemon?
4 Réponses :
Parce que vous utilisez mod_wsgi en mode embarqué, vos modifications ne sont pas automatiquement vues. Vous les voyez de temps en temps parce que Apache démarre parfois les nouvelles instances de gestionnaire, ce qui attrape les mises à jour.
Vous pouvez le résoudre à l'aide du mode Daemon, comme décrit ici . Plus précisément, vous voudrez ajouter les directives suivantes à votre configuration Apache:
Je suppose que vous pouvez simplement mettre les déclarations dans le même contexte que WSGIScriptalias.
Cela semble avoir aucun effet du tout, BTW.
Vous venez de sauver ma journée! :)
Vous pouvez résoudre ce problème en modifiant votre code sur le serveur Live. Sérieusement, il n'y a pas d'excuse pour cela. Développez localement à l'aide de la version de version, et si vous devez, exécutez votre serveur à partir d'une commande en direct, avec un crochet post-validation qui vérifie votre dernière version et redémarre Apache.
Oui, mais parfois Prod Environnement se comporte différemment du serveur de dev intégré, donc pas de choix :)
@jujule: Vous pouvez configurer un domaine de test sur le serveur Prod afin que vous puissiez tester ce que vous développez localement. Je ne peux penser à aucune excuse qui peut justifier la modification du code sur le serveur Prod.
C'est tellement de travail à reproduire l'environnement du serveur cependant! Mon serveur exécute Ubuntu / Apache2 / Postgres, et mon ordinateur à la maison utilise Win7 ... et je n'ai même pas essayé d'installer les deux autres. En supposant que j'ai eu cette course, comment migrerais-je la DB à la production?
Sans oublier que le redémarrage Apache provoque quelques secondes précieuses secondes de temps d'arrêt.
Beaucoup de raisons pour lesquelles les gens codent sur Live Server. Vous n'êtes pas en mesure de lui dire le contraire. Pls coller au sujet.
Lire la documentation MOD_WSGI plutôt que de s'appuyer sur les informations minimales pour MOD_WSGI Hosting contenues sur le site Django. En partie particulaire, lue:
http://code.google.com/p/modwsgi/wiki/reloadingsourcode
Cela vous indique exactement comment le rechargement de code source fonctionne dans mod_wsgi, y compris un moniteur que vous pouvez utiliser pour implémenter le même type de code source Recharger que Django Runserver fait. Voyons également qui parle de savoir comment appliquer cela à Django.
http: //blog.dscpl .Com.au / 2008/12 / Utilisation-Modwsgi-Quand-Development-Django.html http: //blog.dscpl. com.au/2009/02/source-code-reloading-with-modwsgi-on.html
Exécution du processus en mode Daemon ne vous aidera pas. Voici ce qui se passe:
mod_wsgi se fraye plusieurs processus identiques pour gérer les demandes entrantes pour votre site Django. Chacun de ces processus est son propre interprète python et peut gérer une demande Web entrante. Ces processus sont persistants (ils ne sont pas élevés et déchirés pour chaque demande). Un processus unique peut donc gérer des milliers de demandes l'une après l'autre. Mod_WSGI est capable de gérer simultanément plusieurs demandes Web car il existe plusieurs processus.
L'interprète Python de chaque processus chargera vos modules (vos fichiers Python personnalisés) chaque fois qu'un "module d'importation" est exécuté. Dans le contexte de Django, cela se produira lorsqu'une nouvelle vue.py est nécessaire en raison d'une demande Web. Une fois que le module est chargé, il réside en mémoire, puis toute modification que vous apportez au fichier ne sera pas reflétée dans ce processus. Comme d'autres demandes Web entrent, l'interpréteur Python du processus utilisera simplement la version du module déjà chargé en mémoire. Vous voyez des incohérences entre rafraîchissements car chaque demande de bande que vous effectuez peut être traitée par différents processus. Certains processus peuvent avoir chargé vos modules Python lors de révisions antérieures de votre code, tandis que d'autres peuvent les avoir chargées plus tard (puisque ces processus n'avaient pas reçu de demande Web).
La solution simple: chaque fois que vous modifiez votre code, redémarrez le processus Apache. La plupart des temps sont aussi simples que la racine de la coque "/etc/init.d/apache2 redémarrage". Je crois qu'un simple rechargement fonctionne également, ce qui est plus rapide, "/etc/init.d/apache2 recharger"
La solution Daemon: Si vous utilisez mod_wsgi en mode Daemon, tout ce que vous devez faire est Touchez (commande UNIX) ou modifiez votre fichier de script WSGI. Pour clarifier le message de Scrompt.com, les modifications de votre code source Python n'entraîneront pas à Mod_WSGI Recharger votre code. Le rechargement ne se produit que lorsque le fichier de script WSGI a été modifié.
Dernier point à noter: Je n'ai parlé que de la WSGI qu'à utiliser des processus de simplicité. WSGI utilise en fait des piscines de fil à l'intérieur de chaque processus. Je n'ai pas ressenti ce détail pour être pertinent pour cette réponse, mais vous pouvez en savoir plus en lisant sur mod_wsgi < / a>.
Belle explication! Merci. Ce fil est-il en commun avantageux / plus rapide que n'importe quel PHP?
Lors de l'utilisation de multithreading, vous devez faire face au GIL Python. Ainsi, pour calculer le code de gestionnaire de demande intense, vous pouvez subir un peu de ne pas pouvoir exploiter plusieurs processeurs / noyaux dans un processus. Si le code accède aux bases de données et à d'autres modules qui libèrent le GIL, pas tant de problème. Quoi qu'il en soit, beaucoup plus compliqué que cela. Vous suggère de lire ' blog.dscpl.com. AU / 2007/09 / ... '.
BTW, le mode Daemon peut vous aider, car il vous permet d'exécuter le moniteur de code comme décrit dans la documentation MOD_WSGI référencée dans une autre réponse. De cette façon, tout changement de code Python, pas seulement au fichier de script WSGI, peut déclencher automatiquement un redémarrage du groupe de processus Daemon.