Por qué el checkout de PrestaShop se ralentiza al añadir un buscador externo

Un efecto secundario que nadie espera

Se instala Elasticsearch, OpenSearch o Meilisearch en PrestaShop casi siempre por una sola razón: la búsqueda nativa no da abasto con un catálogo grande. Y la búsqueda, en efecto, mejora. Lo que se comprueba con menos frecuencia es qué le pasa al resto de la tienda, en especial al carrito y al checkout, cuando ese índice externo tiene que mantenerse sincronizado con el stock y la disponibilidad, que cambian con cada venta.

Esta parte suele pasar inadvertida por un motivo sencillo: en una demostración, con un puñado de pedidos, no se nota nada. El problema aparece con carga real, cuando varios pedidos llegan a la vez, y a esas alturas el cliente ya está pagando. No es el lugar donde uno quiere descubrir un cuello de botella.

Qué debe ocurrir cuando un cliente cambia una cantidad en su carrito

Con un buscador externo, cada producto existe dos veces: una fila en la base de datos de PrestaShop y un «documento» en el índice del buscador, que contiene los campos necesarios para encontrarlo y filtrarlo (nombre, precio, categorías, disponibilidad, etc.). Cuando un cliente añade un producto al carrito, cambia una cantidad o se confirma un pedido, la disponibilidad de ese producto cambia y el documento del índice tiene que reflejarlo; de lo contrario, otro cliente podría ver como disponible un producto que acaba de agotarse.

La forma más sencilla de hacerlo, y también la más costosa, consiste en reconstruir el documento entero cada vez: volver a leer de la base de datos el nombre, la descripción, el precio, las categorías, las imágenes y todo lo demás, solo para actualizar tres cifras (cantidad, disponibilidad y orden según la disponibilidad). Si esa reconstrucción se dispara una vez por línea de pedido, un pedido de cinco productos distintos la dispara cinco veces, justo cuando el cliente espera la confirmación de su pago.

Las cifras reales

Medido en PrestaShop 9.0.0, con dos tiendas conectadas a Elasticsearch, un pedido de cinco líneas que reconstruía el documento completo por cada línea costaba 243 consultas SQL y 229 milisegundos, únicamente para mover tres cifras en el índice de búsqueda. No es el tiempo del checkout completo, sino el de un solo paso interno: el que mantiene el índice sincronizado.

Con una ruta dedicada que solo actualiza los campos que de verdad han cambiado (cantidad, disponibilidad, orden según la disponibilidad) en lugar de reconstruir todo el documento, el mismo pedido en las mismas tiendas bajó a 9 consultas y entre 16 y 47 milisegundos. Misma operación, mismo resultado final en el índice: lo único que cambia es la cantidad de trabajo necesaria para llegar a él.

La diferencia técnica se explica fácilmente, incluso a quien no escribe código: un buscador externo ofrece normalmente dos maneras de actualizar un documento. La primera, «sustituirlo por completo», sirve cuando cambia de verdad algo estructural, como el nombre o el precio. La segunda, «actualizar solo estos campos», está pensada para el caso mucho más frecuente en que solo cambia la disponibilidad. Usar siempre la primera, incluso cuando basta la segunda, es la causa más habitual de un checkout que se ralentiza justo cuando la tienda vende más.

Por qué casi siempre ocurre en el mismo punto

En PrestaShop, el evento que avisa de un cambio de cantidad durante un pedido puede dispararse una vez por línea de pedido, y no una vez por todo el pedido. Es fácil escribir el código que escucha ese evento pensando «es solo una actualización», sin darse cuenta de que, en un pedido de muchas líneas o en un pico de ventas con muchos pedidos simultáneos, esa decisión se multiplica por el número de líneas y por el número de pedidos en curso al mismo tiempo. Un módulo de búsqueda que parece rápido en pruebas, con un pedido cada vez, puede comportarse de forma muy distinta durante un Black Friday con cientos de checkouts simultáneos.

Qué conviene preguntar si ya tiene un buscador externo

• Pregunte a su módulo de búsqueda o a su integrador si un cambio de cantidad en el carrito actualiza solo los campos de stock o reconstruye todo el documento del producto.
• Haga una prueba con un pedido de varias líneas en un momento tranquilo y vigile el registro de consultas lentas de la base de datos durante el checkout: si ve decenas de consultas repetidas para el mismo producto, es exactamente este síntoma.
• Si gestiona una tienda B2B o de venta al por mayor con carritos de muchas líneas, este problema escala mal: un carrito de treinta líneas con una reconstrucción completa por línea es seis veces más lento que un carrito de cinco líneas, mientras que con una actualización dirigida la diferencia es mucho menor.
• No es una razón para renunciar a un buscador externo: un catálogo grande siempre lo necesita para la búsqueda. Es una razón para comprobar cómo se ha escrito realmente la integración entre el carrito y el índice.

En resumen

Un buscador externo no ralentiza el checkout por sí solo. Lo que lo ralentiza es una integración que reconstruye todo el documento de búsqueda para un cambio que afecta solo a tres cifras. La diferencia medida, de 243 consultas y 229 milisegundos a 9 consultas y entre 16 y 47 milisegundos en el mismo pedido, corresponde al trabajo que hicimos en cll_essearch al separar las actualizaciones de stock de las actualizaciones estructurales en Elasticsearch, OpenSearch y Meilisearch. Si su tienda usa un buscador externo y el checkout se ralentiza justo cuando despegan las ventas, es lo primero que debe comprobar.

Búsqueda Elasticsearch y Navegación por FacetasBúsqueda ultrarrápida y tolerante a errores de tecleo con navegación por facetas moderna en panel modal, con e…99,99 €Ver producto