O que é throughput? RPS, TPS e testes de performance

Throughput (vazão)

Em inglês: Throughput

Também chamado de: vazão, requisições por segundo, transações por segundo, RPS

Definição

A quantidade de trabalho que um sistema conclui por unidade de tempo, normalmente requisições ou transações por segundo, medida junto com a latência e a taxa de erros.

Throughput (vazão) é quanto trabalho um sistema consegue realizar por unidade de tempo: requisições por segundo (RPS) para uma API, transações por segundo (TPS) para um sistema de pagamentos, mensagens por segundo para um consumidor de fila. Ele mede capacidade, enquanto a latência mede quanto tempo cada unidade individual de trabalho leva. Você precisa dos dois, mais a taxa de erros, para descrever a performance.

Como throughput, latência e concorrência se relacionam

Em um sistema estável, a Lei de Little liga os três:

concurrent requests in flight = throughput × average response time

Example: 200 requests/second × 0.25 seconds = 50 requests in flight

Com usuários virtuais que fazem pausas entre as ações, o think time entra no ciclo: throughput ≈ usuários ÷ (tempo de resposta + think time). Assim, 100 usuários com tempo de resposta de 0,5 s e 4,5 s de think time geram cerca de 20 requisições por segundo, e não 100. É por isso que “testamos com 1.000 usuários” significa pouco até você informar também o think time e a taxa de requisições resultante.

Como o throughput se comporta com carga crescente

Conforme a carga aumenta, o throughput primeiro sobe junto com ela. Em algum momento um recurso satura (CPU, um pool de conexões, um componente single-thread), e o throughput se estabiliza enquanto a latência sobe bruscamente. Se você forçar mais, o throughput pode até cair, porque o sistema gasta seu esforço com filas, retries e timeouts. Encontrar esse platô é o principal resultado de um teste de estresse, e é ele que define a capacidade prática.

Dicas para testar

Declare metas como taxa mais latência. “500 RPS com p95 abaixo de 300 ms e menos de 1% de erros” é testável. “Aguenta tráfego alto” não é.
Conte só o trabalho bem-sucedido. Um servidor que responde 2.000 RPS com metade delas sendo erros 500 não está fazendo 2.000 RPS de trabalho útil.
Use carga por taxa de chegada sempre que possível. Gerar uma taxa fixa de requisições mostra diretamente se o sistema consegue sustentá-la; um pool fixo de usuários vai enviar silenciosamente menos requisições conforme as respostas ficam lentas.
Verifique o gerador de carga. Se a máquina que roda o teste está com 100% de CPU, você mediu o throughput do gerador, e não o do sistema.
Fique de olho nos rate limits. Um gateway que retorna 429 limita o throughput medido; decida se você está testando o limitador ou o serviço por trás dele.