Aporte para Lentitud del BackOffice de Prestashop  

Buenas.

Mi nombre es Fernando Alvarez, y soy el que administra, en términos reales, esta cuenta.

Quiero aportar el trabajo realizado para aumentar la velocidad en el Backend a base de muchas horas de investigación, que, finalmente, dieron buenos resultados.

Expongo esto aquí sin la más mínima garantía y que cada cual actúe bajo su propia responsabilidad.

Para empezar, Prestashop cuenta con un módulo llamado Experiencia Comercial, que no es más que un módulo de gamificación que recoge nuestros "avances" en el uso de la plataforma, ofreciéndonos medallitas y otras chorradas inútiles. Este módulo tiene la mala costumbre de acceder a la API externa de Prestashop, con lo que consigue dos cosas, introducir un proceso más de llamada externa completamente inútil, y poner en riesgo la velocidad del BackOffice si el servidor de PS está caído o saturado, como ha pasado esta semana.

Mi recomendación es eliminarlo por completo, y olvidarnos de el para siempre, y, si pensamos que lo hacemos bien, ir a tomar una cerveza en lugar de recibir una medallita virtual de una máquina. Utilidad práctica CERO absoluto.

Por otro lado, la comprobación de actualizaciones de módulos etc. hace llamadas también a nuestro querido y saturado servidor de PS, por lo que es muy importante desactivarlo. Si necesitamos actualizar un módulo, o la versión de PS al completo, esto último hay que hacerlo con pies de plomo, lo vamos a saber, porque va a fallar algo, vamos a necesitar algo nuevo o, en definitiva, va a pasar algo que no va a tener que decirnos una máquina. Aquí sigo un poco la máxima de “si funciona, no lo toques”, además de ahorrarnos las llamadas externas de comprobación, que no solo se hacen al acceder a la sección de módulos.

Mi recomendación es desactivar dicha comprobación que, como siempre, varía su localización de una versión a otra, pero a partir de la 1.6.X está en:

Configurar -> Parámetros Avanzados -> Admiración -> Comprobar automáticamente las actualizaciones de los módulos

Por último, y esto sí que clama al cielo, la base de datos de PS dista muchísimo de estar optimizada en cuanto a estructura. Muchas "mejoras" y características nuevas, pero no se han parado ni un segundo en meterle mano a una correcta colocación de índices y claves a la mastodóntica y mal distribuida base de datos, con tablas redundantes e información distribuida de una manera ilógica por todos lados.
Obviamente, no nos vamos a meter en reestructurar las tablas y sus funciones, sería más fácil hacer una plataforma desde cero, pero si podemos dar un poco de vidilla a las consultas si tenemos conocimientos de SQL.

PS cuenta con una herramienta potente de depuración. Además del DEBUG de siempre, donde nos da información sobre los posibles errores a nivel de código, tenemos una de RENDIMIENTO, que podemos activar para ver que ficheros se cargan, cuanto tardan en hacerlo, que sentencias SQL se ejecutan, y cuando tiempo tardan.

Según la versión, esta herramienta se activa de una u otra forma, lo dejo a vuestro criterio para que cada cual busque su método. Es importante saber que la activación de dicha herramienta arroja información tanto en el Back como en el Front, por lo que no es recomendable hacerlo en webs en producción, o en web abiertas al público.

Cuando activamos dicha herramienta, vemos en la parte inferior las diferentes sentencias SQL ejecutadas y su tiempo, como he comentado. Si vemos que alguna sentencia se va de madre, nosotros teníamos una que se iba a los 25 segundos, lo cual en términos informáticos son dos eternidades, podemos analizar dicha consulta y, en base a los campos comparados o usados en el filtrado, optimizar la tabla en concreto añadiendo nuevos índices.

Al añadir dichos índices, como índices sin más, no como claves únicas o foráneas, que si nos puede dar más de un problema, agilizaremos las búsquedas. En nuestro caso pasamos de una consulta de 25345 ms a 506 ms, es decir de más de 25 segundos a medio segundo.

Claro que el montaje de una página implica muchas llamadas a la base de datos y, por tanto, muchas SQL, pero podemos optimizar las más remolonas, que se notará.

Por ejemplo, en nuestro caso, la tabla remolona era ps_document_references, que se llamaba para revisar la existencia o no de facturas de devolución. En esta consulta se hace referencia a dos campos que no estaban indexados, id_document e document_type. Tan fácil como ir a PhpMyAdmin, mirar la estructura de esa tabla, y poner esos dos campos como índice. Después reparamos y/o optimizamos la tabla (esto no termina de convencerme de tener algún efecto, pero bueno… no cuesta nada) y la consulta se convierte en un rayo.

Obviamente hay que saber leer una sentencia SQL para saber que tablas y que campos están involucrados en ella, y detectar donde recae el peso de la consulta y, entiendo, que eso no está al alcance de todos los usuarios, pero siempre hay profesionales para esas cosas.

No sé si me ha quedado un poco técnico, pero espero que le sirva a alguien.

URL del sitio: Contenido solo visible a usuarios registrados