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 con las modificaciones que se realizan utilizando funcionalidad propias de la nube.

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 Cloud Storage para la persistencia de los vídeos a convertir.

• 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 estrés: Para esto se generará carga constante con un número fijo de usuarios concurrentes que irán aumentando en el tiempo con el fin de determinar el número de usuario y transacciones que soporta la capa web.

Datos de prueba.

Vídeo mp4 de 1,30 MB.

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

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

Iteraciones

La prueba total durará 60 minutos y se empezará con un usuario concurrente por segundo haciendo uso de la herramienta jmeter, la cantidad de usuarios concurrentes irá aumentando de la siguiente manera:

Tiempo	N° Usuarios por segundo
00:00	1
05:00	2
10:00	3
15:00	4
20:00	5
25:00	6
30:00	7
35:00	8
40:00	9
45:00	10
50:00	11
55:00	12
60:00	13

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

• Almacenamiento de archivos Cloud Storage

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.

• Monitoring Instance Group:: Esta herramienta de GCP nos permite realizar un monitoreo sobre los recursos en uso en el grupo de instancias. La herramienta nos muestra métricas como % de utilización de CPU, número de instancias, uso de red, entre otras.

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

• Las pruebas se van a realizar con archivos de tamaño de 1,3 MB debido a que la herramienta seleccionada(Jmeter) para realizar las solicitudes afecta las pruebas cuando se envían archivos de gran tamaño(10MB).

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 estrés para determinar cual es la cantidad de solicitudes recurrentes que soporta la capa web de la aplicación con autoescalamiento, en este caso para el endpoint que permite la creación de la tarea, teniendo en cuenta las especificaciones de la prueba: El archivo a procesar es un video mp4 de 1.3 MB y se pretende convertir a formato 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 realizará una tarea a la vez.

Resultados observados y captura de datos

Tiempo	N° Usuarios por segundo	Resultados Observados
00:00	1	En estos primeros 5 minutos un usuario concurrente por segundo la aplicación supero la métrica del uso del 60% de CPU y el grupo autoescaló a 2 instancias.
05:00	2	Luego de aumentar a 2 usuarios por segundo las dos instancias soportaron la carga sin ningún problema.
10:00	3	Luego de aumentar a 3 usuarios por segundo las dos instancias soportaron la carga sin ningún problema.
15:00	4	Luego de aumentar a 4 usuarios por segundo la aplicación supero la métrica del uso del 120% de CPU y el grupo autoescaló a 3 instancias. La aplicación sigue funcionando sin problemas.
20:00	5	Luego de aumentar a 5 usuarios por segundo la aplicación en algunos casos supero la métrica del uso del 180% de CPU y la aplicación generaba errores en un porcentaje bajo de peticiones.
25:00	6	Luego de aumentar a 6 usuarios por segundo la aplicación en algunos casos supero la métrica del uso del 180% de CPU y la aplicación generaba errores en un porcentaje mayor de peticiones.
30:00	7	Luego de aumentar a 7 usuarios por segundo la aplicación en algunos casos supero la métrica del uso del 180% de CPU y la aplicación generaba errores en un porcentaje mayor de peticiones.
35:00	8	Luego de aumentar a 8 usuarios por segundo la aplicación superó la métrica del uso del 300%(CPU máxima de grupo) de CPU y la aplicación dejó de funcionar.

Resultado pruebas con 5, 6 y 7 usuarios concurrentes por segundo

Resultados con 8 usuarios concurrentes por segundo

Tiempos de respuesta

Capacidad del sistema Vs Uso de la CPU

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 del instance group. Las pruebas revelaron que la aplicación pudo manejar 4 usuarios concurrentes por segundo de manera estable antes de experimentar problemas de rendimiento y recursos. Este máximo ronda las 7 peticiones a la vez. Cuando se supera este límite la aplicación deja de responder debido a que se supera la capacidad de 300% de CPU para las 3 instancias.

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.

Podemos concluir que la aplicación requiere una configuración de instancias con un tipo de máquina de mayor capacidad debido a que la primera instancia no pudo soportar la carga de trabajo con un usuario concurrente. Teniendo en cuenta los tiempos de respuesta promedios de 10 segundos podríamos determinar que para soportar mas de 100 usuarios se necesitaría una máquina base de al menos 8 veces la capacidad actual y un número máximo de instancias superior a 10.

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