Resultados Experimentos
| Titulo del experimento | Validación de tácticas para favorecer la latencia en el proyecto ABC Jobs |
|---|---|
| Propósito del experimento | Validar la hipótesis donde se plantea que al implementar una táctica de múltiples instancias de datos usando un componente de cache, la eficiencia y velocidad de dicho componente permite realizar la evaluación de una pregunta en menos de 0.3 segundos. |
| Resultados Obtenidos | Los resultados del experimento nos muestra que al implementar múltiples instancias de datos usando un componente de cache se logra evaluar una preguntar en menos de 0.3 segundos. Creamos versiones básicas de los microservicios involucrados junto a una instancia del Redis. Usamos Jmeter para hacer las pruebas de carga y simular la actividad de los usuarios. |
| Esfuerzo total invertido | Tiempo y horas hombre reales utilizadas para implementar el experimento Horas x Integrante: 2h investigación 4h desarrollo 2h pruebas 1h análisis 9 horas/ingeniero para un total de 36 horas. |
| Punto de sensibilidad | El punto de sensibilidad, aquel que recibe mayor atención en el experimento y que consideramos crucial para cumplir el ASR, es el componente de Cache que almacenará de forma temporal la información relacionada a preguntas, respuestas y pruebas que los candidatos estén presentando. El cache manejará comunicación síncrona con el componente PruebasOrquestador |
|---|---|
| Historia de arquitectura asociada | HU-68 Latencia en la evaluación de la respuesta Como administrador de ABC Jobs cuando un candidato se encuentra resolviendo una prueba, dado que el sistema se encuentra en operación normal, quiero que evalúe su respuesta para asignar el puntaje a esa pregunta. Esto debe suceder, en menos 0.3 seg |
| Nivel de incertidumbre | Nivel medio de incertidumbre debido al conocimiento previo que tenemos sobre uso de cache, que nos lleva pensar que la hipótesis se va a validar. Sin embargo, aún nos genera dudas que se alcance el objetivo, razón por la cual se realiza este experimento. |
Validamos nuestra hipótesis de diseño, dado que, al implementar múltiples instancias de datos usando un componente de cache, se logró evaluar una pregunta y responder en 10 milisegundos en promedio, utilizando un solo contenedor del microservicio de pruebas-orquestador,
URL Video: Experimento.mov
URL repositorio: https://github.com/andergcp2/backend-proyecto-final
Summary Report JMeter Experimento Latencia - 30 pruebas concurrentes, próxima pregunta en menos de 300 milis
Config JMeter Experimento Latencia
| Titulo del experimento | Validación de tácticas para favorecer la escalabilidad en el proyecto ABC Jobs |
|---|---|
| Propósito del experimento | Validar la hipótesis donde se plantea que al implementar un conjunto de tácticas enfocadas a favorecer la escalabilidad y teniendo un mínimo de 3 instancias de un pod encendido, se logra atender un aumento en la carga de trabajo del microservicio de PruebasOrquestador, pasando de 30 a 100 candidatos y cumpliendo el objetivo de latencia en las respuestas de 0.3 segundos. |
| Resultados Obtenidos | Los resultados del experimento nos muestra que al implementar múltiples instancias de datos usando un componente de cache se logra evaluar una preguntar en menos de 0.3 segundos y además pasar de 30 a 100 candidatos, utilizando 1 solo pod y manteniendo la latencia promedio en 10 milisegundos. Creamos versiones básicas de los microservicios involucrados junto a una instancia del Redis. Usamos Jmeter para hacer las pruebas de carga y simular la actividad de los usuarios. |
| Esfuerzo total invertido | Tiempo y horas hombre reales utilizadas para implementar el experimento Horas x Integrante: 2h investigación 4h desarrollo 2h pruebas 1h análisis 9 horas/ingeniero para un total de 36 horas. |
| Punto de sensibilidad | El punto de sensibilidad a probar es el pod del microservicio PruebasOrquestador que se mantiene encendido en conjunto con la cache, para responder al aumento de carga inicial manteniendo la latencia, lo que permite que el sistema tenga tiempo suficiente para escalar los pods necesarios para soportar la carga máxima de 100 cantidatos concurrentes. |
|---|---|
| Historia de arquitectura asociada | HU-74 Escalabilidad al atender candidatos presentando pruebas Como administrador de ABC Jobs cuando ingreso al sistema de pruebas, dado que el sistema se encuentra en operación normal, quiero poder ejecutar pruebas con concurrencia de 30 hasta 100 usuarios a la vez para continuar con los procesos de selección. Esto debe suceder, el 100% de las veces. |
| Nivel de incertidumbre | El nivel de incertidumbre es medio. Tenemos experiencia y conocimiento configurando arquitecturas que auto escalan, sin embargo, tenemos dudas sobre el número mínimo de pods que debemos mantener para escalar como se requiere, sin comprometer la latencia. |
Validamos nuestra hipótesis de diseño, dado que, al implementar múltiples instancias de datos usando un componente de cache, se logró evaluar una pregunta y responder en 10 milisegundos en promedio, utilizando un solo contenedor del microservicio de pruebas-orquestador para atender 100 candidatos presentando pruebas concurrentes.
Summary Report JMeter Experimento Escalabilidad
Config JMeter Experimento Escalabilidad – 100 candidatos concurrentes
Logs candidatos Experimento Latencia
