Nous parlons de 1 à 3 serveurs frontaux au total, pas d'une grande batterie de serveurs avec équilibrage de charge entre les niveaux?
Mettre nginx devant Vanish vous permet de faire une compression HTTP à la volée. Il s'agit d'une meilleure pratique de performance, mais elle pourrait être supprimée. (Le contenu dans Varnish est souvent conservé non compressé, de sorte que ESI comprend le travail, et vous n'avez donc pas à gérer plusieurs versions mises en cache du même objet en fonction de la correspondance d'en-tête / navigateur Vary.)
En ce qui concerne nginx sur le serveur d'application - Apache avec mod_wsgi n'est- il pas la manière recommandée et la plus courante de déployer de nouvelles installations Django de nos jours? Je ne connais pas de raison impérieuse d'utiliser nginx / fastcgi sur Apache / mod_wsgi pour Django; mais vous devriez demander conseil à un expert Django.
En ce qui concerne le vernis ayant des fonctionnalités d'équilibrage de charge attrayantes que nginx ne possède pas, je ne vois pas ce qu'elles sont? Le vernis a un équilibrage aléatoire et alternatif. nginx a un round robin, une adresse IP client et un hachage cohérent - je ne vois pas d'avantage significatif pour Varnish? S'agit-il de VCL ou d'un rechargement de configuration gracieux de Varnish ou autre chose?
Pour une petite configuration de serveur 1-3, je suppose que je ferais juste
Vernis -> Apache / mod_wsgi / Django
ou peut-être
Squid -> Apache / mod_wsgi / Django
et ignorez la compression HTTP pour plus de simplicité, sauf si la bande passante est coûteuse.
Mise à jour:
Graham Dumpleton a écrit un précieux commentaire ci-dessous. Il mentionne une configuration très courante pour par exemple un blog sur un VPS, ou une petite ferme web sans mise en cache:
nginx -> Apache / mod_wsgi / Django
Il s'agit d'une très bonne solution, pour deux raisons:
- Configuration simple
- nginx, qui a une vitesse élevée et une surcharge minimale, gère le service de fichiers statiques et la connexion au navigateur keepalive.
- Django fonctionne dans l'excellent mod_wsgi de Graham Dumpleton, la plateforme recommandée pour Django.
La raison pour laquelle je n'ai pas mentionné cela au départ est que OP semblait nécessiter Varnish, une solution de mise en cache à très hautes performances. Le combo nginx / Apache / mod_wsgi ne peut pas faire de mise en cache avec un niveau de performance et de flexibilité qui correspond à Varnish.
Vous pouvez utiliser nginx sans vernis pour proxy et mettre en cache le contenu.
la source
J'ai utilisé Nginx, Varnish et Apache / mod_wsgi / Django avec succès. J'ai commencé avec la configuration suivante:
Une fois que j'ai commencé à voir une charge importante sur Apache, j'ai ajouté Varnish:
J'utilise Nginx comme une sorte de "routeur URL". Les demandes d'administrateur de Django sont envoyées directement de Nginx à Apache. Les demandes des clients sont envoyées de Nginx à Varnish qui met en cache les demandes d'Apache et sert également les éléments "honorés" du cache si les serveurs d'application ne sont pas disponibles.
Mon serveur Nginx sert également directement certains contenus statiques (par exemple, images, CSS et fichiers javascript).
En général, les performances ont été excellentes. J'ai remarqué quelques mises en garde que je devrais mentionner:
la source
J'utilise Nginx-> Vernis-> uWSGI-> Django
la source