[Sur Site]{class="badge informative" title="S’applique uniquement aux projets Adobe Commerce on-Premise."}

Configuration du cache L2 pour l’optimisation des performances

La mise en cache L2 (à deux niveaux) réduit le trafic réseau entre le service de cache distant et l’application Commerce en ajoutant une couche de cache locale sur chaque nœud web. Une instance Commerce standard peut transférer environ 300 Ko par requête. Lorsque le volume de requêtes est élevé, le trafic réseau qui en résulte peut être important.

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 :

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 récupérées à partir du service de cache distant via un adaptateur de cache.

L’implémentation du cache L2 disponible dépend de la version de Commerce et du niveau de correctif :

Configuration du cache L2 du cache RemoteSynchronizedCache

Les instructions de configuration du cache dépendent de votre version de Commerce :

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ù :

Pour les versions d’Adobe Commerce antérieures à la version 2.4.9 qui prennent en charge Redis ou Valkey, Adobe recommande d’utiliser Redis ou Valkey pour la mise en cache à distance, comme pris en charge par la version exacte, et Cm_Cache_Backend_File pour la mise en cache locale. Le cache local est généralement stocké sur un système de fichiers temporaire, tel que /dev/shm/ :

'local_backend_options' => [
    'cache_dir' => '/dev/shm/'
]

Adobe recommande d’utiliser la fonction [cache preload](redis-pg-cache.md#redis-preload-feature), car elle réduit la charge sur Redis. Veillez à 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. Les types de cache recommandés et les arbitrages décrits dans cette section s’appliquent à la fois aux implémentations RemoteSynchronizedCache et symfony_l2. Pour obtenir un exemple de configuration symfony_l2, consultez la section Cache Symfony L2 avec cache périmé.

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 utilisateur 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.

Adobe recommande de n’activer l’option use_stale_cache que pour les types de cache qui en bénéficient le plus, notamment :

Adobe déconseille d’activer l’option use_stale_cache pour le type de cache default.

Le code suivant illustre un exemple de configuration pour le serveur principal RemoteSynchronizedCache. Pour obtenir un exemple symfony_l2, consultez la section Cache Symfony L2 avec cache périmé.

'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 Symfony L2

Dans les versions 2.4.9 et ultérieures de Commerce, utilisez l’implémentation du cache Symfony L2 (serveur principal symfony_l2) au lieu de RemoteSynchronizedCache. Le cache Symfony L2 fournit une mise en cache compatible avec PSR-6 à l’aide de Valkey.

Migration de RemoteSynchronizedCache vers Symfony L2

Si vous effectuez une mise à niveau d’une installation sur site du serveur principal RemoteSynchronizedCache vers symfony_l2, consultez les informations suivantes avant de mettre à jour app/etc/env.php. La modification de la seule valeur backend n’est pas suffisante. La structure de configuration, les noms de clés et certains comportements par défaut diffèrent.

Exemple de configuration avec le cache Symfony L2

Dans le fichier app/etc/env.php, utilisez le type de serveur principal symfony_l2 simplifié pour le cache L2. Cet exemple n’inclut pas la configuration preload_keys, qui n’est pas recommandée avec symfony_l2. Pour plus d’informations, consultez Migration de RemoteSynchronizedCache vers Symfony L2.

L’exemple définit cleanup_percentage sur 90. La valeur par défaut est 95. Ajustez cette valeur en fonction de l’espace de stockage du cache local disponible et des exigences de votre déploiement Commerce.

'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',
                    'compress_data' => '1',
                    'persistent_id' => 'magento_l2_default',
                    'timeout' => '2.5',
                    'read_timeout' => '2.0',
                    'use_lua' => '1',
                ],
                // 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é

Consultez la section Options de cache obsolètes pour savoir quels types de cache bénéficient du cache obsolète et pourquoi.

Utilisez l’exemple suivant pour configurer des fronts distincts pour symfony_l2 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',
                    'compress_data' => '1',
                    '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',
                    'compress_data' => '1',
                    '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

Amélioration des performances et de la fiabilité du cache Symfony L2

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

Pour les déploiements de cache Symfony L2 soutenus par Valkey, les balises de cache sont stockées exclusivement dans Valkey. Cela élimine les écritures redondantes de l’index de balises du système de fichiers, réduit les E/S du disque et empêche toute croissance inutile 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.

Correctif d’appartenance à une balise obsolète après le balisage

Le rebalisage d’une entrée du cache peut la laisser associée à des balises auxquelles elle n’appartient 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.

Correctif d’écriture à distance redondant pour les enregistrements inchangés

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.

Correctif d’expulsion L1 basé sur la taille (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é.

Verrouillage de la régénération du cache périmé

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

Pour obtenir des options de configuration détaillées, voir :