Por qué la búsqueda de PrestaShop se ralentiza cuando el catálogo crece

El síntoma

Con un catálogo de demostración de veinte o treinta productos, la búsqueda de PrestaShop funciona siempre bien: sea cual sea la configuración elegida, la página responde en una fracción de segundo. El problema solo aparece cuando el catálogo se hace de verdad grande, y para entonces ya es tarde para darse cuenta a tiempo: una tienda de 50 000, 100 000 o 200 000 productos puede acabar con una página de resultados de búsqueda que tarda varios segundos en responder, o con una página de categoría filtrada que se convierte en la más lenta de todo el sitio.

No es una impresión. En un catálogo sintético de 200 000 productos, con el motor de búsqueda nativo de PrestaShop (el que funciona dentro de la base de datos de la tienda, sin motor externo), una página de resultados de búsqueda tardaba 28 segundos y una página de categoría grande 30 segundos antes de un trabajo de optimización específico. Después, la misma página responde entre 2 y 6 segundos. Siguen siendo segundos, no milisegundos: entender por qué es el objeto de todo este artículo.

Por qué el tiempo crece más rápido que el catálogo

La causa más frecuente no es «la base de datos es lenta», sino que el mismo trabajo se rehace varias veces dentro de una sola petición. Un motor de búsqueda con facetas debe responder a dos preguntas distintas en cada página: qué productos mostrar y, para cada filtro disponible, cuántos productos quedarían si el visitante lo seleccionara. Si el conjunto de productos que coinciden con la búsqueda en curso se recalcula desde cero para cada filtro, en lugar de calcularse una vez y reutilizarse, el coste deja de ser proporcional al número de productos y pasa a ser proporcional al número de productos multiplicado por el número de filtros. En un catálogo pequeño, la diferencia pasa inadvertida. Con 200 000 productos y decenas de filtros activos, una búsqueda que en teoría solo afecta a cinco productos puede acabar recorriendo el catálogo entero una decena de veces.

Lo mismo ocurre con tareas más pequeñas pero repetidas un número enorme de veces: si el precio de cada producto de una página de categoría se pide a la base de datos uno por uno en lugar de obtenerse en bloque, cien productos por página pueden convertirse fácilmente en cien mil consultas en un catálogo grande con reglas de precio por grupo o por cantidad. Ninguna de esas consultas es lenta por separado. Lo insoportable es su número.

El coste oculto de las cifras junto a los filtros

Existe un segundo coste, distinto del primero: mostrar cuántos productos coinciden con cada valor de un filtro, el clásico «Rojo (12)» junto a una casilla. Con un motor de búsqueda externo (Elasticsearch, OpenSearch, Meilisearch), esa cifra es gratuita: llega con la misma consulta que calcula los resultados. Con el motor nativo, que trabaja en la base de datos de la tienda, cada valor de cada filtro puede necesitar su propia consulta de recuento.

En un catálogo de 200 000 productos con unos 2 250 grupos de atributos y características, desactivar el recuento exacto de los filtros (mostrar la lista de valores sin la cifra al lado) hizo pasar una página de categoría con un filtro activo de 43,3 segundos a 11,9 segundos. Solo en las facetas de características y atributos, el tiempo bajó de 6,8 y 5,4 segundos respectivamente a 15 y 19 milisegundos. No es un redondeo: es la diferencia entre una consulta que debe contar las filas una a una en la base de datos y una consulta que se limita a leer una lista de valores distintos hasta cierto límite, sin contarlos todos.

Para el comerciante, la pregunta práctica es sencilla: ¿esa cifra entre paréntesis vale lo que cuesta? En un catálogo de unos pocos miles de productos, casi con seguridad sí. En un catálogo de cientos de miles de productos con muchas características, puede ser la partida más costosa de toda la página, y desactivarla suele ser cuestión de una casilla de configuración, no de reescribir código.

Lo que muestra una prueba real en un catálogo de este tamaño

En un catálogo sintético de 200 321 productos, una prueba interna de la página de búsqueda completa (cálculo de los resultados y de todas las facetas) midió tiempos de respuesta de entre 2,2 y 2,4 segundos. Es coherente con el intervalo de 2 a 6 segundos citado más arriba, obtenido en una instalación distinta: dos mediciones independientes que cuentan lo mismo, un catálogo de este tamaño responde en un tiempo que se cuenta en segundos, no en décimas de segundo, incluso después de un buen trabajo de optimización. Quien prometa lo contrario para un catálogo de este tamaño con solo el motor nativo de la base de datos probablemente mide en un catálogo más pequeño de lo que dice.

Qué conviene comprobar antes de descubrirlo en producción

• Haz al menos una prueba con un volumen de productos cercano al volumen real, no con el catálogo de demostración. Este tipo de problema es invisible por debajo de las diez mil filas y muy visible por encima.
• Comprueba el límite de memoria PHP de tu alojamiento. Muchas ofertas compartidas se quedan en 128 o 256 MB: las operaciones que cargan filas de la base de datos en memoria en lugar de dejar que la base haga el recuento pueden superarlo en catálogos grandes con muchas características o atributos importados por CSV.
• Si usas el motor nativo en un catálogo grande, comprueba si puedes desactivar el recuento exacto de los filtros, o si conviene pasar a un motor externo (Elasticsearch, OpenSearch o Meilisearch) que lo calcula como subproducto de la misma consulta.
• Sea cual sea el módulo de búsqueda que estés evaluando, pregunta si su coste se ha medido de verdad en un catálogo grande, con una cifra. «Rápido» sin una cifra al lado no dice mucho.

En resumen

La búsqueda de PrestaShop no se ralentiza por un defecto misterioso: se ralentiza porque un mismo trabajo se repite más veces de las necesarias, y eso solo se hace visible cuando el catálogo crece lo suficiente para revelarlo. Las dos palancas más sencillas de controlar son saber si el mismo conjunto de resultados se reutiliza de un filtro a otro y si las cifras junto a los filtros se calculan de forma económica o costosa. Hemos pasado meses midiendo y corrigiendo precisamente este tipo de problema en cll_essearch, nuestro módulo de búsqueda y navegación por facetas para PrestaShop, que funciona tanto con el motor nativo como con Elasticsearch, OpenSearch y Meilisearch: si reconoces en tu tienda los síntomas descritos aquí, es exactamente el tipo de problema para el que fue diseñado.

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