Pruebas de carga 22-23

De Wiki de EGC
Revisión del 11:38 3 oct 2022 de Ajramirez (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 pu...»)
(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.

Test de estrés con Locust

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.

Para ejecutar los test de estrés utilizando locust, necesitaremos tener instalado locust:

$ pip install locust

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

  • Visualizer: Simula un usuario que entra en el visualizador de una votación.

Para ejecutar el test de Visualizer, tenemos que tener en cuenta que entra en la votación 1, por lo que necesitaremos tenerla creada para que funcione correctamente, 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.

  • 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 utilizar cuentas de usuarios previamente creada.

Para ejecutar el test de Voter, necesitaremos realizar varios pasos previos.

  1. Necesitaremos la votación 1 abierta.
  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. Para que este script funcione, necesitaremos tener instalado request:
$ pip install requests

Una vez instalado, ejecutamos el script:

$ python gen_census.py

Nota: habrá que editar el contenido de gen_census.py para configurar la cuenta de usuario administrador para crear estos usuarios y su censo.

Tras esto, ya podremos comenzar el test de estrés de votantes:

$ locust Voters

Importante mirar bien el fichero locustfile.py, donde existen algunas configuraciones que podremos cambiar, dependiendo del HOST donde queramos hacer las pruebas y del id de la votación.

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).