Nginx vs Apache en tant que proxy inverse, lequel choisir


36

ce genre de question a peut-être été posée ici mais je n’en ai trouvé aucune qui corresponde vraiment à ma question. Entendu dire que les performances de nginx sont assez impressionnantes, mais Apache a plus de documentation, de communauté (lire: expert) à obtenir de l'aide

Maintenant, ce que je veux savoir, comment se comparent les deux serveurs Web en termes de performances, de facilité de configuration, de niveau de personnalisation, etc. Serveur AS REVERSE PROXY dans un environnement vps?

Je suis toujours en train de peser entre les deux pour une application Web ruby ​​(non ROR) avec Thin (un des serveurs Web Ruby).
Une réponse spécifique sera très appréciée. La réponse générale ne pas toucher la partie rubis est acceptable. Je suis toujours noob dans l'administration du serveur web.


tnx à martin et webdestroya répond, maintenant je me penche vers nginx
mhd

Ne serait-il pas plus judicieux d’utiliser un proxy inverse spécialement conçu, comme le vernis?
ptman

Réponses:


31

Je voulais mettre cela dans un commentaire puisque je suis d’accord avec le point le plus important de la réponse de webdestroyas, mais c’est un peu trop long.

Vous êtes dans un environnement VPS, cela signifie que votre mémoire RAM sera probablement très basse. Pour cette seule raison, vous souhaiterez utiliser Nginx car son empreinte mémoire est inférieure à Apaches.

De plus, je ne suis pas d'accord avec certains des arguments mentionnés.

Facilité de configuration:
Nginx n’est pas plus difficile qu’Apache. C'est différent. Si vous êtes habitué à Apache, le changement sera toujours plus difficile, cela ne signifie pas que le style de configuration lui-même est plus difficile. J'ai migré complètement d'Apache vers Nginx il y a plus d'un an et aujourd'hui, j'ai du mal à configurer un serveur Apache alors que je trouve Nginx extrêmement facile à configurer.

Pour Ruby:
Nginx a Passenger, cependant, je le vois généralement décrit comme la méthode inférieure pour se connecter à Ruby. Je ne suis pas un programmeur Ruby, donc je ne peux pas le vérifier, mais je vois souvent Unicorn et Thin mentionnés comme de meilleures alternatives.

En conclusion:
Nginx a été conçu pour être un proxy inverse. Initialement, il ne servait que les fichiers statiques et le proxy inverse sur un serveur principal via HTTP / 1.0. Depuis lors, fastcgi, l'équilibrage de charge et diverses autres fonctionnalités ont été ajoutés, mais son objectif initial était de servir des fichiers statiques et un proxy inverse. Et ça le fait vraiment bien.

Apache, au contraire, est un serveur Web à usage général. Je ne doute pas qu'il puisse parfaitement inverser le proxy, mais celui-ci n'a pas été conçu pour minimiser l'encombrement de la mémoire. Il nécessite donc plus de ressources que Nginx, ce qui signifie que l'argument initial de mon environnement VPS entre en jeu.


+1 pour la clarification.
John Gardeniers

J'irais même jusqu'à le recommander comme seul serveur Web. voir mes commentaires serverfault.com/questions/133481/… <- ici. Je l'utilise comme seul serveur Web sur mon VPS et les autres utilisateurs ont intégré FastCGI pour leurs applications PHP / CGI.
Jason

Jason Je l'utilise comme seul serveur Web depuis plus d'un an et gère des millions de chargement de pages par jour. Je suis entièrement d'accord avec votre recommandation! :)
Martin Fjordvald

8

Performance:
NGinX. Ce serveur est connu pour être l’un des serveurs Web les plus performants et est utilisé par de nombreuses entreprises différentes (Notable, MediaTemple).

Facilité de configuration:
Apache. La configuration d'Apache est très simple et très puissante. Nginx est puissant, mais peut être très difficile à comprendre, car il ressemble plus à un langage de programmation qu’à un fichier de configuration.

Niveau de personnalisation:
Apache. Apache a écrit des tonnes de mods et d’autres plugins. Bien que Nginx ait encore des plugins, je pense qu'Apache en a beaucoup plus que Nginx.

Pour Ruby:
Je sais que Nginx peut être utilisé comme un équilibreur de charge puissant avec Mongrel / webrick. Cependant, Apache a Phusion / Passenger, ce qui rend l’intégration plus agréable.

Vainqueur du proxy inverse:
NGinX


2
Je suis intéressé, pas discuter. Pourquoi Nginx est-il un gagnant pour le proxy inverse? Le reste de votre réponse ne distingue pas vraiment l'un des autres. Si quelque chose a tendance à favoriser Apache.
John Gardeniers

1
Eh bien, parce que la plupart du temps, vous voulez un proxy inverse en raison d'une charge élevée. Ce qui voudrait dire que la performance est probablement le problème le plus important. Dans ce cas, Nginx était le vainqueur, raison pour laquelle je l'ai choisie. En tant que développeur, j'adore Apache, mais d'un point "Comment puis-je obtenir le maximum de performances de ce serveur Web", j'irais avec Nginx
Mitch Dempsey

8

Nginx est basé sur les événements, tandis qu'apache est basé sur les processus. Sous forte charge, cela fait toute la différence dans le monde ... Apache doit créer un nouveau thread pour chaque connexion, contrairement à nginx. Cette différence se manifeste principalement dans l'utilisation de la mémoire, mais également dans le temps de réponse de l'utilisateur et d'autres indicateurs de performance. Nginx peut gérer des dizaines de milliers de connexions HTTP keepalive simultanées sur du matériel moderne. Apache utilisera 1 à 2 Mo de pile pour chaque connexion. Par conséquent, vous constaterez que vous ne pouvez gérer que quelques centaines, voire un millier de connexions simultanément sans commencer à permuter.

Nous utilisons nginx devant Apache et IIS dans notre environnement en tant que proxy d’équilibrage de charge et de mise en cache, et nous ne pourrions être plus heureux. Nous utilisons deux petites boîtes nginx au lieu d’une paire d’appareils F5 loués très onéreux et nos sites sont beaucoup plus rapides en temps de réponse et de temps de réponse mesurés.


1

J'étais dans le même dilemme que vous il y a environ deux semaines.

Pour vous donner une réponse très succincte: d'après mes recherches, nginx est très rapide et convivial, mais il n'a été conçu que pour inverser les fichiers statiques par proxy. Le reste sont des solutions boulonnées que vous devez configurer ou écrire à votre guise.

Autant que je sache, nginx n'a pas de fichier htaccess, vous devez donc trouver votre chemin si vous dépendez de cette fonctionnalité.

Autant que je sache, tout le nécessaire fonctionne et j'ai vu des tutoriels.

Je vais aller avec nginx avec ma configuration de test et de profilage. J'ai une application typique de la lampe.

J'ai lu qu'il y a des personnes qui inversent le proxy, servent les fichiers statiques de nginx et transmettent tout le reste, comme PHP, à une instance Apache en cours d'exécution. Ils réclament un bon compromis. Je n'ai aucune donnée de performance à ce sujet, mais vous voudrez peut-être savoir.


2
Désactiver les remplacements htaccess sur Apache pour des raisons de performances est assez courant, prendre en charge une telle fonctionnalité sur un serveur conçu pour des performances élevées n’aurait pas beaucoup de sens.
theotherreceive

Merci d'avoir ajouté cette déclaration. Le PO n'est pas un administrateur pro, nous devons donc être clairs.
deploymonkey

1

Au cours des dernières années, j'ai eu de graves problèmes avec mod_proxy d'Apache sur diverses plates-formes et divers environnements. De temps en temps, il cessera tout simplement de fonctionner et le seul moyen de remédier au problème semble être de redémarrer le serveur Apache.

Personnellement, je ne demanderais pas «nginx vs Apache», mais «nginx vs lighttpd» - et c'est un appel beaucoup plus dur!


Argument valable, mais la dernière fois que j'ai vérifié, lighttpd avait encore des bogues en suspens depuis longtemps et était renommé pour des fuites de mémoire. Il a été déconseillé pour le déploiement de production par les administrateurs. Cela a-t-il changé?
deploymonkey

Il a mises en garde, certes (surtout lorsque au service de très gros fichiers), mais il est beaucoup plus stable que Apache en tant que proxy - j'ai eu aucun problème réel dans plusieurs déploiements au cours des six derniers mois
Mo.

J'ai
rayé
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.