Optimización de Redis y OpenSearch en Magento 2

Redis y OpenSearch son donde muchas tiendas Magento pierden en silencio su margen de rendimiento. Los dos funcionan bien en una demo y los dos se caen a escala cuando se dejan con los valores por defecto; y como están en la capa de infraestructura, los síntomas (TTFB lento, checkout a saltos, carritos perdidos) rara vez apuntan directamente a la causa. Esta es la configuración que importa de verdad.

Primero, una nota de versiones: Magento 2.4.8 soporta Redis 7.2 y, más reciente, Valkey 8, el fork de código abierto de Redis que Magento recomienda ahora para instalaciones nuevas. Valkey es un sustituto directo, así que todo lo que sigue vale para los dos; donde decimos «Redis», lea «Redis o Valkey». La búsqueda corre sobre OpenSearch 2.19 en 2.4.8 (OpenSearch 3 llega en la línea de parches 2.4.8-p4). Verifíquelo contra su versión exacta antes de cambiar nada.

Redis: la caché y las sesiones no son el mismo trabajo

El error más habitual es hacer pasar la caché por defecto, la caché de página y las sesiones de Magento por una sola instancia de Redis con valores por defecto. Tienen requisitos opuestos, y compartirla las castiga a todas.

Sepárelas en bases de datos distintas y, como verá, en instancias distintas para la parte que importa. Una configuración de caché en env.php para un solo nodo:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'compress_data' => '1',
                'compression_lib' => 'zstd',
            ],
        ],
        'page_cache' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
                'compress_data' => '0',
            ],
        ],
    ],
],

Dos cosas que conviene saber aquí:

• Si usa Varnish como full-page cache —y en una tienda en producción debería—, Varnish es su caché de página. La page_cache de Redis de arriba es el recurso de reserva para tiendas que no usan Varnish. No espere que la caché de página de Redis haga el trabajo de Varnish.
• Con varios nodos web, no use el backend de Redis a secas para la caché por defecto. Use Magento\Framework\Cache\Backend\RemoteSynchronizedCache —una caché L1 en memoria en cada nodo respaldada por una L2 en Redis— para que los nodos no se sirvan caché desactualizada entre sí. En un solo nodo, el backend de Redis a secas está bien.

Sesiones: instancia separada, política de expulsión distinta

Las sesiones van en su propio sitio, con sus propias reglas:

'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6380',
        'database' => '0',
        'disable_locking' => '0',
        'max_concurrency' => '6',
        'compression_threshold' => '2048',
        'compression_library' => 'gzip',
    ],
],

Fíjese en el puerto: 6380, una instancia distinta. Esta es la razón, y es el detalle que la mayoría de las tiendas tiene mal.

Límites de memoria y expulsión: la parte que muerde

Una instancia de Redis tiene una maxmemory-policy para todas las bases de datos que contiene. Ese único hecho determina toda la arquitectura:

• Las instancias de caché quieren allkeys-lru. Cuando se llenan, Redis debería descartar con elegancia las entradas menos usadas recientemente. La alternativa, el noeviction por defecto, lanza errores duros cuando Redis se llena, lo que aparece como fallos aleatorios de Magento bajo carga.
• La instancia de sesiones no debe usar allkeys-lru. Expulsar una clave de sesión cierra la sesión de un cliente o le vacía el carrito a mitad de compra. Las sesiones quieren noeviction (con memoria suficiente aprovisionada) o volatile-lru.

Como una instancia no puede tener dos políticas, la caché y las sesiones van en instancias de Redis separadas, no solo en bases de datos separadas. Por instancia:

# cache instance (6379)
maxmemory 2gb
maxmemory-policy allkeys-lru

# session instance (6380)
maxmemory 1gb
maxmemory-policy noeviction

Y después vigile de verdad la expulsión, porque una expulsión silenciosa es un arranque en frío de la caché silencioso:

redis-cli -p 6379 info stats | grep evicted_keys
redis-cli -p 6379 info memory | grep used_memory_human

Si evicted_keys sube de forma constante en la instancia de caché, o el conjunto de trabajo ha superado maxmemory o algo está cacheando demasiado: investigue antes de limitarse a subir el límite.

OpenSearch: dimensionado y los ajustes que mueven la aguja

OpenSearch es donde se gana o se pierde el rendimiento de las categorías, la búsqueda y la navegación por capas en un catálogo grande. Apunte Magento a él de forma explícita:

bin/magento config:set catalog/search/engine opensearch
bin/magento config:set catalog/search/opensearch_server_hostname 127.0.0.1
bin/magento config:set catalog/search/opensearch_server_port 9200

Y después los ajustes a nivel de clúster que más importan:

• Tamaño del heap. Ponga el heap de la JVM en torno al 50 % de la RAM de la máquina, y nunca por encima de ~31 GB (a partir de ahí se pierden los punteros de objeto comprimidos y, en la práctica, se desperdicia memoria). Deje la otra mitad para la caché de archivos del sistema operativo de la que depende OpenSearch. Una máquina con el heap de OpenSearch al 90 % de la RAM es más lenta, no más rápida.
• Shards y réplicas. Una instalación de un solo nodo quiere 1 shard, 0 réplicas: las réplicas en un solo nodo no hacen nada salvo costar memoria. Añada réplicas solo cuando tenga un clúster real de varios nodos para alta disponibilidad.
• refresh_interval durante una reindexación masiva. Subirlo temporalmente (o ponerlo en -1) durante una reindexación completa recorta bastante el tiempo de indexación, porque OpenSearch no está haciendo buscable cada cambio casi en tiempo real mientras trabaja.

Estrategia de indexación

Una infraestructura de búsqueda rápida no ayuda si Magento está peleándose con sus propios indexers:

• Todos los indexers en Update by Schedule, no en «Update on Save». La reindexación al guardar bloquea tablas y para tanto la tienda como el admin en un catálogo grande. Compruébelo con bin/magento indexer:show-mode.
• El cron tiene que estar sano: MView agrupa los cambios del catálogo hacia los indexers a través del cron, así que un cron roto significa resultados de búsqueda desactualizados y un retraso que va creciendo. bin/magento cron:status.
• Desactive Flat Catalog. Está obsoleto y, ahora que la búsqueda pasa por OpenSearch, añade sobrecarga de indexación sin ningún beneficio en las consultas. Perdura en las tiendas solo porque las guías antiguas siguen recomendándolo.
• Desactive las funciones de búsqueda que no usa: las sugerencias y las recomendaciones añaden carga de consultas. Si su tienda no las muestra, apagarlas es margen gratis.

Verificar bajo carga

Todos los ajustes de aquí aguantan en una máquina sin actividad. La pregunta es si aguantan en el pico:

• Haga pruebas de carga sobre las páginas de categoría y de búsqueda, no solo sobre la portada: son las que se apoyan en OpenSearch.
• Vigile la expulsión y la memoria de Redis durante la prueba, no después. La expulsión bajo carga es exactamente el modo de fallo que nunca aparece en una comprobación tranquila.
• Confirme que Varnish sigue haciendo el trabajo de caché de página y que Redis solo está gestionando la caché por defecto y las sesiones que le corresponden.

Qué revisaríamos primero

En una tienda lenta, en orden: si la caché por defecto está en Redis y sana; si la caché y las sesiones están en instancias separadas con las políticas de expulsión correctas; si Varnish (y no Redis) está sirviendo la full-page cache; si el heap de OpenSearch tiene un tamaño sensato con el número de shards correcto; y si los indexers están por programación con el cron vivo. Esa lista corta atrapa la gran mayoría de los problemas de Redis y OpenSearch que encontramos, y es la base sobre la que se construye el resto de un proyecto de rendimiento en Magento.

Emyrix hace trabajo de infraestructura y rendimiento en Magento y Adobe Commerce: arquitectura de caché, ajuste de la búsqueda y las pruebas de carga para demostrar que aguanta. Si su tienda es lenta y prefiere saber por qué antes que adivinarlo, escríbanos.