‹M06·02Performance
010203040506070809

CAPÍTULO 02

Performance

Latência vs throughput, por que a média mente, como medir em percentis e onde encontrar gargalos sem chutar.

Por Thiago Souza10 min de leituraAtualizado em 2026-05

Performance é "o sistema é rápido?". Mas essa pergunta é vaga demais. Engenheiros sérios decompõem isso em duas métricas que muita gente confunde.

Latência vs Throughput

  • Latência: quanto tempo uma requisição leva pra ser respondida. Mede-se em ms.
  • Throughput: quantas requisições o sistema processa por segundo (RPS, TPS, QPS).

A analogia clássica é a do caixa eletrônico:

Imagine um banco com um caixa que demora 30 segundos por cliente. A latência é alta. Agora imagine 100 caixas iguais lado a lado: a latência continua 30 segundos por cliente, mas o throughput é altíssimo (atende 100 clientes em paralelo).

Conclusão: adicionar máquinas aumenta throughput, mas não diminui latência. Pra reduzir latência você precisa otimizar o código, o banco, a rede — não só adicionar hardware.

Cuidado com a média

Quase ninguém mede latência usando média. Sério. Se 99 requisições levam 10ms e uma leva 10 segundos, a média é ~110ms — parece "ok", mas tem um usuário furioso esperando 10s.

O padrão de mercado são os percentis:

  • p50 (mediana): metade das requisições é mais rápida que isso.
  • p95: 95% das requisições são mais rápidas. Os 5% piores ficam acima.
  • p99: o "pior caso típico". Geralmente é o que define a UX percebida em horas de pico.
  • p99,9: o terror. Se sua API faz 1 milhão de requisições/dia, isso afeta 1.000 pessoas.
Regra do polegar: otimize o p99, não a média. Usuário que teve experiência ruim conta pra todo mundo; usuário satisfeito não conta pra ninguém.

Gargalos (bottlenecks)

Gargalo é o componente mais lento do seu sistema. E aqui vai a lei mais cruel da performance: o sistema todo é tão rápido quanto o gargalo.

Não adianta sua API responder em 5ms se o banco demora 800ms. Não adianta o banco ser raio se o serviço externo que você chama leva 2s. Otimizar qualquer coisa que não seja o gargalo é desperdício de tempo.

Os gargalos clássicos de um backend

  1. CPU: algoritmos pesados, parsing de JSON gigante, criptografia, compressão, lógica de negócio mal feita. Sintoma: CPU em 100%, requisições enfileirando.
  2. Memória: cache estourando, leak, GC trabalhando demais. Sintoma: latência irregular, OOM kill, pausas de GC visíveis.
  3. I/O de disco: logs síncronos, banco mal indexado, leitura de arquivos grandes. Sintoma: CPU baixa mas o sistema está lento (a aplicação está esperando o disco).
  4. Rede: chamadas a microserviços, DNS lento, TLS handshake, payloads enormes. Sintoma: latência alta com CPU/disco/memória ociosos.
  5. Banco de dados: quase sempre o gargalo principal. Querys sem índice, locks, conexões esgotadas, N+1.
  6. Locks e contenção: mutex, semáforos, transações de banco bloqueando. Sintoma: throughput não cresce mesmo aumentando paralelismo.

Como achar o gargalo (sem chutar)

A regra de ouro: meça, não adivinhe. As ferramentas certas são:

  • APM (Application Performance Monitoring): Datadog, New Relic, OpenTelemetry + Grafana. Mostra onde o tempo está sendo gasto.
  • Profiler: vamos ver na próxima seção.
  • EXPLAIN ANALYZE no banco: identifica queries lentas e falta de índice.
  • htop / iostat / vmstat: velho e bom Linux pra ver CPU, disco, memória.
Erro clássico do iniciante: "ah, vou colocar Redis na frente que melhora tudo". Não. Primeiro descubra onde está o problema. Cache resolve cargas de leitura repetida — se seu gargalo é escrita, não vai ajudar em nada.