Cette question n'est pas nginx vs apache. Je suis plus intéressé par les avantages architecturaux de NGinx sur Apache. Comme je pouvais le comprendre -serveurs web nginx et apache
Pourquoi est-ce? Où Apache est-il en retard?
Il n'y a pas une seule raison pour laquelle nginx "surpasse" strictement Apache. Pour de nombreux modèles de charge, vous pouvez configurer Apache pour qu'il gère cette charge. Pour certains modèles de charge (très chargés), nginx dans la configuration par défaut peut présenter des dégradations de performances et nécessiter un réglage précis pour fonctionner correctement.
Cependant, il a été l'expérience de beaucoup, que nginx fonctionne réellement "mieux" hors de la boîte, ou avec un réglage simple. La performance de nombreux systèmes s'est nettement améliorée lorsque nginx a été installé en tant que frontal, avec Apache déplacé vers l'arrière.
La principale raison est que nginx est piloté par les événements et contient la machine d'état qui gère le cycle de vie des connexions. De cette façon, vous pouvez avoir très peu de processus «travailleurs», chacun traitant plusieurs centaines ou même des milliers de connexions simultanément. Pour Apache, vous devrez exécuter le même nombre de processus fils (ou threads) que le nombre de connexions.
Il est évident que trois processus contre un millier de processus devraient être une grande victoire, à tout le moins.
En particulier, nginx permet facilement de réduire considérablement la charge de servir des fichiers statiques (images, Javascript, CSS). La gestion de chaque connexion supplémentaire dans nginx est très bon marché, de sorte que les fichiers statiques sont généralement la majorité en termes de nombre de demandes, vous obtenez un traitement efficace.
De plus, les performances de nginx sont meilleures pour les "clients lents". Quand Apache regarde directement vers Internet, et que les clients envoient des requêtes sur des lignes (congestionnées), votre serveur (rapide) devra patiemment alimenter le client (lent), attendant qu'il consomme toute la réponse. Ainsi, l'enfant Apache (ou thread) ne peut rien faire d'utile. D'autre part, Nginx worker conserve simplement cette connexion lente dans un ensemble de descripteurs, tout en traitant d'autres connexions. Du point de vue conceptuel, vous devriez toujours essayer de séparer les «classes» de demandes, avec leur propre profil de performance et leurs exigences. Par exemple, servir de petits fichiers statiques est l'une de ces classes; servir des pages dynamiques est une autre classe de ce genre; servir d'énormes fichiers statiques est encore un autre. L'introduction de nginx dans votre système gère implicitement cette séparation.
Quote: * Pour Apache vous devrez exécuter le même nombre de processus fils (ou threads) que le nombre de connexions. * Je crois que cela ne s'applique pas si vous utilisez 'mpm_event'? –
Non, cela s'applique aussi à 'mpm_event' (à la lecture de http://httpd.apache.org/docs/2.4/mod/event.html,' mpm_event' est juste 'worker' avec une torsion). Apache n'a pas de module FSM approprié. – squadette
@squadette D'après ma petite lecture du code 'mpm_event', je ne suis pas d'accord: avec' mpm_event', les travailleurs sont uniquement utilisés pour effectuer des E/S lorsque le socket est prêt et pour exécuter les manipulateurs et les filtres, par ex. de la même manière que les ouvriers sont utilisés dans libevent (libevhtp), Cherokee, etc. Sous 'mpm_event' vous pouvez avoir des milliers de connexions avec seulement quelques travailleurs. – ArtemGr
Vous êtes sûr que Nginx est purement asynchrone? –