Loadrunner 11.5. Revisión caracteristicas y análisis

Introducción

De nuevo un saludo a nuestros lectores .Con la frenética periodicidad de un asteroide de extinción masiva (más o menos), os presentamos un nuevo artículo para el análisis.

Como ya habréis visto en otro de nuestros post, habitualmente tratamos con Loadrunner como herramienta para pruebas de carga. En fechas recientes, hemos tenido la oportunidad de utilizar la última versión de esta utilidad, lider en el mercado de herramientas profesionales, y compartir con los lectores nuestras impresiones y conclusiones .

Vamos a hacer un recorrido por el proceso de instalación y los principales cambios que hemos observado respecto a las versiones 8.X y 9.X  , así como sobre el manejo de los componentes más relevantes.

Instalación

 

Pasos previos

Hemos podido comprobar que , dada la naturaleza de los protocolos más demandados últimamente (AJAX, Siebel ... etc) se ha procedido por parte de HP a incluir,como paso previo a la instalación la autoejecución de los plugins y distribuibles relacionados con los mismos. 

En concreto vemos que ,automáticamente al inicio de la instalación, se ejecutan los MSI de

• Microsoft Visual C++  2005 ,2008 2010 Redistributable
• Microsoft .NET  Framework Cliet & Extended
• Microsoft WSE 2.0 (SP3) -3.0 Runtime

 

Proceso de instalación

No vamos a extendernos en demasía respecto a los pasos que se siguen durante el proceso de implementación de Loadrunner en un sistema ( la guia de instalación es muy completa y los pasos son guiados en su mayor parte ) ,pero sí que procederemos a dar nuestra impresión

El procesos de instalación por lo demás, es bastante similar al de versiones previas, permitiéndote instalar sólo lo que se necesite para el destino final de la máquina :

• Tipo estación de trabajo de desarrollo (Vugen )
• Inyector de carga (Loadrunner Agent)
• Completo (Controler, Analyzer, Vugen, Monitoring…etc)

Imagen 1: Menú instalación Loadrunner 11.5

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.

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.

Estándares de Rendimiento

Si estamos buscando una guía de estándares de pruebas de rendimiento tal vez no tengamos suerte en encontrarla, porque no existe tal, pero hoy en día existen varios intentos informales de definir un estándar, particularmente para aplicaciones web. Probablemente hayamos escuchado esto: “en cuanto tiempo tarda en cargarse una página web?”. Tal vez en algún momento del tiempo se  pudo haber establecido una cantidad de 20 segundos que rápidamente con el paso del tiempo y la evolución de las computadoras  se haya convertido en 8 segundos. Por supuesto para un usuario y una empresa en general se requiere tener respuestas instantáneas, pero todo este tipo de mediciones siempre es difícil de alcanzar y establecer un estándar de lo que quiere un usuario.

Muchos SLA’s (Acuerdos de Nivel de Servicio) están enfocados en estándares de medición de rendimiento a la  infraestructura, en lugar de la propia aplicación y a menudo solo tratan áreas especificas tales como la latencia de red o la disponibilidad del servidor.

La siguiente lista resume las investigaciones realizadas a finales de los 80 (Martin 1988), que intentó mapear la productividad del usuario con el tiempo de respuesta. La investigación original se basa gran parte en aplicaciones de texto monocromáticas, pero sus conclusiones probablemente pueden ser relevantes.

Mayor a 15 segundos

Esta regla descarta la interacción conversacional. Para cierto tipo de aplicaciones, cierto tipo de usuarios, pueden estar contentos de sentarse frente a una computadora por más de 15 segundos esperando la respuesta de su aplicación. Sin embargo para un operador de un call-center este retraso puede ser intolerable. Si estos retrasos pueden ocurrir, el sistema debe ser diseñado de tal forma que el usuario pueda hacer otras actividades y obtener la respuesta en otro momento (procesos asíncronos).