Je pense à l'architecture d'un nouveau serveur Web. Est-ce que avoir Varnish comme cache devant Nginx comme proxy inverse et servir des fichiers statiques devant apache pour tous les efforts serait une bonne idée?
Je vais exécuter des applications php et ruby on rails.
Y aura-t-il trop de frais généraux pour transmettre des requêtes php à apache via deux autres processus?
Merci beaucoup!
Réponses:
Ouais, c'est valide. Mon approche personnelle serait d'utiliser Varnish à l'avant et d'utiliser VCL pour diviser le trafic entre les requêtes NGINX statiques et votre poids lourd (que ce soit Apache ou Passenger ou ... cela n'a pas d'importance). Cela est particulièrement vrai s'il se trouve sur la même machine car vous n'avez pas besoin de la surcharge supplémentaire. Cela ne vous achète pas nécessairement.
Le vernis ne prend pas (encore) en charge la compression gzip, donc ce pourrait être une idée de l'échanger avec nginx devant pour compresser ce que le vernis renvoie. Étant donné que le vernis et nginx ne se battent pas pour les mêmes ressources (nginx utilise le CPU pour la compression gzip, tandis que le vernis utilise la mémoire), ils devraient fonctionner sans problème sur la même machine.
Le vernis prend désormais en charge la compression gzip , donc à moins que vous n'ayez besoin d'une terminaison SSL (comme suggéré dans les commentaires), je suggère de mettre le vernis directement en contact avec Internet.
Pour http:
(internet) -> (vernis, gzip, mise en cache, esi) -> (application)
Pour https:
(internet) -> (nginx, ssl) -> (vernis, gzip, mise en cache, esi) -> (application)
Si vous voulez aussi Apache là-dedans (pour le support omniprésent de mod_foobar), je le mettrais entre le vernis et l'application
Mise à jour: mise à jour pour inclure la prise en charge de gzip dans le vernis 3.0. Ajout de ssl / esi comme suggéré dans les commentaires
Le montant des frais généraux ne devrait pas être significatif. Je suppose qu'une partie de la raison pour laquelle vous voulez avoir ces deux niveaux est pour l'évolutivité; dans ce cas, vous verriez très probablement, par rapport à apache, que le vernis et le nginx ne fonctionnent pas très dur.
Si vous disposez des trois niveaux sur une même machine, il devrait y avoir moins d'impact sur les performances avant d'atteindre la capacité du serveur lui-même.
Comme alternative, pourquoi ne pas vernir + nginx avec passager? J'ai utilisé cette configuration dans le passé et nginx utilisant passager est relativement léger et fonctionnait assez bien. Cela pourrait valoir la peine de réfléchir si vous n'êtes pas marié à Apache qui gère votre pile de rails.
Je suis l'administrateur système d'une plateforme de commerce électronique en démarrage. Nous utilisons vernis + nginx devant notre pile PHP / apache et cela a fait des merveilles.
Nous avons une application qui utilise beaucoup de mémoire et l'application utilisait environ 15 à 20 Go de RAM par nœud Web et une fois que nous avons mis du vernis devant, c'est maintenant environ 8 Go de RAM par nœud. Ils n'ont jamais piqué.
Je le recommande donc vivement.
J'utilise Drupal, avec le module boost sur un serveur Apache + PHP + MySQL, mais devant eux j'utilise Nginx avec la fonction gzip-static activée, et j'utilise les résultats de boost pour servir les utilisateurs.
Et en plus de tout ça j'utilise du vernis, tous sur le même PC, j'ai de bons résultats.
J'utilise également Nginx pour modifier les en-têtes que Drupal ne fait pas très bien pour le cache.
Ce n'est pas une bonne idée, sauf si vous avez besoin de quelque chose comme ESI. Nginx possède son propre système de mise en cache qui fonctionne mieux .
Apache peut être utilisé pour terminer (décrypter) SSL, consultez http://noosfero.org/Development/Varnish#SSL