Le guide définitif sur les performances de Shopware sur Shopware PaaS

Une récente étude de performance analysant des centaines de projets Shopware réels a révélé une différence de 10 fois dans les temps de chargement des pages entre des vitrines similaires. Les pages de recherche de produits variaient de moins de 200 ms à bien plus de 2 secondes ; même plateforme, mêmes types de pages, résultats très différents.

Cet écart considérable n'est pas une question de chance ou de plateforme. Pour gérer une boutique Shopware hautement performante, il faut prendre des décisions réfléchies en matière d'infrastructure, procéder à une configuration minutieuse et définir des pratiques de développement. Un seul plugin mal configuré, une synchronisation ERP non groupée ou un journal de débogage laissé activé en production peuvent transformer une vitrine rapide en une vitrine inutilisable.

Ce guide partage les enseignements pratiques tirés de plusieurs mois de tests de charge sur sept niveaux d'infrastructure. Nous avons testé des scénarios traitant de 3 000 à 73 000 commandes par jour afin d'identifier les configurations offrant les meilleures performances Shopware.

À qui s'adresse ce guide ?

Si vous êtes développeur, architecte logiciel, ingénieur DevOps ou chef de produit travaillant avec Shopware, ce guide est fait pour vous. Nous passerons en revue les problèmes de performances courants que nous avons rencontrés dans des dizaines de projets, ce que révèlent réellement les données de test et comment optimiser votre déploiement Shopware pour une évolutivité réelle.

Le problème de performance

Deux sites Shopware qui semblent identiques peuvent se comporter de manière très différente sous la charge. Voici ce que nous constatons régulièrement dans les projets Shopware :

• Les plugins sont souvent le maillon faible. Les extensions tierces et personnalisées sont souvent mal optimisées, difficiles à déboguer et difficiles à prendre en charge sous charge.
• L'invalidation du cache pose des problèmes. Les importations ERP ou les modifications administratives peuvent déclencher des purges massives du cache, créant des pics de charge et des pics de latence au niveau du backend.
• Les architectures headless exposent les limites du cache. L'API Store repose fortement sur les requêtes POST, qui ne fonctionnent pas bien avec les outils de mise en cache HTTP tels que Fastly ou Varnish.
• Les processus DevOps sont incohérents. Les équipes perdent du temps à réinventer les processus de déploiement, de surveillance et de mise en scène au lieu de se concentrer sur le développement des produits.

Ces problèmes ne sont pas dus à de mauvaises intentions, mais à la complexité. Shopware est modulaire et performant, mais sans discipline et sans les bons outils, les performances en pâtissent.

Ce qui différencie Shopware PaaS

Construit sur Upsun, Shopware PaaS fournit une infrastructure de niveau entreprise avec des SLA pour la scalabilité, la haute disponibilité et les performances. Il comprend des processus de développement standardisés avec des environnements basés sur Git, CI/CD et des capacités de rollback intégrées. Vous bénéficiez également d'outils de diagnostic et d'optimisation des performances, y compris la prise en charge native de Blackfire, ainsi que des modèles de bonnes pratiques et des conseils en matière d'architecture.

Les performances réelles de Shopware

Un récent benchmark des performances de Shopware 6 réalisé par Tideways a analysé des centaines de projets réels et a constaté une différence de 10 fois dans le Time-to-First-Byte (TTFB) entre des types de pages similaires. Les pages de recherche de produits variaient de moins de 200 ms à bien plus de 2 secondes, selon le projet.

Cette disparité reflète ce que nous observons dans la pratique : le logiciel n'est pas intrinsèquement lent, mais il est très sensible à la manière dont il est utilisé.

Exemple concret : la journalisation de débogage a failli causer la perte d'une boutique

Fin 2024, nous avons reçu un ticket d'assistance concernant une boutique Shopware souffrant d'une lenteur importante. Certaines pages mettaient plus de 10 secondes à se charger, avec des cas extrêmes dépassant les 3 minutes.

Grâce aux capacités de profilage de Blackfire, nous avons rapidement identifié la cause profonde : le plugin PayPal fonctionnait avec la journalisation au niveau DEBUG activée. Sous un trafic intense, cela a saturé le disque avec des opérations d'écriture, provoquant des conflits d'E/S alors que les processus faisaient la queue pour écrire leurs propres journaux. Une fois le mode débogage désactivé, les temps de réponse se sont rétablis presque immédiatement.

Ce cas illustre un thème récurrent : une petite erreur de configuration dans une extension tierce peut déstabiliser l'ensemble de la stack.

Pièges courants en matière de performances

• Intégrations ERP qui déclenchent des invalidations de cache : les mises à jour des stocks et des produits, en particulier lorsqu'elles ne sont pas groupées, provoquent des invalidations de cache généralisées, ce qui entraîne des pics de charge backend et une latence frontend.
• Personnalisation excessive : la fourniture de contenu unique, tel que des prix spécifiques aux clients ou des ajustements basés sur le code postal, réduit l'efficacité du cache et augmente la charge de l'infrastructure.
• Absence de budget de performance : les équipes déploient des fonctionnalités ou des plugins sans définir de seuils de performance acceptables, ce qui entraîne une lente dégradation au fil du temps.

Le cache d'abord, tout le reste ensuite

Quelle que soit l'efficacité de votre code personnalisé, rien ne vaut un cache rapide. Que ce soit à la périphérie (Fastly), du côté de l'application (cache HTTP Symfony) ou dans la couche base de données/requête (Redis, métadonnées Doctrine), la mise en cache est la stratégie principale pour des performances durables.

Des études établissent une corrélation entre chaque seconde de temps de chargement supplémentaire et une baisse du taux de conversion. Pour les boutiques Shopware qui se font concurrence sur des marchés de détail saturés, les performances ne sont pas seulement techniques, elles sont aussi commerciales.

Comprendre les options d'infrastructure

Shopware PaaS propose plusieurs niveaux d'infrastructure :

Plans Grid (XL, 2XL, 4XL)

Modèle de ressources partagées où votre projet s'exécute dans des conteneurs isolés sur des machines virtuelles partagées avec d'autres clients. Il convient particulièrement aux projets d'entrée de gamme et aux projets de petite et moyenne envergure, offrant des tarifs avantageux ; cependant, la prévisibilité des performances est limitée dans des conditions de charge extrêmes.

Hôtes de grille dédiés (DGH-16, DGH-32, DGH-64, DGH-128)

Modèle basé sur des conteneurs, mais sur des machines virtuelles dédiées. Toutes les ressources sont exclusives à votre projet, ce qui permet une capacité de pointe et des performances constantes. Tous les conteneurs sont colocalisés sur le même hôte, ce qui élimine la latence du réseau inter-services. Les plans DGH offrent également des limites de mémoire nettement plus élevées que les plans Grid standard.

Idéal pour les boutiques en ligne de taille moyenne à forte fréquentation qui ont besoin d'un accès prévisible au processeur.

Forfaits dédiés (D-12, D-24, D-48, D-96, D-192)

Trois machines virtuelles entièrement dédiées configurées pour une haute disponibilité avec MySQL en configuration de cluster multimaster, Redis avec configuration multimaster et conteneurs d'applications redondants. Calcul, réseau et stockage entièrement dédiés avec une évolutivité verticale sans temps d'arrêt.

Idéal pour les environnements de production avec des exigences élevées en matière de concurrence et de disponibilité.

Clusters divisés dédiés

Séparation explicite des préoccupations : trois nœuds centraux gèrent les services backend (base de données, cache, files d'attente) tandis que trois nœuds web ou plus traitent le trafic des applications. Les nœuds centraux évoluent verticalement ; les nœuds web évoluent à la fois verticalement et horizontalement pour une auto-évolutivité dynamique et transparente.

Idéal pour les configurations de niveau entreprise avec une forte concurrence frontale ou des pics de trafic.

Meilleures pratiques pour des performances élevées

Configuration de l'infrastructure et du runtime

Ne laissez pas l'allocation de mémoire et les ressources CPU à leurs valeurs par défaut. Définissez explicitement les attentes en matière d'utilisation de la mémoire dans .upsun/config.yaml , afin que la plateforme puisse optimiser les paramètres de concurrence PHP-FPM en conséquence.

Maintenez l'utilisation du CPU en dessous de 70 % en charge afin de conserver une marge de manœuvre pendant les pics de trafic. Les niveaux d'infrastructure doivent être sélectionnés en fonction de la charge moyenne et de la capacité de pointe, en tenant compte de la saisonnalité de l'activité.

Stratégie de mise en cache

La mise en cache HTTP, la mise en cache côté application (cache HTTP Symfony) et la mise en cache d'objets (Redis) doivent fonctionner de concert. Dans la mesure du possible, le contenu doit être conçu pour être mis en cache, en utilisant les méthodes GET plutôt que POST lorsque cela est approprié, en garantissant la cohérence des en-têtes de cache et en évitant les modèles qui conduisent à la fragmentation du cache.

Préchauffez le cache Fastly des pages critiques après les déploiements ou les importations de contenu afin de garantir que le trafic ne soit pas servi à froid.

Vérifiez que le cache fonctionne en inspectant les en-têtes de réponse HTTP, en particulier l'en-tête X-Cache. Une valeur HIT indique que la réponse a été servie à partir du cache ; une valeur MISS suggère un contournement ou une expiration du cache.

Gérez l'invalidation du cache de manière responsable. Les mises à jour de produits non groupées ou les synchronisations ERP mal planifiées peuvent entraîner des purges de cache à grande échelle. Des techniques telles que les purges douces et les intervalles de purge différés peuvent aider à atténuer leur impact.

Fonctionnalités avancées du cache

ESI (Edge Side Includes) (Shopware ≥ 6.6.10.0) permet aux développeurs de diviser le rendu des pages en fragments pouvant être mis en cache indépendamment. Cette fonctionnalité est idéale lorsque seules certaines parties d'une page nécessitent des mises à jour fréquentes.

La purge douce (Shopware ≥ 6.4.15.0) marque les entrées comme obsolètes, mais continue de les servir jusqu'à leur actualisation. La première requête déclenche une régénération en arrière-plan, permettant aux utilisateurs de recevoir un contenu fonctionnel sans pics de charge sur le backend.

Gestion des extensions et des plugins

Les régressions de performances sont le plus souvent attribuées à des plugins tiers ou personnalisés. Ceux-ci peuvent introduire des hooks coûteux, enregistrer des services redondants ou exécuter une logique de blocage pendant le rendu des modèles ou les flux de paiement.

Un développement soucieux des performances doit inclure une évaluation de l'impact des plugins, tant lors de l'installation que lors des mises à jour. Même les plugins inutilisés peuvent consommer des ressources. Vérifiez régulièrement l'ensemble du stack de plugins et supprimez les paquets obsolètes.

Configuration administrative et logique d'application

Une mauvaise configuration au niveau de l'administration peut avoir un impact significatif sur les performances. Par exemple, configurer les pages de catégories pour afficher trop de produits entraîne une exécution inefficace des requêtes. Les conditions de règles dynamiques et les promotions doivent être conçues en tenant compte de la complexité des requêtes.

Dans la mesure du possible, évitez de vous fier à un comportement de recherche basé sur du SQL brut. Shopware PaaS prend en charge l'intégration avec des moteurs de recherche évolutifs, tels que OpenSearch, qui déchargent la logique de recherche de la base de données.

Les appels API externes ne doivent jamais bloquer les réponses de la vitrine. Les API sont intrinsèquement fragiles : leur lenteur ou leurs pannes peuvent se répercuter sur l'ensemble de votre système. Les communications externes doivent être traitées de manière asynchrone dans la mesure du possible.

Les niveaux de journalisation doivent être ajustés de manière appropriée pour les environnements de production. L'activation de journaux détaillés ou de niveau débogage dans les vitrines en direct peut saturer les E/S disque et entraîner des retards dans les réponses des applications.

La performance en tant que discipline

Les implémentations Shopware réussies ont un budget de performance défini : des objectifs mesurables pour les seuils TTFB, une utilisation acceptable du CPU en période de pointe, des contraintes de mémoire et des plafonds de taux d'échec. Ces mesures doivent guider le développement et être validées en permanence.

Les attentes en matière de performances doivent également se refléter dans le cycle de vie du développement : processus CI/CD basés sur Git, cohérence de l'environnement (développement, mise en scène, production) et observabilité continue.

Méthodologie des tests de charge

Nous avons utilisé Grafana K6 comme cadre de test de charge, en nous appuyant sur des scénarios K6 spécifiques à Shopware qui incluent quatre modèles de trafic clés :

• browse_only : simule des utilisateurs occasionnels ou des robots (visites de la page d'accueil, recherche, navigation par catégorie, consultation des produits)
• browse_and_buy : émule un parcours client complet (navigation, création de compte, opérations sur le panier, paiement)
• logged_in_fast_buy : modélise les clients réguliers (connexion rapide et paiement direct)
• api_import : représente les intégrations système (importations de produits, mises à jour des stocks, changements de prix)

Nous avons ajusté les tests afin de refléter le comportement en production en utilisant un ensemble de données et une base de code fixes pour tous les tests, en maintenant un état de cache cohérent avec Crawlee pour préchauffer le cache HTTP de Fastly et en réinitialisant la base de données avant chaque exécution.

Nous avons ajusté les utilisateurs virtuels (VU) et les pauses entre les actions afin de simuler une utilisation naturelle plutôt qu'une concurrence brute. Sans ces pauses, les plans plus petits sont saturés presque instantanément, produisant des résultats de test de résistance plutôt que des résultats de test de charge.

Indicateurs cibles

Nous avons calibré chaque test pour qu'il corresponde à :

• Taux de conversion d'environ 3 % (visiteurs devenant acheteurs)
• Part des requêtes API entre 5 % et 10 % du trafic total
• Temps de réponse cible : p95 TTFB inférieur à 600 ms
• Plafond d'utilisation du CPU : maintenu proche mais inférieur à 70 %
• Taux d'erreur : moins de 0,05 % de requêtes échouées

Les tests ont été effectués pendant 5 minutes par configuration, et répétés pour six types de forfaits.

Résultats de performance

Voici ce que les tests ont révélé :

Observations clés

• Les performances évoluent de manière prévisible en fonction des ressources. Même les plans modestes, comme XL, étaient capables de traiter plus de 3 000 commandes par jour dans des conditions optimales.
• Le temps de réponse p95 est resté stable. Le TTFB p95 est resté inférieur ou proche de l'objectif de 600 ms pour tous les plans. Cependant, pour maintenir cet objectif, nous avons dû plafonner les VU d'importation API à un maximum de 5. Au-delà de cinq, le TTFB augmentait et le RPS était limité, même pour les plans les plus importants.
• La charge API est coûteuse. Les requêtes API, en particulier celles qui créent ou mettent à jour des produits, invalident plusieurs couches de cache et sollicitent à la fois la base de données et Fastly Edge. Même si elles ne représentent que 5 à 10 % du trafic total, elles occupent une part disproportionnée de l'utilisation des ressources.
• Faibles taux d'échec à tous les niveaux. Tous les plans ont maintenu des taux d'échec inférieurs à 0,05 %, démontrant la résilience de Shopware PaaS sous une charge constante.

Utilisation de Blackfire pour identifier les goulots d'étranglement

Shopware PaaS inclut Blackfire par défaut, vous offrant ainsi des outils puissants pour profiler, observer et optimiser en permanence vos vitrines.

Pourquoi le profilage est-il important ?

Le profilage permet de répondre à des questions telles que :

• Pourquoi cette page de catégorie provoque-t-elle un pic d'utilisation du processeur ?
• Qu'est-ce qui se cache derrière ce conflit d'E/S soudain ?
• Ma logique de mise à jour ERP est-elle inefficace ?
• Pourquoi ce plugin nuit-il aux performances en phase de test, mais pas en local ?

Comment profiler une page Shopware

Vous pouvez lancer un profilage à partir de l'extension de navigateur Blackfire, de la CLI Blackfire en environnement de test ou de développement, ou de votre pipeline CI pour un profilage automatisé basé sur des tests.

Chaque profil fournit un graphique en flammes du cycle de vie complet de la requête, y compris le temps d'exécution par fonction ou service, les points chauds d'utilisation des E/S et de la mémoire, et le temps passé dans les modèles, les requêtes Doctrine, les appels Redis et les plugins.

Informations spécifiques à Shopware

Blackfire propose des instruments spécifiques à Shopware qui exposent des mesures de performance alignées sur l'architecture de la plateforme, notamment des timings précis pour ProductListingRoute, les performances de rendu des modèles et la surcharge des écouteurs de plugins.

Goulots d'étranglement courants

• Plugins avec des hooks inefficaces : le profilage révèle les plugins qui s'accrochent à chaque requête et exécutent des logiques coûteuses, telles que des recherches redondantes dans la base de données ou des appels API externes.
• Listes de produits surchargées : les pages qui affichent trop de produits ou qui ne sont pas paginées déclenchent des requêtes SQL massives et un rendu coûteux.
• Mises à jour ERP non groupées : les mises à jour fréquentes des produits sans regroupement ni délai saturent les E/S, invalident les caches et bloquent les workers PHP.
• Journalisation verbeuse en production : comme le montre le cas de débogage PayPal, cela peut submerger les E/S disque et entraîner des retards dans les réponses.

Exemple concret : extension d'analyse

Il y a trois ans, un client pilote de Shopware PaaS a connu une dégradation significative des performances, qui a parfois entraîné des temps d'arrêt de plusieurs minutes et s'est produite plusieurs fois par mois. L'utilisation de Blackfire a permis de détecter immédiatement un module Statistics exécutant des requêtes exceptionnellement volumineuses, qui bloquaient efficacement la base de données MySQL pendant des durées pouvant atteindre 16 minutes.

Blackfire a permis d'identifier rapidement la cause profonde en quelques minutes, transformant ainsi des analyses spéculatives prolongées en diagnostics rapides.

Leçons tirées du terrain

La configuration doit être intentionnelle

Les choix de configuration par défaut ou mal réfléchis sont l'une des causes les plus courantes de dégradation des performances. Les pages de catégories configurées pour afficher trop de produits, les niveaux de journalisation laissés en mode débogage en production ou les paramètres de pagination laissés dans leur état par défaut contribuent tous à une mauvaise performance.

Les projets qui fonctionnent bien font preuve d'intentionnalité dans leur configuration : la pagination, la verbosité de la journalisation, le comportement d'invalidation du cache et les configurations des plugins sont explicitement ajustés.

L'utilisation des plugins nécessite de la vigilance

Les plugins tiers et personnalisés sont souvent responsables de la majeure partie de la surcharge d'exécution dans les boutiques en ligne peu performantes. Un plugin peut introduire des hooks qui se déclenchent à chaque requête, effectuer des opérations redondantes sur la base de données ou interférer avec la mise en cache.

Les projets très performants traitent les plugins comme des composants d'exécution à évaluer et, si nécessaire, à remplacer ou à désactiver, et non pas simplement à installer.

La mise en cache est essentielle, mais souvent sous-estimée.

Le succès de la mise en cache dépend d'une mise en œuvre réfléchie : utilisation des méthodes GET plutôt que POST, en-têtes de cache appropriés et structures d'URL qui évitent les variations inutiles.

Dans de nombreux cas, les problèmes de performances ne proviennent pas de l'absence de mise en cache, mais des processus d'invalidation du cache déclenchés par des mises à jour ERP non groupées ou des changements administratifs. Les projets qui maintiennent leurs performances sous charge gèrent soigneusement l'invalidation et emploient des stratégies de purge douce.

Les tests de performance doivent être réalistes

Pour être efficaces, les tests doivent inclure des combinaisons de trafic représentatives, des taux de conversion réalistes, des délais appropriés entre les actions et une reproduction précise des comportements backend. Cela inclut votre CDN ; bien que l'inclusion de Fastly dans les tests de charge puisse sembler controversée, elle est essentielle car Fastly est un composant clé de l'environnement d'exécution.

Les tests qui omettent les importations d'API, le trafic des bots ou les processus de paiement simultanés peuvent ne pas révéler les goulots d'étranglement en matière d'évolutivité avant qu'ils ne se manifestent en production.

La discipline opérationnelle favorise la résilience

Les projets Shopware réussis se caractérisent par une discipline opérationnelle, notamment des pipelines CI/CD, des environnements de staging qui reflètent la production, une surveillance et des alertes, ainsi que des procédures de rollback bien testées.

Cela s'étend à la préparation des campagnes ; les pics de trafic sont traités comme des étapes techniques importantes. Les équipes hautement performantes répètent à l'avance les scénarios de trafic, préchauffent les caches, surveillent les métriques du système tout au long du processus et s'assurent que la restauration est prête.

Liste de contrôle de préparation avant le lancement

Avant la mise en ligne ou le lancement d'une campagne majeure, vérifiez les points suivants :

• [ ] Les listes de produits et de catégories sont paginées et optimisées pour des requêtes SQL efficaces.
• [ ] Les performances des plugins et des extensions ont été profilées ; les plugins inutiles sont désactivés.
• [ ] Les niveaux de journalisation sont correctement définis pour la production (pas de journaux de débogage sauf en cas de besoin temporaire)
• [ ] Les synchronisations ERP et externes sont regroupées et programmées en dehors des heures de pointe.
• [ ] Les invalidations de cache pilotées par API sont retardées, regroupées ou limitées (Shopware ≥ 6.7).
• [ ] Le préchauffage du cache est en place pour les pages d'atterrissage clés et les flux de navigation.
• [ ] Le cache HTTP fonctionne : les en-têtes X-Cache renvoient HIT pour les routes attendues.
• [ ] Le volume d'invalidations de cache par jour reste dans les limites prévues.
• [ ] La capacité de l'infrastructure a été dimensionnée pour une charge de pointe réaliste (l'utilisation du CPU reste inférieure à ~70 %)
• [ ] Des tests de charge ont été effectués à l'aide de combinaisons de trafic et de comportements de session réalistes.
• [ ] Les pipelines CI/CD ont été testés et produisent des builds déterministes.
• [ ] La surveillance et les alertes sont activées pour les métriques critiques pour les applications, le système et l'entreprise.
• [ ] Les journaux de déploiement sont examinés afin de détecter les exceptions non interceptées ou les hooks défaillants.
• [ ] La disponibilité et la latence des intégrations tierces sont surveillées.
• [ ] Les en-têtes de sécurité et l'application du protocole HTTPS sont testés.
• [ ] Les pages critiques pour le référencement sont indexables et performantes selon PageSpeed Insights.

Conclusion

Les résultats de nos tests et de notre expérience sur le terrain démontrent que Shopware peut fonctionner de manière exceptionnelle, mais uniquement lorsqu'il s'appuie sur des décisions infrastructurelles mûrement réfléchies, des modèles architecturaux bien pensés et des pratiques opérationnelles rigoureuses.

La leçon la plus constante : les performances de Shopware sont une responsabilité partagée et continue. Elles ne dépendent pas seulement de la taille de l'infrastructure ou du code de l'application, mais aussi de la manière dont un projet est configuré, étendu, observé et exploité.

Les déploiements dans le monde réel le prouvent. Un plugin de paiement mal configuré enregistrant au niveau du débogage dans un projet a généré un nombre excessif d'E/S disque, ralentissant considérablement le site. Un autre projet a connu des blocages réguliers en raison d'un module d'analyse émettant des requêtes SQL longues qui bloquaient la base de données. Un client a généré plus de 500 millions d'invalidations de cache par jour en raison de mises à jour ERP non groupées, ce qui a entraîné un cache perpétuellement froid.

En revanche, les projets qui ont atteint des temps de réponse stables et rapides partageaient certaines habitudes : ils utilisaient des outils tels que Blackfire pour localiser les goulots d'étranglement, recouraient à la purge différée ou douce pour gérer intelligemment l'invalidation du cache, et maintenaient une étroite coordination entre les mises à jour ERP et les stratégies de régénération du cache. Ils n'ont pas attendu que les performances se dégradent, ils les ont anticipées.

Ce que vous pouvez faire ensuite

• Revoir votre stratégie de mise en cache
• Auditez votre stack de plugins
• Validez la configuration
• Répliquez le trafic
• Standardisez le déploiement
• Utilisez des variables d'environnement pour la configuration
• Protégez votre infrastructure (renseignez-vous sur Fastly Next-Generation WAF)
• Centralisez vos journaux et auditez-les

L'excellence en matière de performances n'est pas réservée aux grandes équipes ou aux budgets d'entreprise ; elle résulte de l'application cohérente de principes d'ingénierie.

Outils et ressources recommandés

• Documentation Blackfire : https://docs.blackfire.io
• Intégration de Shopware PaaS Blackfire : https://developer.shopware.com/docs/products/paas/blackfire.html
• Grafana K6 (open source): https://k6.io
• Référentiel de scénarios Shopware K6 : https://github.com/shopware/k6-shopware
• Crawlee (pour le préchauffage du cache) : https://crawlee.dev
• Réglage du runtime PHP-FPM (Upsun) : https://fixed.docs.upsun.com/languages/php/fpm.html