Pruebas de Carga con Apache JMeter - HanstoC/GRUPO10-2025-PROYINF GitHub Wiki
Reporte Apache Jmeter
El siguiente reporte detalla el plan de pruebas realizado solo el proyecto de la asignatura utilizando el software jmeter. El plan de pruebas consistió en testear 3 endpoints de forma secuencial, en todos los casos con 250 threads en tiempo de despliegue de 1 segundo. Se considero un average response time limite de 1 segundo.
Se eligieron 250 threads dentro de un intervalo de un segundo dado que ejecuciones previas como 150 threads en 10 segundos resultaron poco exigentes para el proyecto. Parafraseando al Profesor Marcello Visconti, el testeo es un acto destructivo, por lo que finalmente se concluyeron los parámetros previamente indicados que resultaron ser mas exigentes.
La estructura del plan de pruebas fue la siguiente:
Se aprecian claramente los tres threads groups apartes, cada uno de 250 hebras desplegadas en 1 segundo. Además el específicamente para el caso de Login se incluyó un cookie manager de forma global (fuera de los thread group) esto porque se intentó compartir el cookie para los tres thread group distintos. Finalmente, por dificultades tecnicas se descartó y con un servicio auxiliar se logró que los endpoints obtener preguntas y obtener estadisticas no tuvieran problemas de autenticación. El detalle de las HTTP request fue el siguiente:
La ejecución del plan arrojó los siguientes resultados:
Los graficos respectivos de cada endpoint fueron los siguientes.
Endpoint Login:
Endpoint Obtener preguntas
Endpoint Obtener estadisticas
Análisis de resultados
El sistema en general soportó bien la carga de 250 threads donde ninguna de estas presentó error de ejecución. Los endpoint Login y Obtener preguntas presentaron rendimiento bastante bueno. Para el caso de Login esto se debe a su simplicidad, la multiple ejecución de este endpoint no supone un overhead para el sistema. El endpoint obtener estadisticas por otra parte, presentó tiempos promedios mas altos, esto muy probablemente debido a que como tal es una operación mas completa que trabaja con un paquete de datos mas grande, no obstante, este endpoint por su naturaleza considera un id para un caso especifico, lo que se mantiene la operación en rangos moderados a diferencia de operaciones donde se llaman a todos los elementos de una clase como es el caso siguiente. El Endpoint Obtener preguntas fue el que presentó peor rendimiento en terminos de tiempo con 689ms, valor notoriamente mayor a los otros 2 endpoints. Como se mencionaba antes, un servicio que consulta todos los elementos de una clase supone una operación de alto costo. Este es el caso, donde el endpoint realiza una consulta a todas las preguntas, considerando enunciado, alternativas, id, alternativa correcta, etc. Resultando así un JSON de gran tamaño que se traduce en el overhead observado.
El patrón de sierra obtenido en los gráficos de Login y Estadisticas se deben a que estos endpoints trabajaron en rangos de tiempo bastante acotados, con respecto a por ejemplo el grafico de Obtener preguntas que evidenció un comportamiento ascendente acorde al aumento de los threads, o sea, fue visible un aumento en los tiempos de respuesta en función de la entrada.
En conclusión, los resultados están dentro de los rangos esperados. El average response time limit no se vio superado en ninguno de los 3 casos pero si se evidenció una debilidad, específicamente en el Endpoint obtener Preguntas que al no contar id, supone una operación bastante costosa que en contexto de uso masivo puede suponer un error catastrófico.