Tienda lenta tras cambiar de servidor: qué mostró el profiling

Durante una migración, Gustavo, de la comunidad, se encontró con que una tienda cargaba en 3 segundos en el servidor viejo y en 20 en el nuevo, con el mismo código. Con un profiling que mide hooks, módulos y consultas encontró tres culpables y la dejó en 7 segundos. Su conclusión: sin el profiling, imposible encontrarlo.

El caso

Era una tienda muy antigua, en PrestaShop 1.4 y con tablas MyISAM, que se cambió de servidor mientras se preparaba su migración. El servidor nuevo, que Gustavo no administraba, tenía un MariaDB recién instalado y sin ajustar. Sospechaba de unos módulos que hacían muchas consultas, pero había que demostrarlo.

Otro compañero le sugirió empezar por lo sencillo: ordenar las tablas por tamaño y mirar cuáles merecían atención. Gustavo llegó a plantearse llevar la base de datos a otro servidor suyo: aunque la conexión remota añadiera medio segundo, le compensaba frente a lo que perdía con el MySQL nuevo.

Lo que mostró el profiling

Como en una 1.4 no hay herramientas modernas, se hizo con ayuda de la IA un profiling que anotaba el tiempo de cada hook y de cada módulo. Salieron tres cosas:

1. Comprobaciones de licencia: módulos que llamaban a un servidor externo para validar su licencia en cada carga de página.
2. Overrides que repetían el trabajo: uno llamaba hasta cinco veces a la misma función en una sola petición.
3. Un MySQL sin optimizar, con la configuración por defecto en my.cnf.

Corrigió los overrides, evitó las comprobaciones de licencia en cada carga y ajustó lo que pudo de my.cnf, incluido el registro de consultas lentas. De 20 segundos a 7. Lo que queda depende del servidor, que no gestiona él; su idea para seguir es montar en Docker la versión de MySQL que la tienda necesita y conectarla por otro puerto.

Cómo hacerlo en PrestaShop 1.7, 8 y 9

En las versiones actuales no hace falta fabricarse nada: PrestaShop trae su propio profiling. En config/defines.inc.php, cambia:

define('_PS_DEBUG_PROFILING_', false);

a true. Al final de cada página del front verás el tiempo total, el de cada hook y cada módulo, las consultas SQL más lentas y las que se repiten. Actívalo en una copia de la tienda o solo durante unos minutos: muestra información interna a cualquiera que visite la web.

Qué buscar

• La misma consulta repetida decenas de veces: casi siempre un módulo u override dentro de un bucle.
• Un módulo que tarda siempre lo mismo, un número redondo: está esperando una llamada externa (licencia, API, estadísticas).
• Hooks lentos en todas las páginas, como displayHeader o actionFrontControllerSetMedia.

Y en el servidor

Si el código es el mismo y el servidor nuevo va más lento, compara la configuración de MySQL. Para empezar, activa el registro de consultas lentas:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/lentas.log
long_query_time = 1

Y revisa que innodb_buffer_pool_size no sea el valor por defecto, que las tablas sean InnoDB y que la versión de PHP y OPcache estén como en el servidor viejo. Convertir tablas MyISAM a InnoDB se hace tabla a tabla, con copia de seguridad antes.

Para hacer este diagnóstico desde el back-office, Rekire tiene RKR Diagnoses, un profiler de rendimiento para PrestaShop.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación