Nous avons effectué des tests de charge réels sur sept plans d'infrastructure différents, de Grid à Dedicated Split, en utilisant des taux de conversion réalistes, des mélanges de trafic de robots et des importations d'API pilotées par ERP. Les résultats étaient clairs : les performances évoluent de manière prévisible avec les ressources, mais uniquement si votre code, votre cache et votre configuration suivent le rythme. Cet article de blog présente les principaux résultats, explique pourquoi la charge des API est disproportionnellement coûteuse et indique les indicateurs les plus importants.
Quelles sont les performances réelles de Shopware sous charge ? Cette question revient souvent, en particulier lorsque les équipes évaluent une nouvelle infrastructure ou se préparent à des pics de trafic. Nous avons donc décidé de le tester nous-mêmes.
Nous avons effectué des tests de charge structurés, de type production, sur sept plans d'infrastructure PaaS Shopware différents, allant des configurations Grid d'entrée de gamme aux clusters Dedicated Split à haute capacité. L'objectif n'était pas de casser le système, mais de simuler une utilisation réelle du commerce électronique sous pression : navigation, achats et automatisation backend, le tout avec des taux de conversion et un comportement de mise en cache réalistes. Voici ce que nous avons découvert.
Le trafic réel est plus complexe que vous ne le pensez
De nombreux tests de performance s'appuient sur des scénarios synthétiques, c'est-à-dire des points d'extrémité uniques soumis à des taux fixes. Ce n'est pas ainsi que se comportent les vitrines réelles. Notre plan de test comprenait :
- Navigation anonyme (page d'accueil, catégories, recherche)
- Nouveaux parcours clients (navigation, inscription, paiement)
- Achats de clients réguliers (connexion et achat rapide)
- Importations de produits via API (simulation ERP)
Nous avons également introduit des taux de conversion réalistes (~3 %), des ratios bot/utilisateur et un comportement de mise en cache. Les caches ont été préchauffés à l'aide de robots d'indexation automatisés afin de refléter les déploiements réels.
Principales conclusions des tests de charge
1. Shopware s'adapte de manière prévisible aux ressources
À mesure que les plans d'infrastructure augmentaient en termes de CPU et de mémoire, Shopware traitait davantage de trafic simultané tout en conservant des temps de réponse faibles. Même les plans modestes ont bien fonctionné dans des conditions optimisées. Par exemple, un Dedicated Grid Host (DGH32) a traité plus de 7 000 commandes par jour avec un TTFB p95 inférieur à une seconde.
2.L'API est un facteur de coût caché
Le trafic API (tel que les mises à jour de produits ou les synchronisations ERP) a généré une part disproportionnée de la charge backend. Même s'il ne représentait que 5 à 10 % du trafic total, les requêtes API étaient responsables des invalidations de cache et des pics d'utilisation du CPU.
3.La stratégie de mise en cache est déterminante pour les performances
Les plans avec des caches Fastly préchauffés ont maintenu des temps de réponse constants. Ceux qui ont été testés sans amorçage correct du cache ont montré une latence importante. La fragmentation du cache et les points de terminaison mal structurés ont entraîné des réponses MISS, ce qui a immédiatement dégradé le débit.
4. L'infrastructure n'est pas le goulot d'étranglement
Dans presque tous les cas où les performances ont baissé, le problème provenait du code, de la configuration ou de l'invalidation du cache, et non de la plateforme sous-jacente. Par exemple, un plugin laissé en mode débogage a introduit un conflit d'E/S disque qui a ralenti les pages.
Remarque sur la méthodologie
Nous avons utilisé Grafana K6 pour simuler le trafic et avons suivi des métriques telles que :
- p95 TTFB (temps jusqu'au premier octet)
- Pic de requêtes par seconde (RPS)
- Saturation du processeur
- Taux d'erreur
- Commandes/heure et commandes/jour
Chaque test a duré 5 minutes dans des environnements isolés et propres. La logique de conversion et la régulation du trafic ont été appliquées afin de refléter le plus fidèlement possible le comportement réel d'une boutique en ligne.
