Escenario y Pruebas de Estrés API REST y Batch

Plan de pruebas

###Objetivo Evaluar la capacidad y la estabilidad de la aplicación de conversión de videos en situaciones de alta carga.

Objetivos específicos

• Determinar la cantidad máxima de usuarios, solicitudes o tareas de conversión que la aplicación puede manejar antes de que se produzcan problemas de rendimiento o errores.

• Determinar la capacidad del sistema de colas para gestionar tareas en lotes.

• Determinar la cantidad máxima de solicitudes de tareas de conversión concurrentes por segundos para el API.

Descripción general

Se va a probar el end point más importante del API que es la creación de tareas y carga de archivos a convertir, además se realizaran pruebas al proceso de conversión que sucede en el worker a través del consumo de la cola. Para ello se realizarán evaluaciones de rendimiento mediante métricas de solicitudes por segundo, tiempo por solicitud, tiempo promedio en atender una solicitud en grupo y tiempo promedio en atender una sola petición, por otro lado, validaremos el porcentaje de utilización de los recursos de cómputo.

Tipos de pruebas

Pruebas de capacidad: Determinar el número de usuarios y transacciones que soporta el API en el proceso de creación de creación de tareas, además determinar el número de usuario y transacciones que soporta el worker para el proceso de conversión de archivos.

Datos de prueba.

Vídeo mp4 de 1,30 MB.

{ "username": "fredy", "password": "Fredy123!" }

{ "username": "camilo", "password": "Camilo123!" }

Iteraciones

Inicial: 50 peticiones para 5 usuarios concurrentes. Que se irá incrementando de 10 en 10 peticiones manteniendo 5 usuarios. Luego de encontrar los valores máximos de capacidad se ejecutarán 3 pruebas repitiendo el proceso con el fin de evitar casos anómalos.

Configuración del sistema

Información técnica asociada con:

Podrán encontrar información completa de la arquitectura en el siguiente enlace. aqui

• Cada maquina virtual es del tipo e2-small (2 vCPU, 2 GB de RAM y 10 GM de almacenamiento)

• Base de datos en Cloud SQL (MySQL 8.0) 1 vCPU y 10 GB de almacenamiento

Herramientas para la prueba

• Apache JMeter Version 5.6.2:: es una herramienta de código abierto desarrollada por la Apache Software Foundation y se utiliza principalmente para probar el rendimiento de aplicaciones web y servicios.

• **Aplication performance management (APM) TOP Versión 4.0.4 y HTOP Versión 3.2.2.:**Herramienta para identificar el nivel de utilización de la infraestructura que soporta la aplicación como porcentajes de CPU, memoria, I/O, etc. Con el siguiente comando permite escribir los porcentajes de utilización de los recursos para un proceso especifico (Flash APP), cada segundo dentro de un archivo txt, este comando será ejecutado al mismo tiempo que la prueba realizada por JMeter en la instancia de capa Web (API) en GCP:

top -p 64329 -n 100 -b > top-output.txt

• Para reportes se utilizará como herramienta Excel y las graficas obtenidas por JMeter.

Métricas de evaluación

Las métricas que se evaluarán durante las pruebas incluyen:

• Tasa de errores.

• Solicitudes por segundo.

• Tiempo por solicitud

• Tiempo promedio en atender una solicitud en grupo

• Tiempo promedio en atender una sola petición

• Porcentaje de utilización de los recursos de cómputo.

Riesgos

No se va a medir lo siguiente:

• Rendimiento de la base de datos.

• Rendimiento de la cola RabbitMQ

La conversión de archivos únicamente se realizará con archivos MP4 a AVI.

Resultados y conclusiones

Escenario Capa Web

Prueba realizada

Para la capa web se realizo la prueba de capacidad para determinar cual es la cantidad de solicitudes recurrentes que soporta la capa web de la aplicacion, en este caso para el endpoint que permite la creacion de la tarea, teniendo en cuenta las especificaciones de la prueba: El archvio a procesar es un video mp4 de 1.3 MB y se pretende convertir a avi. Para las pruebas en la capa Web se tenia desconectado el worker y las solicitudes se iban encolando, esto debido a que el worker realizara una tarea a la vez. Inicialmente se contemplaron 500 solicitudes, lanzandose 50 a la vez, de este modo se continuo escalando la prueba hasta determinar la cantidad maxima de solicitudes que soporta el servicio de creacion de tareas.

Resultados observados y captura de datos

Se llevó a cabo una prueba de capacidad en la capa web para determinar cuántas solicitudes recurrentes puede soportar la aplicación. Esta prueba se centró en el endpoint que permite la creación de tareas, y se llevaron a cabo consideraciones específicas. El archivo a procesar era un video MP4 de 1.3 MB que se pretendía convertir a formato AVI. Durante las pruebas en la capa web, el worker (trabajador) estuvo desconectado, y las solicitudes se acumularon en cola. Esto se debió a que el worker manejaría una tarea a la vez. Resultados de la prueba: En la primera prueba, con 50 peticiones en 10 segundos (5 usuarios concurrentes por segundo), se observó un uso máximo de la CPU del 9.7% y un uso máximo de memoria del 4.1%.

En la segunda prueba, se ejecutaron 200 peticiones en 10 segundos (20 usuarios concurrentes por segundo) y se registró un uso máximo de CPU del 45% y un uso máximo de memoria del 4.4%.

Con 400 peticiones en 10 segundos (40 usuarios concurrentes por segundo), se alcanzó un uso máximo de CPU del 110% y un uso máximo de memoria del 6.7%. Se observaron problemas de latencia y un uso máximo de la CPU, lo que indicó los límites de solicitudes por segundo que el servicio de creación de tareas podía manejar sin degradación.

Otra prueba con 500 peticiones en 10 segundos (50 usuarios concurrentes por segundo) arrojó un uso máximo de CPU del 117% y un uso máximo de memoria del 7.9%. Adicionalmente se realizo una segunda prueba con 300 peticiones en 10 segundos (50 usuarios concurrentes por segundo), se alcanzó un uso máximo de CPU del 123% y un uso máximo de memoria del 7.9%. El sistema falló en esta prueba debido a la cantidad de solicitudes realizadas.

Finalmente, con 800 peticiones de 10 segundos (80 usuarios concurrentes por segundo), se registró un uso máximo de CPU del 125% y un uso máximo de memoria del 7%. En este punto, comenzaron a surgir problemas de conexión a la base de datos debido a la alta cantidad de conexiones abiertas, lo que resultó en un aumento de solicitudes fallidas.

Conclusiones

A medida que se incrementó la cantidad de usuarios concurrentes por segundo, se observó un aumento en el uso máximo de la CPU y la memoria de la aplicación. Las pruebas revelaron que la aplicación pudo manejar una cierta cantidad de solicitudes concurrentes antes de experimentar problemas de rendimiento y recursos. Este maximo ronda las 30 peticiones a la vez. A medida que se superan estos límites, se produjeron problemas de latencia y un mayor uso de los recursos del sistema. A medida que se incrementó la concurrencia, se empezaron a notar problemas con la conexión a la base de datos debido a un elevado número de conexiones abiertas. Esto provocó un aumento en el porcentaje de solicitudes fallidas. Los resultados indican que la aplicación requiere una planificación cuidadosa en términos de capacidad y administración de recursos para manejar un número específico de usuarios concurrentes. Estos resultados son valiosos para determinar el límite superior de concurrencia que la aplicación puede manejar sin degradación del rendimiento. Los problemas de recursos y de conexión a la base de datos sugieren que podría ser necesario optimizar la infraestructura y la lógica de la aplicación para manejar mejor la concurrencia y reducir el uso excesivo de recursos.

Escenario Capa Batch (Worker)

Prueba realizada:

Se procesaron 10 archivos de 1.4 MB con una duración de 44 segundos en formato mp4 para ser convertidos a formato avi, las 12 tareas estaban en la cola de mensajes y fueron procesadas luego de iniciar el servicio del worker.

Captura de los datos:

Con el uso de la herramienta top se capturó el uso de memoria RAM y % de uso de la CPU mientras los 10 archivos estaban siendo procesados, estos datos fueron luego exportados a un archivo de excel en donde se generaron las gráficas que podrá ver en la parte de abajo.

Resultados observados:

• Tiempo promedio de conversión: 13 segundos

• Tiempo máximo: 29 segundos

• Tiempo mínimo: 8 segundos

• %CPU máximo: 86%

• RAM máxima: 531 MB

Conclusión:

Debido a la naturaleza del servicio que se encuentra suscrito a una cola de mensajes donde cada uno es procesado de manera serial hemos notados que:

• El servicio no será afectado por la alta concurrencia en el API.

• La app para hacer la conversión de archivos hace uso eficiente de los recursos disponibles en la máquina.

• La mejor manera de reducir el tiempo de conversión por archivos es con el incremento de CPU.

• También se puede concluir que el servicio podría ser replicado en múltiples instancias con el fin de procesar múltiples archivos en paralelo para mejorar los tiempo de respuesta.

Resultado de las pruebas:

Tiempo	#Archivo procesado	% CPU	RAM Mb
1:57:57		0	343,9
1:58:00		0	343,8
1:58:03		0,2	344,5
1:58:06		22,7	497,1
1:58:09		84,3	524,7
1:58:12		86,6	525,8
1:58:15		49,7	528,2
1:58:18		86	529,5
1:58:21	1	85,2	530,2
1:58:24		49,7	526,9
1:58:27		86,5	527,7
1:58:30	2	67,2	428,3
1:58:33		68,5	528,8
1:58:36		85,7	528,8
1:58:39	3	50,8	477,9
1:58:42		84,3	528,2
1:58:45		85,3	528,9
1:58:48	4	49,7	525,9
1:58:51		86,4	526,9
1:58:54		85,5	527,4
1:58:57	5	49,3	526,1
1:59:00		85,1	526,6
1:59:03	6	67,5	444,3
1:59:06		68,5	527
1:59:09		85,7	527,2
1:59:12	7	50,8	482,5
1:59:15		84,6	524,2
1:59:18		86,9	524,9
1:59:21		79,1	528,9
1:59:24	8	28,8	525,9
1:59:27		60,6	526,3
1:59:30		69,1	526,6
1:59:33		59	530,6
1:59:36		63,7	530,8
1:59:39		61,8	531
1:59:42		63,4	531,3
1:59:45		71,9	531,5
1:59:48		49,8	531,5
1:59:51	9	27,9	442,4
1:59:54		72,1	527,1
1:59:57		75,9	527,4
2:00:00		49,8	527,6
2:00:03		76,3	527,9
2:00:06		53,4	527,9
2:00:09		76,5	528,1
2:00:13		70	528,1
2:00:16		59,6	528,6
2:00:19	10	78,3	528,5