Vernis Nginx Nginx Django?

13

J'ai une application django et je veux configurer Varnish sur un serveur en face d'elle. Dans un autre thread de défaut de serveur, quelqu'un a suggéré de mettre Nginx devant Varnish.

Dois-je mettre Nginx devant Varnish sur le serveur de mise en cache? Si oui, dois-je utiliser Nginx sur le serveur d'applications?

nginx  django  varnish 
— Enrico
source

Réponses:

10

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:

  1. Configuration simple
  2. nginx, qui a une vitesse élevée et une surcharge minimale, gère le service de fichiers statiques et la connexion au navigateur keepalive.
  3. 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.

— Jesper M
source
2
Vous pouvez même utiliser 'nginx -> Apache / mod_wsgi / Django' comme beaucoup de gens le font pour diverses bonnes raisons.
— Graham Dumpleton
4
L'autre chose que nginx fournit dans ce cas d'utilisation que beaucoup ne réalisent pas est que nginx isole Apache des clients lents. En effet, le contenu des requêtes jusqu'à une certaine taille n'est pas diffusé par nginx. Au lieu de cela, il tamponnera les en-têtes de demande et le contenu et ne demandera de proxy que lorsqu'il aura tout. Cela signifie qu'il ne le remet à Apache que lorsque toutes les informations nécessaires pour gérer la demande sont disponibles. Ainsi, Apache / mod_wsgi sera occupé pendant le moins de temps possible et les processus / threads ne seront pas bloqués par un client lent. Une mesure de mise en mémoire tampon se produit également à l'envers afin qu'Apache puisse également terminer plus rapidement.
— Graham Dumpleton
2
@Graham Dumpleton: C'est très agréable de vous avoir ici, j'espère que vous resterez. :-). En ce qui concerne le multiplexage HTTP nginx / la gestion des connexions intelligentes, je suis entièrement d'accord.
— Jesper M
Tout d'abord, merci Jesper et Graham d'avoir pris le temps d'écrire des réponses aussi complètes. Je prévois de mettre un serveur d'équilibrage de charge devant deux serveurs d'applications. Un serveur gérera la majeure partie du trafic, le second étant principalement utilisé pour le basculement et le test bêta de nouvelles fonctionnalités.
— Enrico
Varnish est attrayant car il me donne un contrôle total sur les demandes envoyées à quel backend. Varnish vérifie également l'intégrité des serveurs backend, le basculement est simple à configurer et il gère les backends lents / morts avec élégance (si les deux serveurs meurent).
— Enrico
4

Vous pouvez utiliser nginx sans vernis pour proxy et mettre en cache le contenu.

— silencieux
source
2
vernis a des fonctionnalités d'équilibrage de charge attrayantes que nginx ne sort pas de la boîte
— Enrico
4
quelles fonctionnalités par exemple?
— silencieux
4

J'ai utilisé Nginx, Varnish et Apache / mod_wsgi / Django avec succès. J'ai commencé avec la configuration suivante:

Nginx -> Apache / mod_wsgi / Django

Une fois que j'ai commencé à voir une charge importante sur Apache, j'ai ajouté Varnish:

Nginx -> Vernis -> Apache / mod_wsgi / Django

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:

  1. Sur un site occupé, le redémarrage de Varnish peut entraîner une augmentation de la charge sur les serveurs d'applications, il est donc préférable de limiter au minimum le redémarrage de Varnish. (Varnish ne semble pas avoir un "rechargement" comme Nginx / Apache où il relit juste ses fichiers VCL). Inversement, le rechargement d'une configuration Nginx a un impact minimal. Pour cette raison, je fais la plupart de la réécriture d'URL et du "routage" dans Nginx.
  2. Le vernis est facile à déposer entre Nginx et Apache. Si vous commencez à remarquer une charge élevée sur vos serveurs d'applications, l'ajout de vernis avec même la configuration par défaut peut vraiment faire la différence.
  3. Si vous utilisez Varnish, vous devez absolument réfléchir à la façon dont vous allez gérer l'invalidation du cache.
  4. D'après mon expérience, Varnish gère les backends défaillants un peu plus gracieusement que Nginx (comme vous l'avez souligné plus tôt).
— David Narayan
source
Je n'ai jamais vu de vernis derrière autre chose. Le vernis est généralement l'équilibreur de charge qui fait le routeur d'url. Vous avez donc 2 serveurs Web et 1 proxy ou 2 procurations et 1 serveur Web? Q
— ioanb7
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.