Testing: Load tests

[jonatanvicente]

Es necesario ejecutar pruebas de carga sobre el microservicio Challenge que está desplegado en DEV, atacando http://87.106.229.175:9080/itachallenge/api/v1/challenge/challenges

MUY IMPORTANTE: Las pruebas de carga pueden hacer caer la plataforma DEV. ES NECESARIO AVISAR ANTES DE EJECUTAR LOS PASOS SIGUIENTES

Efectuar los siguientes pasos (en ese orden):

• Descargar e instalar Apache JMeter
• Crear un nuevo Plan de Pruebas.
• Agregar un Grupo de Threads (Usuarios) al Plan de Pruebas. Aquí puedes especificar el número de usuarios que quieres simular.
• Agregar un Controlador de Muestreo HTTP al Grupo de Hilos. Especificar los detalles de la solicitud HTTP, como el método (GET, POST, etc.), la URL del microservicio, los parámetros de la solicitud, etc. Actualmente sólo están habilitados las peticiones GET
• Agregar Listener al Plan de Pruebas. Los oyentes proporcionan acceso a los datos recopilados de las solicitudes. Por ejemplo, agregar un "Listener de Resultados en Árbol" para ver los resultados de las solicitudes individuales, o un "Listener de Resumen de Resultados" para ver un resumen de todas las solicitudes.
• Ejecutar el Plan de Pruebas y revisar los resultados en los Oyentes.

Some more explanations :)....

Load ramping As a general guideline, you might start with a small number of concurrent users (e.g., 10 or 100, depending on the expected load), and gradually increase the load while monitoring the performance and resource usage of your application. This process, known as load ramping, can help you identify the maximum number of concurrent users your application can handle before performance degrades unacceptably. In load ramping, it's generally better to start with a few concurrent users and gradually increase the load over a longer period of time. This approach allows you to observe how your system behaves under increasing load and identify any potential bottlenecks or performance issues.

Spike testing (stress) Starting with many concurrent users in a short time, also known as a spike test, can also be useful, but it's more of a stress test designed to see how your system handles sudden, extreme increases in load. This can be useful for identifying issues that only appear under high load, but it doesn't give you as much information about how your system behaves under more typical conditions.

In general, a combination of both approaches can be beneficial. Start with load ramping to observe the system behavior under normal and increasing load, then perform spike tests to see how it handles sudden, high load. This will give you a more complete picture of your system's performance characteristics.

[Msoler92]

Observaciones preliminares:

Tests de 10 segundos:

• 100 usuarios: funcional, sin grandes diferencias entre llamadas a /test y a /challenges
• 1000 usuarios: funcional, /challenges se ralentiza (~4000ms avg.)
• 2000 usuarios: funcional, /challenges se ralentiza (~10000ms avg.)
• 3500 usuarios: /challenges empieza a devolver timeouts cuando se acumulan ~2000 hilos concurrentes (~20000ms avg.)
• 4000 usuarios: /challenges hace caer la aplicación (~3700 hilos concurrentes).
• 5000 usuarios: /test empieza a devolver timeouts

Tests de 100 segundos:

• 5000 usuarios: funcional
• 6000 usuarios: funcional.
• 6500 usuarios: /challenges hace caer la aplicación (~3000 hilos concurrentes). El primer timeout sucede con ~1600 hilos concurrentes.

ItaChallenge JMeter report - 100-10.csv ItaChallenge JMeter report - 1000-10.csv ItaChallenge JMeter report - 2000-10.csv ItaChallenge JMeter report - 3500-10.csv ItaChallenge JMeter report - 3500-100.csv ItaChallenge JMeter report - 4000-10.csv ItaChallenge JMeter report - 5000-10.csv ItaChallenge JMeter report - 5000-100.csv ItaChallenge JMeter report - 6000-100.csv ItaChallenge JMeter report - 6500-100.csv ItaChallenge JMeter report - 7000-100.csv