J'ai l'intention d'utiliser un seul VPS pour déployer plusieurs applications CherryPy à faible trafic en tant que sous-répertoires; par exemple: example.com/app1, example.com/app2, etc.

Après des recherches sur le déploiement de WSGI, il semble que la méthode préférée pour déployer des applications consiste à utiliser un serveur WSGI (Gunicorn, uWSGI, etc.) et NGinx dans une configuration de proxy inverse. Il semble exagéré d'utiliser deux serveurs Web en tandem - d'autant plus que mon application CherryPy est elle-même un serveur Web - mais je ne veux pas rejeter l'idée telle qu'elle apparaît partout . Je ne suis certainement pas un expert, donc j'aimerais en discuter.

Je vois trois options:

• Déployez CherryPy par lui-même.
• Déployez sous Gunicorn ou un autre serveur WSGI.
• Déployez-le sous un serveur WSGI et inversez-proxy vers NGinx, qui semble être la solution de tout le monde.

Mes questions:

• Quelle est la principale raison pour laquelle je vois ce modèle partout? NGinx est-il juste aussi bon?
• Pour les applications à faible trafic, le serveur natif CherryPy est-il assez bon, ou devrais-je même pas essayer?

Tous les conseils sont appréciés, merci.

La raison pour laquelle tout le monde met nginx (ou un autre serveur tel qu'Apache) devant leurs serveurs d'applications est que tout le monde a du contenu statique tel que des images, CSS et JavaScript, et des exigences étranges qui sont uniques à leur application.

Votre serveur d'application (CherryPy, gunicorn, peu importe) est optimisé pour exécuter votre application et servir sa sortie. Bien que le serveur d'applications puisse également servir du contenu statique, il n'est presque jamais bien optimisé pour cette tâche, car il est secondaire par rapport à l'objectif principal du serveur d'applications. (Certains serveurs d'applications vous aideront également en réduisant et en compressant votre CSS et JS, afin que le serveur Web en face puisse servir ces ressources encore plus rapidement.)

De plus, le serveur Web réel peut faire bien plus que le service de contenu haute performance. Des choses comme la mise en cache, la manipulation d'en-tête, la réécriture d'URL, la géolocalisation et de nombreuses autres fonctionnalités qui ne feraient que gonfler le serveur d'applications sans raison valable.

En règle générale, vous exécutez le serveur d'applications seul uniquement lors du développement de l'application, lorsque vous êtes le seul utilisateur et que les performances ne sont pas un problème. Même si votre site est à faible trafic, vous aimeriez qu'il soit plus rapide, non? Les sites à faible trafic qui sont lents ne deviennent généralement pas des sites à fort trafic ...

Pourquoi les gens mettent-ils Nginx au premier plan?

1. Nginx est un serveur Web asynchrone. Cela signifie qu'il ne dédie pas de thread ou de processus par connexion. Au lieu de cela, il utilise la bibliothèque d'interrogation de socket préférée du système d'exploitation et est donc capable de gérer des centaines de milliers de connexions. Pourquoi devriez-vous, en tant que développeur d'applications, vous en soucier? Parce que Nginx met en mémoire tampon les connexions et ne transmet la demande à votre instance amont CherryPy que lorsque la demande est entièrement lue. Même chose pour les réponses. De cette façon, votre application CherryPy, qui est un serveur threadé, derrière Nginx à bien des égards, devient asynchrone. Plus précisément, vous saluez un problème de client lent et des attaques DOS loris lentes.
2. Nginx a une limite de débit de connexion prête à l'emploi. Dis, je ne veux pas plus de 8 connexions simultanées à partir de la même IP.
3. CherryPy a un problème SSL . Nginx non.
4. Python peut envoyer des octets d'avant en arrière presque aussi bien que C. Python zlibn'est qu'un wrapper autour de la bibliothèque C. Mais parce que Nginx gère efficacement la connexion, c'est une bonne idée de soulager vos threads de travail CherryPy de la diffusion de contenu statique en production et de se consacrer uniquement au contenu dynamique.
5. Multiplexage de plusieurs instances CherryPy sur le même port, domaine, chemin, etc. Généralement, flexibilité supplémentaire d'un autre niveau de configuration.

Est-il sûr d'utiliser CherryPy seul?

Selon l'un des auteurs originaux, oui . La plupart des choses pertinentes sur le Web que vous pouvez faire avec CherryPy seule.

CherryPy a la notion d'application et vous pouvez servir plusieurs applications avec une seule instance CherryPy. CherryPy peut également servir à d'autres applications WSGI .

Déploiement de CherryPy

Dans un déploiement traditionnel de style * nix, vous écrivez le script init, démonifiez votre processus, supprimez ses privilèges, écrivez son PID, etc. Ce n'est pas un gros problème lorsque vous avez quelques instances CherryPy. Lorsque vous en avez des dizaines, cela devient fastidieux et il est logique de transférer la gestion des processus vers Gunicorn ou uWGSI et de faire passer vos instances CherryPy de HTTP à WSGI.

J'ai écrit un tutoriel / squelette de projet, cherrypy-webapp-skeleton , dont le but était de combler les lacunes pour le déploiement (traditionnel) d'une application CherryPy du monde réel sur Debian pour un développeur web.

Emballer

1. Faible trafic, pas d'exigences particulières → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Trafic élevé, exigences particulières → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Des dizaines d'instances CherryPy distinctes sur le même serveur, désireuses de surpasser la solution de tout le monde → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.