Informes de Pruebas de Rendimiento.

Introducción

Una de las tareas más complejas con las que se encuentra un ingeniero de pruebas es mostrar de forma clara los resultados obtenidos en las pruebas de rendimiento. Esta complejidad es debida a:

• Las pruebas de rendimiento contienen un fuerte componente técnico.
• Ideas preconcebidas en los destinatarios del informe sobre los resultados que deben proporcionar las pruebas de rendimiento.

El éxito de las pruebas de rendimiento depende no solamente de una fase de ejecución efectiva, sino también de que los resultados obtenidos sean comunicados de forma comprensible.

Apartados del Informe de Pruebas de Rendimiento

Una aproximación a los apartados que debe contener un informe de pruebas de rendimiento, se muestra en el siguiente mapa mental (puedes acceder también desde aquí):

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.

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ón:  Validación de los requisitos de rendimiento desde el punto de vista operacional.

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

Gráfica 1. Extrapolación de consumo de CPU del modelo

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

Gráfica 2. Consumo de RAM

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

JMeter VII: Ejecución remota de scripts en JMeter.

Una de las características que presenta JMeter es la posibilidad de realizar la inyección de carga de un script desde varios equipos , de manera que se pueda aumentar el número de peticiones concurrentes/simultáneas a los servidores de la aplicación

Para lograr esto , hay que seguir una serie de pasos. En principio, son sencillos y no debe de presentar dificultad para un usuario novato lograr la ejecución de un script simple usando una o varias máquinas inyectoras.

Conceptos y requisitos previos.

Debemos tener en cuenta una serie de requerimientos previos, de sentido común, sobre los equipos controlador, inyectores y la aplicación a analizar.

1. El equipo controlador tendrá el script a probar, así como los ficheros de parámetros CSV Dataset definidos para la prueba
2. El equipo controlador tendrá conectividad con, al menos un puerto TCP de las máquinas inyectoras. Si debe ser un puerto explícito, esto debe ser configurado en el fichero jmeter.properties, sección “remote_hosts”
3. El equipo controlador almacenará todos los ficheros ,tanto de resultados de la prueba generados por los listener o escritores de datos simples, como los de log del comportamiento del jmeter (jmeter.log)
4. Los equipos inyectores tendrán los mismos ficheros de datos definidos en el script en las mismas rutas que se definen en el script.
5. Los equipos inyectores dispondrán al menos de un puerto TCP disponible con el que se comunicarán con el equipo controlador
6. Los equipos inyectores tendrán visibilidad sobre la aplicación a probar
7. Todos los equipos ejecutarán la misma versión de JMeter.
8. Los equipos inyectores , previo al lanzamiento de las pruebas ,tendrán en ejecución el proceso –servicio- demonio jmeter-server (.bat en el caso de Windows .sh en el caso de Unix)

La configuración de los equipos a actuar como inyectores remotos, se efectúa en el fichero jmeter.properties. Este fichero se encuentra en la ruta

JMETER_HOME\bin\jmeter.properties

El fichero tiene una sección “remote hosts” ,donde se incluye ,tanto los equipos que actuarán como inyectores remotos, como la configuración de los puertos TCP por donde se realizará la comunicación

#---------------------------------------------------------------------------
# Remote hosts and RMI configuration
#---------------------------------------------------------------------------

# Remote Hosts - comma delimited
remote_hosts=192.168.0.1,192.168.10.2,192.168.45.3
#remote_hosts=localhost:1099,localhost:2010

# RMI port to be used by the server (must start rmiregistry with same port)
#server_port=1099

# To change the port to (say) 1234:
# On the server(s)
# - set server_port=1234
# - start rmiregistry with port 1234
# On Windows this can be done by:
# SET SERVER_PORT=1234
# JMETER-SERVER
#
# On Unix:
# SERVER_PORT=1234 jmeter-server
#
# On the client:
# - set remote_hosts=server:1234

# To change the default port (1099) used to access the server:
#server.rmi.port=1234

# To use a specific port for the JMeter server engine, define
# the following property before starting the server:
#server.rmi.localport=4000

# From JMeter 2.3.1, the jmeter server creates the RMI registry as part of the server process.
# To stop the server creating the RMI registry:
#server.rmi.create=false

# From JMeter 2.3.1, define the following property to cause JMeter to exit after the first test
#server.exitaftertest=true

Tabla 1. jmeter.properties.Sección configuracion inyección remota

Invocación de inyectores remotos y ejecución de scripts


Una vez cumplimentados los requisitos y preparativos citados, la ejecución remota de scripts es sencilla. Dependiendo de si lo hacemos desde el entorno gráfico o desde línea de comandos.
Vamos a explicar ambos casos, aunque ,como cualquier que haya leido este blog, se recomienda vivamente para pruebas con niveles de carga altos, usar la opción desatendida.

Modo GUI

El modo del entorno gráfico, tiene una ventaja respecto al modo desatendido y es que permite incrementar la carga a lo largo de los inyectores a medida que avanza la prueba.

Para ello, lo que habría que hacer es ir seleccionando inyector remoto, tras inyector remoto , hasta que se llegue a los puntos de saturación o límites de carga buscados

Ilustración1. Opciones de inyección remota en modo GUI JMeter.

Modo desatendido (línea de comandos)

La manera de invocar la opción de inyección remota se haría con la siguiente sentencia y parámetros

JMETER_HOME\bin\jmeter -n -t RUTA_SCRIPT -R IP[,IP2,IP3...IPN] -X

Donde

• RUTA_SCRIPT es la ruta al fichero .jmx del script de prueba
• IP [,IP2,IP3...IPN] es el listado de las IP de los equipos inyectores
• -X es opcional.Indica que ,una vez finalizada la prueba, cierre el servidor de JMeter en los equipos inyectores

Uso de variables en pruebas de carga con inyección remota

Como todos sabemos, uno de los problemas que se presentan con JMeter, es la ejecución de scripts de manera remota. La razón básica es porque no permite la exportación de las variables del equipo que ejecuta el script .jmx a los equipos que actúan como inyectores remotos

Ejemplo.

Ilustración 2. Variables definidas por usuario en script JMeter

Lógicamente, uno esperaría que al ejecutar un script donde se definen estas variables, estas tomaran los valores definidos en todos los equipos de prueba. Pero, ignoro la razón técnica, no se conservan dichas asignaciones. Por lo que las referencias en los equipos, aparecen con las cadenas literales del nombre de la variable.

Así, la variable ${FECHA}, que en un escenario ejecutado desde el equipo local tomaría el valor del año-mes-día , aparecerá en las invocaciones que las use como la cadena literal ${FECHA}

Para solventar esto, por puro método de prueba y error, hemos observado que, si uno quiere usar variables compartidas entre todos los equipos inyectores debe incluir la llamada con el formato

${__property(${expresión a asignar a la variable})}

Es decir: el uso de variables en escenarios remotos debe efectuarse mediante invocación explícita con la llamada a la función ${__property(…)}.

Para el caso de FECHA, la manera de incluir en una petición de muestreador http (o en el nombre de un fichero) sería algo como

${__property(${__time(YMD)})}.

Esto, estimado lector, puede ser algo raro si se ha parado a leer alguna vez la definición de las funciones .En concreto la relativa a property

(http://jmeter.apache.org/usermanual/functions.html . Punto 19.5.9)

“The property function returns the value of a JMeter property. If the property value cannot be found, and no default has been supplied, it returns the property name. When supplying a default value, there is no need to provide a function name - the parameter can be set to null, and it will be ignored.”

Es decir, la función property evalúa una propiedad de JMeter definida en los ficheros de la aplicación jmeter.properties, user.properties o el definido en la invocación por línea de comandos con el parámetro

–Gficherousuario.properties

Sin embargo , si uno intenta llevar a cabo la implementación de parámetros a usar dentro de un fichero “.properties” ,con vistas a evaluarlos como variables con la función property, el resultado es nulo. La función no implementa la variable pasada como parámetro a la función y produce el mismo resultado en su invocación explícita que el que presenta si la definimos como una variable definida por usuario en la construcción del script.

Es decir, según la imagen anterior de “Variables definidas por usuario”, una invocación en un muestreador http, que utilizara la variable YEAR, que ha sido definida como una invocación a la función time con formateo de el año ( ${__time(Y)} )

Ilustración 3. Peticion HTTP con variable de usuario

Debería haber sido invocada como

Ilustración 4. Petición HTTP con variable remota

Por lo tanto, resumiendo para el uso de pruebas distribuidas con JMeter debemos de tener en cuenta:

• Las variables que definimos dentro del script de JMeter , deben ser explicitadas con la evaluación de la expresión que se desee mediante la función property
• Debemos recordar que la carga lanzada en varios inyectores remotos no se distribuye, sino que se ejecuta tal y como se define en el script.
• Es necesario invocar explícitamente a los equipos inyectores desde la línea de comandos con el parámetro –R IP1,IP2,IP3…IPN
• La inclusión de variables de un CSVDataset, forzosamente incluirá que todos los equipos inyectores tengan el mismo fichero de datos, en la misma ruta en la que fue definido en el script.
• Los equipos que actúen como inyectores remotos deben estar ejecutando el programa/servicio/demonio jmeter-server (en Windows jmeter-server.bat) y debe ser la misma versión de JMeter que el equipo que actúe como controlador del escenario.

Conclusión
Hemos llegado de momento, a finalizar esta exposición de conocimiento sobre JMeter. Quiero agradecer a mi compañero Federico Yansón el tiempo y esfuerzo dedicados, para lograr a comprender cómo lanzar pruebas remotas en JMeter de la manera más completa posible.