Hoy ha sido uno de esos días en los que me doy cuenta lo mucho que me gusta mi trabajo.
Ha habido un momento en que me he visto a mi mismo, allí sentado, con dos portátiles delante, uno mostrándome 9 consolas recibiendo los datos de 9 load tests (cada uno modelando un caso de uso del sistema) ejecutandose simultáneamente. El otro mostrándome un conjunto de gráficas sobre el estado del servidor de aplicaciones, todo en tiempo real.
En la misma sala, 5 equipos controlados desde las consolas ejecutando las pruebas y reportando información.
Terminada la primera tanda, decidimos modificar algunas pruebas, lo hago en el equipo que tengo delante (en 3 de las consolas), automaticamente los 5 equipos controlados reciben los cambios, ya estamos preparados para la segunda tanda.
20 minutos, ese el tiempo que he dejado correr los test, ese el tiempo que he tenido para pensar (y disfrutar) del tinglado que teníamos allí montado.
El resultado, una prueba que ha sometido al sistema a una carga muy cercana a lo que sería la mitad de los usuarios potenciales accediendo simultáneamente, y que nos ha dado un conjunto de datos muy valiosos.
Y por si eso es poco, llego a la oficina y me encuentro una sala con las paredes empapeladas con prototipos de una aplicación y anotaciones a rotulador, tres de mis compañeros comentado algo sobre unos de los posters, les digo “¿qué ha pasado aquí?“, y me contestan “nada, una sesión de trabajo con el cliente“… !impresionante!
Pues eso, me gusta mi trabajo ;-)
Categorías: Miscelánea
Cuando ejecutamos pruebas de carga sobre una aplicación web en un entorno de producción nos enfrentamos a una serie de restricciones:
- No podemos ejecutar ninguna herramienta en el entorno de producción. Debemos limitarnos a tocar parte de la configuración.
- No tenemos interfaz gráfica
- Las condiciones del entorno son “las que son”, no hay posibildad de cambio.
Para la ejecución de las pruebas no hay demasiados problemas, accedemos a modo de cliente, con herramientas como Tsung (comentada aquí hace poco tiempo) o The Grinder (con la que estoy teniendo una estrecha relación ultimamente, y escribiré algo pronto).
Los problemas vienen a la hora de tomar datos de rendimiento de la JVM mientras ejecutamos el load-test, que dadas las condiciones anteriores debemos hacerlo de forma remota. Hay varias herramientas que nos pueden ayudar, como son VisualVM o JConsole (ambas distribuidas con JDK 6). Yo me he quedado con JConsole por una sola razón: en modo remoto me proporciona más información sobre la JVM que VisualVM (para monitorizar en local, no hay duda, VisualVM es la elección).
Para configurar el acceso remoto de JConsole se debe lanzar la máquina virtual a monitorizar con las opciones:
-Djava.rmi.server.hostname=192.168.0.12
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9005
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Comprobamos desde la máquina cliente (la que usaremos para lanzar JConsole) que el puerto está abierto en la máquina objetivo (en el ejemplo 192.168.0.12):
Antonio$> nmap 192.168.0.12 -p 9005
Starting Nmap 4.53 ( http://insecure.org ) at 2009-06-14 21:26 CEST
Interesting ports on 192.168.0.12:
PORT STATE SERVICE
9005/tcp open unknown
NMap done: 1 IP address (1 host up) scanned in 0.144 seconds
Sólo queda iniciar JConsole:
Antonio$> jconsole 192.168.0.12:9005
JConsole monitoriza memoria, CPU, Threads y clases instanciadas, además muestra un dashboard muy útil:
JConsole Dashboard
JConsole Memory
JConsole Classes
JConsole Summary
Categorías: Herramientas · Java
Buscando herramientas para realizar labores de profiling Java he encontrado JIP (Java Interactive Profiler). Esta herramienta permite monitorizar a nivel de máquina virtual parámetros tan útiles como métodos que más tardan en ejecutarse, número de veces que se llama al método o el tiempo que ocupó su ejecución durante la vida del Thread que lo contenía.
Además su configuración es muy sencilla, algo poco común en el mundo del profiling Java. Tan solo es necesario iniciar la máquina virtual con los siguientes parámetros:
-javaagent:/antonio/jip/profile.jar -Dprofile.properties=/antonio/jip/profile.properties
En función del contexto en el que nos movamos estas propiedades se configuran de un modo u otro. Por ejemplo, si estamos monitorizando una aplicación web que es lanzada a través de un wrapper incluiremos entradas en el wrapper.conf, pero si nuestra aplicación está en un Tomcat sólo tenemos que incluirlas en $CATALINA_OPTS. Eso si, las rutas a profile.jar y profile.properties (ambos incluidos en la distribución de JIP) deben ser absolutas.
Al inciar la JVM debemos ver en los logs lo siguiente:
Java Interactive Profiler: starting
Si no, algo hemos hecho mal.
Para iniciar la monitorización haremos uso del cliente de JIP:
./file.sh localhost 15599 /Users/Antonio/temp/jip/jip-1.1.1/client/dump.txt
./start.sh localhost 15599
Esto inciará la sesión de profiling. Cuando hayamos realizado las pruebas oportunas:
./finish.sh localhost 15599
Si todo ha ido bien debemos tener en el directorio seleccionado dos ficheros nuevos: dump.txt y dump.xml. Para visualizar los resultados de una forma más amigable podemos usar jipViewer:
./jipViewer.sh dump.xml
La aplicación Java nos mostrará todos los datos del análisis:
JIP Viewer
Para terminar comentar que hay algunos detalles mejorables: la documentación en cuanto a interpretación de los datos es escasa y la aplicación monitorizada va mucho más lenta cuando se está monitorizando. Esto último es un factor común a todas las herramientas de profiling debido al uso de agentes Java que inyectan código para poder realizar los cálculos de tiempo necesarios.
Categorías: Herramientas · Java
Etiquetado: Java, Java Profiler, JIP, JIProf, Profiling
Ya hablaba de esto hace algún tiempo, y después de varios meses de trabajo hemos publicado la primera versión (0.1) de Sonar PDF Plugin.
En esta primera versión se ha optado por envolver la lógica de generación del reporte en un plugin para Maven, el cual está disponible en el repositorio central de Maven.
El reporte actual contiene:
- Información general del proyecto (nombre, descripción, version, módulos)
- Dashboard (indicadores proporcionados por Sonar, similar al dashboard que muestra Sonar en su interfaz web)
- Violaciones de reglas por categorías
- Reglas más violadas
- Ficheros que más violan las reglas
- Todo lo anterior para cada módulo que compone el proyecto (si existe alguno)
Ya hay algunas mejoras reflejadas en JIRA para la versión 0.2, seguiremos trabajando.
Categorías: Maven Plugins · Open Source · Software Quality
Etiquetado: Maven, Plugin, Sonar, Sonar PDF Plugin
