Tarde o temprano, todo producto software debe sobrevivir a la más dura de las pruebas: hordas de usuarios ávidos de respuesta. ¿Cómo generar confianza en que nuestra aplicación podrá con ello? Las pruebas de rendimiento resultan cruciales para asegurar si una aplicación cumplirá los requisitos de funcionamiento, para saber qué volumen de usuarios podrá atender o para estimar cuánto nos costará salir triunfantes.

Mediante unos buenos procesos de pruebas de rendimiento podremos conocer la capacidad de carga que puede soportar el sistema, determinar el límite a partir del cual no funciona correctamente o medir el tiempo que tarda en recuperarse tras una caída del servidor. Valiosa información que analizaremos para identificar los posibles problemas o cuellos de botella del sistema actual y plantear alternativas de mitigación, alineadas con los objetivos de negocio.

Pero esto no es magia. En Panel entendemos que la máxima rentabilidad de los procesos de Calidad Software se consigue jugando en equipo. Esto implica compromiso y motivación de las personas (Cultura), la integración de una metodología de SQA en el desarrollo software (Procesos) y el alineamiento de las herramientas con nuestra metodología y nuestra cultura (Herramientas).

Ya hemos explicado los beneficios de alinear el ciclo de vida de creación del software, así que vamos a detallaros por qué nos conviene integrar y automatizar pruebas de rendimiento, en este caso con Apache Jmeter como caso práctico, una aplicación open-source hecha en Java para la ejecución de pruebas de carga y rendimiento. Jmeter es una herramienta muy versátil gracias a la posibilidad de integración con numerosos plugins, que nos permiten realizar desde simples pruebas con varios usuarios concurrentes hasta simulaciones complejas, introduciendo tiempos de espera entre peticiones o incrementos escalonados de usuarios concurrentes.

JMeter Hilos para Test carga

De entre las Pruebas Software no Funcionales, que se centran en “cómo trabaja el sistema“, podremos trabajar con los tres tipos principales de pruebas de rendimiento:

• • Pruebas de carga : evalúan la capacidad de la aplicación de soportar un volumen dado de solicitudes. Utilizaremos un alto volumen de usuarios concurrentes, sin tiempos de espera entre peticiones.
  • Pruebas de estabilidad : evalúan la capacidad que tiene el servidor de responder a un nivel bajo de peticiones durante largos periodos de tiempo. Nos apoyaremos en introducir tiempos de espera entre peticiones de minutos u horas.
  • Pruebas de estrés: evalúan el comportamiento de la aplicación ante una carga muy elevada de solicitudes hasta provocar la caída del servicio. Para ello, podremos incrementar el volumen de forma escalonada o lineal.

Aunque estas pruebas de rendimiento se diseñan mediante la interfaz gráfica de Jmeter, os recomendamos que su ejecución sea a través de línea de comando para que podáis utilizar mejor los recursos de la máquina desde la que se ejecutan las pruebas (tests). Lo ideal es que exista un servidor (host) dedicado exclusivamente a la ejecución de las pruebas de rendimiento.

Retomando nuestra visión de ciclo de vida en la creación del software, para facilitar la integración continua de las pruebas de rendimiento existe un plugin para la ejecución automática de estos test desde Jenkins (un sospechoso habitual ?). Es el Performance plugin, al que únicamente tendremos que indicar la ruta del archivo que hemos generado con Jmeter y Jenkins hará el resto.

A nivel práctico, estas son algunas de las políticas de ejecución que aplicamos:

• • Las pruebas de estabilidad las lanzamos durante 8 horas, pero buscando un horario que evite que la carga rutinaria sobre el servicio a probar afecte a los resultados, en nuestro caso, a partir de las 18:00 horas.
  • Las pruebas de carga o estrés las programamos a una hora cualquiera porque se ejecutaban durante unos 5-10 minutos. Típicamente, las ejecutamos varias veces al día para identificar si existen diferencias significativas en los resultados obtenidos.
  • Las pruebas de rendimiento (“performance”) se ejecutarán de forma individual si queremos evaluar el rendimiento de cada servicio de forma aislada. Si queremos abusar, Jenkins nos permite configurar varios nodos para realizar ejecuciones paralelas.

Toca analizar los resultados obtenidos, que solemos consolidar en informes de ejecución. El informe lo generamos gracias a BlazeMeter, que nos presenta una interfaz visual donde podemos encontrar y extraer diversas gráficas y tablas de datos que nos permiten trabajar sobre el detalle de las pruebas de rendimiento realizadas. Algunos parámetros interesantes para analizar son:

• • Número de peticiones que no obtuvieron respuesta (% de errores)
  • Tiempo de respuesta (Tiempo que transcurre desde que se realiza la petición hasta que se recibe la respuesta)
  • Número de peticiones por segundo (Throughput)

JMeter – informe con BlazeMeter

¿Y qué hemos conseguido?

La ejecución y posterior análisis de las pruebas de rendimiento sirvieron para verificar si los servicios de la plataforma cumplen con los requisitos de tiempo de respuesta, número de peticiones por segundo o porcentaje de errores. Así, una vez cuantificados estos datos, se emite un informe con recomendaciones, advertencia de riesgos y propuestas de mejora.

En nuestro caso, al utilizar una arquitectura basada en Kubernetes, existe la posibilidad del escalado de los servicios. En otras palabras, si se requería mayor capacidad de un servicio en concreto, se puede incrementar el número de réplicas del contenedor que alberga dicho servicio (pods).

Gracias a los datos obtenidos por las pruebas de performance se pudo ratificar la escalabilidad, de forma que por cada réplica añadida de un pod, el servicio disminuía su tiempo de respuesta e incrementaba el número de peticiones que podía atender por segundo de forma proporcional:

• • Con 2 réplicas el tiempo de respuesta se reduce a la mitad y el número de peticiones por segundo (throughput) se incrementa al doble.
  • Con 3 réplicas el tiempo de repuesta se reduce a la tercera parte y el throughput es del triple.

Por otra parte, con la presencia de al menos una segunda réplica en servicios críticos de la plataforma, se comprobó que se garantizaba la alta disponibilidad con una reducción drástica del número de errores.

Hemos comprobado que tenemos una aplicación escalable y altamente disponible,
¿Qué más podemos pedir? … Que siga así …
Tranquilos, nuestro proceso de integración continua está al quite.
Una experiencia muy reconfortante y recomendable.

Si estás interesado en dar tus primeros pasos en las pruebas de rendimiento, puedes empezar por esta guía para desarrollar un test de carga web. También te incluimos otra guía para desentrañar los misterios de los informes de carga con BlazeMeter, y así ya estás en marcha …

¡ A la carga!