Optimiser les performances de PHP 7 avec NGINX, partie 1 : Service Web et mise en cache

Introduction – Comment NGINX est utilisé avec PHP

PHP est le moyen le plus populaire pour créer une application Web côté serveur, avec environ 80 % de parts de marché . (ASP.net est loin derrière, et Java est encore plus loin derrière.)

L'univers PHP comprend une multitude de frameworks PHP ; les plus populaires incluent Laravel, Phalcon et Symfony 2. PHP est également la base des systèmes de gestion de contenu (CMS) populaires tels que WordPress et Drupal . (La version la plus récente de Drupal, Drupal 8, inclut une intégration significative de Symfony 2 .

L’équipe PHP publie désormais une nouvelle version, PHP 7 , plus d’une décennie après l’introduction de PHP 5. Pendant cette période, l’utilisation du Web et les exigences envers les sites Web ont augmenté de manière exponentielle. PHP a contribué à cette croissance rapide – mais les limites de PHP sont également mises en évidence par la croissance même qu’il a permise.

PHP est généralement considéré comme puissant et flexible, mais sujet à des problèmes de performances. Les sites basés sur PHP peuvent facilement « atteindre un mur » après seulement quelques doublements du trafic. Au moment même où un site commence à atteindre ses objectifs commerciaux ou opérationnels, il commence à planter dès que le volume de trafic augmente.

Pour des milliers et des milliers d’applications basées sur PHP, quelques modifications relativement simples ont suffi à améliorer les performances. Il s'agit notamment de la mise en cache avec des outils tels que memcached , du réglage des bases de données, du proxy inverse et de l'équilibrage de charge avec NGINX Open Source et NGINX Plus . NGINX a considérablement amélioré la réactivité des applications, prenant en charge des augmentations d’ordre de grandeur du nombre d’utilisateurs et du trafic.

Cet article de blog est le premier d’une série en deux parties sur l’optimisation des performances de vos sites Web qui utilisent PHP 7. Ici, nous nous concentrons sur la mise à niveau vers PHP 7, l'implémentation de NGINX Open Source ou NGINX Plus comme logiciel de serveur Web, la réécriture des URL (nécessaire pour que les requêtes soient traitées correctement), la mise en cache des fichiers statiques et la mise en cache des fichiers dynamiques (également appelée mise en cache d'application ou microcaching).

Dans le prochain article de blog, nous nous concentrerons sur les étapes que vous pouvez suivre avec des serveurs supplémentaires : ajout d'un serveur proxy inverse, passage à plusieurs serveurs d'applications, équilibrage de charge entre plusieurs serveurs, prise en charge de la persistance de session pendant l'équilibrage de charge et fin des protocoles de sécurité, tels que SSL/TLS et le protocole HTTP/2 associé.

Pourquoi PHP rencontre un mur

Pourquoi les applications PHP rencontrent-elles un obstacle ? Pour la même raison, tout logiciel de serveur d’application rencontre des difficultés. Lorsqu'une demande d'utilisateur arrive, PHP – et le logiciel de serveur Web sur lequel il s'exécute – doivent effectuer plusieurs choses :

• Déchiffrer la demande . Tout d’abord, le logiciel du serveur Web, puis PHP, doivent lancer des processus pour recevoir, déchiffrer et agir sur la demande. Le serveur HTTP Apache, par exemple, attribue des ressources pour gérer chaque demande de données, aussi simple (récupération d'un fichier JPEG) ou complexe (traitement de demandes CSS imbriquées). Tout cela prend du temps, des ressources système et une allocation de mémoire – qui peut être assez importante si le système d’exploitation, PHP ou les deux doivent charger un certain nombre de bibliothèques avant même de commencer à traiter la demande.
• Gérer les protocoles de support . Si vous exécutez SSL/TLS et/ou HTTP/2, votre logiciel de serveur Web doit décoder les requêtes, un processus potentiellement long.
• Agir sur la demande . PHP doit rassembler les ressources pour gérer la requête. Cela peut nécessiter plusieurs appels de base de données, des appels via Internet vers des services externes et un traitement interne complexe.
• Répondre à la demande . PHP doit renvoyer les résultats au logiciel du serveur Web pour qu'ils soient transmis au demandeur sous forme de réponse HTTP. N'oubliez pas que le logiciel du serveur Web et PHP exécutent tous deux un thread actif et dédié pour chaque requête, de la réception initiale à l'accusé de réception final.

C'est beaucoup de choses à gérer pour un serveur physique, une machine virtuelle ou une instance de serveur cloud pour chaque demande. Les performances ont tendance à baisser lorsque la mémoire physique de la machine serveur, qu’elle soit physique ou virtuelle, est épuisée. Le serveur commence alors à paginer les sessions en cours sur le disque à mesure que de nouvelles demandes arrivent. L’attente de la satisfaction des demandes de fichiers introduit également des états d’attente qui contribuent également à la pagination. Au-delà d’un certain point (très limité), les opérations de pagination et les demandes de données submergent les opérations de traitement, et les performances entrent dans une spirale mortelle qui provoque de longues attentes ou la fin pure et simple de la session pour les utilisateurs frustrés.

Résoudre les problèmes de performances

Surmonter les barrières de performance de PHP est certainement possible, et cela nécessite plusieurs étapes complémentaires. Chaque étape peut être combinée avec d’autres. En gros, ils comprennent :

• Jeter du matériel sur le problème . Plus de mémoire, plus de mémoire, des disques plus rapides, des serveurs de base de données séparés, un réseau de diffusion de contenu, une capacité de débit accrue et d'autres solutions mécaniques sont une solution rapide et simple aux problèmes de performances. Ces solutions peuvent préserver la disponibilité ou faire évoluer les performances de manière linéaire.
• Améliorer le code PHP et l'application . De nouvelles versions de PHP, de nouveaux frameworks et un code d’application amélioré peuvent être d’une grande aide. Là encore, il est possible de doubler, voire de quadrupler, les performances, sans dépenses supplémentaires pour du nouveau matériel.
• Logiciel serveur amélioré . La plupart des serveurs Web et PHP attribuent des ressources dédiées à chaque requête ouverte en cours. Le logiciel serveur NGINX gère les demandes au fur et à mesure qu'elles arrivent, sans monopoliser les ressources, minimisant ainsi l'empreinte du serveur.
• Implémentation multiserveur . Vous pouvez implémenter un serveur proxy inverse pour gérer les requêtes Internet et les partager (équilibrage de charge) entre un ou plusieurs serveurs d'applications. Le serveur proxy inverse peut également gérer la mise en cache des fichiers, la terminaison de protocoles tels que SSL/TLS et HTTP/2, ainsi que la gestion de plusieurs serveurs d'applications. Même avec un seul serveur d'application, cela décharge une grande partie de sa charge de travail. L'équilibrage de charge garantit qu'aucun serveur ne soit surchargé avec plus que sa part de charge à mesure que davantage de serveurs sont ajoutés.

Vous n’êtes pas obligé d’implémenter ces étapes dans un ordre particulier ; par exemple, même si vous conservez Apache comme serveur Web et ne mettez pas à niveau votre serveur d’applications vers PHP 7, le simple fait d’implémenter NGINX comme proxy inverse « devant » vos serveurs existants améliore les performances et vous permet d’implémenter plusieurs serveurs d’applications en parallèle.

Quelle que soit la manière dont vous procédez, le fait essentiel à garder à l’esprit est que vous pouvez obtenir plusieurs facteurs de performances accrus, voire un ordre de grandeur en termes de capacité, avec peu ou pas de modification de votre code d’application actuel. Lisez la suite pour voir comment les gens ont déjà atteint, ou sont en train d’atteindre, ces gains de performance extraordinaires.

Note : Il existe une optimisation multiserveur que nous ignorerons quelque peu dans ces articles de blog. Un serveur de base de données distinct et un réseau de diffusion de contenu (CDN) peuvent décharger votre serveur d'applications et améliorer considérablement les performances ; ces types de modifications sont distincts et parallèles aux améliorations d'application et d'implémentation décrites ici.

Astuce 1 – Mettez à niveau vers PHP 7

La principale raison pour laquelle il faut mettre à niveau vers PHP 7, le plus tôt possible, est simple : la vitesse des applications (permise en grande partie par les économies de mémoire). PHP 7 est censé être deux fois plus rapide que les versions précédentes de PHP et utiliser considérablement moins de mémoire. (Votre kilométrage variera sans doute, dans les deux cas.)

Le temps de réponse est tout simplement critique pour les applications Web. Une application Web plus rapide – qui utilise également moins de mémoire, réduisant ainsi le risque d’échange de pages et les problèmes de performances qui en résultent – accomplit trois choses :

1. Rend les utilisateurs plus heureux et plus susceptibles de visiter et d'effectuer des tâches sur votre site, telles que lire des articles, obtenir des informations sur les produits, appeler un taxi, louer une chambre d'amis ou acheter des choses. C’est-à-dire les raisons pour lesquelles vous avez créé le site ou l’application en premier lieu.
2. Permet à un serveur donné de prendre en charge davantage d'utilisateurs sans courir le risque de le voir ralentir ou même tomber en panne à cause d'utilisateurs supplémentaires. Retarder l’échéance est toujours une bonne chose.
3. Rend votre serveur moins vulnérable aux attaques de pirates qui surchargent votre serveur pour le mettre hors production. Tout le monde est attaqué aujourd’hui, mais les faibles sont attaqués davantage et plus agressivement. Ainsi, une moindre vulnérabilité peut être exponentiellement meilleure qu’une plus grande vulnérabilité.

Ce sont toutes d’excellentes raisons de mettre à niveau ; prises ensemble, les arguments en faveur d’une mise à niveau semblent presque écrasants. Et « passer à la dernière version » est toujours la première recommandation pour résoudre de nombreux problèmes, même lorsqu’il n’y a pas d’avantage évident en termes de performances. Alors pourquoi tout le monde ne fait pas la mise à niveau immédiatement ?

C'est simple : les gens détestent toucher au vieux code, et pour une bonne raison. Si une ancienne application fonctionne suffisamment bien et que les développeurs obtiennent de meilleurs résultats en créant de nouvelles applications qu'en mettant à niveau les anciennes, l'ancienne application peut rester inchangée pendant très longtemps. (Consultez le deuxième article de blog de cette série pour obtenir des informations sur la manière d’utiliser NGINX pour améliorer les performances de votre application sans aucune modification de votre serveur Web et de votre application actuels.)

Mais la chose la plus efficace à faire, si possible, est de commencer votre quête de meilleures performances en passant à PHP 7. Ne commencez cependant pas avant d’avoir suffisamment de temps pour terminer, surtout sans lésiner sur les tests.

Voyons ce qu’il faut pour passer à PHP 7 :

• Modifications apportées à l’évaluation des expressions . Vous devrez peut-être modifier la façon dont certaines expressions sont écrites pour qu'elles soient évaluées correctement en PHP 7. (Ou, si vous êtes vraiment prudent et ne mettez pas à niveau tous vos serveurs PHP en même temps, pour les faire évaluer correctement à la fois dans PHP 5.6 et PHP 7.) Si vous avez des variables variables ou des propriétés variables, vous devrez réviser le code pour les faire évaluer de la même manière dans les deux versions PHP.
• Modifications de syntaxe . PHP 7 ne prend pas en charge les balises ASP ou de script. Vous ne pouvez pas avoir plusieurs cas par défaut pour un commutateur. (Nous laissons de côté la controverse sur switch versus if-then-else .)
• Suppression des fonctionnalités obsolètes . Toutes sortes de choses qui étaient obsolètes dans diverses versions 5.x de PHP sont désormais plus mortes qu'un perroquet mort . Ils ne fonctionnent tout simplement pas en PHP 7. S'ils sont présents dans votre code et que vous essayez de les supprimer tous et que vous échouez, la fonctionnalité de votre code de panier d'achat disparaîtra certainement à 23h59 la nuit précédant le Cyber Monday.
• Nouvelles fonctionnalités . PHP 7 ajoute un certain nombre de nouvelles fonctionnalités pour inciter quiconque à mettre à niveau un ancien code, mais soyez prudent lorsque vous ajoutez de nouvelles fonctionnalités lors d'un nettoyage de code. Les nouvelles fonctionnalités sont souvent merveilleuses, sinon elles n'auraient pas été ajoutées, mais elles sont également des aimants à bugs (les vôtres et ceux des autres) et à révisions futures à mesure que PHP est mis à niveau.
• Révision générale du code . Chaque fois que vous touchez à du code (ou même à chaque fois que vous ouvrez un fichier de code et que vous n’êtes pas sûr de l’avoir modifié ou non), vous devez vraiment tout revoir, en particulier tout ce que vous avez modifié.
• Essai . Tout doit être testé en permanence. Si vous apportez des modifications, vous devez tout tester à nouveau, et cela ne signifie pas pour autant que vous détecterez tous les bugs. Un environnement DevOps bien implémenté peut rendre ces tests relativement faciles, mais seuls quelques-uns d’entre nous vivent aujourd’hui dans cette terre promise.

Ce blog sur Engine Yard présente de bons exemples de la plupart de ces problèmes.

Si vous décidez de passer à PHP 7, pensez à effectuer une analyse complète des performances et une révision de votre code, ou au moins de ses fonctionnalités critiques, en tirant parti des nouvelles fonctionnalités de PHP 7. Il n’y a pas de meilleur moyen pour vous et votre équipe de vous perfectionner, et les changements que vous apportez, examinez et testez aujourd’hui vous serviront probablement pendant de nombreuses années à venir. Vous tirerez également le meilleur parti des autres suggestions de performances de cet article de blog, car le code optimisé bénéficie grandement de l’exécution dans un environnement optimisé.

Ainsi, même si les sites déploient souvent NGINX pour obtenir de meilleures performances sans toucher au code de l'application, nous vous recommandons de prendre le mors aux dents et de foncer. Il existe de nombreuses aides pour vous aider à déménager, ou vous pouvez simplement retrousser vos manches et le faire vous-même . Il existe un guide de migration vers PHP 7 sur le site officiel de PHP et un livre pratique de mise à niveau vers PHP 7 d'O'Reilly.

Astuce 2 – Choisissez NGINX Open Source ou NGINX Plus

NGINX est le logiciel qui gère plus de 140 millions de sites Web, dont la moitié des 10 000 sites Web les plus fréquentés . (Ces mesures détectent le serveur Web sur les sites à serveur unique et le serveur proxy inverse sur les sites à plusieurs serveurs.) En tant que serveur Web, les deux offrent une amélioration immédiate des performances – dans certains cas, lorsqu'un serveur exécutant un autre logiciel a été surchargé et soumis à des contraintes, jusqu'à 10 fois. En tant que serveur proxy inverse, les deux permettent l'utilisation de plusieurs serveurs dédiés pour étendre un déploiement aussi largement que nécessaire.

PHP et Apache attribuent tous deux des ressources à chaque requête ouverte ; si l’un ou les deux doivent charger un certain nombre de bibliothèques, le temps de démarrage par requête et l’empreinte mémoire peuvent être considérables. Le passage à NGINX comme logiciel de serveur Web supprime ce problème au niveau du serveur. L'utilisation de la fonctionnalité de NGINX pour décharger le travail sur le serveur Web (comme la diffusion de fichiers statiques) ou sur un serveur proxy inverse (tout type de mise en cache, de terminaison de protocole, d'équilibrage de charge, etc.) minimise ce que PHP doit faire, simplifiant et accélérant le traitement des applications.

Si vous disposez de modules Apache personnalisés ou propriétaires pour votre site, vous ne pourrez peut-être pas remplacer Apache par NGINX tant que vous n'aurez pas remplacé les modules. Vérifiez auprès de NGINX pour voir s’il existe des solutions de contournement simples ; si ce n’est pas le cas, évaluez le temps et les efforts nécessaires pour effectuer le changement.

Une fois que vous décidez d'utiliser NGINX, vous avez le choix entre NGINX Open Source et NGINX Plus. Certaines des fonctionnalités les plus importantes de NGINX Plus par rapport à NGINX Open Source sont :

• Code précompilé . NGINX Plus est distribué sous forme compilée, comprenant des bibliothèques populaires et des modules dynamiques que vous pouvez ajouter et supprimer à la volée. (NGINX Open Source est disponible sous forme de code compilé et non compilé .) Vous pouvez effectuer une large gamme de modifications de configuration sans redémarrer le serveur .
• Soutien . NGINX Plus inclut un package de support , vous donnant un accès direct aux ingénieurs NGINX.
• Suivi et gestion . Les outils compatibles DevOps vous aident à maintenir votre serveur opérationnel afin de respecter les accords de niveau de service (SLA).

En tant que serveur proxy inverse, NGINX Plus présente des avantages supplémentaires :

• Équilibrage de charge . Les deux versions de NGINX prennent en charge l'équilibrage de charge HTTP de base, mais NGINX Plus ajoute des algorithmes plus sophistiqués et un équilibrage de charge TCP .
• Persistance de session . Outre l'équilibrage de charge, NGINX Plus offre une persistance de session plus sophistiquée, souvent très pertinente pour les serveurs d'applications PHP.
• Suivi et gestion . L'ensemble des fonctionnalités de surveillance et de gestion de NGINX Plus entre en jeu dans un déploiement multiserveur ; la valeur du code précompilé et du support est également maximisée dans les implémentations plus complexes.

NGINX Open Source et NGINX Plus prennent en charge la mise en cache de contenu et la microcaching (également appelée mise en cache d'application ). La mise en cache est utile dans le contexte du serveur Web, car elle décharge le serveur d'applications, mais les deux fonctions partagent toujours une seule machine ou instance de machine virtuelle. Sur un serveur proxy inverse, la mise en cache peut décharger une quantité importante de travail du périphérique serveur d'applications, offrant ainsi de meilleurs avantages en termes de performances.

Vous pouvez télécharger le logiciel Open Source NGINX directement depuis nginx.org , où vous trouverez également le support de la communauté . Pour démarrer un seul abonnement NGINX Plus, inscrivez-vous pour un essai gratuit de 30 jours ou achetez en ligne . Pour les bundles multi-instances, contactez le service commercial NGINX .

Astuce 3 – Convertir la configuration Apache en syntaxe NGINX

Lorsque vous passez d’Apache à NGINX comme logiciel de serveur Web, vous devez effectuer quelques modifications, détaillées dans un excellent article sur sitepoint.com :

• Créer ou convertir des fichiers de configuration . Modifiez le code de configuration pour spécifier quels fichiers NGINX (et non plus Apache) doit utiliser pour la configuration.
• Modifier les autorisations de lecture/écriture . Ajoutez l'autorisation à votre compte pour effectuer des opérations CRUD (Créer, Lire, Mettre à jour, Supprimer) sur les fichiers du répertoire racine du site Web.
• Spécifiez des modèles de recherche valides . Ajoutez un bloc d’emplacement pour spécifier les modèles que NGINX peut et ne peut pas essayer lors du traitement des requêtes.
• Remplacez le code de configuration .htaccess . Les détails de configuration d'Apache ont tendance à résider dans des fichiers .htaccess ou dans des fichiers de configuration statiques (directives mod_rewrite , par exemple). Remplacez-les par les spécifications de configuration pertinentes dans les fichiers de configuration NGINX. Pour quelques exemples, consultez notre blog .

Ces modifications vous permettent de vous familiariser avec NGINX et de vous préparer à optimiser des sites plus complexes, comme nous le décrivons dans la partie 2 de cet article de blog. Toutefois, si ces modifications de configuration représentent une quantité de travail ou un degré de risque inacceptable pour les opérations de votre site, n'ayez crainte : vous pouvez implémenter les architectures multiserveurs décrites dans la partie 2 sans mettre à niveau le logiciel de serveur Web principal d'Apache, et donc sans modifier les fichiers de configuration de votre serveur Web.

Astuce 4 – Implémenter la mise en cache des fichiers statiques

Les fichiers statiques sont simplement des fichiers qui ne changent pas souvent, du moins en termes de serveur Web. Les fichiers statiques incluent généralement des fichiers graphiques tels que des fichiers JPEG et PNG et des fichiers de code tels que des fichiers CSS et JavaScript. Si vous placez ces fichiers sur votre serveur d'applications ou sur un serveur de base de données distinct, les demandes les concernant doivent être traitées par le code de l'application, avec toute la charge requise pour effectuer et exécuter une demande. Cela « distrait » le serveur d’applications de tâches plus importantes et peut le rapprocher du point où la mémoire physique est surchargée et où les nouvelles requêtes entraînent la pagination des requêtes actuelles sur le disque.

La mise en cache de fichiers statiques est une fonction essentielle de NGINX. Vous pouvez l'implémenter sur un serveur Web ou un serveur proxy inverse :

• Sur un serveur Web NGINX, la mise en cache de fichiers statiques décharge le serveur d'applications ; les fichiers sont récupérés plus rapidement et avec beaucoup moins de surcharge de mémoire. Cependant, la récupération des fichiers s’effectue toujours à partir du même serveur physique ou de la même instance de serveur virtuel, de sorte que le processeur du serveur est toujours obligé de gérer des tâches autres que l’exécution de votre application.
• Un serveur proxy inverse NGINX s'exécute sur une machine ou une instance différente du serveur Web, de sorte que sa mise en cache de fichiers statiques ne consomme aucune ressource sur les serveurs d'applications. Le serveur d’applications peut se concentrer exclusivement sur l’exécution de votre application.

La mise en œuvre de la mise en cache de fichiers statiques sur NGINX comporte trois étapes globales :

• Spécification du répertoire racine pour les recherches.
• Traitement des demandes.
• Optimiser la vitesse de réponse.

Sur un serveur Web NGINX, sans serveur proxy inverse impliqué, vous ne mettez pas en cache au sens habituel du terme. Vous redirigez simplement les demandes de fichiers statiques vers le serveur Web, à l'aide de l'en-tête X-Accel-Redirect . Le serveur d’application ne voit jamais la requête et peut consacrer toutes ses ressources aux requêtes d’application. Avec un serveur proxy inverse, vous utilisez la mise en cache de fichiers statiques – et le serveur physique ou l'instance de serveur virtuel qui exécute l'application n'a aucun rôle à jouer dans la réponse aux demandes de fichiers statiques.

À titre d'exemple d'optimisation de la vitesse de réponse, l'extrait de configuration suivant permet à NGINX d'utiliser l'appel système sendfile du système d'exploitation, ce qui permet d'économiser une étape dans la transmission de fichiers en ne copiant pas le fichier dans un tampon intermédiaire :

emplacement /mp3 { sendfile activé ;
sendfile_max_chunk 1m ;
# ...
}

Pour plus de détails sur la configuration de NGINX pour la mise en cache de fichiers statiques, consultez le Guide d'administration NGINX Plus .

Astuce 5 – Mettre en œuvre la microcaching

La microcaching porte, de manière déroutante, de nombreux noms, qui incluent également la mise en cache d'application et la mise en cache pure et simple. Ici chez NGINX, nous utilisons le terme microcaching pour souligner la courte durée de validité de ces fichiers.

Disons que vous avez une page d’article de blog qui fournit un mécanisme pour les commentaires des utilisateurs. Vous souhaitez inclure les commentaires les plus récents et les plus intéressants à chaque fois qu’un nouveau visiteur arrive sur la page – ou à chaque fois que les utilisateurs existants actualisent la page pour voir leur propre nouveau commentaire ou celui de quelqu’un d’autre. Dans ce cas, il semble être une bonne idée de générer à nouveau la page à chaque fois que quelqu'un la visite.

Cependant, « à chaque fois » peut devenir contraignant. Si une page reçoit une visite par seconde, il est logique de la générer à nouveau à chaque visite. Mais si la page reçoit dix, cent ou mille visites par seconde, comme toutes les autres pages du site, le serveur d'application peut être surchargé. Atteindre l’objectif de proposer aux gens du contenu nouveau signifie que personne n’obtient du contenu rapidement.

La micromise en cache consiste à générer une fois une page marquant la version mise en cache comme valide pendant une brève période de temps, par exemple une ou quelques secondes. Lorsque la version mise en cache expire, la requête suivante demande la génération d'une nouvelle page et demande juste après d'obtenir sa version mise en cache. Il s'agit du même comportement que pour un fichier statique, mais sur des délais beaucoup plus courts.

Cette image indique où rechercher sur votre site le contenu que vous pouvez mettre en microcache. Il s'agit d'un article de blog sur le microcaching publié par notre propre Owen Garrett.

La micromise en cache est géniale car elle supprime le travail du serveur d’applications au moment même où cela est le plus nécessaire, et avec très peu ou pas de préjudice pour l’utilisateur. C’est tellement génial que c’est intégré à certains systèmes. Drupal considère ses capacités robustes de microcaching intégrées comme si essentielles que, dans le monde Drupal, le microcaching est simplement appelé « mise en cache ».

Mais la solution Drupal est un peu décevante, tout comme toute solution similaire. Le serveur d’application fait moins de travail, mais c’est toujours Drupal (ou, plus généralement, PHP) qui doit gérer la configuration, l’implémentation et le service de fichiers. En utilisant NGINX pour la microcache, le serveur d'applications est totalement déchargé de toute tâche, à l'exception de la génération d'une nouvelle page à la fréquence spécifiée par la microcache. Il ne voit même pas les autres requêtes, et encore moins doit stocker ou récupérer quoi que ce soit pour les hits du cache.

En utilisant NGINX Plus ou d'autres outils, vous pouvez surveiller votre site et voir quelles pages bénéficieront de la microcaching. L'extrait de configuration suivant implémente une période de mise en cache d'une seconde pour les réponses avec un 200Code d'état OK .

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
proxy_cache cache;
proxy_cache_valid 200 1s;
# ...
}

Conclusion de la partie 1

Cette première partie de notre article de blog PHP est axée sur les solutions à serveur unique, ainsi que sur la mise en cache, qui est efficace dans les implémentations à serveur unique, mais encore plus lorsqu'un serveur proxy inverse est dans le mix. La partie 2 décrit les avantages d'un serveur proxy inverse et d'une implémentation multiserveur autour de votre application PHP.

Pour essayer NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation.