Pruebas de carga a servicios REST

Pruebas de carga a servicios REST utilizando JMeter

En este artículo vamos a ver cómo realizar pruebas de carga a un servicio REST para que podamos comprobar cómo va a responder ante escenarios de alta demanda de nuestro servicio. Para llevarlas a cabo vamos a hacer uso de la aplicación JMeter.

 

¿Qué es JMeter?

JMeter es una aplicación creada en Java y de código abierto, que nos permite realizar diferentes pruebas para analizar el rendimiento de aplicaciones web, bases de datos, servicios web, conexiones TCP, etc. Podemos descargar el programa desde este enlace: http://jmeter.apache.org/download_jmeter.cgi. Al ser una herramienta creada en Java necesitamos tener instalado en nuestro ordenador el JRE.

Al iniciar el programa nos encontraremos con la siguiente pantalla, en la que podemos ver que tenemos creado un primer plan de pruebas:

Thread Group

Lo primero que necesitamos es añadir un nuevo “Thread Group” a nuestro plan de pruebas.

Un “Thread Group” es un conjunto de hilos encargado de ejecutar el escenario que definamos. Este grupo de hilos vienen a simular los X usuarios que harán llamadas a nuestro servicio web.

Dentro de un “Thread Group” tenemos las siguientes opciones de configuración. Vamos a describir las que nos interesan:

  • Name: nos permite indicar un nombre representativo al “Thread Group”.
  • Number of Threads (users): número de usuarios (hilos) que realizaran las llamadas a nuestro servicio.
  • Ramp-up period: tiempo en segundos durante el cual se distribuirán la ejecución de las llamadas. Por defecto es 1 segundo, es decir, se lanzarían todas las llamadas en el transcurso de 1 segundo. Ej: si configuramos 5 hilos y en Rump-up period indicamos 10 segundos, los hilos se iniciaran cada 2 segundos. Si indicamos un 0, los hilos se ejecutarían los 5 de forma simultánea.
  • Loop Count: número de veces que se ejecutara cada hilo. Si se selecciona “infinite”, los hilos ejecutaran de forma permanente peticiones. Ej: siguiendo con el ejemplo anterior, si el Loop Count lo definimos a 5, se realizaran 25 llamadas en total ya que cada hilo ejecutara 5 llamadas.

 

HTTP Request

Una vez configurado el “Thread Group” tenemos que indicarle que acción o acciones queremos que realice. En nuestro caso queremos hacer llamadas a un servicio REST, por lo que tenemos que indicarle que queremos hacer llamadas HTTP. Para ello vamos a añadir un elemento “HTTP Request” haciendo clic con el botón derecho sobre el Thread Group → Add → Sampler → HTTP Request:

Con esto ya podremos ver que se ha añadido un elemento “HTTP Request” a nuestro “Thread Group”. Para configurarlo simplemente pinchamos sobre el elemento recién creado y veremos la siguiente pantalla:

Las opciones que nos interesan son:

  • Name: podemos darle un nombre representativo a la llamada.
  • Protocol: por defecto es HTTP, pero podemos indicar que la llamada sea por HTTPS.
  • Server Name or IP: nombre o IP del servidor al que hacer la llamada.
  • Port Number: número del puerto al que realizar la llamada (en caso de que sea necesario indicar uno).
  • Method: podemos indicar el tipo de llamada a realizar.
  • Path: ruta del servicio que queremos llamar sin incluir los datos del host. Ej: “/api/Values”.
  • Parameters: es posible añadir los parámetros que necesitemos a la llamada.

Con estos datos podemos configurar la llamada a realizar a nuestro gusto. Es posible añadir al “Thread Group” tantas llamadas como queramos para poder realizar la prueba con distintos endpoints de nuestro servicio.

 

HTTP Request Defaults

Por comodidad, podemos crear un elemento “HTTP Request Defaults” en nuestro “Test Plan” que nos servirá para indicar valores por defecto a las llamadas HTTP Request. Para añadirlo hacemos clic derecho sobre nuestro TestPlan →Add →Config Element → HTTP Request Defaults:

Una vez añadido, pinchamos sobre el elemento que acabamos de crear para poder configurarlo:

En el elemento “HTTP Request Defaults” podemos definir valores que serán comunes para todas las llamadas HTTP de nuestro plan de pruebas. Nos va a resultar interesante configurar valores por defecto para los campos: “Protocol”, “Server Name or IP” y “Por Number” (en caso de necesitar un número de puerto concreto).

Leer resultados de las llamadas

Una vez hemos configurado las llamadas a realizar podríamos ejecutar el plan de pruebas, pero no tendríamos forma de ver los resultados del mismo. Para eso necesitamos añadir “Listeners”. Hay muchos tipos diferentes de “Listeners” para poder añadir, pero en nuestro caso vamos a añadir uno de tipo “View Results in Table”. Los “listeners” los podemos añadir a nivel de “HTTP Request” con lo que solo escucharía resultados de esta petición, a nivel de “Thread Group” con lo que escucharía resultados de las distintas “HTTP Requests” del grupo de hilos o a nivel de “Test Plan”. En nuestro caso lo vamos a añadir al “Thread Group” haciendo clic con el botón derecho sobre él → Add → Listeners →View Results in Table

Simplemente con añadirlo ya va a “escuchar” las llamadas y mostrarnos los resultados. Si pinchamos sobre el elemento recién creado podemos darle un nombre específico y configurar un archivo de salida donde guardar los resultados.

 

Ejecución del plan de pruebas

Ahora que ya tenemos todo configurado podemos ejecutar nuestro plan de pruebas. Para ello tenemos en la barra de herramientas los siguientes botones:

  • 1. Iniciar el plan de pruebas.
  • 2. Limpiar los datos del “listener” seleccionado.
  • 3. Limpiar los datos de todos los “listeners”.

 

Iniciamos el plan de pruebas y podemos ver el resultado en el elemento “View Results in Table”:

En la tabla podemos ver los datos de las llamadas realizadas:

  • Start Time: fecha de inicio de la llamada.
  • Label: nombre de la HTTP Request que ha realizado la llamada.
  • Sample Time: duración de la petición hasta recibir la respuesta.
  • Status: estado de la petición.
  • Etc.

Con estos sencillos pasos hemos visto cómo podemos hacer pruebas de carga a un servicio web y poder hacernos una idea de la respuesta que tendrá el mismo ante escenarios de gran concurrencia de usuarios.

 

Custom Thread Groups

Si queremos afinar más las pruebas de carga que queremos realizar existen plugins para JMeter que nos permiten ajustar más valores para poder realizar pruebas de carga más concretas y exhaustivas. Para ello vamos a añadir el plugin “Custom Thread Groups” que nos va a poner a nuestra disposición nuevos tipos de “Thread Groups”. Para añadir un nuevo plugin debemos acceder al “Package Manager” (en caso de no tenerlo disponible, puedes seguir las instrucciones de este enlace para instalarlo: https://jmeter-plugins.org/wiki/PluginsManager/ ). Esto lo podemos hacer de 2 maneras:

  • 1. Menú Options → Package Manager.
  • 2. Pulsando en el botón que aparece en la barra de herramientas.

 

Una vez abierto, veremos una ventana con las siguientes pestañas:

  • Installed Plugins: plugins ya instalados en JMeter.
  • Available Plugins: plugins disponibles para añadir.
  • Upgrades: actualizaciones disponibles en alguno de nuestros plugins instalados.

 

En la pestaña “Available Plugins” tenemos que seleccionar “Custom Thread Groups” que es el que queremos instalar y pulsar en el botón “Apply Changes and Restart JMeter”.

Una vez que se ha reiniciado JMeter, al añadir un nuevo “Thread Group” a nuestro plan de pruebas tendremos nuevas opciones disponibles. La que nos interesa es “Concurrency Thread Group”, que nos va a permitir afinar las pruebas de carga de concurrencia de una forma muy sencilla.

Una vez añadido, al seleccionar el nuevo elemento creado podemos ver su pantalla de configuración:

Con este “Thread Group” tenemos más opciones para definir cómo se va a comportar la carga. Además con el grafico que aparece disponemos de una forma muy visual de saber cómo va a distribuirse la carga a lo largo de lo que dura la prueba. Vamos a ver las opciones que nos ofrece “Concurrency Thread Group”:

  • Target Concurrency: número de usuarios totales que realizaran peticiones.
  • Ramp Up Time: tiempo durante el cual se irán añadiendo usuarios hasta alcanzar el total.
  • Ramp-Up Steps Count: número de incrementos de usuarios en el tiempo definido en el punto anterior.
  • Hold Target Rate Time: tiempo durante el cual, una vez alcanzado el número total de usuarios, éstos van a permanecer realizando peticiones.

 

En la captura anterior podemos ver cómo hemos definido un total de 1000 usuarios concurrentes que se irán añadiendo durante un tiempo de 30 minutos. Al definir el campo “Ramp-Up Steps Count” a 10, estamos indicando que cada 3 minutos se incremente en 100 usuarios la carga. Una vez alcanzada la carga de 1000 usuarios concurrentes, se mantendrá esta carga durante 15 minutos, que es lo que hemos configurado en “Hold Target Rate Time”. Con esta configuración podremos ir comprobando cómo se comporta nuestro servicio web según van incrementándose los usuarios que realizan llamadas a nuestro servicio. Los usuarios van a realizar llamadas constantes, por lo que en cada salto comprobaremos la respuesta ante 100 usuarios haciendo llamadas, 200, 300, etc.

Como hemos comentado, haciendo modificaciones en los valores de configuración podremos ver como evoluciona el grafico de carga para obtener una información muy clara de cómo se va a comportar la prueba. Ej:

Como hemos podido ver, utilizando el “Concurrency Thred Group” disponemos de una sencilla pero poderosa herramienta para realizar pruebas de carga a servicios REST.

Carlos

Carlos Gil, es desarrollador Full-Stack en Indicus Software y es aficionado a la tecnología Mac y a descubrir los mejores locales de Malasaña.

¿Te ha gustado el artículo? ¡Compártelo!