Quand dois-je passer à NGinx?

J'ai un serveur avec plusieurs domaines et applications en cours d'exécution, tout au long d'Apache. Tout va bien pour le moment, mais j'ai l'intention de développer une application Web très performante (en utilisant C ++ avec CPPCMS), en commençant par mon serveur pour les tests, peut-être en obtenant un serveur séparé uniquement pour cette application une fois qu'elle sera prête.

Quoi qu'il en soit, j'ai beaucoup entendu parler de NGinx, qui semble être plus performant qu'Apache, alors je me demandais si cela valait la peine de travailler avec lui pour ce nouveau projet. Ce n'est pas clair dans mon esprit car je ne sais pas quel type de goulot d'étranglement de performances NGinx résout exactement.

Je ne suis pas un utilisateur avancé d'Apache, je suis un pauvre administrateur Linux et je ne développe pas beaucoup d'applications Web (mais j'ai des notions). Je suis principalement dédié à l'écriture de logiciels, donc la partie serveur Web est parfois très obscure pour moi. Chaque fois que je dois configurer un site Web via Apach, j'ai besoin de beaucoup de temps pour parcourir le document pour m'assurer de ne pas tout casser.

Cela dit, je pense que je vais beaucoup mieux de ce côté-ci, mais j'ai encore besoin de conseils. J'ai vu des fichiers de configuration nginx autour, et cela semble beaucoup plus compréhensible que ceux d'Apache, mais peut-être que je me trompe?

D'après les informations que j'ai recueillies, NGinx serait le meilleur choix lorsque vous souhaitez équilibrer la charge, donc si votre application est répartie sur plusieurs machines, non? Comme je pense à ma demande de scalling (et de performance), il semble que c'est ce dont j'ai besoin, mais peut-être que je dois en savoir plus sur le moment où il est intéressant de passer d'Apache à NGinx. Vaut-il la peine de passer à NGinx pour toutes mes applications actuelles? Combien ça coûte? (Je veux dire, est-il coûteux de passer de l'un à l'autre à temps?) Puis-je utiliser Apache et NGinx sur la même machine sans aucun problème?

Note latérale : veuillez ne pas m'encourager à utiliser des langages interprétés au lieu de C ++, ce n'est pas lié à la question. Voir la page de justification du CPPCSM pour voir quel type d'application peut en bénéficier. Je comprends parfaitement les inconvénients (par rapport aux applications en Ruby et Python, que j'utilise déjà pour des webapps moins gourmandes en énergie) et je suis d'accord avec ça.

Plusieurs points:

La principale différence entre Apache et Nginx ou Lighttpd (que j'aime beaucoup personnellement) est l'architecture:

1. Apache gère une connexion par processus ou par thread (selon le mod-XYZ)
2. Nginx et Lighttpd sont des connexions multiples à un seul thread dans une seule boucle d'événements.

Par conséquent:

1. Nginx et Lighttpd évoluent beaucoup mieux sous un nombre élevé de connexions simultanées, disons qu'avec 1000 connexions Apache mourrait presque car il faudrait 1000 processus dans mod-prefork ou 1000 threads dans mod-worker.

   Si vous prévoyez d'utiliser les technologies Comet où chaque connexion nécessite une connexion HTTP d'interrogation longue, Apache ne serait pas acceptable car il ne s'adapte pas bien.

2. Nginx et Lighttpd consomment moins de mémoire car chaque connexion nécessite + - deux sockets (HTTP et FastCGI), un tampon de mémoire intermédiaire et un certain état, tandis qu'Apache aurait besoin d'un thread complet, y compris la pile et d'autres choses.

D'après mon expérience personnelle dans les benchmarks, j'ai fait Lighttpd (et je suppose que Nginx aussi) est légèrement plus rapide avec le backend FastCGI puis Apache mais c'est pour une faible quantité de connexions.

Maintenant, un autre point est lorsque vous souhaitez effectuer des équilibrages de charge à l'aide de connexions FastCGI.

Dans l'architecture traditionnelle, il y a

                               |
                              HTTP
                               |
         Balancer (Nginx/Lighttpd/Cherooke/something-else)
            /      |           |            |      \
         HTTP    HTTP         HTTP        HTTP     HTTP
         /         |           |            |         \
 Apache+PHP   Apache+PHP   Apache+PHP   Apache+PHP   Apache+PHP   
  Server 2    Server 3     Server 4      Server 5     Server 6

Parce qu'Apache gère des pools de processus exécutant chacun mod-PHP (ou d'autres modes)

Lorsque vous utilisez CppCMS qui gère seul les pools, vous pouvez faire quelque chose de différent:

                               |
                              HTTP
                               |
         Balancer (Nginx/Lighttpd/Cherooke/something-else)    
                           Server 1
            /      |           |            |      \
         FCGI    FCGI         FCGI        FCGI     FCGI
         /         |           |            |         \
    CppCMS App  CppCMS App  CppCMS App    CppCMS App  CppCMS App
     Server 2    Server 3     Server 4      Server 5     Server 6

Donc, fondamentalement, vous n'avez pas besoin d'un autre niveau d'indirection car CppCMS gère pour vous le processus, le thread et le pool de connexions. Alors que PHP / Ruby / Perl ont besoin d'Apache mod-XYZ ou gèrent leur propre connecteur FastCGI.

Nginx, parlant très ( très ) généralement, peut obtenir un débit beaucoup plus élevé qu'Apache grâce à une approche architecturale différente du problème de la diffusion de pages sur le Web. Nginx a également été construit principalement en tant que proxy inverse, et il remplit ce rôle exceptionnellement bien (c'est le bit d'équilibrage de charge auquel vous avez fait allusion); Apache, d'autre part, a été conçu pour servir des pages Web, et a ensuite acquis la capacité de proxy.

Cela dit, il y a presque certainement des domaines où Apache surpassera constamment Nginx, tandis qu'il y en a d'autres où Nginx surpassera tout aussi régulièrement Apache.

La réponse courte est que si Apache fonctionne pour vous, il n'est pas nécessaire de changer. (Et je dis cela en tant qu'ancien utilisateur d'Apache qui est devenu un disciple Nginx entièrement converti.) Uniquement lorsque le trafic vers votre serveur commence à atteindre des niveaux où Apache devient votre goulot d'étranglement (c'est de l'ordre de quelques milliers de connexions simultanées, mais varient énormément en fonction des spécifications de votre serveur et de la charge du serveur), ou si vous essayez d'exécuter Apache dans un environnement pauvre en ressources où il peut à peine s'adapter, le passage à Nginx vous offre de solides avantages.

Cela dit, si vous voulez passer à Nginx (ce que j'encourage!), Alors allez-y. En verrez-vous des avantages? 9 fois sur 10: Non, vous ne le ferez pas. Mais vous avez dit que vous aimez la langue de fichier de configuration de Nginx mieux, donc si elle vous fait vous sentir plus à l' aise pour configurer Nginx que Apache, eh bien, c'est un avantage pour vous! (Personnellement, je trouve les configurations Apache plus faciles à lire en général, mais cela pourrait être dû au fait que j'ai passé de très nombreuses années à les lire, et que quelques mois seulement ont été consacrés à Nginx!)

En passant: vous avez mentionné votre désir de créer une application web en C ++. Pour votre raison, je vous invite fortement à utiliser à la place un langage de niveau supérieur comme PHP, Python ou même Java. Ensuite, profilez votre code et envisagez de créer des modules basés sur C ++ pour résoudre des goulots d'étranglement spécifiques (Python et PHP le permettent assez facilement; je ne sais pas pour Java). Si vous êtes préoccupé par les performances globales, considérez ceci: EVE Online, le plus grand MMORPG non fragmenté au monde, est construit sur une variante de Python (Stackless Python), avec uniquement des composants clés (par exemple les bibliothèques graphiques) écrits en C ++. Si Python peut gérer cela, il peut sûrement gérer votre application Web?

Personne ne peut vraiment répondre à la question «quand dois-je changer» - cela dépendra de votre charge, des performances de votre propre code d'application, etc.

NGinx, qui semble être plus performant qu'Apache

nginx utilise un seul processus (ou un très petit nombre de processus de travail) pour gérer toutes les connexions client à l'aide d'E / S avec événements. Apache a plusieurs "modules multi-traitement" disponibles, mais ils s'appuient tous davantage sur de nombreux processus / threads. Par conséquent, Apache consommera généralement plus de RAM et de CPU que nginx pour la gestion de connexion HTTP de base. Vous pouvez obtenir un aperçu des différentes approches de gestion des connexions sur la page C10K de Kegel .

application web très performante (en utilisant C ++ avec CPPCMS)

Je suggérerais fortement d'envisager de faire la webapp de base dans un langage de plus haut niveau (Python, ou peut-être Ruby, Scala), et d'utiliser une file d'attente de messages pour envoyer des tickets de travail aux machines de travail qui gèrent les tâches "gourmandes en performances" de manière asynchrone.

NGinx serait le meilleur choix lorsque vous souhaitez équilibrer la charge,

nginx est un bon équilibreur de charge; mais il existe de nombreuses options dans cet espace .

Puis-je utiliser Apache et NGinx sur la même machine sans aucun problème?

Oui. Il suffit de les exécuter sur différents numéros de port IP et / ou adresses IP.