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.

La relación entre las pruebas de rendimiento y el tunning

Cuando las pruebas de rendimiento a un sistema end to end revelan que dicho sistema o algunos de sus componentes  son inaceptables, muchos equipos centran su atención en el tunning de la aplicación y su infraestructura con el objetivo de descubrir qué se necesita cambiar para que dichos elementos tengan una mejora en el rendimiento. Un equipo también puede cambiar su enfoque para afinar los criterios de rendimiento que se han establecido desde el principio, mediante la reducción de cantidad de recursos que utiliza con el fin de aumentar la capacidad del sistema o simplemente para optimizarla lo mejor posible y también disminuir el volumen del hardware empleado.

Esfuerzo Cooperativo.

          Aunque el tunning no es directamente responsabilidad del ingeniero de pruebas de rendimiento, este proceso es más eficaz cuando existe un esfuerzo de  cooperación entre los distintos roles involucrados de un proyecto u organización, tales como:

·         Empresas externas proveedoras de un servicio

·         Arquitectos de Software

·         Desarrolladores

·         Ingenieros de pruebas

·         Administradores de Bases de Datos

·         Administradores de Sistemas

·         Administradores de Redes

Sin la cooperación de estos roles es casi imposible tener toda la perspectiva de la arquitectura del sistema y por ende la resolución del problema de optimización  no se puede llevar acabo del todo bien.

El equipo de pruebas de rendimiento es un componente crítico de este conjunto cooperativo. Típicamente en el tunning de aplicaciones se requiere monitoreo adicional de componentes en específico, recursos, tiempos de respuesta bajo diferentes condiciones de carga y configuraciones. En términos generales el ingeniero de pruebas de rendimiento es quien tiene las herramientas y la experiencia para proporcionar esta información para facilitar la tarea de optimización.

Y a todo esto… Que es el tunning? A continuación una breve descripción de lo que es el proceso de tunning.