Estou tentando carregar o teste do meu servidor de API usando o Locust.io em instâncias otimizadas de computação do EC2. Ele fornece uma opção fácil de configurar para definir otempo de espera de solicitação consecutiva enúmero de usuários simultâneos. Em teoria,rps = tempo de espera X #_Comercial. No entanto, durante o teste, essa regra é quebrada para limites muito baixos de#_Comercial (na minha experiência, cerca de 1200 usuários). As variáveishatch_rate, #_of_slaves, inclusive em umconfiguração de teste distribuído teve pouco ou nenhum efeito sobre orps.

Informações da experiência

O teste foi realizado em um nó de computação C3.4x AWS EC2 (imagem AMI) com 16 vCPUs, com SSD geral e 30 GB de RAM. Durante o teste, a utilização da CPU atingiu um pico de 60% no máximo (depende da taxa de hachura - que controla os processos simultâneos gerados), mantendo-se em média abaixo de 30%.

Locust.io

setup: usa pyzmq e setup com cada núcleo da vCPU como escravo. Configuração de solicitação POST única com corpo de solicitação ~ 20 bytes e corpo de resposta ~ 25 bytes. Taxa de falha de solicitação: <1%, com tempo médio de resposta de 6 ms.

variáveis: tempo entre solicitações consecutivas definidas como 450ms (min: 100ms e max: 1000ms), taxa de hachura a 30 confortáveis por segundo eRPS medido variando#_Comercial.

O RPS segue a equação prevista para até 1.000 usuários. Aumentando#_Comercial depois disso, retornos decrescentes com um limite atingido em aproximadamente 1200 usuários.#_Comercial aqui não é a variável independente, alterando otempo de espera afeta o RPS também. No entanto, alterar a configuração da experiência para instância de 32 núcleos (instância c3.8x) ou 56 núcleos (em uma instalação distribuída) não afeta o RPS.

Então, realmente, qual é a maneira de controlar o RPS? Há algo óbvio que estou perdendo aqui?