Objetivos

Al finalizar el taller el estudiante estará en capacidad de:

• Diseñar y ejecutar pruebas de carga utilizando JMeter

Requisitos para desarrollar el taller

En particular se verán los siguientes temas:

• 1 máquina (virtual) con sistema operativo Ubuntu 20.04 con la aplicación
• 1 máquina (virtual o física) con sistema operativo Ubuntu o MacOS o Microsoft Windows con JMeter
• Python 3.8 o superior
• Permisos de administrador para instalar paquetes
• Conocimientos en comandos de consola

Ambiente requerido

La aplicación que se utilizara en este tutorial corresponde al API RESTful utilizada en los tutoriales anteriores. Recuerde que esta API expone un par de servicios para cifrar y descifrar información con el algoritmo RC4.

Recuerde que el repositorio está disponible:

$ git clone https://github.com/jpadillaa/taller-api-flask-2.git

Utilice una máquina donde tenga instalada la aplicación, sino es así, aprovisione la aplicación en producción en un ambiente Gunicorn + Nginx + Ubuntu 20.04 LTS.

Una prueba de carga es una simulación de la demanda en un servicio o una aplicación para medir el desempeño de ese servicio o aplicación. Las pruebas de carga a veces se denominan de otras formas, como pruebas de rendimiento, pruebas no funcionales o pruebas de estrés.

El generador de carga es una aplicación que se ejecuta sobre un recurso computacional que utiliza todos sus recursos de forma exclusiva para realizar las tareas de simulación de solicitudes sobre un servicio o una aplicación de interés (usuarios virtuales de una aplicación).

El objetivo de no compartir recursos con otros procesos o aplicaciones, es porque se realizan tareas precisas de medición de tiempo y cualquier proceso genera ruido sobre las métricas que se desean medir.

JMeter es una herramienta para generar carga, también se puede medir el rendimiento, por medio de la colaboración de herramientas externas o aplicaciones de monitoreo de rendimiento, esta combinación es importante para establecer los umbrales críticos de operación de un servicio.

JMeter simula las peticiones a nivel de HTTP y permite simular cientos de solicitudes sobre un servicio (usuarios virtuales) con pocos recursos.

JMeter requiere de Java para poder ejecutarse, por lo cual es requisito instalarlo previamente. JMeter requiere una versión de Java 8. JMeter puede operar con el JRE (Java Runtime Environment), pero se recomienda utilizar el JDK para garantizar el soporte de todas las librerías y funcionalidades de JMeter. Si utiliza el JDK se recomienda configurar la variable de entorno en el PATH del sistema operativo.

Descargue JMeter del sitio oficial:

https://jmeter.apache.org/download_jmeter.cgi

JMeter es una carpeta comprimida, no se requiere ningún proceso de instalación en particular. Descomprima la carpeta en Microsoft Windows, MacOS o GNU/Linux.

Una vez descomprima el archivo, ingrese a la carpeta bin, en donde encontrarás los archivos jmeter.sh y jmeter.bat, para el caso de sistemas basados en Unix, GNU/Linux y MacOS tendrá que usar el archivo jmeter.sh y para el caso de Microsoft Windows jmeter.bat.

En este caso la instancia de JMeter se ejecuta en Microsoft Windows, como se puede observar en la imagen.

Asigne un nombre a su plan de pruebas. En la siguiente imagen asignamos el nombre APIREST y un comentario al plan sobre el plan de pruebas.

Ahora en la barra lateral izquierda, seleccione el plan de pruebas y presione el botón derecho del mouse, a continuación, podrá ver un menú desplegable, seleccione la opción: Add -> Threads (users) -> Thread Group.

El grupo de threads simula un escenario de solicitudes concurrentes sobre uno o más recursos de la aplicación durante la ejecución del plan de pruebas. Por defecto podrá observar las opciones Threads (users) con un valor de 1. Es decir, un usuario concurrente o una solicitud de un usuario a la vez sobre un recurso y un Ramp-up period de 1 segundo.

Según la documentación oficial de JMeter [4], los grupos de threads son los puntos de inicio de cualquier plan de pruebas. Todos los controladores y muestreadores deben estar bajo un grupo de threads. El grupo de threads controla el número de subprocesos que utilizará JMeter para ejecutar su prueba. Los controles de un grupo de threads permiten:

• Establecer el número de hilos
• Establecer el período de aceleración
• Establecer el número de veces para ejecutar la prueba

Cada hilo ejecutará el plan de prueba en su totalidad y de forma completamente independiente de otros hilos de prueba. Se utilizan varios subprocesos para simular conexiones simultáneas a su aplicación de servidor [4].

El Ramp-up period indica cuánto tiempo se tarda en "acelerar" hasta el número total de threads elegidos. Si se utilizan 10 threads y el período de aceleración es de 100 segundos, JMeter tardará 100 segundos en poner los 10 threads en funcionamiento. Cada hilo comenzará (100/10) segundos después de que se inició el hilo anterior. Si hay 30 hilos y un período de aceleración de 120 segundos, cada hilo sucesivo se retrasará 4 segundos [4].

La aceleración debe ser lo suficientemente larga para evitar una carga de trabajo demasiado grande al comienzo de una prueba, y lo suficientemente corta como para que los últimos threads comiencen a ejecutarse antes de que terminen los primeros (a menos que uno desee que eso suceda) [4].

Comience con Ramp-up igual al número de hilos y ajuste hacia arriba o hacia abajo según sea necesario [4]. Para iniciar este ejercicio configure 100 threads y un periodo de ramp-up de 100 segundos. Para explorar otras características del ramp-up y algunos conceptos asociados revise la referencia [5].

El campo Loop count es una variable que nos permite indicar cuantas veces se va a repetir esta prueba, por el momento deje el valor en 1.

Nuevamente en la barra lateral izquierda seleccione el Thread Group y presione el botón derecho del mouse, a continuación, podrá ver un menú desplegable, seleccione la opción: Add -> Sampler -> HTTP Request.

Un HTTP Request corresponde a un recurso que se desea probar con JMeter, en este caso nuestra API cuenta con dos endpoints cipher y decipher. A continuación, se presenta la configuración del recurso cipher para lanzar el escenario de pruebas hacia este recurso en particular.

Es importante resaltar que es necesario especificar si el protocolo es HTTP o HTTPS, la dirección del servidor (IP o URL), el puerto, la codificación de caracteres, el verbo HTTP y los parámetros que requiere el recurso, ya sea en los HEADERS o en el BODY de la solicitud. Para este ejemplo solo se configuró el BODY.

En la barra lateral izquierda seleccione el HTTP Request y presione el botón derecho del mouse, a continuación, podrá ver un menú desplegable, seleccione la opción: Add -> Config Element -> HTTP Header Manager.

El HTTP Header Manager nos permite especificar variables y valores globales que las solicitudes utilizar durante una solicitud. Ejemplo: un token de autorización. Para este ejemplo solo vamos a especificar que el tipo de contenido del request es un application/json. Presione el botón agregar de la interfaz para crear la nueva variable.

Finalmente, en la barra lateral izquierda seleccione el HTTP Request y presione el botón derecho del mouse, a continuación, podrá ver un menú desplegable, seleccione la opción: Add -> Listener -> View Results Tree.

Los listeners brindan acceso a la información que JMeter recopila sobre las pruebas realizadas. El Graph Results traza los tiempos de respuesta en un gráfico. View Results Tree muestra detalles de las solicitudes y respuestas del muestreador, y puede mostrar representaciones HTML y XML básicas de la respuesta. Otros listeners proporcionan información de resumen o agregación.

Para validar si la configuración realizada hasta el momento es correcta lance el escenario de pruebas, en la barra lateral izquierda seleccione el plan de pruebas y en la barra superior presione el botón de inicio.

En el View Results Tree podrá observar cómo se ejecuta de forma secuencial la prueba de carga y podrá ver cada una de las solicitudes enviadas y las respuestas que obtiene de parte de la aplicación o del servidor.

Para una solicitud cualquiera seleccione la pestaña Request, donde podrá observar la información enviada.

Para una solicitud cualquiera seleccione la pestaña Response data, donde podrá observar la información recibida desde el servidor.

Un reporte agregado (Aggregate Report) consolida en una tabla la información asociada a nuestro escenario de pruebas, es importante tener presente que si realizamos una nueva ejecución el reporte agrega a la tabla la información recolectada, sin eliminar los datos anteriores, esto tiene sentido si el escenario se ejecuta bajo las mismas condiciones.

La información que entrega el reporte es la siguiente:

• Label: Nombre de los pedidos "HTTP Request". Esto permite clasificar por separado etiquetas idénticas de diferentes grupos de hilos si fuera necesario.
• Samples: Cantidad de veces que se ejecutó la solicitud. Teniendo en cuenta nuestra imagen tendríamos 100 solicitudes.
• Average: Tiempo de respuesta promedio expresado en milisegundos. Teniendo en cuenta nuestra imagen, el primer sample podemos observar un average de 4 ms.
• Median: Es el tiempo en el medio del resultado de un conjunto de muestras. Indica que el 50% de las muestras no tomó más de este tiempo, es decir, el resto tomó al menos el mismo tiempo.
• 90% Line: El 90% de los pedidos tienen un tiempo de respuesta inferior al indicado.
• 95% Line: El 95% de los pedidos tienen un tiempo de respuesta inferior al indicado.
• 99% Line: El 99% de los pedidos tienen un tiempo de respuesta inferior al indicado.
• Min: El menor tiempo que tomó un request
• Max: El mayor tiempo que tomó un request
• Error: Porcentaje de las solicitudes que respondieron con error.
• Throughput: Indica la cantidad de solicitudes por segundo de la prueba. Este tiempo se calcula desde el inicio de la primera muestra hasta el final de la última muestra.
• Received KB/s: Cantidad de KiB recibidos por segundo.
• Sent KB/s: Cantidad de KiB enviados por segundo.

Ahora modifique su escenario de pruebas con las siguientes consideraciones:

• Number of Threads (users): 100
• Ramp-up period (seconds): 1
• Loop Count: 10
• Sobre el shell del servidor ejecute una herramienta de monitoreo de recursos (Ejemplo: top o htop) antes de ejecutar la prueba y realice el seguimiento al porcentaje de uso de CPU.
• Agregue un Aggregate Report para visualizar los datos consolidados de la prueba.

Como puede observar en el reporte agregado, el escenario de pruebas se ejecutó correcta y completamente. Sin embargo, al visualizar el estado de la máquina durante la ejecución de la prueba podemos validar que la máquina ocupó su CPU a un 100% durante el periodo de ejecución de la carga de trabajo.

La grabación de scripts de JMeter permite crear de una manera ágil los planes de pruebas que se ejecutan sobre una aplicación o un servicio. Para este propósito JMeter opera como un servidor proxy entre su máquina (el cliente) y la aplicación web.

Se utilizará como ejemplo la grabación de scripts sobre una aplicación web que permite manejar eventos.

Configuración del servidor Proxy

En primer lugar, se debe crear un plan de pruebas y un grupo threads como se observó en la sección anterior, a continuación, se debe crear el servidor proxy incluyendo al plan de pruebas un HTTP(S)Test Script Recorder. Para agregarlo realice lo siguiente:

En la barra lateral izquierda, seleccione el plan de pruebas y presione el botón derecho del mouse, en el menú desplegable seleccione la opción: Add -> Non-Test Elements -> HTTP(S) Test Script Recorder.

En la ventana de configuración del HTTP(S) Test Script Recorder, se debe modificar dos parámetros, el Puerto del servidor proxy y el Target Controller, este último es necesario ya que allí se especifica el grupo de threads donde se almacenarán todas las grabaciones de las peticiones realizadas a la aplicación web. Para el ejemplo se utilizará el puerto 8888 el cual es el que está configurado por defecto.

Configuración del navegador

Para ejecutar de manera correcta la grabación de las peticiones, se debe configurar el navegador web (Ejemplo: Mozilla Firefox) la configuración de red, para permitir la conexión a la internet a través del servidor proxy que se configuró en el paso anterior.

En el navegador, seleccione el botón abrir menú que se encuentra ubicado en la parte superior derecha y de clic en Opciones.

En la ventana que se abre, diríjase a la barra de búsqueda en la parte superior del navegador y escriba la palabra "proxy", esto permitirá encontrar la configuración de red rápidamente.

Cuando haya finalizado la búsqueda, seleccione el botón Configuración el cual permitirá realizar la configuración de red.

Se abrirá una nueva ventana la cual permitirá configurar el acceso proxy. Seleccione la opción Configuración manual del proxy y modifique el campo Proxy HTTP con la dirección local "localhost" y en el puerto, escriba el mismo que configuro en el servidor proxy de JMeter, para este caso 8888. Seleccione el checkbox "Usar también este proxy para FTP y HTTPS" y, por último, de clic en el botón Aceptar para guardar los cambios.

Grabación de las peticiones

En este punto, cuando ya se ha configurado todo lo necesario, se podrá proceder con la grabación de los scripts cuando se realice una petición a la aplicación web.

Diríjase nuevamente a JMeter y en las opciones del HTTP(S) Test Script Recorder, de clic en el botón Start. Al dar clic se abrirá una ventana emergente con el nombre "Recorder: Transactions control", el cual tiene como objetivo, poder modificar el nombre de cada una de las grabaciones que se realicen.

El primer ejemplo realiza una petición al index de la página web, por lo cual la grabación se deberá registrar con el método GET.

En la ventana emergente mencionada anteriormente, asigne un nombre para la grabación (en este caso Index) e ingrese a la página web a través del navegador.

Al momento de ingresar a la página web, JMeter inició automáticamente la grabación de la petición y dejó el registro en el grupo de Threads que se configuró con anterioridad.

Dentro de la grabación se podrá observar el método HTTP que se usó en la petición (GET), el protocolo, la IP o DNS, el path y el puerto de la aplicación.

El segundo ejemplo, ejecuta una petición con el método POST, simulando el registro de un evento en la página web.

En la ventana emergente asigne un nombre para la grabación (en este caso POST_Event) y registre el formulario en la página web a través del navegador.

Al momento de llenar y enviar el formulario en la página web, nuevamente JMeter inició automáticamente la grabación de la petición y dejó el registro en el grupo de Threads que se configuró con anterioridad.

Dentro del grupo de Threads se encontrará una nueva grabación y dentro de ella, se podrá observar el método HTTP que se usó en la petición (POST), el protocolo, la IP o DNS, el path, el puerto de la aplicación y adicional, todos los parámetros que se usaron en el formulario web.

Por último, detenga la grabación de scripts, dando clic en el botón Stop que se encuentra en las opciones del HTTP(S) Test Script Recorder. Adicional, recuerde cambiar nuevamente las opciones del proxy de su navegador para que pueda navegar sin ningún inconveniente.

En conclusión, la grabación de scripts de JMeter le permite crear un plan de pruebas de una manera ágil, el cual podrá automatizar las pruebas de carga o estrés sobre su aplicación. Es de resaltar que esta grabación de scripts se podrá realizar sobre cualquier aplicación web.

[1] JMeter Docs - https://jmeter.apache.org/usermanual/

[2] Ramp-up - https://dzone.com/articles/jmeter-ramp-up-the-ultimate-guide