Jmeter : Revista de actualidad . Revisando la versión 2.9

Saludos a todos los jotaemeteros. Como bien sabrán nuestros lectores habituales, la información proporcionada sobre la utilidad de pruebas Jmeter es una de las especialidades de este blog. Por lo que, siguiendo nuestra línea de oportunismo y descaro habituales, aprovecharemos para hacer un nuevo artículo que, creemos  será útil para los usuarios habituales y visitantes ocasionales.

Jmeter versión 9.

Analizamos en este post la última versión  disponible de Jmeter publicada en la web oficial. En concreto es la 2.9 r1437961

 

Introducción

En anteriores entradas de nuestro monográfico de Jmeter, hemos estado trabajando con las versiones 2.4 y 2.5.1 . Tras diversas experiencias en el día a día con las mismas sacamos algunas conclusiones acerca de su fiabilidad para pruebas con diversas navegaciones y en el aprovechamiento de recursos.

Estas conclusiones se pueden resumir en

• Un elevado uso de recursos en la ejecución de pruebas con el interfaz de usuario gráfico iniciado
• Problemas con la ejecución de escenarios que reflejen navegaciones múltiples de usuario.
• Falta de compatibilidad con scripts grabados con  versiones  distintas a la del inyector.
• Tasa de errores elevada de la versión 2.5.1 con peticiones HTTP sobre AJAX.

Sigue sin resolverse el problema de compatibilidad, siendo al parecer inherente a esta utilidad ,aunque ya desde la versión 2.8 ,se solventó el de las peticiones HTTP sobre AJAX

Cambios en el interfaz.

Hasta la versión 2.6 no se introdujo la “barra gráfica “ que adorna el interfaz de usuario de Jmeter. En este aspecto, no se observan prácticamente cambios entre versiones,salvo la marcada con el circulo rojo

Gráfica 1. Barra de herramientas UI JMeter v 2.6

Gráfica 2.Barra de herramientas UI JMeter v 2.9

JMeter Revista de actualidad . Plugins versión 0.5.6

Plugins versión 0.5.6

En esta nueva entrega de los plugins, vemos un nuevo juego de los mismos a usar.

Como novedades particularmente interesantes –desde nuestro punto de vista- , indicamos  los siguientes

Una nueva opción de los listener que muestran gráficas o datos durante la prueba, es la posibilidad de expandirlos a pantalla completa , pulsando sobre el ícono   

AutoStop Listener.

Este listener permite intrroducir criterios de parada en la carga , de manera que si, se superan ,la carga se detiene. 

Gráfica 1.Listener de autostop.

Unix V. Parámetros de monitorización de red.

Es tiempo de reencuentros en qatecnico. Tras este largo paréntesis en nuestros artículos relacionados con nuestro sistema operativo preferido, volvemos con una nueva entrega que puede ser de utilidad para aquellos que se dediquen a monitorizar el rendimiento del sistema.

Comandos de consulta de configuración de sistema.

Una situación típica durante la preparación de unas pruebas de rendimiento de sistema, es averiguar si la máquina sobre la que estamos monitorizando tiene (o responde) por una serie de IP como propias . Habitualmente , para averiguar estos datos , se puede proceder de dos modos : 

• como usuario con permisos administrativos de la máquina . 
• usuario sin permisos especiales

 

Consulta como usuario privilegiado

En el primer caso, el comando a ejecutar sería el que permite realizar cambios de la configuración de los interfaces de red de la máquina. Dicho comando es el ifconfig

Para usarlo con meros propósitos de consulta, debemos ejecutar en  línea de comandos ifconfig. Mostramos un ejemplo sobre un sistema con sólo una tarjeta de red

[root@mortadelo ~]# ifconfig eth0      Link encap:Ethernet  HWaddr 00:04:C5:06:F3:BF            inet addr:192.168.9.64  Bcast:192.168.9.255  Mask:255.255.254.0           inet6 addr: ff50::142:c2bf:fe06:f3:bf/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:3581337903 errors:0 dropped:0 overruns:0 frame:0           TX packets:3956497861 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:1572087099 (1.4 GiB)  TX bytes:2666945600 (2.4 GiB)           Interrupt:16 lo        Link encap:Local Loopback            inet addr:127.0.0.1  Mask:255.0.0.0           inet6 addr: ::1/128 Scope:Host           UP LOOPBACK RUNNING  MTU:16436  Metric:1           RX packets:8461 errors:0 dropped:0 overruns:0 frame:0           TX packets:8461 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:0           RX bytes:6134634 (5.8 MiB)  TX bytes:6134634 (5.8 MiB)

  

Pruebas de carga CITRIX con Loadrunner (3ª Parte)

Continuamos  nuestro recorrido por las pruebas CITRIX con la parte más importante del ciclo de grabación, la sincronización.

6.- Sincronizando...

La sincronización es el paso indispensable para que la grabación en CITRIX sea exitosa. Como comentábamos en el artículo anterior, este tipo de grabaciones no va por eventos o URLs como sucede en otros protocolos más comunes, sino por coordenadas asociadas a pulsaciones de ratón y/o teclado. Por lo tanto después de cada acción debe establecerse algo, una sincronización, para que el usuario virtual espere a que se cargue el evento, la ventana o los datos, antes de realizar la siguiente, de lo contrario podrían producirse eventos inesperados. Estas sincronizaciones deben realizarse en objetos, textos…. que no se encuentren en el estado anterior a la acción realizado.

Se pueden diferenciar dos tipos de sincronización dependiendo de la presencia o ausencia del agente CITRIX de LoadRunner en el servidor CITRIX:

Pruebas de carga CITRIX con Loadrunner (2ª Parte)

Tras este “corto” periodo de silencio vamos a continuar con los consejos de grabación sobre CITRIX con LoadRunner.

En el anterior artículo nos quedamos en los consejos previos a la grabación incluyendo los métodos de conexión a la granja CITRIX, durante este segundo post nos centraremos en la grabación propiamente dicha.

5.- Grabando...

El cuadro de control del proceso de grabación será el siguiente:

	Paramos la grabación, finaliza la ejecución y genera el script.
	Pausamos la grabación, no se graban los eventos hasta que volvamos a pulsar el botón de grabación.
	Aquí estableceremos en la parte que nos encontramos (vuser_init, Action, vuser_fin)
	Start Transaction (Comienzo de una transacción)
	End Transaction (Fin de la transacción)
	Sincronizar por bitmap (imágenes).
	Sincronizar por texto.