Ce qu'on a appris en testant la résistance de Shopware à grande échelle

On a réalisé des tests de charge en conditions réelles sur sept plans d’infrastructure différents — de « Grid » à « Dedicated Split » — en utilisant des taux de conversion réalistes, des mélanges de trafic généré par des bots et des importations d’API pilotées par un ERP. Les conclusions sont claires : les performances évoluent de manière prévisible en fonction des ressources, mais seulement si ton code, ton cache et ta configuration suivent le rythme. Cet article de blog passe en revue les principaux résultats, explique pourquoi la charge des API est disproportionnellement coûteuse et indique quelles sont les métriques les plus importantes.

Quelles sont les performances réelles de Shopware sous charge ? Cette question revient souvent, surtout lorsque les équipes évaluent une nouvelle infrastructure ou se préparent à des pics de trafic. On a donc décidé de le tester nous-mêmes.

On a mené des tests de charge structurés, similaires à ceux en 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 faire planter le système, mais de simuler une utilisation réelle du e-commerce sous pression : navigation, achats et automatisation du backend, le tout avec des taux de conversion et un comportement de mise en cache réalistes. Voici ce qu’on a découvert.

Le trafic réel est plus complexe que tu ne le penses

De nombreux tests de performance s’appuient sur des scénarios synthétiques, c’est-à-dire des points de terminaison uniques sollicités à des cadences fixes. Ce n’est pas ainsi que se comportent les vraies boutiques en ligne. Notre plan de test comprenait :

• La navigation anonyme (page d’accueil, catégories, recherche)
• Parcours de nouveaux clients (navigation, inscription, paiement)
• Achats de clients fidèles (connexion et achat rapide)
• Importations de produits via API (simulation ERP)

On a aussi intégré des taux de conversion réalistes (~3 %), des ratios bots/utilisateurs et un comportement de mise en cache. Les caches ont été préchauffés à l’aide de robots d’exploration automatisés pour reproduire les déploiements réels.

Principales conclusions des tests de charge

1. Shopware évolue de manière prévisible en fonction des ressources

À mesure que les plans d’infrastructure augmentaient en termes de CPU et de mémoire, Shopware gérait davantage de trafic simultané tout en conservant des temps de réponse faibles. Même les plans les plus modestes ont bien fonctionné dans des conditions optimisées. Par exemple, un hôte dédié en grille (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 (comme les mises à jour de produits ou les synchronisations ERP) a généré une part disproportionnée de la charge du backend. Même s’il ne représentait que 5 à 10 % du trafic total, les requêtes API étaient à l’origine d’invalidations de cache et de pics d’utilisation du processeur.

3. La stratégie de mise en cache est déterminante pour les performances

Les formules avec des caches Fastly préchauffés ont permis de maintenir des temps de réponse constants. Celles testées sans amorçage correct du cache ont montré une latence importante. La fragmentation du cache et des 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 chuté, le problème venait du code, de la configuration ou de l’invalidation du cache — pas de la plateforme sous-jacente. Par exemple, un plugin resté en mode débogage a provoqué une contention d’E/S disque qui a ralenti les pages au point de les rendre presque inutilisables.

Remarque sur la méthodologie

On a utilisé Grafana K6 pour simuler le trafic et on a suivi des indicateurs tels que :

• TTFB p95 (temps jusqu’au premier octet)
• Nombre maximal de requêtes par seconde (RPS)
• Saturation du processeur
• Taux d'erreur
• Commandes par heure et commandes par jour

Chaque test a duré 5 minutes dans des environnements isolés et propres. Une logique de conversion et une régulation du trafic ont été mises en place pour reproduire le plus fidèlement possible le comportement réel d’une boutique en ligne.

Télécharge le guide de performances avec les résultats de la campagne de tests de charge rigoureux effectués sur Shopware PaaS, une plateforme e-commerce gérée, construite sur Upsun Cloud et spécialement conçue pour faire tourner Shopware à grande échelle.