Pruebas de carga 23-24

De Wiki de EGC
Revisión del 14:37 1 oct 2023 de Brgutierrez (discusión | contribuciones) (Página creada con «Las pruebas de carga se usan para simular cómo responde un software ante una serie de usuarios concurrentes que la usan. Son especialmente útiles cuando estimamos que pue...»)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)
Saltar a: navegación, buscar

Las pruebas de carga se usan para simular cómo responde un software ante una serie de usuarios concurrentes que la usan. Son especialmente útiles cuando estimamos que pueden existir picos de uso de una aplicación (p.e. Amazon en Black friday). Este pudiese ser el caso de decide. Para observar como responde vamos a usar locust, una aplicación python que esta dirigida a efectuar este tipo de operaciones.

Antes de empezar, hay que entender para qué sirven las pruebas de estrés. A veces necesitamos soportar que nuestra aplicación ofrezca una cantidad de peticiones por segundo porque habrá muchos usuarios entrando a la misma vez y, ante este estrés, tenemos que comprobar cómo se comporta nuestra aplicación. No es lo mismo que cuando la estresemos nos de un error 500 a que nos devuelva la petición de otro usuario. Con estos test conseguiremos comprobar cuál es ese comportamiento y, quizás, entender cómo mejorar la velocidad de procesamiento de las peticiones para permitir más peticiones por segundo.

Una vez instalado locust, necesitaremos tener un fichero locustfile.py donde tengamos la configuración de lo que vamos a ejecutar. En nuestro caso, tenemos en decide dos ejemplos dentro de decide/loadtest/locustfile.py, que vamos a utilizar en la práctica.

EJERCICIO 9: PRUEBAS DE ESTRÉS EN VISUALIZER

En esta prueba simularemos usuarios que entrar a visualizar los resultados de una votación. Para ejecutar el test de visualizer, tenemos que tener en cuenta que entra en la votación con id 1, por lo que necesitaremos tenerla creada para que funcione correctamente, o, en su defecto, modificar el locustfile para que acceda a la votación que deseemos. Una vez hecho esto, podemos comenzar a probar con el siguiente comando (dentro de la carpeta loadtest):

locust Visualizer

Esto abrirá un servidor que podremos ver en el navegador, el mismo comando nos dirá el puerto. Cuando se abra, nos preguntará cuantos usuarios queremos que hagan peticiones a la vez y cómo queremos que vaya creciendo hasta llegar a ese número. Por ejemplo, si ponemos 100 y 5, estaremos creando 5 nuevos usuarios cada segundo hasta llegar a 100.

EJERCICIO 10: PRUEBAS DE ESTRÉS EN VOTACIÓN

La prueba denominada Voters simula un usuario cuando va a votar, por lo que, con este ejemplo, estaremos comprobando cuantas votaciones podemos hacer por segundo. A nivel de locust, esos usuarios hacen la secuencia de peticiones REST: login, getuser y store. Para ello, este test debe poder utilizar cuentas de usuarios previamente creada. Para ejecutar el test de Voter, necesitaremos realizar varios pasos previos:

  1. Necesitaremos la votación con id 1 abierta, o, en su defecto, modificar el locustfile para que acceda a la votación que deseemos.
  2. Necesitaremos crear una serie de usuarios en el censo de esta votación, para que cuando hagamos el test, estos usuario puedan autenticarse y votar correctamente. Para facilitar esta tarea, hay creado un script de python gen_census.py, con el cual se crean los usuarios que tenemos dentro del fichero voters.json y se añaden al censo utilizando la librería requests.

Ejecutaremos el script gen_census.py. Para ello, habrá que editar parte de su contenido: la cuenta de usuario administrador, para poder tener autorización para crear usuarios y añadirlos al censo.

python gen_census.py
locust Voters


A tener en cuenta:

  • En un servidor local, con un postgres que por defecto nos viene limitado a 100 usuarios concurrentes, cuando pongamos más de 100, lo normal es que empiecen a fallar muchas peticiones.
  • Si hacemos las pruebas en local, donde tenemos activado el modo debug de Django, lo normal es que las peticiones tarden algo más y consigamos menos RPS (Peticiones por segundo).