Vs Nginx FastCGI_Cache PHP Mise en cache
J'ai expérimenté les performances de la mise en cache à l'aide de loader.io et j'ai obtenu des résultats surprenants.
J'étais à l'origine sur un hôte partagé qui utilisait une pile LAMP. Même avec la mise en cache activée, il tomberait après 200 visiteurs en 1 minute.
J'ai installé un droplet Ubuntu de 1 Go LEMP de base (Nginx 1.9.12 + PHP-FPM7.0) sur Digital Ocean et copié mon site sur plusieurs sites (multisite sous-dominian).
Pour obtenir une ligne de base, j'ai configuré le plug-in wp-super-cache automattic à l'aide de l'option de mise en cache PHP pour plus de simplicité, puis exécuté un test. Cela a fonctionné extrêmement bien, j'ai donc tiré le maximum de mon forfait gratuit (10 000 en 1 min) et voici les résultats.
C'est incroyablement bon comparé à mon hôte partagé qui ne passerait jamais en dessous de 300 ms sur une seule demande et subirait des délais d'attente sous n'importe quel type de charge.
Tout ce que j'ai lu indique qu'en utilisant PHP la mise en cache dans wp-super-cache, les performances de la mise en cache seront moins bonnes que celles de la mise en cache du serveur Web, car les pages statiques générées via PHP génèrent une surcharge.
Heureux de voir à quelle vitesse je pouvais obtenir mes réponses, j'ai configuré fastcgi_cache pour mettre en cache les fichiers PHP, puis j'ai désactivé le plug-in wp-super-cache.
J'ai refait le test de charge et voici les résultats:
Les résultats sont à peu près les mêmes. La première demande prend un peu plus de temps, mais c’est la réponse en cache qui m’intéresse, car elle pourrait probablement être optimisée avec quelques ajustements.
D'après ce résultat, je ne vois aucun avantage à utiliser fastcgi_cache par rapport à wp-super-cache qui gère la mise en cache à l'aide de PHP. L'utilisation de la mise en cache PHP est certainement beaucoup plus simple lorsqu'il s'agit de sous-domaines générés par l'utilisateur et de domaines mappés.
Je suis seulement sur le plan libre, je ne peux donc pas pousser le test de charge plus haut, mais mes besoins ne dépassent pas 10k en une minute.
Cela m'a laissé perplexe, car chaque article que j'ai lu dit que l'utilisation d'une règle de mise en cache dans le serveur Web présente des avantages considérables en termes de performances, au lieu de servir un fichier statique avec PHP, mais avec cette installation qui ne fonctionne pas. t semble être le cas.
Fastcgi_cache est servi directement à partir de ram. Wp-super-cache utilise php pour lire un fichier statique à partir du SSD, alors je vois pourquoi il devrait être plus rapide, alors pourquoi pas?
Bien entendu, ce n'est pas un problème réel, je ne comprends pas pourquoi mes résultats sont comme ils sont et semblent contredire tous les guides que j'ai lus.
Quelqu'un peut-il nous expliquer pourquoi j'obtiens ces résultats?
Nginx est vraiment bon en concurrence (PHP pas tellement) donc vous devriez essayer un peu plus de 180 demandes par seconde. Peut-être 500 ou 1 000 selon les ressources de votre serveur et le débit du réseau.
Fastcgi_cache est servi directement à partir de ram. Wp-super-cache utilise php pour lire un fichier statique à partir du SSD, alors je vois pourquoi il devrait être plus rapide, alors pourquoi pas?
Ça dépend. Tout d'abord, si fastcgi_cache est servi de mémoire ou non dépend de votre fastcgi_cache_path. S'il est défini sur un montage tmpfs, alors oui, il sera en mémoire. S'il est défini sur un répertoire standard non-tmpfs, il sera servi à partir du disque.
Mais disque ne signifie pas toujours le disque réel :)
Lorsque vous accédez à un fichier depuis un disque, Linux le met en cache dans la mémoire. Ainsi, lors de votre prochain accès au même fichier, il sera servi à partir de la mémoire. C'est pourquoi la plupart des tests avec loader.io, Apache-bench et d'autres outils qui "martèlent" la même page sont erronés. Ils font tous en sorte que votre pile accède aux mêmes fichiers disponibles en mémoire et les serve. C'est pourquoi votre option WP-Super-Cache PHP ne provoque probablement pas beaucoup plus de disques IO que Nginx et semble donc tout aussi rapide avec une faible simultanéité.