Medir, ajustar, monitorear.

Acá viene mi primer post técnico…

Sobre el final del cara a cara de java del último evento recomendé a los asistentes el uso de JMX. Una vez fuera de la sala una asistente me preguntó si tenía algo escrito sobre JMX en mi blog. Mi respuesta con un poco de verguenza…. “No tengo blog”.

Internamente me prometí que cuando empezara mi blog uno de los primeros post iba a ser sobre JMX en GeneXus y aquí estamos.

JMX (Java Management eXtensions) es una tecnología que permite monitorizar y administrar aplicaciones hechas en Java. Sobre .NET existe algo similar llamado WMI.

GeneXus hace uso de esa tecnología para hacer dos tipos de cosas en las aplicaciones generadas: Monitorear y medir la performance general.

Cuando estamos hablando de medir la performance general nos referimos a lo siguiente:

Encontrar las sentencias SQL que se ejecutan mas veces, las que tienen peor tiempo promedio, las que ocupan mas tiempo total de la aplicación, etc.

A la vez permite encontrar medidas similares para el caso de procedimientos.

Mi recomendación siempre es la de hacer un stress test antes de poner una aplicación en producción y sobre ese stress test analizar las medidas que nos tira JMX. De esa forma podemos analizar las sentencias SQL mas problemáticas y podemos realizar alguna tarea en el DBMS, o cambiar el código GeneXus para que la sentencias generada sea mas eficiente o porque no? usar cache de datos sobre esa tabla en caso de ser posible.

Como dije anteriormente lo otro que nos permite el uso de JMX en GeneXus es el monitorear el comportamiento de la aplicación.

A diferencia de la parte de performance que claramente es una tarea para hacer antes de poner una aplicación en producción, la tarea de monitoreo es sobre todo una operación para realizar sobre producción.

Entre las cosas que se pueden monitorear están, el uso del pool de conexiones, el estado de cada una de las conexiones a la base de datos, el estado del cache de datos, etc.

Además se pueden realizar operaciones en caliente sin tener que bajar la aplicación, como ser aumentar el tamaño del pool de conexiones o matar alguna conexión problemática.

A modo de ejemplo un posible caso de uso podria ser el encontrar un loqueo en la aplicación. Podriamos por ejemplo ver en el DBMS cuales son las conexiones que estan loqueadas, luego ir a buscar esas conexiones en JMX, y ver cada una de las conexiones cual es la sentencias que esta ejecutando y cual es el procedimiento que esta ejecutando esas sentencias. Eso tal vez nos permita encontar un posible error de programación.

Adicionalmente JMX permite el programar “alarmas”. Esto quiere decir disparar alguna acción como por ejemplo mandar un mail o un SMS a algún administrador en caso de que alguno de los medidores este dando un valor no deseado, por ejemplo que haya contención en el pool de conexiones o que alguna sentencia SQL fundamental en la aplicación este dando tiempos no esperados.

Todo lo anterior pretendió ser una explicación “marketinera” sin ir al detalle de la implementación, ni de su configuración en GeneXus, sino más bien para incitar a los desarrolladores de aplicaciones GeneXus a su conocimiento y su uso.

Los detalles para su uso los pueden encontrar en esta dirección:
http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Application+Monitoring+and+Management%3A+using+a+JMX+or+WMI+monitor,