Nous exécutons actuellement un petit service d'hébergement partagé pour quelques centaines de petits sites PHP sur nos serveurs. Nous aimerions offrir un soutien à Python aussi, mais de notre première recherche au moins, un redémarrage de serveur semble être requis après chaque changement de code source.
Est-ce vraiment le cas? Si tel est le cas, nous ne pourrons tout simplement pas offrir un soutien à l'hébergement Python. Donner à nos clients la possibilité de télécharger des fichiers est facile, mais nous ne pouvons pas les avoir redémarrer le processus de serveur (partagé)!
php est facile - vous téléchargez une nouvelle version d'un fichier, la nouvelle version est exécutée.
J'ai beaucoup de respect pour la langue et la communauté python, alors trouvez difficile de croire que cela nécessite vraiment un processus aussi fou de mettre à jour le code d'un site. S'il vous plaît dites-moi que je me trompe! : -)
3 Réponses :
dépend de la manière dont vous déployez l'application Python. S'il s'agit d'un script pur python CGI, aucun redémarrage n'est nécessaire (non informé du tout, car il sera très lent). Si vous utilisez modwsgi dans Apache, il existe des façons valides de Rechargement de la source . ModpyThon apparemment a quelques problèmes de support et d'accompagnement pour le rechargement du module.
Il existe des moyens autres que Apache d'héberger l'application Python, y compris le serveur de cerisier, le serveur de pâte, le zope, torsadé et la tornade.
Toutefois, à moins que vous n'ayez une raison spécifique de ne pas l'utiliser (comme vous venez de vraisemblablement une boutique Apache / PHP), je recommanderais fortement mod_wsgi sur Apache. Je sais que Django recommande Modwsgi sur Apache et la plupart des autres principaux cadres de Python fonctionneront sur Modwsgi.
Merci pour la réponse John. Vous avez donné de beaux notionners à suivre, mais n'ont pas vraiment répondu à la vraie question: pourquoi les redémarrages du serveur sont-ils requis? Ils ne sont pas en PHP, mais sont en python (CGI de côté). Je trouve cela déroutant, car ils partagent le même modèle d'exécution de base autrement ...
Ils ne partagent pas le même modèle d'exécution de base. PHP est basé sur le fichier. Apache / Mod_PHP lit un fichier et interpets le code PHP sur chaque demande. Contraste que les applications Python, qui (selon le déploiement) sont généralement des processus de fonctionnement de longue date qui existent même lorsqu'il n'y a aucune demande. Vous n'avez pas besoin de redémarrer le serveur sous Apache Mod_WSGI. Vous touchez simplement le fichier .WSGI et le processus de python (ES) sera rechargé.
Il convient de noter que le mode mod_wsgi 'S "Embedded", en plus des problèmes de performance et de fiabilité, empêche le bon fonctionnement du rechargement de code. I TOUJOURS Configurez mes serveurs en mode Daemon et de ce que j'ai entendu parler des autres, la modification de la mode Daemon corrige de nombreux problèmes avec mod_wsgi .
John, mode embarqué de mod_WSGI n'a pas de problèmes de performance et de fiabilité. Le module MOD_WSGI fonctionne lui-même parfaitement bien, tout comme une application Web Python s'exécutant sur le dessus, à condition de configurer Apache correctement. Donc, rien à voir avec mod_wsgi, mais en raison des personnes qui ne configurent pas Apache correctement lorsque le mode embarqué est utilisé. Lire ' blog.dscpl.com. AU / 2009/03 / ... '. C'est un problème gérable si vous faites vos devoirs correctement.
Brian, touchant le fichier .wsgi ne fonctionne que pour le mode Daemon de mod_wsgi. Voir ' code.google.com/p/modwsgi/wiki/reloadingsourcecode ' ' .
John, la capacité de mod_python à recharger des fichiers de code ne s'applique qu'aux manuels spécifiques à mod_python et non tous les modules Python. Ainsi, dans mod_python, si elle exécute Django ou une autre application ou cadre spécifique non mod_python, vous devez toujours redémarrer le serveur Apache entiers pour le code dans les modules / packages de Python standard à recharger.
@Graham: Je parle de mod_wsgi, pas de mod_python. Le mode intégré de Mod_WSGI est lent, parfois acticule et ne supporte pas correctement le rechargement. Bien que Mod_python soit encore pire - dans mon expérience, passant de mod_python à mod_wsgi peut presque doubler les connexions prises en charge par seconde.
@Graham, oui, j'ai échoué à mentionner que cela fonctionne uniquement en mode Daemon. Merci.
Python est une langue compilée; Le code d'octet compilé est mis en cache par le processus Python pour une utilisation ultérieure, pour améliorer les performances. PHP, par défaut, est interprété. C'est un compromis entre la convivialité et la vitesse.
Si vous utilisez un module WSGI standard, tel que Apache 'CODE> MOD_WSGI , vous n'avez pas à redémarrer le serveur - il suffit de toucher le fichier .wsgi . et le code sera rechargé. Si vous utilisez un serveur étrange qui ne prend pas en charge WSGI, vous êtes en quelque sorte sur votre propre convivialité.
En fait, les deux langues sont compilées au code octet, le code d'octets est interprété dans les deux cas, bien qu'il soit vrai que la mise en œuvre CPPHON met en cache le bytecode pour une startup plus rapide. PHP a zend accélérateur et APC qui font quelque chose de très similaire. Ma lecture semble suggérer que ce n'est pas aussi simple que simplement toucher le fichier .wsgi, mais je vais enquêter plus loin, merci!
J'utilise mod_wsgi et Apache, et c'est vraiment aussi simple. touche /path/to/site.wsgi et le nouveau code va en direct. En ce qui concerne PHP, je crois comprendre que la mise en œuvre "principale" est un interprète, avec des implémentations de compilation commerciales disponibles - est-ce correct? dépassé?
Bon à savoir, merci John. Ce comportement de rechargement s'applique-t-il également aux modules inclus dans le script principal .WSGI? (Voir la réponse de Bibince)
Oui; Lorsque le processus enfant de la WSGI est rechargé, tout modules modifiés sera rechargé.
Commentaire répétant d'ailleurs, toucher le fichier .WSGI ne fonctionne que pour le mode Daemon de mod_wsgi. Voir ' code.google.com/p/modwsgi/wiki/reloadingsourcecode ' ' .
Leon, en PHP, le monde entier est construit sur chaque demande, puis déchiré. En d'autres termes, l'interprète revient à un nouvel état après chaque demande. Ce n'est généralement pas la manière dont vous exécutez une application Web Python. Les applications Python sont des processus longs en cours d'exécution qui persistent entre les demandes.
Est-ce vraiment le cas?
Cela dépend. Le rechargement de code est hautement spécifique à la solution d'hébergement. La plupart des serveurs offrent un moyen de recharger automatiquement le script WSGI lui-même, mais il n'y a pas de normalisation; En effet, la question de savoir comment un objet d'application WSGI est connecté à un serveur Web à tous diffère largement sur des environnements d'hébergement variés. (Vous pouvez simplement créer un seul fichier de script qui fonctionne comme une colle de déploiement pour CGI, Mod_WSGI, Passager et ISAPI_WSGI, mais ce n'est pas totalement trivial.)
Qu'est-ce que Python se bat vraiment, cependant, est le rechargement de module. Qui est problématique pour les applications WSGI car toute WebApp non triviale encapsulera ses fonctionnalités dans des modules et des packages plutôt que de simples scripts autonomes. Il s'avère que le rechargement des modules est assez difficile, car si vous
Recharger () Les un par un, ils peuvent facilement se retrouver avec de mauvaises références aux anciennes versions. Idéalement, la voie à suivre consisterait à recharger l'ensemble de l'interprète Python lorsqu'un fichier est mis à jour, mais dans la pratique, il semble que certaines extensions C ne semblent pas aimer cela, ce qui n'est pas généralement fait.Il y a Solution de contournement pour recharger un groupe des modules à la fois qui peuvent mettre à jour de manière fiable une application lorsque l'un de ses modules est touché. J'utilise un module de déploiement qui le fait (ce que je n'ai pas au courant de la publication, mais peut vous choisir une copie si vous êtes intéressé) et cela fonctionne bien pour mes propres webapps. Mais vous avez besoin d'une petite discipline pour vous assurer que vous ne démarrez pas accidentellement de laisser des références aux objets de vos anciens modules dans d'autres modules, vous ne rechargez pas; Si vous parlez de charges de sites écrits par des tiers dont le code peut être fuyant, cela pourrait ne pas être idéal.
Dans ce cas, vous voudrez peut-être examiner quelque chose comme exécuter Mod_WSGI en mode Daemon avec un groupe d'applications pour chaque partie et rechargement du niveau de processus, puis appuyez sur le fichier de script WSGI lorsque vous avez mis à jour l'un des modules.
Vous avez raison de vous plaindre; Cela (et de nombreux autres problèmes de déploiement de la WSGI) pourraient faire avec une aide de normalisation.
Merci Bobince pour une réponse très gentille! S'il vous plaît, ne pensez pas que je me plains cependant, j'aimerais vraiment savoir pourquoi et comment nous pouvons améliorer les choses. La recherche d'hébergement partagé est difficile pour les développeurs de python et restera de cette manière à moins que nous puissions simplifier le modèle d'exécution partagé ...
Il suffit de relire votre réponse. Vous dessinez une distinction utile entre le code (comme dans 'Main.WSGI ») et des modules importés dans ce code (et des modules inclus dans ces modules, etc.). Je suis parti pour diriger certaines expériences avec mod_wsgi en mode Daemon, comme cela semble être l'avenue la plus prometteuse d'enquête, merci.
Pouvez-vous fournir le lien ou référence à cette entreprise de redémarrage? Regardez-vous mod_wsgi?
Chaque méthode de fonctionnement de Python sur la bande semble avoir un redémarrage du serveur dans le cadre du processus, à l'exception de la CGI. Mon intuition est que cela se tiendra avec le comportement standard de CPPHON de la mise en cache agressive de bytecode, mais aimerais entendre de quelqu'un qui peut faire plus que devinez ...
"Chaque méthode?" Puisque mod_wsgi ne fonctionne pas de cette façon, je suis curieux de quelles méthodes que vous avez trouvées. Pouvez-vous fournir des liens ou des références?
Steven, s'il vous plaît ne soyez pas défensive. Je cherche la compréhension, pas l'antagonisme. Un peu de temps sur Google vous convaincre que ma question est valide. Voir les réponses ci-dessous ou mieux, écrivez le vôtre! :-)
Vous avez explicitement demandé aux gens de vous dire que vous aviez tort. Vous êtes, et ils l'ont fait.
@Leon: J'essaie de comprendre la question avant que je tente de répondre. Je n'ai pas "chaque méthode". Je voulais savoir quelle était votre source, je pourrais déterminer ce qu'ils voulaient dire avant de tenter de la discuter plus loin. Je ne peux pas répondre à une question que je ne me manque pas.