Prueba de carga con langosta. Parte 3

Artículo final sobre la herramienta de prueba de resistencia a la langosta. Hoy compartiré las observaciones que se han acumulado en el proceso. Como siempre, el video está adjunto.

Parte 1 - prueba con langosta
Parte 2 - Escenarios avanzados

Iniciar sesión

Al escribir mis primeras pruebas con Locust, me enfrenté a la necesidad de iniciar sesión en un recurso, obteniendo un token de autorización, que luego usaría para las pruebas de carga. Entonces surgió de inmediato la pregunta: cómo hacer esto, porque la herramienta se agudiza para enviar todas las solicitudes a un recurso, lo que indicamos en la consola al comenzar la prueba. Hay varias soluciones al problema:

• deshabilitar la autorización en el recurso probado, si es posible
• generar un token por adelantado y ponerlo en el código de prueba antes del lanzamiento, la opción más débil, que requiere trabajo manual en cada lanzamiento, pero que tiene derecho a existir en algunos casos raros
• envíe una solicitud utilizando la biblioteca de solicitudes y obtenga un token de la respuesta: bueno, la sintaxis es la misma

Elegí la tercera opción. A continuación, propongo un ejemplo renovado del primer artículo con diferentes posibilidades de obtener un token. Google.com actuará como un servidor de autorización y así
como no hay token, obtendré los valores más simples

from locust import HttpLocust, TaskSet, task import requests class UserBehavior(TaskSet): def on_start(self): response = requests.post("http://mysite.sample.com/login", {"username": "ellen_key", "password": "education"}) # get "token" from response header self.client.headers.update({'Authorization': response.headers.get('Date')}) # get "token" from response cookies self.client.cookies.set('Authorization', response.cookies.get('NID')) # get "token" from response body self.client.headers.update({'Authorization': str(response.content.decode().find('google'))}) 

Como puede ver en el ejemplo, antes de comenzar a trabajar, el usuario envía una solicitud a un servidor externo y procesa la respuesta, colocando los datos en encabezados o cookies.

Encabezados

Al trabajar con encabezados de solicitud, hay varios matices importantes a tener en cuenta.
Para cada solicitud por separado, puede especificar su propio conjunto de encabezados de la siguiente manera

 self.client.post(url='/posts', data='hello world', headers={'hello': 'world'}) 

Cuando se ejecuta el ejemplo anterior, el encabezado hola se agregará a los encabezados existentes de la sesión del cliente, pero solo en esta solicitud no se incluirá todo lo siguiente. Para que el título sea persistente, puede agregarlo a la sesión:

 self.client.headers.update({'aaa': 'bbb'}) 

Otra observación interesante: si en la solicitud especificamos el encabezado que ya está en la sesión, se sobrescribirá, pero solo en esta solicitud. Por lo tanto, no puede tener miedo de borrar accidentalmente algo importante.

Pero hay excepciones. Si necesitamos enviar un formulario de varias partes , la solicitud generará automáticamente un encabezado Content-Type , que indicará el separador de datos del formulario. Si forzamos la reescritura del encabezado utilizando el argumento de encabezados , la solicitud fallará porque el formulario no se puede procesar correctamente.

También vale la pena señalar que todos los encabezados son necesariamente cadenas. Si intenta especificar un número, por ejemplo {'aaa': 123} , la solicitud no se enviará y el código generará una excepción InvalidHeader

Pruebas distribuidas

Para las pruebas distribuidas, locust proporciona varios argumentos de la CLI: --master y --slave , para definir claramente los roles. En este caso, la máquina con master no simulará la carga, sino que solo recopilará estadísticas y coordinará el trabajo. Intentemos ejecutar nuestro servidor de prueba y varias sesiones en modo distribuido ejecutando los siguientes comandos en diferentes consolas:

 json-server --watch sample_server/db.json locust -f locust_files\locust_file.py --master --host=http://localhost:3000 locust -f locust_files\locust_file.py --slave --master-host=localhost locust -f locust_files\locust_file.py --slave --master-host=localhost 

Al abrir la langosta en el navegador ( localhost: 8089 ), puede notar que en la esquina superior derecha tenemos la cantidad de máquinas que llevarán la carga

Prueba sin interfaz de usuario

Cuando todas las pruebas se escriben y depuran, sería bueno incluirlas en las pruebas automáticas de regresión y solo verificar periódicamente los resultados. Con el siguiente comando, puede ejecutar la prueba de langosta sin una interfaz de usuario:

 locust -f locust_files\locust_file.py --host=http://localhost:3000 --no-web -c 10 -r 2 --run-time 1m --csv=test_result 

donde

• --no-web - un argumento que le permite ejecutar pruebas sin una interfaz de usuario
• -c 10 - número máximo de usuarios
• -r 2 : crecimiento del usuario por segundo
• - tiempo de ejecución 1m - tiempo de ejecución de prueba (1 minuto)
• --csv = test_result : una vez completada la prueba, se crearán 2 archivos csv con resultados en la carpeta actual, sus nombres comienzan con test_result

Datos finales, observaciones y conclusiones.

Las pruebas distribuidas se pueden combinar con pruebas de regresión: para garantizar que se inicien todos los nodos para la carga, puede agregar el argumento --expect-slaves = 2 en el maestro, en cuyo caso la prueba solo comenzará cuando se inicien al menos 2 nodos.

Encontré una situación un par de veces: el recurso probado solo funciona en HTTPS, mientras que el certificado es generado por el cliente y el sistema operativo lo marca como sospechoso. Para que las pruebas funcionen correctamente, puede agregar un argumento a todas las consultas que ignoren la verificación de seguridad, por ejemplo:

 self.client.get("/posts", verify=False) 

Como no siempre puedo estar seguro de en qué entorno se ejecutarán las pruebas, siempre indico este argumento.

Eso es todo lo que quería compartir. Por mí mismo, descubrí una herramienta simple y conveniente con excelentes capacidades de prueba y variabilidad en la creación de solicitudes y el procesamiento de respuestas del servidor. Gracias por leer hasta el final.