miércoles, 14 de marzo de 2012

Pruebas de carga CITRIX con Loadrunner (1ª Parte)


1.- ¿Qué es CITRIX?

CITRIX es una empresa norteamericana dedicada al software de virtualización de sesiones y sistemas operativos. Este software permite tener un control preciso del software utilizado por la empresa, manteniendo la misma versión para todos los usuarios de forma que los administradores únicamente tengan que desplegar las mejoras en la “granja”* de servidores CITRIX. Administrando esta “granja” se puede permitir o restringir el acceso a una aplicación determinada a cada cuenta de usuario.


* Granja: Conjunto de servidores que contienen todas las aplicaciones publicadas.


2.- Acceso a las aplicaciones

Existen dos formas de conectarnos a las aplicaciones CITRIX, a través de un portal web o directamente a un servidor. Como veremos más adelante, dependiendo del tipo de conexión las opciones para la grabación con Loadrunner son distintas, aunque las instrucciones son comunes.

  • El método más común que nos vamos a encontrar es acceso a través de un frontal web. Por regla general es el tipo de acceso que van a utilizar los “clientes” del sistema. Se accede a la URL del frontal en el navegador y se debe introducir un usuario y contraseña. Dependiendo de los permisos otorgados por los administradores se nos presentarán una serie de iconos que nos dan acceso a las aplicaciones desplegadas en la granja CITRIX para este usuario.

sábado, 3 de marzo de 2012

Pruebas de Rendimiento: Tipos y objetivos

1 Introducción.
El concepto de pruebas de rendimiento de software (pruebas de prestaciones, performance test,....) a veces aparece como un término ambiguo que puede llevar a cometer errores sobre los verdaderos objetivos de este tipo de prueba.

En esta entrada intentaremos definir el concepto de prueba de rendimiento, los objetivos, y veremos los tipos de pruebas de rendimiento que podemos diferenciar en base a los objetivos perseguidos y la fase en la que se ejecutan

2 Pruebas de rendimiento (performance test).

El término de pruebas de rendimiento se encuentra definido dentro de la ISTQB y hace referencia al estudio del comportamiento de un sistema cuando se ve sometido a una carga que actúa de manera concurrente.


Hasta que un sistema no es sometido a carga, no podremos conocer su comportamiento, ya que las pruebas funcionales no suelen incluir niveles altos de concurrencia.

El elemento diferenciador de las pruebas de rendimiento es la existencia de concurrencia en el sistema. Desde este punto de vista, no se consideran pruebas de rendimiento: 
  • Aquellas pruebas encaminadas a optimizar procesos que se ejecutan de manera aislada, aunque sean procesos lentos o pesados que se alarguen en el tiempo
  • Las pruebas de volumen en las que únicamente se prueba como se comporta el sistema cuando funciona o procesa un volumen alto de datos.

3 Tipos de Pruebas de Rendimiento.
Dependiendo del objetivo perseguido podemos diseñar distintos tipos de pruebas.

  • Pruebas de Carga: Intentarán validar que se alcanzan los objetivos de prestaciones a los que se verán sometido el sistema en un entorno productivo. Por ejemplo:
    • Un sistema web debe soportar 3.500 reservas de viajes por hora con un tiempo de respuesta no superior a 6 segundos por página.
    • Se deben alcanzar 25 llamadas al servicio de localización geográfica con un tiempo de respuesta máximo de 2 segundos. 
  • Pruebas de Capacidad: Su objetivo es encontrar los límites de funcionamiento del sistema y detectar el cuello de botella o elemento limitante para poder actuar en caso de ampliación del servicio. Un ejemplo:
    • El consumo de CPU en los servidores de base de datos alcanza el 100% con un nivel de servicio de 3.950 operaciones por hora.
  • Pruebas de estrés: Someten al sistema a una carga por encima de los límites requeridos de funcionamiento. Situaciones de este tipo serían:
    • Puesta a la venta de un producto estrella en un canal de venta
    • Visitas masivas a una web de noticias ante un evento relevante
  • Pruebas de estabilidad: Comprueban que no existe degradación del servicio por un uso prolongado del sistema. 
    •  El sistema debe funcionar sin incidencia ni degradación del sistema durante 24 horas.
  • Pruebas de aislamiento: Provocan concurrencia sobre componentes aislados del sistema para tratar de detectar posibles errores en ellos.
  • Pruebas de regresión de rendimiento: Su objetivo es comprobar si se mantienen los niveles de rendimiento tras un cambio en el sistema, comparando el nivel de rendimiento (tiempo de respuesta, operaciones/hora, etc...) con el que ofrecía con anterioridad.
Será muy importante mostrar los objetivos de las pruebas que realicemos quede especificada en nuestro plan de pruebas de rendimiento para que posteriormente podamos detallar de manera comprensible los resultados en el Informe de Resultados.
4 La planificación de las pruebas de rendimiento
Uno de los problemas que presentan las pruebas de rendimiento es determinar el momento en el que se deben realizar y el entorno en el que realizarlas.

Como cualquier otro proceso de pruebas, cuanto antes comiencen a realizarse las pruebas de rendimiento, mayor será la calidad de nuestro sistema, se minimizará el número de defectos y se producirá un ahorro económico por la detección temprana de errores. 

Una buena estrategia es integrar las pruebas de rendimiento dentro del desarrollo del sistema. El objetivo en cada una de las etapas será diferente.


  • Pruebas Unitarias: Pruebas de rendimiento de los componentes desarrollados. Comprobaciones como:
    • tratamiento concurrente de las peticiones que recibe el módulo, 
    • paralelización en las peticiones, 
    • uso óptimo de los recursos (CPU, memoria, etc..), 
    • comprobación de cierre de los recursos de los que se haga uso (conexiones a la base de datos, etc,..), 
    • comprobación del número de peticiones concurrentes que recibe un componente hardware con diferentes configuraciones.

  • Pruebas de Integración:  Pruebas de rendimiento para comprobar que los diferentes módulos o programas funcionan correctamente de manera integrada. Al igual que en pruebas funcionales se pueden utilizar técnicas de botton-up o top-down. Con estas pruebas también es posible detectar posibles cuellos de botella en los componentes que se van integrando.

  • Pruebas de Sistema: Pruebas  a nivel funcional de nuestro sistema en situaciones de carga ( Altas, consultas, etc...)

  • Pruebas de aceptaciónValidación de los requisitos de rendimiento desde el punto de vista operacional.











jueves, 1 de marzo de 2012

Gestión de Capacidad.Conceptos y aplicación

Introducción

En el campo de las pruebas de prestaciones, la pregunta que más escucha el técnico promedio es “¿Y cuántos usuarios pueden trabajar como máximo sobre la aplicación?” . Esto suele llevar al técnico a repetir, por enésima vez en su experiencia profesional ,los conceptos de ciclo de navegación, transacciones por unidad de tiempo, concurrencia y simultaneidad, sesión activa…etc.
La segunda pregunta que más escuchará el técnico es “Y estos resultados ¿son extrapolables a Producción?”.

Es en esos momentos cuando se distingue las tablas que tiene el profesional, dando dos posibles respuestas, que más que respuestas son escuelas de pensamiento:

  • “El entorno de pruebas no es comparable, puesto que no tiene la misma infraestructura, ni tan siquiera a escala, siendo muy difícil establecer conclusiones válidas.”
  • “Sería conveniente hacer una prueba de gestión de capacidad .Rellene este formulario.”

Una prueba de gestión de capacidad(o "Capacity Planning"), es básicamente, una aplicación de un modelo teórico, en el cual, mediante la entrada de datos obtenidos de pruebas específicas de carga en un entorno controlado, se obtiene un patrón de comportamiento, que puede ser extrapolado a un entorno real de explotación.

En este modelo se obtienen predicciones del consumo de CPU, memoria y concurrencia ante la carga prevista e incluso, ante posibles incrementos de uso.

Breve descripción teórica

El modelo descrito en este artículo se basa en las siguientes hipótesis, que
deben cumplirse, para que tenga validez:

  • El tiempo de servicio es constante o depende linealmente del número de usuarios concurrentes.
  • Se dispone de datos suficientes para definir los ciclos de trabajo típico de un usuario de la aplicación, y su proporción de ejecución
  • El consumo de memoria es proporcional al número de usuarios concurrentes de la aplicación.

Aquí introducimos un concepto nuevo, que es el del
tiempo de servicio, que describimos como


"El tiempo de servicio es la cantidad de tiempo de procesamiento en una CPU
necesario para la ejecución de un ciclo de trabajo completo."

De este modo, podemos, mediante tablas comparativas entre máquinas, extrapolar los tiempos que tardaría cada ciclo, sobre una máquina distinta, tanto en número, como en potencia de procesadores.

Otro concepto que surge es el llamado factor de corrección, que básicamente indica a cuantos procesadores de una máquina A, equivale un procesador de una máquina B.
Aplicación del modelo

Es en este punto cuando el técnico de prestaciones empieza ya a tratar con conceptos familiares, como “escenario”, “proporciones de carga”, “métricas de monitorización” y demás ideas que emplea en el día a día

Al aplicar el siguiente modelo hemos realizado los siguientes pasos:

  1. Hemos lanzado una prueba, en la que la carga se reparte
    progresivamente en varias etapas hasta llegar al 100% del rendimiento,
    Durante esta prueba se ha medido el consumo de la CPU, memoria y el
    número de usuarios concurrentes
  2. La carga es el número de transacciones (ciclos) dividido por el tiempo
    total de la prueba, que proporcionará la herramienta de carga. Aplicando
    la fórmula se obtiene el tiempo de servicio:
Ts = num_procesadores_A x %CPU / TPS

Donde:

  • Ts es el tiempo de servicio, que es constante
  • numero_procesadores_A es el número de procesadores de la máquina donde quedemos medir el tiempo de servicio
  • %CPU es el consumo de CPU de la maquina cuando alcanza…
  • TPS, que es la carga medida en número de transacciones por segundo
La extrapolación del tiempo de servicio a otra máquina se logra dividiendo el tiempo de servicio entre el factor de corrección
Extrapolando,que es gerundio

El modelo que define el consumo de CPU en función de la carga (TPS) y del
número de procesadores de la máquina:

%CPUe = TPS x Tsf / num_procesadores_B

  • %CPUe es el consumo de CPU extrapolado
  • TPS es la carga medida en número de transacciones por segundo
  • Tsf es el tiempo de servicio factorizado, que es constante
  • num_procesadores_B es el número de procesadores de la máquina a la que se quiere extrapolar
Por otra parte, se considera que el consumo de memoria es proporcional al
número de usuarios concurrentes:

Memoria = a * u + b
Donde:
  • Memoria será la estimación de la memoria en Kbytes.
  • a el consumo para cada usuario
  • u el número de usuarios concurrentes
  • b el consumo mínimo de memoria (aplicación en vacío)
Resultados e interpretación.

La aplicación de este modelo, de manera que se obtengan las fórmulas antes citadas, permite generar funciones en las que sustituir valores y hacer predicciones de consumo de CPU,memoria , rendimiento en transacciones,usuarios…sencillamente interpretando un sistema de ecuaciones

  • CPU

Los valores de esta gráfica se obtienen en base a las medidas del consumo de CPU y transacciones por segundo (en la gráfica hemos indicado “por hora”, pero eso, el avezado lector lo podrá hacer de manera sencilla) , promediadas a lo largo de varios intervalos de muestra durante el escenario de carga.

Su interpretación es bien sencilla: para un nivel de 12.000 transacciones por hora , que sería la media de la prueba) el consumo extrapolado con la fórmula citada en el punto “Aplicación del modelo” , el consumo de CPU en la máquina destino de la extrapolación sería del 5,7%.

Podemos también interpretarlo como una predicción, es decir, si quisiéramos ver cuánto consumo de CPU sería necesario para alcanzar las 20.000 transacciones por hora , se consumiría un 9,83% de CPU, aproximadamente

  • Memoria
Los valores de esta gráfica se generan en base a las métricas de usuarios concurrentes y memoria consumida a lo largo de la prueba, promediadas en diferentes puntos a lo largo de la carga. A partir de ellos, mediante un gráfico de dispersión y una línea de tendencia, sacamos la función que determina el comportamiento de la memoria


Memoria = 3543,5 x usuarios +167317

Esto nos permitiría saber cúanta memoria consumiria para “n” usuarios concurrentes.


Nota
Es necesario tener en cuenta que la memoria máxima
definida en la instancia de web debe tener el
tamaño máximo suficiente como para poder albegar a los usuarios
También hay que tener en cuenta los casos de balanceo entre máquinas, así como las particularidades de los productos a monitorizar



Bibliografía

Entre varios artículos, documentos propios de trabajo ,destacar los siguientes

  • Capacity Planning for Web Services (Daniel A. Menasce, Virgilio A. F. Almeida).2002
  • Calculus (Spivak). 3ª Edición .1994