He estado intentando cargar la prueba de mi servidor API usando Locust.io en instancias optimizadas de cómputo EC2. Proporciona una opción fácil de configurar para configurar eltiempo de espera de solicitud consecutiva ycantidad de usuarios concurrentes. En teoria,rps = tiempo de espera X #_usuarios. Sin embargo, durante las pruebas, esta regla se rompe para umbrales muy bajos de#_usuarios (en mi experimento, alrededor de 1200 usuarios). Las variablesvelocidad de eclosión, #_de_esclavos, incluso en unconfiguración de prueba distribuida tuvo poco o ningún efecto en elrps.

Información del experimento

La prueba se realizó en un nodo de cómputo C3.4x AWS EC2 (imagen AMI) con 16 vCPU, con SSD general y 30 GB de RAM. Durante la prueba, la utilización de la CPU alcanzó un máximo del 60% (depende de la tasa de eclosión, que controla los procesos concurrentes generados), en un promedio que se mantiene por debajo del 30%.

Locust.io

configuración: utiliza pyzmq y configuración con cada núcleo de vCPU como esclavo. Configuración de solicitud POST única con cuerpo de solicitud ~ 20 bytes y cuerpo de respuesta ~ 25 bytes. Tasa de falla de la solicitud: <1%, con un tiempo de respuesta promedio de 6 ms.

variables: tiempo entre solicitudes consecutivas establecido en 450 ms (mínimo: 100 ms y máximo: 1000 ms), velocidad de eclosión a una cómoda 30 por segundo, yRPS medido variando#_usuarios.

El RPS sigue la ecuación como se predijo para hasta 1000 usuarios. Creciente#_usuarios después de eso tiene rendimientos decrecientes con un límite alcanzado a aproximadamente 1200 usuarios.#_usuarios aquí no es la variable independiente, cambiando eltiempo de espera afecta al RPS también. Sin embargo, cambiar la configuración del experimento a una instancia de 32 núcleos (instancia de c3.8x) o 56 núcleos (en una configuración distribuida) no afecta el RPS en absoluto.

Entonces, ¿cuál es la forma de controlar el RPS? ¿Hay algo obvio que me estoy perdiendo aquí?