Jmeter: Análisis de Resultados

JMeter: Una aproximación al análisis de resultados

 A lo largo de varias entradas de este blog hemos aprendido las diferentes etapas que hay que cumplimentar para realizar pruebas de rendimiento con Jmeter.  Una vez realizada las pruebas llega el momento de recopilar la información y generar un informe de pruebas de rendimiento que sea comprensible y cumpla con los objetivos esparados.

Jmeter es una herramienta potente cuyo uso se ha generalizado en las diferentes etapas del desarrollo software. A pesar de que ha sido complementada con extensiones, la obtención de gráficas y métricas que muestren de manera sencilla los resultados puede implicar la realización de tareas manuales costosas que retardan la obtención de los informes.

La mayoría de herramientas comerciales de pruebas de rendimiento integran módulos de análisis y exportación de resultados. En la siguiente presentación se muestra como es posible obtener una herramienta que trate de manera automática los resultados obtenidos con Jmeter.

El "Tester del Futuro"

Actualmente nos encontramos ante un desarrollo tecnológico que está dando lugar a nuevos entornos y necesidades. Algunos ejemplos son:

• La proliferación de dispositivos móviles hace que al día se realicen millones de descargas de apps. Las apps para dispositivos móviles integran distintas tecnologías y a su vez pueden hacer uso de aplicaciones de terceros
• El Cloud Computing está tomando una gran relevancia debido a las facilidades que ofrece para que cualquier empresa pueda utilizar aplicaciones en Cloud de manera barata y accesible.
• Las aplicaciones son cada vez más complejas e integran componentes de distintas tecnologías y proveedores.

El testing, como cualquier otra actividad del desarrollo e implantación de los S.I., se ha adaptado a este nuevo entorno: herramientas, metodología, tecnología, etc...

El ingeniero de pruebas se ha renovado y adaptado a los cambios. Pero, ¿cuáles son las características del tester del futuro?, ¿y qué conocimientos debe tener?

Intentaremos enumerar algunos de los desafíos a los que se enfrentan los ingenieros de pruebas en el actual contexto tecnológico, pero... el futuro ya está aquí!!

SOAP UI y JMeter. Colaboraciones

En esta entrega, vamos a hacer un post absolutamente oportunista, combinando dos de las herramientas de prestaciones y calidad quizás más conocidas por los usuarios de este mundillo.
SOAP UI realiza pruebas sobre servicios web. Aunque ya se explicó en otro artículo, daremos unos breves apuntes sobre cómo acceder a un servicio publicado para realizar una grabación del mismo y combinarlo con la herramienta JMeter, para obtener un sistema de pruebas sobre dichos webservices. De esta forma combinaremos las capacidades de manejo de los WDSL de SOAP con las utilidades de análisis y las capacidades de monitorización (a través de los plug-ins) que permite JMeter.

Grabando un webservice. Conceptos y definición

En la pantalla de inicio de SOAP UI, podemos ver la invocación a un WDSL cualquiera  de ejemplo

• Diferentes métodos WDSL - XML descriptivo.
• Validación del WDSL.

Pruebas de rendimiento en Producción

1. ¿Pruebas en Producción?

Los entornos diseñados para pruebas presentan limitaciones a la hora de realizar pruebas de rendimiento:

• Los entornos de pruebas son de capacidad inferior a los entornos productivos. Se han diseñado esencialmente para realizar pruebas funcionales y para soportar niveles de concurrencias inferiores a las de producción.

• No son idénticos. El entorno de pruebas y el entorno de produción están configurados por elementos diferentes:
• Elementos de red: firewalls, encriptadores, balanceadores
• Sistemas Operativos diferentes.
• Configuraciones diferentes en los servidores.

• Generalmente, el volumen de datos almacenados es inferior en los entornos de pruebas.

Estas limitaciones implican que los resultados de las pruebas de rendimiento obtenidos en los entornos de pruebas no son extensibles a los entornos de producción. Más allá de que los tiempos de respuesta estén relacionado con la capacidad de las máquinas, en general, el comportamiento de un sistema o aplicación depende de la configuración y carácterísticas de los recursos. Todos hemos oído frases como "en el entorno de pruebas no conseguimos reproducir el error que se está dando en producción", o "en producción ese error no se va a dar porque la configuración es diferente".

Una posible solución, más usada de lo que a podría caber esperar, es realizar las pruebas de rendimiento directamente sobre el entorno de producción para garantizar que los resultados obtenidos y el comportamiento del sistema bajo pruebas sea similar al que los usuarios se van a encontrar una situación real.

 

2. Condicionantes de las pruebas en Producción

A la hora de diseñar y ejecutar pruebas de rendimiento en entorno productivos, debemos tener en cuenta algunos condicionantes y carácterísticas. Veamos algunos de ellos:

• Datos de prueba:
• En Producción, las pruebas se realizan sobre datos reales. El uso de usuarios, passwords u otros datos de prueba puedeestar sujetos a clausulas de confidencialidad.

• Ciclos de pruebas/modificación de datos: 
• Por defecto, los ciclos de prueba actúan sobre datos reales. Las actuaciones sobre los datos quedarán realizadas de manera real: Altas, Bajas, modificaciones, etc.. se realizan sobre datos reales.

• Inyección de carga:
• Tenemos que asegurarnos que nuestros inyectores de carga "atacan" a la aplicación a través de los mismos componentes que los usuarios reales. La situación habitual en la que los inyectores de carga se encuentran sobre la misma red que los servidores de la aplicación, puede implicar que las peticiones se salten ciertos elementos de red como firewalls, encriptadores, etc... que sí se encuentran los usuarios reales. 

• Intrusividad:
• Las pruebas sobre entornos productivos son intrusivas para los usuarios reales. Por ejemplo, pueden introducir retardos, sobresaturar elementos de la red etc...

Podemos aplicar distintas soluciones para solventar estos condicionantes. Entre ellos podemos citar la creación de datos ficticios dentro de la producción, conmuntar el entorno a una base de datos ficticia para su uso únicamente durante las pruebas, o la posibilidad de recurrir al cloud testing para la inyección de carga desde áreas geográficas externas a la red corporativa.

Para el disño de las pruebas en producción podemos realizar  un mapa menata en el que escribamos cada una de las fases y las posibles condicionantes o riesgos. Un ejemplo es el siguiente:

"Click" para aumentar la imagen

Think Time y Pruebas de Rendimiento

Definición:

En el ámbito de las pruebas de rendimiento, se define el Think Time o Tiempo de espera como el intervalo de tiempo que simula los instantes en los cuales un usuario de la aplicación está ocupado en realizar tareas de manera local.

• Ejemplos:
  
  

  
  • Un lector de un periódico on-line se encuentra leyendo una noticia.

• Un operador de un call-center cumplimenta los campos de un formulario con los datos que le indica un cliente que se encuentra al teléfono.

  
  
  
  
  

Criterio de calidad de las pruebas de prestaciones. Una aproximación

Introducción

Como bien sabe todo aquel que haya presentado en alguna ocasión un informe de pruebas de rendimiento, presenta de manera periódica la típica frase del solicitante de las pruebas:

“Si, el informe muy bien, los gráficos muy bonitos y demás, pero ¿cómo va la aplicación:mejor o peor ,bien o mal…?”

Habitualmente nuestra respuesta se basa en disponer de datos previos al lanzamiento de las pruebas, bien sea por criterios de rangos de rendimiento establecidos por los solicitantes de las pruebas (“se deben alcanzar las 300 transacciones por hora, con una concurrencia de 15 usuarios”) o si se trata de pruebas sobre aplicaciones con versiones en Producción, sacar datos de rendimiento históricos y extrapolarlos.

Sin embargo, muchas veces nos encontramos con la falta de este tipo de información y es cuando surge la pregunta ¿va bien o mal?

Proponemos un criterio que mezcle la subjetividad con los datos que podemos obtener de la prueba. El dato en el que nos podemos basar es el del tiempo en vacio.

Desarrollando el modelo.

Recordemos que esta métrica indica lo que tardaría un usuario sin concurrencia en realizar una navegación o ciclo de prueba. Si tomamos ese dato podemos extrapolarlo al número de operaciones que se pueden ejecutar a la hora. Una manera de establecer el criterio de calidad sería

“Si el usuario tarda 10 segundos en realizar una navegación completa, hará 360 transacciones a la hora”.

Si incrementamos el número de “N” usuarios virtuales/unidades de inyección de carga a lo largo de la prueba, en el punto de saturación debería hacer

Rendimiento teórico=N * transacciones/hora usuario virtual en vacio

Tabla 1. Fórmula del rendimiento máximo teórico del modelo

Como realmente lo que se obtiene en el punto de saturación son “M” transacciones por hora, un criterio de calidad fácil sería

Rendimiento real M / Rendimiento teórico N

Tabla 2. Cálculo del porcentaje de calidad real respecto del máximo teórico

expresado en forma de porcentaje.

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.

Unix (IV) .Monitorizando el sistema con lsof

Como indicamos en la última entrada, en esta entrega vamos a hacer un desglose de algunas de las opciones útiles de cara a detectar cuellos de botella en el sistema del comando lsof.

Este comando , permite generar un listado informativo acerca de los descriptores de ficheros asociados a uno o varios procesos. Esto entronca con la filosofía de Unix en la que el principio es que todo lo que hay en el sistema es un fichero

Ilustración 1. Man lsof v.4.76. Plataformas sobre las que existe versión de lsof

Mediante este comando, podemos, entre otras cosas,

• Verificar los procesos que generan un fichero específico
• Comprobar las conexiones TCP abiertas por un proceso
• Localizar los descriptores de fichero de varios procesos simultáneamente.

Sin embargo, un vistazo a la ayuda incluida en sistemas operativos como Solaris o HP-UX acerca del comando lsof no produce muchas certezas, sino más bien una expresión de desconcierto notable. Por ejemplo ,en Solaris 2.9, vemos que el man de dicho comando tiene una extensión de 3696 líneas (3432 en HP-UX v 11.23) , frente a las 726 del comando ps o las 594 de netstat.

Debido a la complicación del comando, he llegado a ver cómo se usa el comando pfiles como la “versión del pobre” a la hora de encontrar en qué puertos están escuchando procesos https://gist.github.com/227926

Sin embargo, dada la versatilidad de lsof, es más interesante hacer un breve recorrido por algunas de las opciones que permite dicho comando y una breve descripción de su utilidad. En este caso, sólo voy a adaptar la documentación que conseguí años ha en http://www.physiol.ox.ac.uk/Computing/Online_Documentation/lsof-quickstart.txt

Hemos de recordar también que la ejecución del comando lsof sobre procesos o sistemas de ficheros requiere de operaciones privilegiadas. Tanto en el sentido de tener permisos sobre dichos procesos o ficheros , como en el uso de operaciones de sistema a bajo nivel en el núcleo del mismo. Lo cual si que puede afectar a la estabilidad y rendimiento del sistema

Ejecución de lsof.

Localización de los procesos que tienen ficheros abiertos en un sistema de ficheros

$lsof /FILESYSTEM

Ilustración 2. ejecución de lsof sobre un sistema de ficheros

Número de descriptores de fichero abiertos por un proceso

$lsof –p PID

Lógicamente, esto se combina con la limitación de descriptores definidos para un sistema

Ilustración 3. Ejecución de lsof para averiguar el número de descriptores de fichero abiertos por un proceso

Podemos observar las sesiones abiertas en terminal (TYPE CHR , /dev/pts/6) por el proceso con PID buscado

Descriptores abiertos por un grupo de programas/ instancias de un servidor

$lsof – c CADENA_TEXTO

Hace operaciones suma lógica sobre distintas opciones , con -a

$lsof –p PID –au USER :

Lista los descriptores de fichero usados por un protocolo

$lsof –i

Ejemplo:

$lsof –i tcp

Ilustración 4. Ejecución lsof .Descriptores de fichero asociados al protocolo TCP

Podemos extender esto a las conexiones abiertas por un proceso específico a un puerto

$lsof -i:ssh

Ilustración 5. Ejecución de lsof sobre un puerto.

Recomendaciones sobre el rendimiento y estabilidad en uso de lsof.

Según se indica en el documento de referencia, el uso del comando lsof posee ciertas opciones recomendables de uso, para evitar que ejecute operaciones que puede afectar a la estabilidad del núcleo

$lsof –b

Asimismo también se puede ejecutar con opciones que permiten mejorar su rendimiento y tiempo de respuesta de cara a operaciones sobre red

$lsof –n : Evita lookups de nombre de host

$lsof –y: evita lookups de nombre de servicio

Nuestra próxima entrega:De lo global a lo sumamente especifico: sar y ptruss