Est Nginx + php-fpm est supposé être beaucoup plus rapide que Apache + mod-php
J'ai une PHP application web basée sur le serveur Apache qui a une quantité considérable de traitement php en back-end. Comme les performances globales sont faibles, j'ai travaillé sur l'amélioration des performances de l'application. J'ai suivi des techniques telles que la mise en cache côté client, l'activation de gzip, la minification js-css qui ont amélioré les performances jusqu'à un bon point.
Afin d'améliorer encore les performances, je voulais essayer l'amélioration du niveau du serveur. J'ai donc essayé de comparer les performances de l'application en l'hébergeant sur des serveurs Apache et Nginx.
- Version Nginx - 1.0.15;
- Version Apache - 2.2.15;
- version php - 5.4.38;
Dans Apache, j'utilise Apache + mod-php et dans Nginx, j'ai utilisé Nginx + php-fpm pour cette comparaison. Comme la plupart des didacticiels l'ont expliqué, j'ai configuré le nombre de travailleurs Nginx égal au nombre de cœurs dans mon processeur. J'ai utilisé jmeter pour effectuer les tests de résistance et voici les graphiques que j'ai pu en générer.
Dans tous ces graphiques, l'axe des x représente chaque demande que j'ai envoyée et l'axe des y représente les millisecondes pour obtenir une réponse pour chaque demande.
Accéder à la page de connexion
Soumettez la page de connexion
Accéder à la page d'accueil
Je n'ai pu effectuer les tests que jusqu'à 100 utilisateurs simultanés connectés en 1 seconde, car il a commencé à supprimer les demandes par la suite dans les deux configurations de serveur.
Il y avait une petite amélioration des performances dans Nginx par rapport à Apache mais ce n'était pas une différence majeure où cela valait la peine de changer toute l'architecture de mon serveur d'Apache à Nginx. Et quand j'observe l'utilisation des ressources du serveur, je n'ai pas trouvé beaucoup de différence entre Nginx et Apache
Lorsque j'ai parcouru d'autres comparaisons que les gens ont faites, j'ai constaté qu'ils affirment que Nginx est beaucoup plus rapide dans les accès simultanés, comme le montre le graphique suivant.
http://www.eschrade.com/wp-content/uploads/2014/01/event-mpm-nginx.gif
Mais je n'ai pas pu observer de différence de performance majeure dans Nginx par rapport à Apache, même avec 100 accès simultanés en 1 seconde.
Voici mes questions.
- Nginx + php-fpm est-il censé effectuer les opérations sur le serveur beaucoup plus rapidement que Apache + mod-php en raison d'une utilisation efficace de la mémoire et d'autres ressources?
- Nginx est-il uniquement recommandé pour les serveurs statiques et non pour les sites d'exploitation de serveurs lourds?
- Existe-t-il un meilleur moyen de configurer Nginx pour améliorer davantage les performances?
J'ai fait un peu plus de recherche à ce sujet et j'ai découvert que Nginx fonctionnera bien avec des ressources statiques et non avec d'autres livraisons de contenu dynamique telles que le traitement php qui doit être fait à l'aide d'une application externe telle que php-fpm. Donc, si votre application Web a un goulot d'étranglement sur le traitement php, le remplacement d'Apache par Nginx ne sera pas une solution.
L'article suivant explique une recherche détaillée effectuée sur la comparaison de la livraison de contenu statique et de la livraison de résultats de script php à l'aide d'Apache + mod_php et Nginx + php-fpm.
http://blog.a2o.si/2009/06/24/Apache-mod_php-compared-to-nginx-php-fpm/
Voici les points de conclusion décrits dans l'article ci-dessus.
Conclusion ou "devriez-vous passer d'Apache à Nginx?"
- Réponse courte: je ne sais pas.
Des réponses plus longues sont ici:
- Si vous hébergez de nombreux sites Web et utilisateurs utilisent des fichiers .htaccess et les modifiez fréquemment, la réponse est probablement "non". Le coût du passage à Nginx et de la conversion de toute la configuration au nouveau format atteint généralement le coût d'achat d'un autre serveur.
- Si vous avez une seule application sur plusieurs serveurs et que la majeure partie de la puissance de traitement n'est pas consommée en servant du contenu de fichier statique, la réponse est également probablement "non".
- Si vous diffusez principalement du contenu statique, la réponse est évidemment "oui".
- Si vous créez un nouveau système de solution d'hébergement Web, la réponse est probablement "oui", en supposant que les utilisateurs ne manqueront pas la fonctionnalité .htaccess ou qu'elle sera fournie par d'autres moyens.
- Si vous consolidez des services avec une technologie de virtualisation, la réponse est probablement "oui", car Nginx a tendance à avoir une empreinte mémoire plus petite qu'Apache.
- Si vous regardez vers Nginx comme votre PHP, regardez à nouveau, mais pas vers Nginx, votre code d'application.
Bien qu'il y ait beaucoup d'affirmations selon lesquelles c'est plus rapide, ou supposé l'être, non, ce n'est pas censé être plus rapide, du moins pas inconditionnellement.
Ce qui est plus rapide, mod_php ou ext-fpm, n'a pas été prouvé et il est susceptible de varier. En ce qui concerne les performances, vous avez trois considérations: la théorie, l'implémentation, le cas d'utilisation, les ressources et la charge.
En théorie, mod_php est le plus rapidement réalisable. Avec mod_php, le serveur Web et l'interprète communiquent directement, ils partagent les mêmes ressources et le même espace mémoire. Avec ext-fpm, vous avez des processus distincts qui ne communiquent pas aussi directement et qui doivent dupliquer les ressources.
Traditionnellement, les processus séparés sont populaires car ils ont tendance à avoir une plus grande flexibilité en ce qui concerne des choses telles que l'exécution simultanée d'autant d'utilisateurs différents, de versions différentes simultanément, etc. Beaucoup de gens utilisent également plusieurs systèmes de processus car ils ne peuvent pas être dérangés par free(), fclose(), etc.
Alors que ext-fpm, en utilisant FastCGI, est une tentative pour que le modèle de processus séparé atteigne sa vitesse théorique maximale, la vitesse théorique maximale est toujours plus lente que la vitesse théorique maximale des processus unifiés.
Il peut être difficile de déterminer lequel est le plus rapide. Les tests d'autres personnes ne seront pas fiables même s'ils sont bien orchestrés car ils peuvent ne pas être pertinents pour votre cas d'utilisation et votre configuration. Dans vos propres tests, vous pouvez faire l'un plus rapidement que l'autre, mais cela ne signifie pas que quelqu'un ne peut pas venir et changer cela. Que quelqu'un puisse être vous avec plus de temps et de compréhension à votre disposition.
L'implémentation de mod_php n'est pas nécessairement celle qui l'amène à sa vitesse théorique maximale. Les deux pourraient ne pas être aussi éloignés l'un de l'autre que les gens pourraient s'y attendre, d'autant plus que la surcharge SAPI peut se révéler triviale par rapport à tout ce qui se passe lors du traitement d'une demande statique. De nombreux benchmarks doivent tester avec des scripts virtuellement noop pour que la différence apparaisse significative.
C'est devenu une croyance populaire que ext-fpm "est rapide". Il existe de nombreuses forces qui persistent, dont certaines sont innocentes, d'autres puisent dans l'incompétence et certaines sont tout à fait manipulatrices.
- Apache httpd ne veut pas recommander l'utilisation de mod_php ne fonctionne pas avec les MPM threadés pour diverses raisons. Apache httpd avec des modèles filetés ou pilotés par les événements qui peuvent avoir des demandes d'impact sur les performances qui ne servent pas PHP. Alors que PHP a fait des progrès significatifs vers la prise en charge des modèles filetés et pilotés par les événements, le cheminement événementiel est encore loin et sa prise en charge filetée n'a pas été aussi éprouvée au combat que par processus traditionnel Ce n'est pas quelque chose qui rend PHP plus rapide. C'est un compromis. Potentiellement ralentir PHP, accélérer le contenu statique. Apache a commencé à recommander contre mod_php entièrement ce qui est susceptibles de confondre beaucoup de gens ainsi que l'origine probable de l'erreur croient que ext-fpm "est plus rapide".
- Rejetés par des choses telles que la recommandation Apache, de nombreuses personnes ont essayé ext-fpm et ont ensuite utilisé leurs plateformes telles que des discours lors de conférences ou de blogs pour rapporter leurs "succès" anecdotiques qui propagent ensuite les phénomènes à un public impressionnable plus large.
- Parfois, lorsque les résultats passent mieux à ext-fpm, les raisons ne sont souvent pas celles que les gens attendent. Beaucoup de gens en passant de mod_php à ext-fpm font plus que cela ou d'autres facteurs sont en jeu.
- En technologie, le Word fast est particulièrement problématique. Souvent, cela ne veut vraiment rien dire. Les derniers systèmes que j'ai utilisés et qui ont été qualifiés de rapides (technologies très populaires) se sont avérés être le contraire. Beaucoup de gens confondent rapide et sens plus rapide. En réalité, cela ne signifie pas grand-chose. Rapide en termes de perception? Un disque dur tournant à 100 tr/min semblera tourner "rapidement" pour la plupart des gens. Un disque dur tournant à 1000 tr/min semblera tourner "rapidement" pour la plupart des gens. Le plus rapide ne signifie pas grand-chose.
- Les conflits d'intérêts. nginx a une entreprise commerciale et il reste à voir si cela pourrait être une source de marketing pour ext-fpm. Il sert à nginx pour les gens de croire qu'il est plus rapide que mod_php qui n'est disponible que pour un serveur Web concurrent. Il y a cependant un module de threads disponible pour nginx et PHP donc il ne semble pas que ce serait une source probable de lobbying pour ext-fpm. Le meilleur résultat dans Google provient cependant d'un marketing blog essayant d'amener du trafic vers des services d'hébergement commercial qui ignore la plupart des détails pertinents, de sorte que les parties le traitent clairement.
Souvent, lorsque les gens voient un résultat différent, ils ne comprennent pas pourquoi. Les détails intimes de leur processus, des mesures et du trafic sont laissés de côté. Les gens tentent alors souvent de répéter ces succès et échouent à laisser des résultats de recherche infinis de personnes se demandant pourquoi ce n'est pas plus rapide. Le plus important est que les gens réussissent en utilisant un MPM basé sur plusieurs processus avec mod_php tout en ayant une lourde charge de contenu statique. Ces cas peuvent être particulièrement trompeurs car la charge des requêtes statiques peut rebondir sur PHP.
Une autre erreur courante est que les utilisateurs testent également deux configurations différentes. La configuration de php-fpm pourrait être plus optimisée que celle de mod_php. Parfois, cela peut être aussi simple que les gens optimisent tout ce qui devrait être plus rapide tout en négligeant l'original. Cela est particulièrement pertinent lorsque des personnes peuvent faire des choses telles que ne pas vérifier si les demandes ont réussi, tout en modifiant des choses telles que la limite de mémoire ou le temps d'exécution maximal. Beaucoup de choses peuvent changer dans la configuration lorsque les gens ne sont censés changer le SAPI, parfois même inévitablement, parfois même de manière transparente. Un exemple courant pourrait être que les limites sur le serveur Web pourraient être insuffisantes pour maximiser l'utilisation des ressources du serveur où ext-fpm pourra générer des processus supplémentaires pour tirer parti de cœurs supplémentaires. Il est courant de voir des gens déplacer des éléments tels que le routage de PHP vers le serveur Web pour FPM.
Comparé à mod_php avec un MPM multithread à un seul thread, ext-fpm est un bon candidat avec de nombreux avantages, même si de meilleures performances ne sont pas strictement garanties. Cependant, si votre charge sert entièrement PHP requêtes, Apache fait déjà plus ou moins ce que ferait ext-fpm autrement.
Il existe également une différence entre des éléments tels que la latence par rapport au débit et les cycles par rapport aux octets et aux attentes.
En théorie, la voie à suivre est php-zts avec ngx_php ou mod_php. La grande mise en garde est que php-zts n'a pas obtenu la prise en charge ni l'attention et l'attention en tant que php-nts de sorte qu'il introduit des frais généraux à PHP exécution elle-même, ce qui rend très difficile la concurrence avec php -fpm à l'heure actuelle. L'implémentation ne permet pas d'atteindre son optimum. Dans certains cas, le sous-optimal peut être un euphémisme. Beaucoup de gens sont préoccupés par la fiabilité de threaded PHP qui peut ou peut ne pas vous affecter. Ce ne sera certainement pas une préoccupation si vous ne servez que du contenu dynamique et ne dirigez pas un service d'hébergement partagé. Cela semble être potentiellement une campagne de peur orchestrée par Apache. Il devrait y avoir suffisamment de personnes utilisant php- zts pour les plateformes où c'est la seule option pour qu'il soit relativement stable.
Il existe d'autres options, mais elles peuvent être plus pratiques. Il est même possible d'ouvrir un socket Unix vous-même, d'analyser le FCGI et de le gérer de manière asynchrone avec des choses telles que select. La mise en garde des événements pilotés par PHP est que la plupart des principales bibliothèques de haut niveau IO telles que MySQL ne le prennent pas en charge de manière unifiée).
php-swoole commence à sembler prometteur même si ce n'est que le début. La situation avec php-fpm, mod_php et php-zts est un gâchis.
J'ai un site Web fonctionnant avec l'équilibrage de charge de 3 serveurs. 2 d'entre eux fonctionnent sur nginx avec PHP-FPM (nouveaux). Cependant, le serveur principal est sur Apache + PHP FastCGI hittng environ 40% du trafic. J'ai récemment pensé à changer Apache également en nginx; j'ai donc installé nginx sur le même serveur pour une IP différente et en ai fait Mais étonnamment, Apache pourrait générer la page en 10 à 20 millisecondes à chaque fois, mais nginx prend 60 à 70 millisecondes. nginx est plus rapide pour les fichiers statiques, mais si vous avez un CDN, vous n'avez pas à vous soucier du contenu statique. Apache est un excellent serveur. Mais essayez FastCGI et non le module PHP.