Un panel de filtros que tarda cuatro segundos en responder se percibe como roto. El problema rara vez es el módulo en sí: viene de la forma en que se construyen las consultas y de lo que la base debe recorrer para responderlas.
He aquí cómo localizar la causa antes de cambiar nada.
Medir antes de suponer
Tres mediciones, en este orden.
El tiempo de respuesta real de una consulta de filtrado, medido en la pestaña de red del navegador sobre su categoría más grande con dos o tres filtros activos. Anote el valor: es su punto de partida.
La parte de ese tiempo pasada en base de datos. Active el perfilado de PrestaShop en entorno de pruebas: muestra el número de consultas ejecutadas y su duración acumulada. Si el tiempo de base representa el 80 % del total, inútil mirar en otra parte.
El número de consultas ejecutadas. Es a menudo la revelación: una página de categoría filtrada que ejecuta trescientas consultas tiene un problema de diseño, no de potencia de servidor.
Este tercer punto merece atención. Una multiplicación de las consultas señala generalmente un cálculo de contadores valor por valor, o una carga de productos uno a uno en un bucle.
Las cuatro causas principales
Los joins sobre las tablas de atributos. Filtrar sobre tres atributos supone unir varias veces las tablas de valores. En un catálogo de veinte mil combinaciones, estos joins producen conjuntos intermedios considerables.
El cálculo de los contadores. Mostrar el número de resultados tras cada valor supone una agregación por valor. En un panel de sesenta valores, eso puede hacer sesenta agregaciones a cada cambio de selección.
El conteo total para la paginación. Contar las filas de una selección amplia cuesta casi tanto como leerlas.
Los índices que faltan. En las tablas de enlace entre productos, atributos y categorías, un índice ausente transforma una búsqueda en recorrido completo de tabla.
Diagnosticar los índices
Es la verificación más rentable y más rápida.
Recupere la consulta de filtrado más lenta desde el registro de consultas lentas de su base, y ejecútela precedida de la palabra clave de explicación del plan de ejecución.
Tres señales a detectar en el resultado.
Un tipo de acceso que indica un recorrido completo sobre una tabla voluminosa. Es el signo de un índice ausente o inutilizable.
Un número de filas examinadas sin proporción con el número de filas devueltas. Examinar doscientas mil filas para devolver cuarenta indica que el filtrado se hace tras la lectura y no por índice.
La mención de una ordenación temporal o de una tabla temporal, que señala que la base no puede satisfacer la ordenación por índice y debe materializar un resultado intermedio.
Punto práctico: los índices útiles en estas tablas cubren a menudo columnas combinadas, y su orden cuenta. Un índice sobre producto y después atributo no sirve a las mismas consultas que un índice sobre atributo y después producto.
Filtros por Facetas AJAX para PrestaShopLa navegación por facetas que filtra rápido e indexa bien€99,00
Reducir el trabajo en lugar de acelerarlo
Antes de la optimización técnica, tres decisiones funcionales tienen a menudo más efecto.
Reducir el número de filtros. Cada atributo filtrable añade joins potenciales y contadores a calcular. Doce filtros de los que cuatro se usan cuestan tres veces demasiado.
Renunciar a los contadores en los catálogos grandes, o calcularlos solo en los filtros más usados. El confort perdido es real, la ganancia de tiempo también.
Limitar la profundidad de combinación. Más allá de tres filtros simultáneos, las selecciones se vuelven raras y costosas. Puede poner un tope sin que nadie se dé cuenta.
Estas tres medidas no requieren ningún desarrollo y se prueban en una tarde.
El índice dedicado
Cuando las medidas anteriores no bastan, la respuesta estructural consiste en dejar de interrogar las tablas de catálogo en el momento del filtrado.
El principio: una tabla plana, precalculada, que contiene para cada producto sus valores filtrables, su precio, su disponibilidad y sus categorías. El filtrado se convierte en una consulta simple sobre una sola tabla indexada.
Tres puntos de implementación.
La actualización debe dispararse a cada modificación de producto, de precio o de stock. Un índice desincronizado muestra productos que ya no existen u oculta novedades.
La reconstrucción completa debe seguir siendo posible, y su tiempo de ejecución medido: en un catálogo grande, puede tomar varios minutos y no debe ejecutarse en hora punta.
El disparo en masa. Una importación de catálogo que modifica diez mil productos no debe disparar diez mil reconstrucciones unitarias. Prevea un modo diferido.
La caché, y sus límites
La caché es útil y a menudo está mal empleada en este tema.
Cachear los resultados de filtrado funciona bien cuando las combinaciones solicitadas son pocas y repetidas. Es el caso en la mayoría de las tiendas: unas decenas de combinaciones cubren lo esencial del tráfico.
Dos límites a conocer. La caché no trata la primera visita de cada combinación, que sigue siendo lenta. Y debe ser invalidada a cada cambio de stock o de precio, sin lo cual muestra informaciones falsas.
Sobre los datos de disponibilidad, la duración de caché debe permanecer corta, unos minutos, lo que reduce mucho su interés. Un enfoque corriente consiste en cachear la lista de productos correspondientes y recuperar precio y stock en directo.
Las verificaciones del lado de la infraestructura
Tres puntos que no corresponden al código.
La memoria asignada a la base. Una base que no puede mantener sus índices en memoria los relee desde el disco a cada consulta. Es la causa más frecuente de lentitud generalizada tras un crecimiento de catálogo.
La configuración de la caché de consultas y de los búferes, a ajustar según el tamaño real de sus datos en lugar de quedarse con los valores por defecto de la instalación.
Los recursos concurrentes. Una exportación de catálogo o una tarea programada que se ejecuta al mismo tiempo que el pico de tráfico lo degrada todo. Desplace lo que pueda desplazarse.
El proceso completo
Seis etapas, en este orden de rentabilidad decreciente.
1. Mida el tiempo de respuesta y el número de consultas.
2. Verifique los índices con un plan de ejecución sobre la consulta más lenta.
3. Reduzca el número de filtros propuestos a los únicos usados.
4. Desactive o limite los contadores si el catálogo es importante.
5. Implemente una caché sobre las combinaciones frecuentes.
6. Considere un índice dedicado si las cinco primeras etapas no bastan.
Punto de método: mida después de cada etapa. Franquear varias etapas de golpe le priva de saber cuál ha producido el efecto, y por tanto de saber dónde concentrar el esfuerzo la próxima vez.
El módulo Filtros por Facetas AJAX para PrestaShop integra estos mecanismos en PrestaShop 8 y 9: índice dedicado precalculado con actualización incremental, contadores de resultados en agregación única, caché por combinación con invalidación en los cambios de stock y de precio, y limitación parametrizable de la profundidad de combinación.
