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).