Visión General de las Pruebas de Rendimiento (II)

El siguiente paso a dar, es conocer bien la arquitectura del sistema que se pretende probar, esto es importante, aunque no sea experto en arquitectura de sistemas, para que al momento de la ejecución de las pruebas, sepamos situar el problema ó cuello de botella.

El conocer el modelo o arquitectura del sistema nos llevará a un análisis mas profundo de las pruebas y determinar la forma de lanzamiento de las pruebas, es decir, desde que capas vamos a atacar.

No existe una formula matemática para calcular la cantidad de carga que vamos a inyectar a algún sistema, pero existen los modelos de uso que nos permiten saber cual es la carga aceptada por el sistema (basados en estadísticas de producción, si el sistema está ya implementado. Cuando el sistema es nuevo es necesario que, una vez que se ha determinado desde que capa de la arquitectura se va a lanzar las pruebas, es necesario hacer pruebas distintas (carga en vacío, estrés, estabilidad) con el objeto de obtener mediciones y poder determinar que niveles de carga acepta el sistema.).

Es importante que al momento de realizar estas pruebas, se comience a monitorizar los sistemas o elementos afectados (por los cuales pasa la pruebas, o los que sean de interés).

Continuará…

(Próximamente: Mejores prácticas de HP LoadRunner VUGen)

JMeter (II). Casos de Prueba

Continuando con la entrada anterior, seguimos describiendo el proceso de preparación de un caso de prueba.Ahora con la parametrización de un script.
 

Cada petición que se incluye en el script, puede ser modificada para:

· Cambiar los parámetros con los que hace la invocación al servidor

· Parametrizar las peticiones de manera que use un fichero para cada ejecución

· Especificar un servidor Proxy para acceder a direcciones externas

· Indicar timeout de petición

El cambio de parámetros dependerá de si están incluidos en la URL de invocación

O, si se capturan en la sección correspondiente 

En este caso, el parámetro mediador_Aceptacion.aceptacion.nif, tomará el valor definido en la variable ${NIF}. Esta variable puede estar definida como un Elemento de configuración: Variables definidas del plan de prueba o bien como una variable de un CSV Dataset

Ilustración 1. Configuración variables definidas por el usuario

Ilustración 2. Configuración fichero CSV Dataset

La invocación a las variables se realiza con el formato ${NOMBREVARIABLE}. Las variables tienen ámbito global dentro del plan de pruebas, por lo que pueden ser referenciadas a cualquier nivel dentro del mismo. Habitualmente, para pruebas de carga, se usan variables definidas dentro de un fichero 

Ilustración 3. Ventana de configuracion de fichero de parámetros (CSV DATASET)

Nombre descriptivo del fichero Campo de texto libre Ruta al fichero CSV(separado por carácter) Variables (una por cada columna) Caracter delimitador entre campos Permite datos entrecomillados Reinicia al llegar al final del fichero

Las peticiones admiten también el uso de funciones para el paso de parámetros. JMeter proporciona una ayuda –aunque no muy extensa- sobre el uso de las funciones. Para ello, en las opciones del menú gráfico, seleccionamos el elemento “Diálogo de Ayuda de Función”

Ilustración 4. Opción de menú funciones

Seleccionando esta opción, podemos insertar, dentro del elemento muestreador o declaración de variables esta invocación a función.

Por ejemplo, podemos crear una variable con la fecha formateada para usarla en diferentes operativas dentro de la lógica de la navegación –como un parámetro de envio de una petición HTTP – o bien dentro del manejo del propio script –un fichero de resultados que contenga ese campo de tipo fecha en el nombre o en alguno de los registros que capture-

Ilustración 5.Diálogo de Ayuda de función

Una declaración de función para generar una fecha en formato año/mes/dia y que la volcara a una variable FECHA, la crearíamos así

${__time(YMD,FECHA)}

Podemos invocar a la llamada a dicha función dentro de los parámetros de una petición HTTP, sustituyendo el valor que tuviera capturado durante la grabación, por el nombre de la función, marcando la casilla de “¿Codificar?” del parámetro
 

Ilustración 6.Invocación a función

Esta opción haría que en cada invocación, se ejecutara la función dando la fecha en el momento. En el caso de que se utilizara ${FECHA} en la invocación tendría el valor del momento en el que se invocara explícitamente a la función.

En el caso de la función de tiempo, los valores por defecto que proporciona JMeter son el tiempo en milisegundos dede el 1 de Enero de 1970. Para cambiar el formato que utiliza la función es necesario modificar el fichero que está en la ruta de instalación del JMeter->directorio “bin” y que responde por jmeter.properties En concreto la sección # Timestamp format - this only affects CSV output files # legitimate values: none, ms, or a format suitable for SimpleDateFormat #jmeter.save.saveservice.timestamp_format=ms Por esta opción jmeter.save.saveservice.timestamp_format=yyyy/MM/dd HH:mm:ss.SSSS

Se puede especificar que las peticiones http se redirijan a través de un Proxy específico
 

Ilustración 7. Configuración red de muestreador HTTP

Se configuran los parámetros de nombre o servidor IP del Proxy ,el puerto ,así como los datos de usuario y clave necesarios para validarse en dicho Proxy (si aplica)

Otro campo interesante es es el de Embebbed URLs. En este apartado, podemos especificar el dominio o “patrón” de las URL desde las que se quiere mantener comunicación ,ya sea de envío o recepción.

Otros elementos útiles para la correcta ejecución funcional del script o grupo de hilos, son:

· Gestor de autorización http: Permite el envio de pares usuario/contraseña a una URL de autenticación

· Gestor de cabecera http: Permite definir la cabecera común a todas las peticiones http, salvo que se defina una cabecera específica para alguna en particular

· Gestor de Cookies http: Permite que JMeter gestione de manera automática las cookies que envia el servidor para la identificación de sesión

· Gestor de caché http. Simula el comportamiento de la caché de navegador.

Continuará…

Visión General de las Pruebas de Rendimiento (I)

Con frecuencia escuchamos el término pruebas de rendimiento, e inmediatamente se viene a nuestra cabeza el hecho de hacer pruebas a una aplicación web.

  El termino de pruebas de rendimiento (performance, prestaciones, etc, etc) muchas veces es tomado de forma errónea por diferentes profesionales de las empresas que se dedican al desarrollo de software, incluso por los que nos dedicamos a hacer pruebas de rendimiento.

  Una prueba de rendimiento evalúa el comportamiento de un sistema completo o cualquiera de sus elementos (back-end, front, middle-ware) conforme a un requerimiento especifico. Esto generalmente es posible, mediante una herramienta de prueba automática, capaz de simular un gran número de acciones simultaneas que nos permita llegar a tal objetivo.

  Lo que he considerado el punto clave en la concepción de este tipo de pruebas, es que las tareas comiencen desde el inicio de desarrollo del sistema, y aún más importante saber cual es el modelo de uso del mismo. Por modelo de uso, me refiero a saber cuales son las características más usadas del sistema (o las acciones que más importancia e impacto tienen, si estamos hablando de una aplicación web). También habría que considerar todas las capas que involucran las pruebas, para que en momento dado, sepamos donde situar los problemas que puedan resultar.

 
 Los modelos de uso nos darán la pauta para plantear los objetivos, que mas adelante cuando estemos listos para realizar las pruebas, tendrán que alcanzarse y lograr su cumplimiento.

Continuará...

Ancho de banda disponible en Cloud Testing

1 Ancho de banda en Cloud Testing

Durante las pruebas de rendimiento de un sistema es importante asegurarnos que no existe ningún elemento ajeno a la aplicación que pueda actuar como limitador de la inyección de carga. La capacidad de los inyectores de carga y el ancho de banda disponible deben ser elementos que debemos tener controlados durante un proceso de pruebas de rendimiento. En esta entrada nos centraremos en los problemas asociados al ancho de banda y a la lantencia. 

En un entorno clásico de pruebas (hosting), los inyectores de carga se sitúan "lo más cercanos" posible a los servidores de la aplicación bajo pruebas. Esto permite disponer de un ancho de banda próximo al de la red corporativa y que las peticiones que realicen "pasen" por un número mínimo de elementos de red (routers, hubs, switches, etc...). 

En la actualidad, el crecimiento de entornos Cloud, y la necesidad de utilizar técnicas Cloud Testing para realizar las pruebas de rendimiento impide que tengamos controlado el ancho de banda del que disponemos. Los inyectores de carga en un entorno Cloud Testing se encuentran distribuidos en situaciones geográficas alejadas de los servidores, de forma que la red puede influir negativamente en nuestras pruebas.

2 La red como cuello de botella

Después de realizar una prueba de rendimiento podemos encontrarnos un punto de saturación que no corresponda con la saturación de otros elementos en la plataforma de la aplicación: CPU de los servidores, memoria, etc...

Cuando se produce esto, es necesario que nos tomemos un tiempo en comprobar el ancho de banda del cual disponemos para asegurarnos que la red no es un cuello de botella.

El Test de ancho de banda es aplicable a entornos de pruebas clásicos donde los inyectores se encuentran dentro de la red corporativa, pero es extremadamente necesaria realizarla cuando las pruebas de rendimiento se realizan sobre entornos de Cloud Testing, ya que en ese caso la red no es un elemento que podamos controlar, y es necesario seleccionar aquellos inyectores de carga en una situación geográfica adecuada.


3 Test de ancho de banda 

Los problemas asociados a la red en las pruebas de carga no son fáciles de desenmascarar. De hecho, demostrar que la red es un cuello de botella para nuestras pruebas de carga es una tarea complicada. En cambio, demostrar la red NO es el problema, es una tarea relativamente sencilla.

El Test consiste básicamente en realizar una prueba de carga contra una URL de nuestra aplicación controlando el tamaño de la misma y las carácterísticas. Nuestros scripts y nuestra herramienta de pruebas la debemos configurar adecuadamente:

• La URL debe hacer referencia a un elemento estático de nuestra aplicación. No es conveniente seleccionar peticiones que implique a la capa lógica de la aplicación.
• El tamaño del elemento estático no debe ser excesivamente pequeño. Un tamaño entre 50 y 500 Kbytes es suficiente. En otro caso nuestra en prueba podría verse afectada por la propia latencia de red.
• Debemos seleccionar peticiones que implique elementos "non-compressible" y que en las cabeceras de la  petición aparezca explicitamente la opción "non-compressed". De esa forma garantizamos que los servidores no comprimirán el elemento que estamos pidiendo en el test.
• Debemos usar peticiones persistentes. Forzar a que se abra una nueva conexión en cada petición añade una mayor latencia.
• No utilizar peticiones SSL. La encriptación es un procedimiento costoso y añade un mayor tiempo de respuesta.
• No utilizar la simulación de caché de los navegadores durante la prueba. En caso contrario la petición no recibirá el tamaño completo del elemento, tan solo la confirmación de que el elemento no ha cambiado y que se encuentra cacheado (HTTP code 304).
• Realizar la prueba seleccionando varios inyectores de carga. Idealmente intentaríamos realizar el test de ancho de banda con los mimos inyectores que en la prueba de carga de nuestra prueba.
• Utilizar un número de Usuarios Virtuales relativamente elevado (superior a 10).

Una buena solución es seleccionar para la prueba un elemento ya comprimido y de tamaño medio. Por ejemplo elementos con extensión *.gif, *.mp3, etc... A modo de ejemplo se muetra una petición de URL en la sintáxis de LoadRunner:

    web_url("icoazul.gif",
        "URL=http://servidor:puerto/base/img/icoazul.gif",
        "Resource=1",
        "RecContentType=image/gif",
        "Referer=http://servidor:puerto/base/frameabajo",
        LAST);

Con estas condiciones realizaremos una prueba de carga y observaremos los resultados del througput (Bytes/s) que obtenemos durante ella. 

Si el througputh alcanzado en el test de ancho de banda es superior al alcanzado en la prueba de rendimiento contra la aplicación, debemos descartar que la red no puede ser un cuello de botella, y que por lo tanto debe existir otro elemento que limite el rendimiento de nuestra aplicación.

En el caso de el througputh sea similar en el test de ancho de banda y en la prueba de rendimiento, cabe la posibilidad de que hayamos saturado la capacidad de inyección de los inyectores. En ese caso debemos repetir el test pero seleccionando un número mayor de inyectores. Si doblamos el número de inyectores, el throughput debe incrementarse en la misma proporción. Si por el contrario el throughput se mantiene en los mismos valores, debemos valorar la posibilidad de que la red sea un cuello de botella en nuestra capacidad de inyección.

JMeter(I). Primeros Pasos

Jmeter (I). Primeros pasos

En esta serie de artículos, vamos a tratar sobre una de las herramientas más populares que se encuentran disponibles en la actualidad para las pruebas de carga. Las razones que la avalan son su disponibilidad, su amplio uso por la comunidad de técnicos y su flexibilidad.

Un poco de biografia.

Un breve vistazo a la página oficial (http://jakarta.apache.org/jmeter/index.html) nos cuenta que JMeter es una aplicación de código libre, basada en el lenguaje 100% compatible Java , diseñada para pruebas funcionales y medición de rendimiento. Inicialmente se usaba únicamente para pruebas de aplicaciones web, pero se ha extendido a otros entornos.

Soporta entre otros, los siguientes protocolos

· Web - HTTP, HTTPS

· SOAP

· Database via JDBC

· LDAP

· JMS

· Mail - POP3(S) and IMAP(S)

Asimismo, permite la inclusión de código ejecutable creado por el usuario basado en diferentes lenguajes de scripting a través de un módulo llamado Beanshell scripting. Esto permite realizar determinadas tareas en las pruebas, como validación de respuestas específicas, creación de flujos de control dependiendo de las respuestas recibidas, correlación…etc. Sin embargo, no es una tarea simple y su uso requiere de conocimientos avanzados de programación en los lenguajes de scripting y su adaptación al módulo de JMeter.

Instalación

La instalación de la herramienta es muy sencilla. Básicamente requiere de dos cosas

· En entorno de ejecución Java (JRE), que se puede obtener de http://java.sun.com

· El binario distribuido por la web disponible en (http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi)

· También se encuentra disponible el fuente de la aplicación, para compilarlo directamente en el equipo o, si uno tiene la capacidad y las ganas, realizarle modificaciones de acuerdo a la licencia GNU.

Es conveniente incluir las siguientes variables en el sistema

• JAVA_HOME ;Indicando la ruta de instalación definida para la JRE.

• JAVA_BIN ; Indicando la ruta JAVA_HOME/bin, para indicarle el binario.También se puede incluir en la variable de entorno PATH

• JAVA_LIB ; Indicando la ruta JAVA_HOME/lib, para incluir las librerias

Las últimas versiones del JRE (al menos bajo Windows), crean este tipo de variables y actualizan el entorno para que sea transparente al usuario

Grabación de navegaciones

Como otras herramientas, el concepto de ciclo de navegación está presente en JMeter. Básicamente trataremos de reproducir la secuencia de navegación deseada, capturando las peticiones HTTP lanzadas por un navegador, modificándolas para parametrizarlas y tratar sus respuestas para comprobar su validez o reutilizarlas en peticiones siguientes.

Aunque la herramienta permite crear peticiones de manera directa, tecleando directamente la secuencia de URLs a probar, lo más común es utilizar un navegador y capturar dicha respuesta. Para ello utilizaremos dos elementos de JMeter:

· El Banco de Trabajo

· El plan de pruebas

El Banco de trabajo podemos considerarlo como la parte de configuración y grabación online de las navegaciones. Un detalle MUY IMPORTANTE es que lo que se añade a este elemento NO SE GRABA, estando sólo disponible mientras si se mantenga la instancia de JMeter abierta

El Plan de Pruebas podemos considerarlo como una mezcla entre “script” que reproduce la navegación y el escenario que los ejecuta.

Es muy útil hacer una planificación previa sobre lo que se va a grabar, dividiéndolo en pasos o subtransacciones, de manera que tengamos claro a qué paso pertenece cada petición. Esto nos permitirá no sólo tener un flujo de control sobre la navegación, sino que permitirá realizar mantenimientos sobre el script de manera más sencilla . Hemos creado sobre un Thread Group/Grupo de Hilos Dos controladores de transacción (T0_Login y T1_Logout)

Primeros pasos de grabación

Como paso necesario para la captura de la navegación de un usuario a través de un navegador, debemos incluir un servidor Proxy http en el banco de trabajo.

El servidor Proxy es lo que se da en llamar un “Elemento No de Prueba”, que son las diferentes opciones que se pueden incluir sólo el banco de trabajo. Este elemento funciona como un Proxy /capturador de tráfico, que escuchará todo el flujo http que pase por el puerto configurado en sus opciones

Aquí se indica en qué puerto TCP estará escuchando. Se incluirá en la configuración de Proxy del navegador a usar como cliente para la navegación	En esta “rama” del plan de pruebas se graban y agrupan las peticiones correspondientes al paso	Indicamos elementos a excluir de la grabación, esto permite evitar llamadas a elementos estáticos (imágenes, textos..etc). Se pueden definir patrones de elementos a grabar/excluir siguiendo el formato de reglas usado por Perl para expresiones regulares.
Podemos especificar qué contenido queremos incluir/excluir explícitamente	Podemos indicar que no grabe peticiones fuera de dominio de prueba	A priori, es mejor dejar por defecto esta sección

Una vez que configuremos el navegador, pulsaremos en la pantalla del Servidor Proxy http el botón , con lo que empezará a grabar las solicitudes que le lleguen.

El procedimiento sobre el que hacemos hincapié es grabar cada paso, seleccionando en el controlador objetivo la transacción correspondiente. Pueden incluso añadirse subtransacciones de la transacción marcándolas como hijas de la que cuelgan

El resultado de la grabación de la actividad del navegador, será reflejada como una estructura en árbol de peticiones HTTP , como la que se observa en la siguiente imagen.

Ilustración 1. Resultado de la grabación de un ciclo simple de navegación

En este caso, podemos ver como una petición http de tipo GET sobre la URL https://www.prueba.es refleja el acto de la pulsación el botón “Aceptar”,junto con algunos parámetros .

En este caso, el campo “Nombre” y “Comentarios” son de texto libre y pueden ser usados para una descripción textual del paso (si procede)

El campo “Path”, refleja el camino relativo al dominio www.prueba.es, junto con determinados parámetros incluidos en la llamada.

Este script puede ser salvado con las opciones del menú típicas de cualquier entorno gráfico de ventanas y posteriormente ejecutado para ser depurado, incluyéndole modificaciones para variar su comportamiento según la respuesta y salvar sus resultados en un fichero para su análisis posterior.

Continuará….