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

Floyd SmithDirecteur du marketing de contenu

Introduction – Comment NGINX est utilisé avec PHP

PHP est la technologie la plus populaire pour créer une application Web côté serveur, avec environ 80 % de parts de marché. (ASP.net arrive loin derrière en deuxième position, et Java encore plus loin en troisième position.)

L’univers PHP comprend une multitude de frameworks PHP ; parmi les plus populaires figurent Laravel, Phalcon et Symfony 2. PHP sert également de 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, intègre largement Symfony 2.

Aujourd’hui, l’équipe PHP publie une nouvelle version, PHP 7 – plus de dix ans après le lancement de PHP 5. Durant cette période, l’utilisation du Web et les exigences imposées aux sites Web ont toutes deux connu une croissance exponentielle. PHP a contribué à cette croissance rapide, mais celle-ci, qu’il a lui-même rendue possible, met également en évidence ses limites.

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 leurs limites » après seulement quelques doublements du trafic. Au moment même où un site commence à atteindre ses objectifs commerciaux ou opérationnels, il se met à planter dès que le volume de trafic augmente.

Pour des milliers et des milliers d’applications basées sur PHP, quelques changements relativement simples ont suffi à améliorer les performances. Il s’agit notamment de la mise en cache à l’aide d’outils tels que memcached, de l’optimisation des bases de données, ainsi que de l’utilisation d’un proxy inverse et de la répartition de charge avec NGINX Open Source et NGINX Plus. NGINX a considérablement amélioré la réactivité des applications, permettant de multiplier par dix le nombre d’utilisateurs et le volume de trafic.

Cet article de blog est le premier d’une série en deux parties consacrée à l’optimisation des performances de vos sites Web utilisant PHP 7. Nous nous concentrons ici sur la mise à niveau vers PHP 7, l’utilisation de NGINX Open Source ou de 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 celle des fichiers dynamiques (également appelée mise en cache des applications ou microcache).

Dans le prochain article de blog, nous nous intéresserons aux mesures que vous pouvez prendre en ajoutant des serveurs : mettre en place un serveur proxy inverse, passer à plusieurs serveurs d’applications, répartir la charge entre plusieurs serveurs, assurer la persistance des sessions lors de la répartition de charge et gérer la terminaison des protocoles de sécurité, tels que SSL/TLS et le protocole HTTP/2 associé.

Pourquoi PHP atteint ses limites

Pourquoi les applications PHP finissent-elles par atteindre leurs limites ? Pour les mêmes raisons que n’importe quel logiciel de serveur d’applications. Lorsqu’une requête utilisateur arrive, PHP – ainsi que le logiciel de serveur web sur lequel il s’exécute – doivent effectuer plusieurs opérations :

• Déchiffrer la requête. Le logiciel de serveur web, puis PHP, doivent d’abord lancer des processus pour recevoir, déchiffrer et traiter la requête. Apache HTTP Server, par exemple, alloue des ressources au traitement de chaque requête de données, qu’elle soit simple (récupération d’un fichier JPEG) ou complexe (traitement de requêtes CSS imbriquées). Tout cela nécessite 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 plusieurs bibliothèques avant même de commencer à traiter la requête.
• Gérer les protocoles complémentaires. Si vous utilisez SSL/TLS et/ou HTTP/2, votre logiciel de serveur web doit décoder les requêtes, un processus qui peut prendre du temps.
• Traiter la requête. PHP doit rassembler les ressources nécessaires pour traiter la requête. Cela peut nécessiter plusieurs appels à la base de données, des appels à des services externes via Internet et des traitements internes complexes.
• Répondre à la requête. PHP doit renvoyer les résultats au logiciel du serveur web afin qu’ils soient transmis au demandeur sous la forme d’une 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 sa réception initiale jusqu’à son accusé de réception final.

Cela représente une charge considérable à traiter pour un serveur physique, une machine virtuelle ou une instance de serveur cloud, et ce, pour chaque requête. Les performances ont tendance à se dégrader lorsque la mémoire physique de la machine serveur, qu’elle soit physique ou virtuelle, est saturée. Le serveur commence alors à transférer sur disque les sessions en cours à mesure que de nouvelles requêtes arrivent. L’attente liée au traitement des requêtes de fichiers crée également des états d’attente qui accentuent encore ce phénomène. Au-delà d’un seuil très limité, les opérations de pagination et les requêtes de données prennent le pas sur les opérations de traitement, et les performances entrent dans une spirale infernale qui entraîne de longs délais d’attente, voire l’interruption pure et simple des sessions, au grand dam des utilisateurs.

Résoudre les problèmes de performances

Il est tout à fait possible de surmonter les problèmes de performances de PHP, moyennant plusieurs mesures complémentaires. Chacune d’elles peut être combinée aux autres. Dans les grandes lignes, elles comprennent :

• Résoudre le problème à coups de matériel. Davantage de mémoire, encore davantage de mémoire, des disques plus rapides, des serveurs de base de données distincts, un réseau de diffusion de contenu, une capacité de traitement accrue et d’autres solutions matérielles constituent un moyen rapide, mais peu élégant, de résoudre les problèmes de performances. Ces solutions peuvent préserver la disponibilité ou permettre une montée en charge linéaire.
• Amélioration de PHP et du code de l’application. Les nouvelles versions de PHP, les nouveaux frameworks et l’amélioration du code de l’application peuvent être très utiles. Là encore, il est possible de doubler, voire de quadrupler les performances, sans dépenses supplémentaires en nouveau matériel.
• Logiciel serveur amélioré. La plupart des serveurs web et PHP allouent des ressources dédiées à chaque requête ouverte en cours de traitement. Le logiciel serveur NGINX traite les requêtes à mesure qu’elles arrivent, sans monopoliser les ressources, ce qui réduit au minimum l’empreinte du serveur.
• Mise en œuvre multiserveur. Vous pouvez mettre en place un serveur proxy inverse pour traiter les requêtes Internet et les répartir (é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’applications, cela permet de le décharger d’une grande partie de sa charge de travail. À mesure que des serveurs sont ajoutés, l’équilibrage de charge garantit qu’aucun d’entre eux ne se retrouve surchargé au-delà de sa part de la charge.

Vous n’avez pas besoin de suivre 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 de déployer NGINX comme proxy inverse « devant » vos serveurs existants améliore les performances et vous permet d’exécuter plusieurs serveurs d’applications en parallèle.

Quelle que soit votre approche, l’essentiel à retenir est que vous pouvez multiplier les performances, voire décupler la capacité, en modifiant peu ou pas du tout le code actuel de votre application. Poursuivez votre lecture pour découvrir comment certains ont déjà obtenu, ou sont en passe d’obtenir, ces gains de performances exceptionnels.

Remarque: il existe une optimisation multiserveur que nous laisserons quelque peu de côté dans ces articles de blog. Un serveur de base de données distinct et un réseau de diffusion de contenu (CDN) peuvent alléger la charge de votre serveur d’applications et améliorer considérablement les performances. Ces types de modifications sont indépendants des améliorations apportées à l’application et à son implémentation décrites ici, et peuvent être réalisés en parallèle.

Conseil n° 1 – Passez à PHP 7

La principale raison de passer à PHP 7 sans tarder est simple : la vitesse des applications (rendue possible notamment par les économies de mémoire). PHP 7 serait deux fois plus rapide que les versions précédentes de PHP et utiliserait nettement moins de mémoire. (Les résultats varieront sans aucun doute sur ces deux points.)

Le temps de réponse est, tout simplement, crucial pour les applications web. Une application web plus rapide — qui utilise également moins de mémoire, réduisant ainsi le risque de pagination et les problèmes de performances qui en découlent — permet d’accomplir trois choses :

1. Rend les utilisateurs plus satisfaits et plus enclins à consulter votre site et à y effectuer des tâches, comme lire des articles, obtenir des informations sur des produits, héler un taxi collectif, louer une chambre libre ou faire des achats. Autrement dit, les raisons mêmes pour lesquelles vous avez créé le site ou l’application.
2. Permet à un serveur donné de prendre en charge davantage d’utilisateurs sans risquer de ralentir, voire de tomber en panne sous l’effet de cette charge supplémentaire. Retarder l’inévitable est toujours une bonne chose.
3. Rend votre serveur moins vulnérable aux attaques de pirates informatiques qui le surchargent afin de le mettre hors service. Aujourd’hui, tout le monde subit des attaques, mais les systèmes les plus fragiles sont attaqués plus souvent et plus agressivement. Réduire la vulnérabilité peut donc s’avérer exponentiellement plus avantageux que de l’accroître.

Ce sont là d’excellentes raisons d’effectuer une mise à niveau ; prises dans leur ensemble, elles rendent cette décision presque incontournable. Et « passer à la dernière version » est toujours la première recommandation pour résoudre de nombreux problèmes, même lorsque le gain de performances n’est pas aussi évident. Alors pourquoi tout le monde ne le fait-il pas immédiatement ?

Les mises à jour selon xkcd

C’est simple : les gens détestent toucher à du code ancien, et pour cause. Si une ancienne application fonctionne suffisamment bien et que les développeurs obtiennent de meilleurs résultats en créant de nouvelles applications plutôt qu’en mettant à niveau les anciennes, celle-ci peut rester en place, inchangée, pendant très longtemps. (Consultez le deuxième article de blog de cette série pour savoir comment utiliser NGINX afin d’améliorer les performances de votre application sans apporter la moindre modification à votre serveur web ni à votre application actuels.)

Mais la solution la plus efficace, dans la mesure du possible, consiste à commencer votre quête de meilleures performances en passant à PHP 7. Toutefois, ne vous lancez pas avant de disposer de suffisamment de temps pour aller jusqu’au bout, surtout sans lésiner sur les tests.

Voyons ce qu’implique la mise à niveau vers PHP 7 :

• Modifications apportées à l’évaluation des expressions. Vous devrez peut-être modifier la façon dont certaines expressions sont écrites afin qu’elles soient évaluées correctement dans PHP 7. (Ou, si vous êtes particulièrement prudent et ne mettez pas à niveau tous vos serveurs PHP en même temps, afin qu’elles soient évaluées correctement à la fois dans PHP 5.6 et PHP 7.) Si vous utilisez des variables dynamiques ou des propriétés dynamiques, vous devrez revoir le code afin qu’elles soient évaluées de la même manière dans les deux versions de PHP.
• Modifications de syntaxe. PHP 7 ne prend pas en charge les balises ASP ni les balises script. Une instruction switch ne peut pas comporter plusieurs cas par défaut. (Nous laisserons de côté la controverse autour de switch par rapport à if-then-else.)
• Suppression des fonctionnalités obsolètes. Toutes sortes d’éléments qui avaient été déclarés obsolètes dans différentes versions 5.x de PHP sont désormais plus morts qu’un perroquet mort. Ils ne fonctionnent tout simplement pas sous PHP 7. S’ils sont présents dans votre code et que vous tentez de tous les supprimer sans y parvenir, les fonctionnalités de votre panier disparaîtront à coup sûr à 23 h 59 la veille du Cyber Monday.
• Nouvelles fonctionnalités. PHP 7 ajoute un certain nombre de nouvelles fonctionnalités susceptibles de séduire quiconque met à niveau du code ancien, mais soyez prudent lorsque vous ajoutez de nouvelles fonctionnalités dans le cadre d’un nettoyage du code. Les nouvelles fonctionnalités sont souvent formidables — sinon, elles n’auraient pas été ajoutées —, mais elles attirent aussi les bogues (les vôtres comme ceux des autres) et nécessiteront de futures révisions à mesure que PHP continuera d’évoluer.
• Revue générale du code. Chaque fois que vous touchez au code — et même chaque fois que vous ouvrez un fichier de code sans savoir avec certitude si vous l’avez modifié ou non — vous devez vraiment tout passer en revue, en particulier ce que vous avez modifié.
• TestsTout doit être testé en permanence. Si vous apportez la moindre modification, vous devez tout tester à nouveau, sans pour autant être certain de détecter tous les bugs. Un environnement DevOps bien mis en œuvre peut rendre ces tests relativement faciles, mais à ce jour, rares sont ceux d’entre nous qui vivent dans cette terre promise.

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

Si vous décidez de passer à PHP 7, envisagez d’effectuer un audit complet des performances et de revoir votre code, ou au moins ses fonctionnalités critiques, afin de tirer parti des nouveautés de PHP 7. Il n’y a pas de meilleur moyen pour vous et votre équipe de développer vos compétences, et les modifications que vous apportez, révisez et testez aujourd’hui vous seront probablement utiles pendant de nombreuses années. Vous profiterez également pleinement des autres recommandations de cet article de blog en matière de performances, car un code optimisé tire largement parti d’un environnement lui-même optimisé.

Ainsi, même si les sites déploient souvent NGINX pour améliorer leurs performances sans toucher au code de l’application, nous vous recommandons de prendre le taureau par les cornes et de vous lancer. Vous trouverez de nombreuses ressources utiles pour effectuer la migration, mais vous pouvez aussi retrousser vos manches et vous en charger vous-même. Vous trouverez un guide de migration vers PHP 7 sur le site officiel de PHP, ainsi qu’un guide pratique de mise à niveau vers PHP 7 publié par O’Reilly.

Conseil n° 2 – Choisissez NGINX Open Source ou NGINX Plus

NGINX est le logiciel qui fait fonctionner 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 serveurs web, les deux offrent un gain de performances immédiat, pouvant aller jusqu’à décupler les performances dans certains cas où un serveur exécutant un autre logiciel était surchargé et saturé. En tant que serveurs proxy inverses, les deux permettent d’utiliser plusieurs serveurs dédiés afin d’adapter le déploiement à l’échelle requise.

PHP et Apache allouent tous deux des ressources à chaque requête ouverte. Si l’un ou l’autre, voire les deux, doivent charger plusieurs bibliothèques, le temps d’initialisation par requête et l’empreinte mémoire peuvent être considérables. L’utilisation de NGINX comme logiciel de serveur web élimine ce problème au niveau du serveur. Exploiter les fonctionnalités de NGINX pour déléguer certaines tâches au serveur web (comme la diffusion de fichiers statiques) ou à un serveur proxy inverse (mise en cache de tous types, terminaison de protocole, équilibrage de charge, etc.) réduit au minimum le travail que PHP doit effectuer, ce qui simplifie et accélère le traitement des applications.

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

Une fois que vous avez décidé d’opter pour NGINX, vous avez le choix entre NGINX Open Source et NGINX Plus. Parmi les principales fonctionnalités offertes par NGINX Plus par rapport à NGINX Open Source figurent :

• Code précompilé. NGINX Plus est distribué sous forme compilée et inclut des bibliothèques courantes ainsi que des modules dynamiques que vous pouvez ajouter et supprimer à la volée. (NGINX Open Source est disponible sous forme de code à la fois compilé et non compilé.) Vous pouvez apporter de nombreuses modifications à la configuration sans redémarrer le serveur.
• Assistance. NGINX Plus inclut une offre d’assistance, qui vous donne un accès direct aux ingénieurs NGINX.
• Supervision et gestion. Des outils adaptés aux pratiques 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 offre des avantages supplémentaires :

• Répartition de charge. Les deux versions de NGINX prennent en charge la répartition de charge HTTP de base, mais NGINX Plus propose en plus des algorithmes plus sophistiqués ainsi que la répartition de charge TCP.
• Persistance de session. Outre l’équilibrage de charge, NGINX Plus offre une persistance de session plus sophistiquée, souvent particulièrement utile pour les serveurs d’applications PHP.
• Supervision et gestion. L’ensemble des fonctionnalités de supervision et de gestion de NGINX Plus prend tout son sens dans un déploiement multiserveur ; le code précompilé et l’assistance offrent également une valeur maximale dans les implémentations plus complexes.

NGINX Open Source et NGINX Plus prennent tous deux en charge la mise en cache du contenu et la mise en microcache (également appelée « mise en cache des applications »). La mise en cache est utile dans le contexte d’un serveur web, car elle décharge le serveur d’applications, mais les deux fonctions partagent toujours une même machine physique ou instance de machine virtuelle. Sur un serveur proxy inverse, la mise en cache peut décharger le serveur d’applications d’une part importante de son travail, ce qui améliore davantage les performances.

Vous pouvez télécharger le logiciel NGINX Open Source directement depuis nginx.org, où vous trouverez également une assistance communautaire. Pour souscrire un abonnement individuel à NGINX Plus, inscrivez-vous pour bénéficier d’un essai gratuit de 30 jours ou achetez-le en ligne. Pour les offres groupées multi-instances, contactez le service commercial de NGINX.

Conseil n° 3 – Convertir la configuration Apache à la syntaxe NGINX

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

• Créez ou convertissez les fichiers de configuration. Modifiez le code de configuration pour indiquer les fichiers que NGINX (et non plus Apache) doit utiliser pour sa configuration.
• Modifier les autorisations de lecture/écriture. Ajoutez à votre compte l’autorisation d’effectuer des opérations CRUD (création, lecture, mise à jour et suppression) sur les fichiers du répertoire racine du site web.
• Spécifier des modèles de recherche valides. Ajoutez un bloc location pour indiquer les modèles que NGINX peut ou ne peut pas tester lors du traitement des requêtes.
• Remplacez le code de configuration .htaccess. Les détails de configuration d’Apache se trouvent généralement dans des fichiers .htaccess ou dans des fichiers de configuration statiques (mod_rewrite directives, par exemple). Remplacez-les par les spécifications de configuration correspondantes dans les fichiers de configuration NGINX. Pour consulter quelques exemples, rendez-vous sur notre blogue.

Ces modifications vous permettent de vous familiariser avec NGINX et vous préparent à optimiser des sites plus complexes, comme nous l’expliquons dans la deuxième partie de cet article de blog. Toutefois, si ces changements de configuration représentent une charge de travail ou un niveau de risque inacceptable pour l’exploitation de votre site, rassurez-vous : vous pouvez mettre en œuvre les architectures multiserveurs décrites dans la deuxième partie sans remplacer Apache, le logiciel principal de votre serveur web, et donc sans modifier les fichiers de configuration de ce dernier.

Conseil n° 4 – Mettre en œuvre la mise en cache des fichiers statiques

Les fichiers statiques sont tout simplement des fichiers qui changent peu souvent, du moins à l’échelle d’un serveur web. Ils comprennent généralement des fichiers graphiques, tels que des fichiers JPEG et PNG, ainsi que des fichiers de code, comme les 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 requêtes qui les concernent doivent être traitées par le code de l’application, avec toute la surcharge nécessaire à leur création et à leur exécution. Cela « détourne » le serveur d’applications de tâches plus importantes et peut le rapprocher du seuil de saturation de la mémoire physique, auquel cas les nouvelles requêtes entraînent le transfert sur disque des requêtes en cours.

La mise en cache des fichiers statiques est une fonctionnalité essentielle de NGINX. Vous pouvez la mettre en œuvre sur un serveur web ou un serveur proxy inverse :

• Sur un serveur web NGINX, la mise en cache des fichiers statiques allège la charge du serveur d’applications ; les fichiers sont récupérés plus rapidement et avec une empreinte mémoire bien moindre. Toutefois, leur récupération s’effectue toujours depuis le même serveur physique ou la même instance de serveur virtuel. Le processeur du serveur doit donc encore gérer d’autres tâches que l’exécution de votre application.
• Un serveur proxy inverse NGINX s’exécute sur une machine ou une instance distincte du serveur web. Ainsi, la mise en cache des fichiers statiques ne consomme aucune ressource sur les serveurs d’applications. Le serveur d’applications peut donc se consacrer exclusivement à l’exécution de votre application.

La mise en œuvre de la mise en cache des fichiers statiques sur NGINX se déroule en trois grandes étapes :

• Spécifier le répertoire racine pour les recherches.
• Traitement des requêtes.
• Optimisation de la vitesse de réponse.

Sur un serveur web NGINX sans serveur proxy inverse, la mise en cache ne s’effectue pas au sens habituel. Il suffit de rediriger les requêtes de fichiers statiques vers le serveur web à l’aide de l’en-tête X-Accel-Redirect. Le serveur d’applications ne voit jamais la requête et peut consacrer toutes ses ressources aux requêtes applicatives. Avec un serveur proxy inverse, les fichiers statiques sont effectivement mis en cache, et le serveur physique ou l’instance de serveur virtuel qui exécute l’application n’intervient aucunement dans le traitement des requêtes 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 élimine une étape lors de la transmission du fichier en évitant de le copier dans une mémoire tampon intermédiaire :

location /mp3 {    sendfile           on;
    sendfile_max_chunk 1m;
    # ...
}

Pour plus de détails sur la configuration de NGINX pour la mise en cache des fichiers statiques, consultez le Guide de l’administrateur NGINX Plus.

Conseil n° 5 – Mettez en œuvre la mise en cache de courte durée

Le microcache, ce qui peut prêter à confusion, porte de nombreux noms, notamment cache applicatif ou tout simplement cache. Chez NGINX, nous utilisons le terme microcache pour souligner la courte durée de validité de ces fichiers.

Imaginons que vous ayez une page d’article de blog permettant aux utilisateurs de publier des commentaires. Vous souhaitez afficher les commentaires les plus récents chaque fois qu’un nouveau visiteur accède à la page, ou que des utilisateurs déjà présents l’actualisent pour voir leur nouveau commentaire ou celui de quelqu’un d’autre. Dans ce cas, il semble judicieux de générer à nouveau la page à chaque visite.

Cependant, « à chaque fois » peut vite devenir contraignant. Si une page reçoit une visite par seconde, il est logique de la générer à nouveau à chaque visite. Mais si elle reçoit dix, cent ou mille visites par seconde, en plus de toutes les autres pages du site, le serveur d’applications risque d’être surchargé. À vouloir proposer du contenu actualisé, on finit par ne plus pouvoir fournir rapidement le moindre contenu à qui que ce soit.

La mise en cache de courte durée consiste à générer une page une seule fois et à considérer sa version mise en cache comme valide pendant un bref laps de temps, par exemple une ou quelques secondes. Lorsque la version mise en cache expire, la requête suivante déclenche la génération d’une nouvelle page, dont les requêtes qui suivent immédiatement reçoivent la version mise en cache. Le comportement est identique à celui d’un fichier statique, mais sur des périodes beaucoup plus courtes.

Cette image indique où rechercher, sur votre site, du contenu pouvant être mis en microcache. Elle est tirée d’un article de blog sur la mise en microcache rédigé par notre collègue Owen Garrett.

Une grande partie du contenu dynamique se prête à la mise en cache de courte durée

La mise en cache de très courte durée est formidable, car elle allège la charge du serveur d’applications précisément au moment où cela est le plus nécessaire, sans pratiquement nuire à l’utilisateur. Elle est si efficace qu’elle est intégrée à certains systèmes. Drupal considère ses solides fonctionnalités intégrées de mise en cache de très courte durée comme tellement essentielles que, dans l’univers Drupal, on parle simplement de « mise en cache ».

Mais la solution de Drupal présente quelques lacunes, comme toute solution similaire. Le serveur d’applications est moins sollicité, mais c’est toujours Drupal (ou, plus généralement, PHP) qui doit gérer la configuration, la mise en œuvre et la diffusion des fichiers. En utilisant NGINX pour la mise en microcache, le serveur d’applications est entièrement déchargé de toutes les tâches, à l’exception de la génération d’une nouvelle page à la fréquence définie par le microcache. Il ne voit même pas les autres requêtes, et n’a donc rien à stocker ni à récupérer lorsque le contenu demandé se trouve dans le cache.

À l’aide de NGINX Plus ou d’autres outils, vous pouvez surveiller votre site et déterminer quelles pages tireront parti de la mise en cache de très courte durée. L’extrait de configuration suivant définit une durée de mise en cache de 1 seconde pour les réponses ayant un code d’état 200 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 première partie

Cette première partie de notre article de blog sur PHP porte sur les solutions à serveur unique, ainsi que sur la mise en cache, qui est efficace dans les déploiements à serveur unique, mais encore davantage lorsqu’un serveur proxy inverse entre en jeu. La deuxième partie présente les avantages d’un déploiement multiserveur reposant sur un serveur proxy inverse pour votre application PHP.

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

À propos de l’auteur

Floyd SmithDirecteur du marketing de contenu

Autres articles de Floyd Smith