Salut Internaute!
J’espère que tu aimes la technique, parce que là, on fonce droit dessus! ;-)
J’utilise personnellement la configuration qui suit sur mes hébergements WordPress : Nginx + php-fpm avec l’extension WordPress W3 Total Cache. Ca tourne très bien, pas de problème majeur, si ce n’est la difficulté à trouver des versions correspondantes dans les dépots officiels Debian.
Google a publié son module pour Apache: mod_pagespeed qui se charge de compresser le contenu, les images et les JS pour vous. Magique, et gratuit! Mais ça implique d’utiliser Apache comme serveur Web, ce qui n’est pas mon cas comme expliqué plus haut ;-). Alors, que choisir? J’avais choisi Nginx pour pouvoir l’utiliser en reverse proxy avec W3 Total Cache qui me générait des pages HTML statique dans un dossier particulier et que je pouvais donc resservir sans même à soliciter PHP, ni MySQL : Royal.
Mais, depuis je me suis amusé avec Varnish, qui finalement propose de faire totalement le boulot de reverse proxy sans forcément avoir W3 Total Cache d’installé. Qui est le plus fort?
Bigre, mais Pierre? Que faire? Faisons un bench!!!
Nginx + php-fpm + W3 Total Cache
La configuration testée est donc la suivante:
- Nginx 0.6.32 (dépot officiel Debian Lenny)
- WordPress 3.0.1 installé avec seulement W3 Total Cache comme extension d’installée et activée
- le thème par défaut de WordPress 3 avec 10 posts en home, contenant tous une série d’images.
- php-fpm 5.3.3 (dépot dotdeb)
- Le tout est installé sur une Dedibox V3 avec Debian Lenny.
Tous les tests sont lancés depuis une machine virtuelle hébergée chez Gandi avec 5 Mbits de Bande passante burstable à 10 Mbits avec l’outil Apache Bench (dispo dans le paquet apache2-utils des dépots officiels Debian) avec la commande suivante: ab -n 10000 -c 100 http://test.delacelle.com/ . Soit 10 000 requètes sur la home avec 100 requètes concurentes.
Voici donc les résultats d’Apache Bench pour notre ami Nginx: (j’utilise des images pour conserver la mise en forme de Apache Bench même si c’est pas très optimal ;) )
Le serveur testé est monté jusqu’à 0,53 de charge lors de ce bench…
Et maintenant, testons avec le même site Internet, la même page, la même machine, servit par :
Varnish + Apache + mod_pagespeed + W3 Total Cache
Le serveur testé est monté à 0,04 de charge pendant ce test, par contre, au bout de 4 ou 5 salves de 10 000 requêtes, la charge processeur fait brutallement un pic (à 3,5 de charge environ) , mais redescend tout aussi sec. Je pense qu’il s’agit d’un flush du fichier binaire de Varnish (qui lui sert à stocker les infos cachées), mais je n’en suis pas certain, vu que je découvre encore.
Que peux-t-on en conclure?
Et bien, en s’attachant aux chiffres simplement, je trouve que les résultats sont très similaires. Donc en terme de performances pures côté client, l’un et l’autre sont de bonnes solutions.
Il faut noter que je connais plutôt bien Nginx, et qui est donc aux petits oignons sur cette configuration, alors que Varnish a très légèrement été configuré (passage du fichier de cache à 512Mo et configuration en VCL pour WordPress via la Documentation Varnish ).
La configuration avec Nginx a le gros inconvénient de reposer sur php-fpm, qui bien qu’intégré dans le trunk de PHP depuis 5.3.3, n’est pas présent sur les dépots officiels Debian et je rencontre régulièrement quelques problèmes avec des extensions comme APC. Le deuxième inconvénient du fonctionnement avec Nginx, est la ré-écriture complète des rêgles htaccess pour Nginx suivant l’outil que vous utilisez derrière, ce qui n’est pas forcément simple.
Enfin, Nginx est un serveur HTTP qui peut être utilisé comme reverse-proxy,
Donc personnellement, je pencherais plus sur le couple Varnish + Apache pour plusieurs raisons:
- Utilisation de paquets officiels Debian (au lieu de versions compilées, ou piochées ici et là)
- On conserve le règles htaccess du CMS utilisé (ici WordPress)
- Possibilité d’utiliser de l’ESI (Edge Side Inlude) (si des portions de pages doivent rester statiques)
- Pas de dépendances avec un plugin WordPress
Et toi, Internaute, un avis éclairé sur le sujet? un interprétation de ces données?
Allez, salut!
salut
merci d’avoir fait ces tests là, par contre une question me turlupine : as tu activé tous les filtres de mod_pagespeed ? http://code.google.com/intl/fr/speed/page-speed/docs/filters.html
l’intérêt principal de ce plugin n’est pas d’accélérer la construction du HTML (au contraire, logiquement il la ralentit), mais d’accélérer le rendu côté navigateur. Tout l’enjeu pour les perfs web est de savoir si on va tuer les processeurs serveurs avec ce plugin toutes options activées ou pas. Si le proc et le nombre de QPS reste stable ou n’augment que légèrement alors ça vaut vraiment le coup
[...] This post was mentioned on Twitter by Clément, Clément, Yves Désigaud, William DURAND, Timothée Barray and others. Timothée Barray said: Ah très sympa! RT @pie Comparatif Nginx + php-fpm VS Varnish + apache + mo http://bit.ly/90BMcN #apache #nginx [...]
Juste une petite remarque qui a une grosse influence sur les benchs.
Le transfère des données brouille souvent ce que tu cherche à tester (même avec une bande passante suffisante).
Je te conseille d’utiliser ab avec l’option -i qui utilise le mode HEAD pour les requêtes.
Je suis également curieux de voir l’optimisation faite par pagespeed surtout que les résultats de tes benchs montrent un volume de donnée plus important pour pagespeed …
@jpvincent : oui, j’ai activé tous les filtres pour que la réponse HTML stockée dans Varnish soit la plus compacte possible.
Pourtant, seules les images étaient effectivement traitées… Les commentaires restaient dans le code HTML, et les CSS n’étaient pas minifiés malgré l’activation des filtres correspondants! J’ai repéré plusieurs personnes ayant eu le même soucis.
Après, vu qu’Apache Bench ne s’occupe pas du rendu (il récupère que la réponse HTML), le gain de vitesse au rendu navigateur grâce à mod_pagespeed n’est pas mesuré ici. Je regarderais ça avec mon Yslow magique! ;-)
@romain : j’ai été surpris aussi de voir la taille de la page être plus important avec pagespeed! Mais comme dit à ma réponse à jpvincent, pagespeed ne m’a pas fait rêver hier soir, et j’ai du louper qqch dans sa config. Là, le but du test était plus porté sur Nginx VS Varnish, mais la perf apportée par pagespeed , je vais creuser ça! ;-)
Je suis d’accord sur le transfert des données, il serait intéressant de tester aussi depuis la machine en local, chose que j’ai bien zappé! ;-)
Je note pour le -i , je connaissais, mais j’ai pas le réflexe de l’utiliser.
le mod modifie le HTML pour par exemple mettre des urls générées sur les fichiers statiques, donc ça rallonge les urls, du coup il est normal de voir une taille différente
par contre comme tu dis, les commentaires ou les retours chariots étaient censés être supprimés, pour faire un HTML plus léger
concernant le fait que pas tous les filtres ne s’activent … peut être qu’il fait du sniffing de user-agent et qu’il ne sert pas la même chose à tout le monde ? ou alors c’est bugué :)
si tu refais un test avec un pagespeed + fonctionnel, ça serait top ;)
Tu peux aussi tester « Apache2 + W3 Total Cache + Varnish », ça marche vraiment très très bien. Le plugin optimise les sorties (Minifie, paramètre la compression et le cache) et Varnish sert efficacement tout ce qui peut être mis en cache.
Pour PHP-FPM, il y a le dépôt dotdeb.org, ce n’est pas officiel, mais c’est sérieux. Je ne connaissais pas le module mod_pagespeed de Google, merci pour l’info.
Nginx est bien plus performant qu’Apache sur les fichiers statiques pour des tas de bonnes raisons, par exemple il ne fait pas douze mille stat() pour chercher un .htaccess, le module rewrite de nginx est plus performant etc…
Toutefois servir WordPress, meme en fastcgi, n’a rien de comparable a des pages statiques, c’est normal que les performances soient similaires entre nginx et Apache : probablement >90% du temps est passé dans php a générer la page.
Le gros avantage de nginx sur Apache est qu’il peut gérer des milliers de connexions simultanées alors qu’Apache va utiliser des Giga de RAM pour faire la meme chose. (c’est pas nouveau, Apache n’est pas scalable)
Le load de 0.5 avec nginx semble bien haut, on devrait avoir au minimum le meme load avec Apache, a moins qu’Apache ait deja tout pre-forké, ce qui conduit a :
Il manque la configuration fastcgi utiliséé pour chaque config:
- Quel est le manager fastcgi utilisé par Apache et nginx ?
- Combien de process spawnés initialement ?
- Combien de process max autorisés ?
- Combien de process ‘de reserve’ min et max ?
- Quel module apache utilise (mod_fcgid est soi disant moins performant que mod_fascti)
- Nombre de requetes max par process ?
Et dynamiquement : combien de process php mini et maxi vois-tu pendant l’execution de apache Bench ?
C’est tres difficile de faire un benchmark qui teste dans les memes conditions, sans favoriser l’un ou l’autre.
Idéalement il faudrait éviter les effets de ‘cache’ systeme en rebootant entre les tests (ou au pire en redémarant proprement le serveur et les demons associés apres avoir flushé les ‘buffers’ de Linux (si c’est possible))
[...] Je voulais au départ tenter l’aventure avec NginX mais les quelques revues effectuées sur le net ne m’ont pas poussé à fondamentalement abandonner Apache que je maîtrise bien. Peut être [...]
Ton serveur est un bousin, pourtant le mien est loin d’être une foudre de guerre. Donc voilà avec Nginx sur le port 8080, apache sur le 80, wordpress, apc, w3tc qui va chercher tout les fichiers statiques sur le sous domaineen :8080, et qui sont donc servies par nginx :
http://ctrlv.in/188781
J’ai été surpris moi même par les résultat, car j’ai choisi cette solution pour pas me prendre la tête avec nginx et plesk 10.