Optimisation des performances
Cette section fournit des recommandations techniques pour la préparation des environnements Adobe Commerce (Commerce sur infrastructure cloud et sur site) pour les événements à trafic élevé tels que la saison des fêtes.
Optimisation de la mise en cache des requêtes Fastly (cloud uniquement) optimize-fastly-request-caching
Fastly met en cache les réponses à la périphérie pour réduire la charge sur votre serveur d’origine. Pendant la haute saison, quelques vérifications de configuration vous aident à tirer le meilleur parti de ce cache, en particulier lorsque vous exécutez des promotions avec des paramètres de suivi ou un storefront découplé. Pour consulter la référence complète de la configuration, voir Personnaliser la configuration du cache .
- Normaliser les paramètres de tracking : pendant la saison des fêtes, vous exécuterez probablement des campagnes sociales et payantes, telles que Google Ads, Facebook et X, qui ajoutent des chaînes de tracking uniques à chaque URL. Chaque chaîne unique crée une entrée de cache distincte pour ce qui est autrement la même page, ce qui réduit votre taux d’accès au cache. Ajoutez ces paramètres à la liste Paramètres d’URL ignorés dans la configuration Fastly de l’administration Adobe Commerce afin que Fastly les traite comme équivalents.
- Vérifiez que vos pages de destination peuvent être mises en cache : vérifiez l’en-tête de réponse
x-cachesur chaque page de destination de promotion. Une page pouvant être mise en cache renvoie uneHITou une paireHIT/MISSlors des chargements suivants. Si l’en-tête renvoieMISS, MISS, la page ne se met pas en cache et nécessite une enquête. - Utiliser des requêtes GET pour les requêtes GraphQL : si vous exécutez un storefront PWA ou découplé, envoyez des requêtes GraphQL en tant que requêtes
GETavec la requête incluse dans l’URL, plutôt qu’en tant que requêtesPOST. Fastly ne met en cache queGETrequêtes dans lesquelles la requête fait partie de l’URL. Une requêteGETavec la requête envoyée dans le corps n’est pas mise en cache.
Activer Fastly IO (cloud uniquement) enable-fastly-io
Fastly’E/S décharge le redimensionnement des images et la conversion des formats sur le réseau Edge de Fastly plutôt que sur l’origine Adobe Commerce. Cela réduit la charge du serveur et améliore la vitesse de rendu des pages pour les storefronts riches en images, un goulot d’étranglement courant pendant les périodes de vente à trafic élevé. Pour connaître les options de configuration, voir Optimisation rapide des images.
Avant de commencer, vérifiez que le blindage d’origine est configuré. Fastly Les E/S nécessitent au préalable un blindage d’origine. Pour plus d’informations sur la configuration, voir Fastly origin shielding.
Pour activer les E/S Fastly :
- Dans Admin, accédez à la page Configuration Fastly et sélectionnez Configurer en regard de Options de configuration d’E/S par défaut.
- Vérifiez que le fragment de code d’E/S Fastly est activé.
- Dans la configuration Optimisation des images, définissez Activer l’optimisation d’image profonde sur Oui. Ce paramètre désactive le redimensionnement d’image intégré d’Adobe Commerce et transfère la tâche vers Fastly.
- Vérifiez que l’emplacement du bouclier est correctement défini. Pour plus d’informations sur la configuration, voir Fastly origin shielding.
Pour vérifier que Fastly E/S fonctionne, vérifiez les en-têtes de réponse sur une demande d’image de produit :
- L’en-tête
x-cacherenvoieHIT. - Les en-têtes
fastly-io-infoetfastly-statssont renseignés. - L’URL de l’image n’inclut pas de répertoire
/cache/dans le chemin d’accès.
Implémentation du cache L2 Redis implement-redis-l2-cache
Implémentez des pratiques de mise en cache efficaces afin que votre boutique fonctionne de manière fiable pendant les saisons de trafic élevé. Redis Le cache L2 réduit la bande passante du réseau à Redis en stockant les données de cache localement sur chaque nœud web. Pour en savoir plus sur le fonctionnement du cache L2, consultez Cache de niveau 2.
Sur Commerce sur les infrastructures cloud, activez cette option en définissant la variable de déploiement REDIS_BACKEND . Pour connaître les étapes de configuration, consultez REDIS_BACKEND dans le guide Commerce sur les infrastructures cloud. Sur site, configurez-le directement dans app/etc/env.php.
VALKEY_BACKEND.Activer les connexions esclaves MySQL et Redis (Cloud uniquement) enable-mysql-and-redis-slave-connections
Les connexions esclaves Redis et MySQL déchargent le trafic de lecture vers les nœuds de réplication, ce qui réduit la charge sur la connexion maître pendant les périodes de trafic élevé. Pour les étapes de configuration, voir MYSQL_USE_SLAVE_CONNECTION et REDIS_USE_SLAVE_CONNECTION ou VALKEY_USE_SLAVE_CONNECTION, selon votre version d’Adobe Commerce.
Redis les connexions esclaves
Une connexion esclave Redis est une connexion en lecture seule à une instance Redis, ce qui permet au trafic de lecture d’être diffusé à partir d’un nœud non maître. Si elle n’est pas activée, MySQL pouvez rencontrer un goulot d’étranglement à forte charge. Vérifiez le graphique APM Overview de New Relic pour identifier les temps de réponse croissants comme signe précoce, puis confirmez dans l’onglet Base de données en triant par transaction la plus longue pour identifier les requêtes de SELECT de MySQL lentes. Activez cette option en définissant la variable de déploiement REDIS_USE_SLAVE_CONNECTION sur true.
REDIS_USE_SLAVE_CONNECTION est pris en charge uniquement dans les environnements de cluster Staging et Production Pro. Il n’est pas pris en charge sur les projets d’architecture de démarrage ou de mise à l’échelle (partage). Son activation sur une architecture mise à l’échelle entraîne des erreurs de connexion Redis ; utilisez Redis cache L2 à la place sur cette architecture. Voir la section Implémentation du cache Redis L2 ci-dessus.Connexions esclaves MySQL
Activez l’indicateur MYSQL_USE_SLAVE_CONNECTION sur les environnements de cluster Pro pour diriger des requêtes de base de données spécifiques en lecture seule vers une connexion esclave, déchargeant l’exécution des requêtes de la connexion maître.
Activer le traitement asynchrone des commandes et des e-mails enable-asynchronous-order-and-email-processing
Utilisez le traitement asynchrone pour mettre en file d’attente et exécuter des opérations liées aux commandes de gros volumes en arrière-plan, ce qui réduit la latence frontale pendant le trafic de pointe. Cela couvre trois paramètres associés mais distincts. Pour une présentation, reportez-vous à la section Bonnes pratiques de configuration .
-
Passation de commande asynchrone : le module de commande asynchrone marque une commande comme reçue, la place dans une file d’attente et traite les commandes premier entré, premier sorti. Cette fonctionnalité est désactivée par défaut. Activez-la à partir de la ligne de commande :
code language-none bin/magento setup:config:set --checkout-async 1Une fois activée, les détails de la commande ne sont pas disponibles immédiatement. La commande reste en file d’attente jusqu’à ce que le client
placeOrderProcessla vérifie par rapport à l’inventaire (activé par défaut) et la mette à jour. Avant de désactiver ce module, vérifiez que le traitement de toutes les commandes asynchrones en cours est terminé. Pour plus d’informations, consultez Bonnes pratiques relatives aux performances de passage en caisse. -
Traitement asynchrone des données de commande : les ventes de storefront intensives et le traitement intensif des commandes peuvent créer des conflits au niveau de la base de données. L’activation de ce paramètre permet de distinguer les deux modèles de trafic, de sorte que les commandes soient placées en stockage temporaire et déplacées en bloc vers la grille Order Management sans conflits. Cette planification met à jour, par cron, les grilles Commandes, Factures, Livraisons et Avoirs, évitant ainsi les blocages et réduisant le temps de traitement. Pour de meilleurs résultats, configurez cron pour qu’il s’exécute une fois par minute.
note NOTE La méthode d’activation dépend de votre mode de déploiement. Par défaut, les environnements d’évaluation et de production d’Adobe Commerce sur les infrastructures cloud s’exécutent en mode Production, où ce paramètre n’est pas disponible via l’administration. En mode Production, exécutez bin/magento config:set dev/grid/async_indexing 1à la place. En mode par défaut, accédez à Magasins > Configuration > Avancé > Développeur > Paramètres de grille et définissez Indexation asynchrone sur Activer.Pour plus de détails, voir Opérations de commande planifiées.
-
Notifications par e-mail asynchrones : ce paramètre déplace les notifications par e-mail de passage en caisse et de traitement de commande vers l’arrière-plan. Activez-le à l’adresse Magasins > Configuration > Ventes > E-mails commerciaux > Paramètres généraux > Envoi asynchrone.
Configuration des indexeurs pour une mise à jour selon le calendrier configure-indexers-for-update-on-schedule
Définissez les indexeurs pour qu’ils s’exécutent en mode planifié afin d’éviter le verrouillage de la base de données et d’améliorer la réactivité lors des mises à jour fréquentes des catalogues. Pour plus d’informations, consultez Bonnes pratiques relatives à la configuration de l’indexeur.
Un indexeur peut s’exécuter en mode Mise à jour lors de l’enregistrement ou Mise à jour selon le calendrier.
- Mise à jour lors de l’enregistrement indexe immédiatement chaque fois que le catalogue ou d’autres données sont modifiés. Elle suppose une faible intensité de mise à jour et de navigation, et peut entraîner des retards importants et une indisponibilité des données sous une charge élevée.
- Mise à jour selon le calendrier est recommandé pour la production. Il stocke des informations sur les mises à jour de données et les réindexations en arrière-plan via une tâche cron dédiée.
Définissez le mode de mise à jour de chaque indexeur indépendamment à l’adresse Système > Outils > Gestion des index.
customer_grid dépendent de votre version d’Adobe Commerce. Dans les versions antérieures à la version 2.4.8, la grille client prend uniquement en charge Mise à jour lors de l’enregistrement—ne la définissez pas sur Mise à jour selon le calendrier. Dans Adobe Commerce 2.4.8 et les versions ultérieures, la grille cliente prend en charge les deux modes et utilise désormais par défaut Mise à jour selon le calendrier.Désactiver et évaluer la table plate du catalogue disable-and-evaluate-catalog-flat-table
L’utilisation de tables plates pour les produits et les catégories n’est pas recommandée. Cette fonctionnalité obsolète peut entraîner une dégradation des performances et des problèmes d’indexation. Pour plus d’informations, consultez la section Catalogues plats.
Pour désactiver le catalogue plat, accédez à Magasins > Configuration > Catalogue > Catalogue > Storefront, définissez Utiliser la catégorie de catalogue plat à No, définissez Utiliser le produit de catalogue plat à No, puis cliquez sur Enregistrer la configuration.
Certains modules tiers et certaines personnalisations nécessitent des tableaux plats pour fonctionner correctement. Évaluez l’impact et le risque de continuer à utiliser ces extensions avant de désactiver les tables plates.
Étudier l’architecture mise à l’échelle (partage) (cloud uniquement) consider-scaled-split-architecture
Si, après l’application de la configuration et des optimisations au niveau du code précédentes, les tests de charge ou les performances de l’infrastructure en direct montrent toujours que CPU et d’autres ressources sont à leur maximum, envisagez de passer à une architecture à l’échelle (partagée). Pour plus d’informations, consultez Architecture mise à l’échelle.
L’architecture à niveaux partagés utilise au moins six nœuds : trois nœuds de service exécutant OpenSearch ou Elasticsearch, MariaDB et Redis ou Valkey, et trois nœuds web exécutant php-fpm et NGINX.
- Les nœuds de service ne peuvent être dimensionnés que verticalement, en augmentant la taille du serveur (CPU et mémoire). Le cluster de base de données étant conçu pour offrir une haute disponibilité, les nœuds de service ne peuvent pas être dimensionnés horizontalement de manière fiable.
- Les nœuds web peuvent être mis à l’échelle verticalement et horizontalement, ajoutant ainsi des serveurs web pour gérer l’augmentation du volume de requêtes.
Vous pouvez ainsi étendre l’infrastructure à la demande pendant les périodes de forte charge, en dimensionnant chaque niveau indépendamment. Pour passer à une architecture à plusieurs niveaux avant une période de charge importante, contactez l’équipe chargée de votre compte Adobe.