Sprint 2. Documentanción de Resultados y Análisis

1. Diseño de escenarios de prueba

Aspectos generales de las pruebas:

• ASR 1: Se utilizará JMeter y un volumen de datos de alrededor de 4'000.000 de datos para realizar la consulta.
• ASR 2: Se utilizará JMeter y un volumen de datos de alrededor de 4'000.000 de datos para realizar la consulta.

Para realizar el análisis de resultados de las pruebas:

• ASR 1: Summary report de JMeter
• ASR 2: Summary report de JMeter

ID ASR	Atributo de calidad	Métrica	Valor Esperado	Valor Obtenido	Funcionalidad a Probar	No. Threads Inicial	No. Threads Final	Ramp Up
1	Desempeño	Latencia	3 Segundos	1,093 Segundos	Listado de productos a sugerir	500	2000	30 seg
2	Desempeño	Escalabilidad/ Rendimiento	50 - 500 pets/seg	70,2 pets/seg	Historial de pedidos realizados	120	1200	10 seg

2. Selección de tecnologías y frameworks utilizados

Para el desarrollo del Sprint 2, se usaron varias tecnologías dentro de las que se comprende: JMeter, esta herramienta posibilitaba generar pruebas de carga para verificar que la arquitectura propuesta estuviera dando resultado con los atributos de calidad propuestos en los ASRs; se utilizó una base de datos Postgres que permitía un mejor y mayor manejo de datos basados en los modelos que se construyeron con Django/Python; _Python_que fue el lenguaje principal de desarrollo de nuestro proyecto, permitió junto al framework _Django _un manejo más fácil de las consultas en la base de datos y una nueva comprensión del desarrollo basado en MVT (model, view, template).

Adicional a esto, se utilizaron Softwares especializados en la generación de datos para "poblar" las tablas de la base de datos, entre ellos se encuentra Mockaroo. Finalmente, no sobra nombrar los editores que se utilizaron para escribir el código del proyecto, estos fueron: Visual Studio Code y PyCharm.

Estas fueron las principales tecnologías y frameworks ocupados durante el desarrollo del Sprint 2.

3. Análisis de resultados

ASR1: Sugerencias de pedidos de mayor rotación en la zona.

Para observar con claridad el comportamiento del sistema a partir de los valores indicados en la tabla ubicada en la parte superior, se realizaron varias pruebas para verificar en qué momento se dejaba de cumplir con la métrica del ASR. Las pruebas que se realizaron fueron las siguientes:

#Threads	Ramp up (s)	Latencia promedio (ms)	Rendimiento promedio (pets/s)	%Error
350	1	817	60,2	0.4%
400	1	1093	51,1	0.25%
500	1	9465	22,7	42.8%
1000	1	15282	45,4	71.4%
400	10	187	15,8	0.3%
500	10	157	49,5	0.4%
1000	10	139	98,8	0.1%

A realizar las pruebas se obtuvieron diferentes resultados, dando por lo general una buena media y un bajo porcentaje de error. Al realizar la prueba con más threads y menos tiempo de ramp up, se observó una gran diferencia en el desempeño del sistema en general, llegando a valores con media de 15000 y porcentaje de error del 71,4%. No obstante, como se puede ver, el escenario en el que mejor se comporta el sistema es cuando hay 400 solicitudes cada 1 segundo. Por lo tanto, este se puede considerar como el ambiente normal para el sistema, ya que se tiene una media de 1093ms, teniendo en cuenta que el valor esperado planteado inicialmente era de 3000ms.

Evidencias:

A continuación se pueden observar varias capturas de pantalla con los resultados de las pruebas, en donde se evidencia que los valores en los que el sistema empieza a tener dificultades son 350 threads y 1(S) de ramp up:

ASR2: Historial de pedidos realizados a Chiper.

Para observar con claridad el comportamiento del sistema a partir de los valores indicados en la tabla ubicada en la parte superior del documento, se realizaron varias pruebas para verificar en qué momento se dejaba de cumplir con la métrica del ASR. Las pruebas que se realizaron fueron las siguientes:

#Threads	Ramp up (s)	Latencia promedio (ms)	Rendimiento promedio (pets/s)	%Error
150	1	1627	44,3	0.0%
200	1	2269	46,4	0.0%
250	1	2220	54,3	0.0%
260	1	5974	10,4	23.46%
275	1	12651	11,7	56.00%
500	10	500	48,9	0.0%
800	10	665	70,1	0.12%
1000	10	3816	52,8	0.1%
1200	10	2865	70,2	0.17%
1300	10	187	15,8	0.3%

Como muestra la tabla, la escalabilidad planteada inicialmente para el cumplimiento del ASR (pasar de 50 a 500 peticiones por segundo) no se pudo cumplir con las condiciones actuales del sistema. El rendimiento máximo obtenido fue de 70,2 peticiones atendidas por segundo. Este comportamiento sugiere que es necesario entender un poco más sobre la realidad del negocio para definir si este rendimiento es suficiente para satisfacer el requerimiento, o si por el contrario conviene tomar decisiones de arquitectura adicionales para ajustar la escalabilidad al valor deseado.

Además de ello, para los escenarios considerados se encontraron valores aceptables de latencia y porcentaje de error los cuales dan cuenta de la factibilidad del requerimiento del ASR.

Evidencias:

Las evidencias de los resultados mostrados se ven a continuación: