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.
ece-tools) gère automatiquement cette configuration. 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.symfony_l2 est disponible uniquement dans Adobe Commerce 2.4.9 et versions ultérieures, configurez-le avec Valkey comme serveur principal distant. Redis n’est pas un serveur principal distant officiellement pris en charge pour symfony_l2. Consultez Configuration requise pour connaître les services de cache pris en charge par version.Avantages 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
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.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.
Amélioration de l’invalidation du cache
L’invalidation du cache utilise désormais des verrous de régénération TTL avec un nettoyage de balise L1 correct, éliminant les entrées de cache obsolètes qui pouvaient auparavant persister après l’invalidation de la balise.
Compression activée par défaut
La compression Redis/Valkey (compress_data) est désormais activée par défaut pour le cache Symfony L2, ce qui réduit la consommation de mémoire et le trafic réseau et s’aligne sur le comportement par défaut de l’implémentation du cache hérité.
Impact
- Élimine les écritures d’index de balises de système de fichiers redondantes pour les déploiements de cache Symfony L2 avec support Valkey.
- Réduit les E/S du disque et améliore les performances d’écriture du cache.
- Empêche toute croissance inutile du répertoire
var/cache/symfony/tags/. - Garantit que les déploiements de cache basé sur des fichiers utilisent le
cache_dirconfiguré de manière cohérente, tout en préservant le comportement d’invalidation du cache. - Élimine les entrées de cache obsolètes par le biais de verrous de régénération basés sur TTL et d’un nettoyage de balise L1 approprié.
- Réduit la consommation de mémoire et le trafic réseau avec le
compress_dataactivé par défaut.
Pour obtenir des options de configuration détaillées, voir :