Este artículo es, como todo lo que está en esta web, un ejemplo de qué herramientas disponemos para observar, medir y si se puede, corregir los rendimientos que nuestras aplicaciones de PHPRunner tienen.

En PHPRunner, se producen y ejecutan muchas querys que nosotros no definimos, en muchos casos desconocemos, y que en pocas ocasiones, pero muy importantes estas, tienen rendimientos que no son los esperados.

PHPRunner no te da muchas herramientas, una vez que se produce el “desastre” de observar y medir qué es lo que está pasando.

En el fichero “include/appsetting.php” en la primera sentencia se dispone de este código:

$dDebug = false;

Si ponemos “true” nos facilita trazas en el navegador, de los querys que hace pero al mezclar datos de traza con datos de aplicación, esto normalmente da muchos problemas y ayuda poco, aunque algunas veces puede ser suficiente.

Objetivo:

El objetivo del presente artículo es conocer todas las consultas que se hacen a la base de datos y una vez que se identifican las que nos pueden dar problemas, identificar planes de acceso del gestor de base de datos y algunas referencias de qué podemos hacer para mejorar los tiempos de acceso.

Explicaciones:

Lo primero que vamos a hacer en activar trazas en el gestor de base de datos de MySQL, para que nos informe de todos los querys que resuelve. Muy importante, estas trazas no se deben activar en sistemas en Producción porque va a hacer que el servidor sea más lento.

La herramienta que vamos a utilizar para observar y medir es MySQL Workbench.

Una vez instalada y configurada, accedemos a consultar nuestra Base de datos y accedemos a la consulta de status del gestor y su instancia.

Es muy normal no encontrarse con los ficheros de LOG activos. En la figura se ve el estado una vez que está configurado.

Para activarlos, en este caso, vamos a modificar el fichero “my.ini” que está en “Base Directory”  de la instalación de MySQL.

Muy importante – Antes de iniciar los cambios, hacer copia del fichero por si tenemos algún error/problema y tenemos que volver a la configuración anterior

Puede variar alguna de las variables, ya que dependerá de la versión de MySQL/MariaDB que estéis utilizando, pero son las marcada con brillo.

Si no se indica ningún Path los ficheros serán creados en el “Data Directory”. Son ficheros TXT, que podréis observar su contenido con cualquier editor.

Cómo podéis observar, se puede configurar un fichero para recoger los accesos que tardan más del tiempo (en segundos) que se fije. Esto puede servir para detectar problemas que desconocemos en qué punto de la aplicación se produce o por concurrencia de consultas “Slow Query Log”.

Para analizar una consulta he utilizado una aplicación muy simple y en la caja de consulta general he puesto un valor y el sistema me ha resuelto resultado.

En el fichero “FHUMANES.log” vemos todas las consultas que se han realizado y observo las que ha construido PHPRunner para resolver lo que nosotros le hemos indicado.

Podemos observar que hace (aún siendo un ejemplo muy simple) 2 querys nada simples.

Cada query que deseemos medir la copiaremos y la ejecutaremos en MySQL Workbench.

Explico las anotaciones que he hecho en la figura:

(1) .- Este botón nos permite poner en “bonito” la sentencia para que nos sea más legible.

(2).- En este botón “de lupa”, nos permite la información de la estrategia que va a utilizar el gestor de base de datos para resolver la consulta.

(3).- Este botón nos permite ver la información del Plan en formato gráfico o de tabla.

(4).- La información del Plan, donde nos explica si utiliza índices, parte de estos o hace una lectura secuencial de todos los datos.

Una vez que hemos observado y medido, nos toca corregir. Aquí nos os voy a dar una regla, pues no existe sólo una, si no muchas cosas que hay que tener en cuenta, por ejemplo:

• Ver si todos los campos que utiliza en la búsqueda son necesarios. Los que no se necesiten hay que indicar a PHPRunner que no los utilice en este tipo de consulta.
• Analizar los JOIN que pueda definir por los LOOKUP que hemos definido. Identificar si están bien definidas los FOREING KEY y los índices.
• Para tablas con muchos registros y muy volátiles, MyISAM te puede dar mejores rendimientos, pero no todo son ventajas, pues este tipo de almacenamiento no controla la integridad referencial.

Conociendo los problemas se puede definir cuáles son las soluciones.

Espero que os haya sido ilustrativo y para cualquier consulta, contactarme en [email protected].

PD
Muchos de los problemas de rendimiento vienen por un defectuoso diseño del Modelo de Datos. Si queréis mejorar vuestros diseños utilizar la parte de MySQL WorKBench de diseño y documentación de Modelo de Datos y veréis que vuestros sistemas mejoran considerablemente.