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

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.

Il existe deux implémentations du cache L2 disponibles dans Adobe Commerce :

Le cache Symfony L2 est l’implémentation recommandée pour Adobe Commerce 2.4.9 et les versions ultérieures. Il fournit une mise en cache moderne, conforme à la norme PSR-6, avec des performances nettement supérieures à celles de la RemoteSynchronizedCache traditionnelle.

Configuration de cache L2 héritée (RemoteSynchronizedCache)

Les instructions de configuration de cache L2 héritées s’appliquent aux versions plus anciennes d’Adobe Commerce. Si vous utilisez la version 2.4.9 ou une version ultérieure d’Adobe Commerce, utilisez Valkey avec l’implémentation du cache L2 de Modern Symfony.

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, 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. Les types de cache et les arbitrages recommandés décrits dans cette section s’appliquent à la fois aux implémentations RemoteSynchronizedCache et symfony_l2 héritées. 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 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.

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 l’ancien 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 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.

Avantages du cache Symfony L2

Migration de RemoteSynchronizedCache vers Symfony L2

Si vous effectuez une mise à niveau d’une installation sur site à partir de l’ancien 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.

'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

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.

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

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 :