Test de charge de votre plateforme de commerce électronique : préparation au trafic du Black Friday

Shopify a rapporté que les commerçants ont réalisé collectivement 9,3 milliards de dollars de ventes pendant le Black Friday/Cyber ​​Monday 2024 – et chaque minute d'arrêt pendant ces 96 heures coûte des milliers de dollars en perte de revenus. Les tests de charge font la différence entre une plate-forme qui évolue gracieusement pendant les pics de trafic et une plate-forme qui plante au pire moment possible. Pourtant, la plupart des entreprises découvrent le point de rupture de leur plateforme lors de l'événement lui-même plutôt que lors des tests.

Points clés à retenir

• Test de charge avec des modèles de trafic réalistes, pas seulement un nombre brut de requêtes - modélisez les parcours réels des utilisateurs, depuis la navigation jusqu'à la caisse.
• Commencez les tests de charge 8 à 12 semaines avant les événements de pointe afin de laisser du temps pour les modifications de l'infrastructure et l'optimisation du code.
• Identifier progressivement les goulots d'étranglement : passer de la ligne de base au pic 2x attendu, en testant chaque couche indépendamment
• L'analyse post-test est aussi importante que le test lui-même : corrélez les temps de réponse avec les métriques de l'infrastructure pour trouver la véritable contrainte.

---

Comparaison des outils de test de charge

Le choix du bon outil de test de charge dépend des compétences techniques, de l'infrastructure et des exigences de test de votre équipe.

k6 : recommandé pour la plupart des équipes

k6 est notre outil recommandé pour la plupart des tests de charge du commerce électronique. Il utilise JavaScript pour les scripts de test, s'intègre aux pipelines CI/CD et produit des métriques détaillées, notamment les centiles de temps de réponse, le débit et les taux d'erreur. Il s'exécute localement ou dans le cloud, et sa sortie s'intègre aux tableaux de bord Grafana pour une surveillance en temps réel.

Les tests k6 définissent des utilisateurs virtuels (VU) qui exécutent des scénarios : des séquences de requêtes HTTP qui simulent le comportement de l'utilisateur. Chaque VU conserve son propre état de session (cookies, en-têtes), permettant des flux de travail authentifiés réalistes.

Artillerie : idéale pour une configuration rapide

Artillery utilise une configuration basée sur YAML pour les scénarios courants et prend en charge JavaScript pour la logique complexe. Il excelle dans les tests de charge à démarrage rapide où vous avez besoin de résultats en quelques minutes plutôt qu'en heures de script. Il prend également en charge nativement les tests Socket.io et WebSocket.

---

Modélisation de modèles de trafic réalistes

La plus grosse erreur des tests de charge est d’envoyer un trafic uniforme qui ne correspond pas au comportement réel des utilisateurs. Le trafic réel présente des modèles spécifiques qui exposent différents goulots d'étranglement.

Modélisation du parcours utilisateur

Un test de charge de commerce électronique doit modéliser des parcours utilisateur complets, et pas seulement des accès individuels aux points de terminaison. Un test réaliste inclut les types d'utilisateurs suivants avec des ratios appropriés :

Modèles de rampe de circulation

Ne passez pas directement à la charge de pointe. Ramenez progressivement pour identifier les points de rupture.

Modèle de montée en puissance pour les tests du Black Friday :

1. ** Base de référence (0 - 10 minutes) ** – commencez par un trafic quotidien normal pour établir une référence de performances. 2. Rampe jusqu'au pic prévu (10-30 minutes) -- augmenter progressivement jusqu'au trafic prévu du Black Friday 3. ** Maintenir le pic (30 à 60 minutes) ** : maintenez la charge maximale pour tester les performances soutenues et les fuites de ressources. 4. Test de pic (60 à 70 minutes) – simule le début d'une vente flash avec un pic de trafic multiplié par 3 à 5 sur 30 secondes 5. Récupération (70-80 minutes) -- revenez à la charge normale et vérifiez que le système récupère sans intervention manuelle 6. Test d'immersion (exécution séparée, 4 à 8 heures) - charge modérée soutenue pour détecter les fuites de mémoire et l'épuisement du pool de connexions

Pensez au temps et au rythme

Les vrais utilisateurs ne lancent pas de requêtes aussi rapidement que possible. Ils lisent le contenu, comparent les produits et remplissent des formulaires. Incluez des temps de réflexion réalistes entre les demandes :

• Entre les pages vues : 5 à 30 secondes
• Remplir le formulaire de paiement : 30 à 120 secondes
• Lecture des descriptions de produits : 10 à 60 secondes
• Recherche et filtrage : 3 à 10 secondes entre les actions

Sans temps de réflexion, votre test génère une charge concentrée de manière irréaliste qui ne correspond pas aux modèles de trafic de production.

---

Identification des goulots d'étranglement

Les tests de charge révèlent des goulots d'étranglement, mais vous devez savoir où chercher. Surveillez les métriques de l’infrastructure ainsi que les résultats des tests pour corréler la dégradation des temps de réponse avec l’épuisement des ressources.

Goulots d'étranglement dans la base de données

Symptômes : Les temps de réponse augmentent linéairement avec la charge, le processeur de la base de données est à plus de 90 % et le journal des requêtes lent se remplit rapidement.

Causes courantes :

• Index manquants sur les colonnes fréquemment interrogées
• Requêtes N+1 qui se multiplient avec les utilisateurs simultanés
• Verrouiller les conflits sur les mises à jour d'inventaire lors du paiement
• Épuisement du pool de connexions (toutes les connexions utilisées, file d'attente des nouvelles requêtes)

Diagnostic : Surveillez pg_stat_activity pour les requêtes actives, pg_stat_user_tables pour le nombre d'analyses séquentielles et les métriques du pool de connexions. Consultez notre guide détaillé sur l'optimisation des requêtes de base de données.

Goulots d'étranglement du serveur d'applications

Symptômes : Le processeur atteint 100 %, le décalage des boucles d'événements augmente (Node.js), les pauses du garbage collection provoquent des pics de latence.

Causes courantes :

• Opérations synchrones bloquant la boucle événementielle (traitement d'image, génération PDF)
• Des fuites de mémoire provoquant un garbage collection de plus en plus fréquent
• Processus de travail insuffisants pour les opérations liées au processeur
• Mise en cache manquante pour les calculs coûteux

Diagnostic : Surveillez les métriques du processeur, de la mémoire, du décalage des boucles d'événements et du garbage collection par instance d'application.

Goulots d'étranglement du réseau et de l'infrastructure

Symptômes : Saturation de la bande passante, délais d'attente de connexion, retards de négociation SSL sous charge

Causes courantes :

• Réponses non compressées consommant de la bande passante
• Actifs statiques servis depuis le serveur d'applications au lieu du CDN
• Terminaison SSL/TLS sur le serveur d'applications au lieu de l'équilibreur de charge
• Bande passante réseau insuffisante pour le type d'instance de serveur

---

Planification des capacités

Les tests de charge alimentent la planification de la capacité, en déterminant la quantité d'infrastructure dont vous avez besoin pour les événements de pointe.

La formule de planification des capacités

1. Déterminez les prévisions de trafic de pointe – utilisez les données de l'année dernière ainsi que les projections de croissance. S'il s'agit de votre première vente importante, estimez-la en fonction de la portée marketing et des références du secteur. 2. Ajoutez une marge de sécurité – prévoyez un pic 2 à 3 fois plus attendu pour gérer le trafic viral inattendu
2. Exécutez un test de charge à la capacité cible : vérifiez que votre infrastructure gère 2 à 3 fois les pics avec des temps de réponse acceptables.
3. Calculer le coût : déterminez le coût de l'infrastructure pour la capacité de pointe et décidez si la mise à l'échelle automatique ou le pré-provisionnement est plus rentable.

Liste de contrôle préalable à la mise à l'échelle

Commencez à vous préparer 8 à 12 semaines avant l’événement :

Mise à l'échelle automatique et pré-provisionnement

La mise à l'échelle automatique ajuste la capacité en fonction des mesures de la demande, mais prend 3 à 10 minutes pour ajouter de nouvelles instances. En cas de pics de trafic soudains (début de vente flash, publication virale sur les réseaux sociaux), le pré-approvisionnement évite les retards.

Approche recommandée : Pré-provisionner pour gérer les pics attendus, configurer la mise à l'échelle automatique pour les surtensions inattendues au-delà de la capacité pré-provisionnée.

---

Analyse post-test

Le test de charge lui-même ne représente que la moitié de la valeur. L'analyse post-test transforme les données brutes en priorités d'optimisation exploitables.

Indicateurs clés à analyser

Créer un plan d'action

Hiérarchisez les résultats par impact commercial :

1. Erreurs au pic -- toute requête qui renvoie 5xx sous charge doit être corrigée. Ce sont des ventes perdues.
2. Performances de paiement : si les temps de réponse de paiement dépassent 2 secondes, optimisez d'abord ce chemin. Un paiement lent a un impact direct sur la conversion.
3. Performances de recherche et de navigation : la lenteur de la découverte des produits réduit les articles consultés et la taille des paniers.
4. Administrateur et back-office : ils peuvent se dégrader pendant les périodes de pointe sans impact sur les revenus. Déprioriser si nécessaire.

---

Questions fréquemment posées

Comment tester en charge une boutique Shopify si je ne contrôle pas l'infrastructure ?

Concentrez-vous sur ce que vous contrôlez : votre code de thème personnalisé, les applications tierces et les intégrations externes. Utilisez des outils tels que Lighthouse CI pour les tests de performances front-end. Testez vos points de terminaison de traitement de webhook et vos API de synchronisation d'inventaire sous charge. Pour les marchands Shopify Plus, travaillez avec l'équipe de réussite des marchands de Shopify pour examiner la capacité de votre magasin spécifique.

Quelle est la différence entre les tests de charge et les tests de contrainte ?

Les tests de charge valident que votre système gère le trafic de pointe attendu avec des performances acceptables. Les tests de résistance vont au-delà des limites attendues pour trouver le point de rupture et vérifier la dégradation progressive. Test de charge pour se préparer aux événements connus ; test de résistance pour découvrir des limites inconnues et garantir que le système tombe en panne en toute sécurité plutôt que de manière catastrophique.

Dois-je charger les tests en production ou en staging ?

Testez dans un environnement qui reflète le plus fidèlement possible la production. Les environnements de test disposent souvent de bases de données plus petites, de moins de serveurs et de configurations réseau différentes. Si possible, exécutez des tests de charge sur l’infrastructure de production pendant les heures de faible trafic. Au minimum, utilisez des données de taille production dans votre base de données intermédiaire.

Comment simuler un traitement de paiement réaliste dans des tests de charge ?

Utilisez les modes sandbox/test du fournisseur de paiement qui acceptent les numéros de carte de test. Stripe, PayPal et d'autres fournisseurs proposent des environnements de test qui traitent les transactions sans facturer de vraies cartes. Testez le flux de paiement complet, y compris les appels d'API de paiement, pour identifier les goulots d'étranglement de l'intégration. Surveillez les limites de taux des fournisseurs de paiement : certains fournisseurs limitent les demandes du bac à sable différemment de la production.

À quelle fréquence dois-je exécuter des tests de charge ?

Exécutez des tests de charge complets avant tout événement majeur de trafic (Black Friday, lancements de produits, campagnes marketing). Exécutez des tests de charge automatisés plus petits chaque semaine ou après des modifications importantes du code dans le cadre de CI/CD. Incluez les tests de charge dans votre liste de contrôle de déploiement pour les modifications qui affectent les points de terminaison à fort trafic.

---

Quelle est la prochaine étape

Commencez par un test de charge de base par rapport à vos modèles de trafic de production actuels. Identifiez vos trois principaux goulots d'étranglement et optimisez-les avant d'exécuter le prochain test. Répétez ce cycle jusqu'à ce que votre plate-forme gère confortablement 2 à 3 fois le trafic de pointe prévu avec des temps de réponse inférieurs à 500 ms.

Pour un contexte plus large d'ingénierie des performances, consultez notre guide des piliers sur la mise à l'échelle de votre plateforme d'entreprise. Pour optimiser l'infrastructure sur laquelle vos tests de charge mettent l'accent, lisez notre guide sur la mise à l'échelle de l'infrastructure et l'équilibrage de charge.

ECOSIRE fournit des tests de charge et une optimisation des performances pour les plateformes de commerce électronique sur Shopify et Odoo. Contactez notre équipe pour la préparation de la performance avant l'événement.

---

Publié par ECOSIRE — aider les entreprises à évoluer grâce à des solutions basées sur l'IA dans Odoo ERP, Shopify eCommerce et OpenClaw AI.