[En las instalaciones]{class="badge informative" title="Solo se aplica a los proyectos locales de Adobe Commerce."}

Configuración de caché L2 para la optimización del rendimiento

El almacenamiento en caché L2 (de dos niveles) reduce el tráfico de red entre el almacenamiento de caché remoto (Redis o Valkey) y la aplicación de Commerce al agregar una capa de caché local en cada nodo web. Una instancia estándar de Commerce transfiere unos 300 KB por solicitud y el tráfico puede aumentar rápidamente a más de 1000 solicitudes en algunas situaciones.

Con el almacenamiento en caché L2, cada nodo web almacena localmente los datos a los que se accede con frecuencia y utiliza la caché remota para dos fines:

Commerce almacena la versión de los datos con hash en la caché remota, con el sufijo :hash anexado a la clave normal. Cuando la caché local está obsoleta, los datos se recuperan del equipo remoto a través de un adaptador de caché.

Hay dos implementaciones de caché L2 disponibles en Adobe Commerce:

La caché de Symfony L2 es la implementación recomendada para Adobe Commerce 2.4.9 y versiones posteriores. Proporciona una implementación de almacenamiento en caché moderna y compatible con PSR-6 con mejoras de rendimiento significativas con respecto a la implementación tradicional de RemoteSynchronizedCache.

Configuración de caché L2 heredada (RemoteSynchronizedCache)

Las instrucciones de configuración de caché L2 heredada se aplican a versiones anteriores de Adobe Commerce. Si utiliza la versión 2.4.9 o posterior de Adobe Commerce, use Valkey con la implementación de caché de nivel 2 de Modern Symfony.

Para las versiones locales de Adobe Commerce compatibles con Redis, utilice el siguiente ejemplo para modificar o reemplazar la sección de caché existente en el archivo 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'],
    ],
]

Donde:

Para las versiones de Adobe Commerce anteriores a la 2.4.9 que admiten Redis, Adobe recomienda usar Redis para el almacenamiento remoto en caché (\Magento\Framework\Cache\Backend\Redis) y Cm_Cache_Backend_File para el almacenamiento local en caché de datos en la memoria compartida, con: 'local_backend_options' => ['cache_dir' => '/dev/shm/'].

Adobe recomienda el uso de la característica cache preload, ya que reduce drásticamente la presión sobre Redis. No olvide agregar el sufijo :hash para las claves de precarga.

Opciones de caché antiguas

A partir de Commerce 2.4, la opción use_stale_cache puede mejorar el rendimiento en casos específicos al ofrecer datos almacenados en caché anteriormente mientras se generan nuevos datos de caché en un proceso paralelo. Los tipos de caché recomendados y las compensaciones descritas en esta sección se aplican a las implementaciones heredadas de RemoteSynchronizedCache y symfony_l2. Para ver un ejemplo de configuración de symfony_l2, consulte Caché de Symfony L2 con caché obsoleta.

Por lo general, el equilibrio con la espera de bloqueo es aceptable desde el punto de vista del rendimiento. Sin embargo, a medida que aumenta el número de bloques o entradas de caché, las esperas de bloqueo tardan más. En algunos casos, la espera puede ser de hasta el número de claves x tiempo de espera de búsqueda para el proceso. En casos excepcionales, un comerciante puede tener cientos de claves en la caché de Block/Config, por lo que incluso un pequeño tiempo de espera de búsqueda para un bloqueo puede costar segundos.

Adobe recomienda habilitar la opción use_stale_cache solo para los tipos de caché que más se benefician de ella, incluidos:

Adobe no recomienda habilitar la opción use_stale_cache para el tipo de caché default.

El siguiente código muestra un ejemplo de configuración para el backend RemoteSynchronizedCache heredado. Para ver un ejemplo de symfony_l2, vea Caché de Symfony L2 con caché obsoleta.

'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']
    ],
],

Implementación moderna de la caché Symfony L2

En las versiones de Commerce 2.4.9 o posterior, utilice la implementación de caché L2 basada en caché de Symfony (symfony_l2 backend) en lugar de la caché L2 heredada. La caché Symfony L2 proporciona una implementación de almacenamiento en caché moderna compatible con PSR-6 con mejoras de rendimiento significativas con respecto a la versión tradicional de RemoteSynchronizedCache.

Ventajas de la caché Symfony L2

Migración de RemoteSynchronizedCache a Symfony L2

Si está actualizando una instalación local desde el servidor heredado RemoteSynchronizedCache a symfony_l2, revise lo siguiente antes de actualizar app/etc/env.php. No basta con cambiar únicamente el valor backend. La estructura de configuración, los nombres clave y algunos comportamientos predeterminados son diferentes.

Ejemplo de configuración con caché Symfony L2

En el archivo app/etc/env.php, use el tipo de servidor symfony_l2 simplificado para la caché L2. Este ejemplo no incluye la configuración preload_keys, que no se recomienda con symfony_l2. Para obtener más información, consulte Migración de RemoteSynchronizedCache a 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'],
    ],
],

Caché Symfony L2 con caché obsoleta

Consulte Opciones de caché obsoletas para ver qué tipos de caché se benefician de la caché obsoleta y por qué.

Utilice el siguiente ejemplo para configurar front-end independientes para la compatibilidad con caché obsoleta de symfony_l2:

'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'],
    ],
],

Opciones de servidor para la caché de Symfony L2

Rendimiento y fiabilidad mejorados de la caché Symfony L2

Las actualizaciones más recientes mejoran la escalabilidad de la caché de Symfony L2, reducen la E/S innecesaria del sistema de archivos y mejoran la consistencia y fiabilidad de la caché.

Almacenamiento de etiquetas de caché de Symfony L2 optimizado

Se ha optimizado el comportamiento de la caché de Symfony L2 para implementaciones respaldadas por Valkey al eliminar escrituras redundantes de índices de etiquetas de sistemas de archivos. Las etiquetas de caché ahora se almacenan exclusivamente en Valkey, alineando el comportamiento de la caché de Symfony L2 con la implementación de la caché heredada. Esto reduce la E/S de disco innecesaria, mejora el rendimiento de escritura en caché y evita el crecimiento del directorio var/cache/symfony/tags/.

Comportamiento de caché basado en archivos mejorado

Para implementaciones que utilizan la caché basada en archivos (sin Valkey), el índice de etiquetas local se sigue manteniendo para admitir la invalidación de la caché. El índice de etiquetas ahora se escribe en la ubicación cache_dir configurada en lugar de en la ubicación var/cache codificada anteriormente, lo que garantiza un uso coherente del directorio de caché y una compatibilidad mejorada con las configuraciones de caché personalizadas.

Corrección de pertenencia a etiqueta obsoleta después de reetiquetar

Si se reetiqueta una entrada de caché, podría dejarla asociada a etiquetas a las que ya no pertenecía. Las suscripciones a etiquetas antiguas ahora se borran al volver a etiquetar, por lo que las entradas de la caché solo se invalidan con las etiquetas asignadas actualmente a ellas.

Corrección de escritura remota redundante para guardar sin modificar

Al guardar una entrada de caché con contenido no modificado, se sigue activando una escritura en el backend remoto (Valkey). Las operaciones de guardado ahora se omiten cuando el contenido no se modifica, lo que reduce las escrituras remotas innecesarias.

Corrección de desalojos basada en el tamaño L1 (cleanup_percentage)

El umbral cleanup_percentage utilizado para la expulsión basada en el tamaño L1 no almacenaba en déclencheur la limpieza de forma coherente. La expulsión de caché de L1 ahora respeta correctamente la configuración de cleanup_percentage.

Bloqueo de regeneración para caché obsoleta

Cuando use_stale_cache está habilitado y la copia remota de una entrada no está disponible temporalmente, solo un proceso adquiere ahora un bloqueo de corta duración para regenerar esa entrada. Otras solicitudes simultáneas para la misma entrada siguen sirviendo al valor local existente en lugar de regenerarlo ellas mismas, reduciendo las estampidas de regeneración y la carga redundante del servidor.

Impacto

Para ver las opciones de configuración detalladas, consulte: