Análisis de capacidad de convertidor.

Infraestructura actual y esperada:

En esta segunda semana la aplicación está corriendo en la nube, en 5 instancias de GCP. Se tiene un servidor NFS para alojar los archivos, un servidor con la Api desplegada, un servidor de Redis, un servidor con celery para el VideoConverter y finalmente un servidor de base de datos con el componente CloudSQLPostgres, que para la realización de pruebas se reemplazaba por un servidor con el componente de PostgresDB. Cada instancia se encuentra en la región de us-west. El tipo de máquina para la instancia de CloudSQL es e2-smalll con especificaciones de 3.75 GB de memoria ram, 10GB de almacenamiento en SSD y 1 procesador virtual (vCPUs). Las especificaciones de las instancias para el resto de componentes son configuración E2, tipo de máquina e2-small con 2 procesadores virtuales (vCPUs), 1 core y 2 gb de memoria ram, la capacidad del disco es de 20GB, el sistema operativo es Ubunto versión 20.04.

Se espera que el entorno de pruebas sea en una máquina virtual que esté en la nube corriendo diferentes contenedores, entre otros el de la API en sí misma. Por el mismo hecho de que la infraestructura y la solución tecnológica de despliegue va a cambiar, es que se tiene este documento de análisis de capacidad para seguir una ruta de escenario de pruebas para los diferentes escenarios que se vayan a implementar. El objetivo es poder determinar la capacidad de la aplicación de conversión de archivos, en términos de lanzamiento de peticiones, usuarios en simultáneo utilizando la aplicación entre otras. En resumen, dada una infraestructura X cual será la capacidad de la misma.

Escenarios clave:

Escenarios en los que se harán pruebas de carga. En lo posible se tratara de mantener estos dos escenarios durante todo el curso, pero puede que algunos criterios cambien a través del tiempo en base a la experiencia que vayamos adquiriendo en el uso de las tecnologias.

Rutas críticas de los usuarios en la aplicación (servicios que generan más valor al usuario):

• Subir un video

• Iniciar sesión

Estos escenarios no se van a testear como un escenario en conjunto, ambos se testearán de manera aislada.

Subir Video

Testea la capa web de la aplicación la API en sí, esta ruta se encuentra en el endpoint POST api/tasks.

• Descripción general: Se evaluará por medio de la tecnología Jmeter cuantas peticiones puede recibir el endpoint dado un intervalo de tiempo. Se va a simular cuantos usuarios concurrentes puede soportar el sistema.

• Tipos de prueba a realizar: Prueba de capacidad.

• Criterios de aceptación:

1. Se espera que sea posible realizar al menos 10 peticiones en un periodo de 30 segundos.
2. El tiempo de respuesta de una petición no debe ser superior a 600 milisegundos.
3. Se espera un porcentaje de fallos de 0%

• Datos de prueba: Se va a cargar un archivo de video de 50mb en cada petición.

• Iteraciones: 1 iteración.

Iniciar sesión.

Testea la capa de autenticación.

• Descripción general: Se va a determinar cuántos usuarios se pueden autenticar dado un intervalo de tiempo específico, se va a simular cuantos usuarios concurrentes puede soportar el sistema.

• Tipos de prueba a realizar: Prueba de carga sobre el componente de autenticación.

• Criterios de aceptación:

1. Se espera poder autenticar un mínimo de 100 usuarios en un periodo de 60 segundos.
2. El tiempo de respuesta de una petición no debe ser superior a 300 milisegundos.
3. Se espera un porcentaje de fallos de 0%

• Datos de prueba: Usuario previamente creado en la aplicación utilizando la función de signup.

• Iteraciones: 1 iteración.

Resultados:

Se tiene un servidor NFS para alojar los archivos, un servidor con la Api desplegada, un servidor de Redis, un servidor con celery para el VideoConverter y finalmente un servidor de base de datos con el componente CloudSQLPostgres, que para la realización de pruebas se reemplazaba por un servidor con el componente de PostgresDB. Cada instancia se encuentra en la región de us-west. El tipo de máquina para la instancia de CloudSQL es:

• e2-smalll
• 3.75 GB de memoria ram
• 10GB de almacenamiento en SSD
• 1 procesador virtual (vCPUs).

Las especificaciones de las instancias para el resto de componentes son configuración:

• E2
• tipo de máquina e2-small
• 2 procesadores virtuales (vCPUs)
• 1 core
• 2 gb de memoria ram
• Capacidad del disco es de 20GB
• Sistema operativo es Ubuntu versión 20.04.**

Descripción de la arquitectura del sistema (a nivel de aplicación y a nivel de infraestructura).

Sistemas de terceros o externos requeridos:

• JMeter

Iniciar sesión

Numero de iteración	Resultado obtenido Criterio 1 (s)	Resultado esperado Criterio 1(s)	Resultado obtenido Criterio 2(ms)	Resultado esperado Criterio 2(ms)	Resultado obtenido Criterio 3	Resultado esperado Criterio 3
Iteración 1	81	60	269	300	0	0
	Criterio se cumple: No		Criterio se cumple: Si		Criterio se cumple: Si

Resultado No exitoso

Subir video

Numero de iteración	Resultado obtenido Criterio 1 (s)	Resultado esperado Criterio 1(s)	Resultado obtenido Criterio 2(ms)	Resultado esperado Criterio 2(ms)	Resultado obtenido Criterio 3	Resultado esperado Criterio 3
Iteración 1	54	30	791	600	0	0
	Criterio se cumple: No		Criterio se cumple: No		Criterio se cumple: Si

Resultado No exitoso##

Análisis de resultados:

Inicio de sesión

Gráfica de tiempo de respuesta

• Se puede observar como el promedio de respuesta por cada petición ronda los 270 milisegundos. Es un tiempo constante que nos permite asegurarnos de que la aplicación está funcionando correctamente y no tiene tiempos de espera fuera de lo común.
• El tiempo de respuesta no es el esperado debido a que el software de pruebas JMeter se ejecuta en una máquina local en Colombia y los servidores de GCP se encuentran en la región us-west. La distancia física afecta la latencia, el troughput y el porcentaje de errores.
• El máximo tiempo de respuesta fue de 330 milisegundos un 10% más de lo esperado, pero en general el sistema se comportó dentro de lo establecido.
• No se lograron procesar las 100 solicitudes en un minuto, con un incremente aproximado de 21 segundos, por lo que hay margen de mejora a futuro para poder procesar las solicitudes establecidas.
• El porcentaje de errores ha sido 0, lo que nos permite concluir que el sistema de autenticación funciona sin ningún problema.
• Si ejecutamos el JMeter en una máquina virtual en GCP usando us-west como zona configurada podemos obtener mejores resultados en latencia y podríamos configurar más hilos en las pruebas.

Cargar un video

Gráfica de tiempo de respuesta

• Se puede observar como el promedio de respuesta por cada petición ronda los 800 milisegundos. Es un tiempo constante que nos permite asegurarnos de que la aplicación está funcionando correctamente y no tiene tiempos de espera fuera de lo común.
• No se alcanzó el tiempo de respuesta esperado por 191 milisegundos, lo que nos permite concluir de que estando el JMeter funcionando desde un servidor en la nube en la misma región de los demás, podría ser posible alcanzar la meta.
• El porcentaje de errores ha sido 0, en este caso ha sido exitoso el criterio de aceptación, pero la distancia física pudo haber influido también para que el token de acceso venciera debido a la latencia alta y como consecuencia algunas peticiones fallaran.
• El procesamiento de las 10 solicitudes no alcanzaron a procesarse en 30 segundos, por el contrario se incrementó un 70% de lo esperado. Se tendrá que evaluar los tiempos de respuesta con una herramienta de medición en la nube para aterrizar la meta esperada.

Herramientas para la prueba:

• Jmeter: Permite simular un gran número de usuarios virtuales que envían solicitudes al servidor para evaluar cómo maneja la aplicación la carga.

Conclusiones

• Distribuir el sistema en diferentes instancias mejora la escalabilidad del software dado que si se requiere modificar o cambiar una funcionalidad no implica cambiar toda la solución.
• Ejecutar la herramienta de prueba JMeter en una máquina local, puede aumentar la latencia al evaluar endpoints que se encuentran en servidores de GCP debido que la distancia física retrasa la transferencia de datos.
• Los dos escenarios clave han tenido un porcentaje de fallo del 0% lo que indica que la migración fue un éxito y la aplicación funciona correctamente en la nube.
• Ningún criterio de aceptación referido a las peticiones realizadas dadas un tiempo tuvo éxito. Se debe evaluar cuál es el comportamiento con el JMeter funcionando desde una máquina de GCP en la región us-west.
• El tiempo de respuesta de las peticiones en ambos escenarios clave fue constante, lo que indica que la aplicación está funcionando de manera correcta sin tiempos de espera fuera de lo común.