Configuration du cache L2 pour l’optimisation des performances
La mise en cache L2 (à deux niveaux) réduit le trafic réseau entre le stockage de cache distant (Redis ou Valkey) et l’application Commerce en ajoutant une couche de cache locale sur chaque nœud web. Une instance Commerce standard transfère environ 300 Ko par requête et le trafic peut rapidement passer à plus de 1 000 requêtes dans certains cas.
Avec la mise en cache L2, chaque nœud web stocke localement les données fréquemment consultées et utilise le cache distant à deux fins :
- Vérification de la version des données du cache pour s’assurer que le dernier cache est stocké localement
- Transfert des données de cache mises à jour du magasin distant vers l’ordinateur local
Commerce stocke la version des données hachées dans le cache distant, avec le suffixe :hash ajouté à la clé normale. Lorsque le cache local est obsolète, les données sont extraites de l’ordinateur distant via un adaptateur de cache.
Deux implémentations du cache L2 sont disponibles :
Cm_Cache_Backend_File pour le stockage localConfiguration de cache L2 héritée (RemoteSynchronizedCache)
Les instructions de configuration du cache dépendent de votre type de déploiement :
-
Pour Adobe Commerce on Cloud, configurez le cache L2 en définissant la variable de déploiement
REDIS_BACKENDouVALKEY_BACKENDdans.magento.env.yaml. Consultez Configuration du cache L2 pour obtenir des exemples de configuration. -
Pour les versions sur site d’Adobe Commerce qui prennent en charge Redis, utilisez l’exemple suivant pour modifier ou remplacer la section de cache existante dans le fichier
app/etc/env.php.
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
],
'frontend_options' => [
'write_control' => false,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
],
]
Où :
-
backendest l’implémentation du cache L2. -
backend_optionsest la configuration du cache L2.remote_backendest l’implémentation du cache distant : Redis ou MySQL.remote_backend_optionsest la configuration du cache distant.local_backendmise en œuvre du cache local :Cm_Cache_Backend_Filelocal_backend_optionsest la configuration du cache local.cache_direst une option spécifique au cache de fichiers pour le répertoire dans lequel le cache local est stocké.
Pour Adobe Commerce, Adobe recommande d’utiliser Redis pour la mise en cache à distance (\Magento\Framework\Cache\Backend\Redis) et Cm_Cache_Backend_File pour la mise en cache locale des données en mémoire partagée, en utilisant : 'local_backend_options' => ['cache_dir' => '/dev/shm/']
Adobe recommande l’utilisation de la fonction cache preload, car elle réduit considérablement la pression sur Redis. N’oubliez pas d’ajouter le suffixe ‘:hash’ pour les clés de préchargement.
Options de cache obsolètes
À partir de Commerce 2.4, l’option use_stale_cache peut améliorer les performances dans des cas spécifiques en diffusant des données précédemment mises en cache pendant que de nouvelles données de mise en cache sont générées dans un processus parallèle.
En règle générale, le compromis avec l’attente du verrou est acceptable du point de vue du rendement. Cependant, à mesure que le nombre de blocs ou d’entrées de cache augmente, les attentes de verrouillage prennent plus de temps. Dans certains scénarios, l’attente peut atteindre le nombre de clés x délai de recherche pour le processus. Dans de rares cas, un commerçant peut avoir des centaines de clés dans le cache Block/Config, de sorte que même un petit délai de recherche pour un verrou peut coûter des secondes.
'use_stale_cache' => true à la configuration de niveau supérieur du cache L2 frontal.Adobe recommande de n’activer l’option use_stale_cache que pour les types de cache qui en bénéficient le plus, notamment :
block_htmlconfig_integration_apiconfig_integrationfull_pagelayoutreflectiontranslate
Adobe déconseille d’activer l’option use_stale_cache pour le type de cache default.
Le code suivant illustre un exemple de configuration :
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
]
],
'frontend_options' => [
'write_control' => false,
],
],
'stale_cache_enabled' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'remote_backend_options' => [
'persistent' => 0,
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'compress_data' => '1',
],
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/'
],
'use_stale_cache' => true,
],
'frontend_options' => [
'write_control' => false,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
'layout' => ['frontend' => 'stale_cache_enabled'],
'block_html' => ['frontend' => 'stale_cache_enabled'],
'reflection' => ['frontend' => 'stale_cache_enabled'],
'config_integration' => ['frontend' => 'stale_cache_enabled'],
'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
'full_page' => ['frontend' => 'stale_cache_enabled'],
'translate' => ['frontend' => 'stale_cache_enabled']
],
],
Implémentation du cache moderne Symfony L2
Dans les versions 2.4.9 et ultérieures de Commerce, utilisez l’implémentation du cache L2 basée sur le cache Symfony (serveur principal symfony_l2) au lieu de l’ancien cache L2. Le cache Symfony L2 offre une mise en cache moderne conforme à la norme PSR-6, avec des performances nettement supérieures à celles de la RemoteSynchronizedCache traditionnelle.
symfony_l2. Pour Commerce On-Premise, voir Configuration de Valkey. Pour Commerce on Cloud, voir Configuration de Valkeysymfony_l2. Si vous utilisez une version prenant en charge symfony_l2, vous devez utiliser Valkey pour la mise en cache. Consultez Configuration requise pourAvantages du cache Symfony L2
- Architecture moderne : repose sur les composants de cache Symfony (compatible avec PSR-6)
- Meilleures performances : prise en charge native de la sérialisation Igbinary, de la compression gzip et des scripts Lua
- Connexions persistantes : réduit la surcharge de connexion Valkey avec le pool de connexions
- Clés de préchargement : prend en charge le préchargement des clés de cache pour les données critiques
- Prise en charge du cache obsolète : compatibilité totale avec l’option
use_stale_cache - Configuration simplifiée : noms des types de serveur principal plus propres (
valkey,file)
Exemple de configuration avec le cache Symfony L2
ece-tools) gère automatiquement la configuration du cache. Ne modifiez pas directement les app/etc/env.php : le déploiement remplace les modifications manuelles. Pour la configuration du cloud, voir Configurer le cache L2 de Symfony à la place.Utilisez le type de serveur principal symfony_l2 simplifié pour le cache L2 :
'cache' => [
'frontend' => [
'default' => [
'backend' => 'symfony_l2',
'backend_options' => [
// L2 (Remote): Valkey with Symfony Cache
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'password' => '',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'persistent_id' => 'magento_l2_default',
'timeout' => '2.5',
'read_timeout' => '2.0',
'use_lua' => '1',
'preload_keys' => [
'prefix_EAV_ENTITY_TYPES:hash',
'prefix_GLOBAL_PLUGIN_LIST:hash',
'prefix_DB_IS_UP_TO_DATE:hash',
'prefix_SYSTEM_DEFAULT:hash',
],
],
// L1 (Local): File cache
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1'
],
'cleanup_percentage' => 90,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
],
],
Cache Symfony L2 avec cache périmé
Configurez des fronts distincts pour la prise en charge du cache obsolète :
'cache' => [
'frontend' => [
// Default frontend: NO stale cache
'default' => [
'backend' => 'symfony_l2',
'backend_options' => [
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'persistent_id' => 'magento_l2_default',
],
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1'
],
],
],
// Stale cache enabled frontend
'stale_cache_enabled' => [
'backend' => 'symfony_l2',
'backend_options' => [
'remote_backend' => 'valkey',
'remote_backend_options' => [
'server' => 'localhost',
'database' => '0',
'port' => '6379',
'serializer' => 'igbinary',
'compression_lib' => 'gzip',
'persistent_id' => 'magento_l2_stale',
],
'local_backend' => 'file',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_l1_stale'
],
'use_stale_cache' => true,
],
]
],
'type' => [
'default' => ['frontend' => 'default'],
'layout' => ['frontend' => 'stale_cache_enabled'],
'block_html' => ['frontend' => 'stale_cache_enabled'],
'reflection' => ['frontend' => 'stale_cache_enabled'],
'config_integration' => ['frontend' => 'stale_cache_enabled'],
'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
'full_page' => ['frontend' => 'stale_cache_enabled'],
'translate' => ['frontend' => 'stale_cache_enabled'],
],
],
Options principales du cache Symfony L2
remote_backend'valkey'valkey ou file. Utilisez valkey pour le cache L2.remote_backend_options[]local_backend'file'file ou apculocal_backend_options[]cleanup_percentage95use_stale_cachefalseremote_backend accepte également une valeur de redis. Cependant, Redis n’est pas un service de cache officiellement pris en charge pour Adobe Commerce 2.4.9 et versions ultérieures. Adobe recommande de configurer symfony_l2 avec valkey uniquement. Consultez Configuration requise pour connaître les services de cache pris en charge par version.Amélioration des performances et de la fiabilité du cache Symfony L2
symfony_l2 et sont disponibles avec le correctif ACP2E-5132. Voir Correctifs cloud pour Commerce pour consulter les dernières notes de mise à jour des correctifs.Les mises à jour les plus récentes améliorent l’évolutivité du cache Symfony L2, réduisent les E/S inutiles du système de fichiers et améliorent la cohérence et la fiabilité du cache.
Stockage optimisé des balises de cache L2 Symfony
Optimisation du comportement du cache Symfony L2 pour les déploiements pris en charge par Valkey en éliminant les écritures d’index de balises de système de fichiers redondantes. Les balises de cache sont désormais stockées exclusivement dans Valkey, ce qui aligne le comportement du cache Symfony L2 sur l’implémentation de cache héritée. Cela réduit les E/S de disque inutiles, améliore les performances d’écriture du cache et empêche la croissance du répertoire var/cache/symfony/tags/.
Amélioration du comportement du cache basé sur les fichiers
Pour les déploiements utilisant le cache basé sur les fichiers (sans Valkey), l’index de balise local continue d’être conservé pour prendre en charge l’invalidation du cache. L’index de balise est désormais écrit dans le cache_dir configuré au lieu de l’emplacement de var/cache précédemment codé en dur, ce qui garantit une utilisation cohérente du répertoire de cache et une meilleure prise en charge des configurations de cache personnalisées.
Correction des abonnements aux balises obsolètes après la rebalise
Le rebalisage d’une entrée du cache peut la laisser associée à des balises auxquelles elle n’appartenait plus. Les appartenances aux balises obsolètes sont désormais effacées lors du retag, de sorte que les entrées du cache ne sont invalidées que par les balises qui leur sont actuellement affectées.
Correction d’une écriture distante redondante sur un enregistrement inchangé
L’enregistrement d’une entrée de cache avec du contenu inchangé a tout de même déclenché une écriture sur le serveur principal distant (Valkey). Les enregistrements sont désormais ignorés lorsque le contenu est inchangé, ce qui réduit les écritures distantes inutiles.
Correction d’une expulsion basée sur la taille L1 (cleanup_percentage)
Le seuil de cleanup_percentage utilisé pour l’expulsion L1 basée sur la taille n’a pas déclenché de manière cohérente le nettoyage. L’éviction du cache L1 respecte désormais correctement le cleanup_percentage configuré.
Ajout d’un verrou de régénération pour le cache obsolète.
Lorsque use_stale_cache est activé et que la copie distante d’une entrée est temporairement indisponible, un seul processus acquiert désormais un verrou de courte durée pour générer à nouveau cette entrée. D’autres requêtes simultanées pour la même entrée continuent à servir la valeur locale existante au lieu de la régénérer elles-mêmes, ce qui réduit les bousculades de régénération et la charge redondante du serveur principal.
Impact
- Élimine les écritures d’index de balises de système de fichiers redondantes pour les déploiements de cache Symfony L2 soutenus par Valkey, ce qui réduit les E/S de disque et empêche toute croissance inutile du répertoire
var/cache/symfony/tags/. - Garantit que les déploiements de cache basé sur des fichiers utilisent de manière cohérente le
cache_dirconfiguré pour l’index de balise local tout en préservant le comportement d’invalidation du cache. - Empêche l’invalidation incorrecte du cache causée par les appartenances obsolètes aux balises laissées derrière après le rebalisage.
- Réduit les écritures distantes inutiles pour des enregistrements de cache inchangés, ce qui réduit la charge du réseau et du serveur principal.
- Garantit que l’éviction du cache L1 se déclenche de manière fiable au seuil de
cleanup_percentageconfiguré. - Réduit les bousculades de régénération pour les entrées
use_stale_cacheen sélectionnant un seul régénérateur par clé au lieu de chaque requête simultanée la reconstruisant.
Pour obtenir des options de configuration détaillées, voir :