Quando sua API está lenta, dizer "está lenta" não basta. Você precisa saber onde o tempo está sendo gasto. É a resolução DNS? O handshake TLS? O processamento do servidor? O download da resposta?

Este guia detalha cada fase de uma requisição API, explica as métricas que importam e mostra como usá-las para diagnosticar problemas reais.

Anatomia de uma Requisição API

Cada requisição HTTP passa por uma série de fases antes que um único byte de resposta chegue:

Cliente → DNS Lookup → TCP Connect → TLS Handshake → Envio → Processamento → TTFB → Transferência → Fim

Cada fase tem sua própria métrica de tempo, e cada uma pode ser o gargalo.

DNS Lookup Time: O Gargalo Silencioso

O DNS lookup mede quanto tempo leva para resolver um nome de domínio em um endereço IP. Acontece antes de qualquer conexão ser estabelecida.

Um lookup típico leva 10-50ms com entradas em cache. Qualquer valor consistentemente acima de 200ms é um sinal de alerta.

Causas de DNS Lento

  • Provedor DNS distante: Se seu DNS autoritativo está em uma única região, clientes distantes pagam penalidade de round-trip.
  • TTL baixo: Um TTL de 60 segundos força re-consultas a cada minuto. TTLs de 300-3600 segundos são mais práticos.
  • Sem anycast: Provedores DNS sem anycast servem todas as consultas de poucas localizações.
  • Problemas de propagação: Após uma mudança DNS, diferentes resolvers têm valores em cache distintos.

Como Diagnosticar

$ dig api.exemplo.com +stats
;; Query time: 23 msec

Se o DNS lookup é consistentemente alto, a solução geralmente é mudar para um provedor DNS anycast (Cloudflare, Route 53, Google Cloud DNS) e configurar TTLs adequados.

TLS Handshake: O Custo da Criptografia

O handshake TLS estabelece uma conexão segura criptografada. É obrigatório para qualquer API HTTPS e adiciona latência mensurável.

Um handshake TLS 1.3 tipicamente adiciona 50-100ms (um round trip). TLS 1.2 requer dois round trips, adicionando 100-200ms.

Causas de TLS Lento

  • Cadeias de certificados longas: Se seu servidor envia 4+ certificados, o cliente deve verificar cada um.
  • Certificados intermediários ausentes: O cliente deve buscá-los separadamente, adicionando centenas de milissegundos.
  • OCSP stapling desabilitado: Sem OCSP stapling, o cliente faz uma requisição separada para verificar revogação.
  • Versões TLS antigas: TLS 1.2 requer dois round trips vs. um para TLS 1.3.

Com HTTP/2, múltiplas requisições são multiplexadas sobre uma única conexão, amortizando o custo do handshake. Por isso a reutilização de conexões é crítica.

Time to First Byte (TTFB): A Métrica Mais Importante

TTFB mede o tempo entre enviar a requisição e receber o primeiro byte da resposta. Isola o tempo de processamento do servidor do overhead de rede.

O Que é Normal

  • Menos de 100ms: Excelente. Provavelmente servindo de cache.
  • 100-300ms: Normal para endpoints com consultas ao banco de dados.
  • 300-500ms: Aceitável para operações complexas.
  • Acima de 500ms: Investigar. Geralmente indica consultas lentas ou dependências externas não responsivas.

TTFB vs. Tempo de Resposta Total

    Tempo Total = DNS + TCP + TLS + Envio + TTFB + Download
TTFB = Apenas processamento do servidor

Duas APIs podem ter TTFB idêntico mas tempos totais muito diferentes. Monitorar ambas as métricas separadamente é essencial para diagnóstico preciso.

P50, P95, P99: Por Que Médias Mentem

Se seu dashboard mostra apenas o tempo de resposta médio, você está perdendo informação crucial. Médias escondem a dor dos seus usuários mais afetados.

Exemplo Concreto

Uma API com estes tempos para 100 requisições:

  • 90 requisições: 80-120ms
  • 7 requisições: 400-600ms
  • 3 requisições: 2000-4000ms

A média é ~230ms. Parece bom. Mas P50 é 100ms, P95 é 550ms, e P99 é 3200ms. 1% dos usuários espera 32 vezes mais que o usuário típico.

Causas de Latência na Cauda

  • Esgotamento do pool de conexões: Algumas requisições esperam na fila por uma conexão disponível.
  • Pausas de garbage collection: Em JVM ou .NET, o GC pode congelar todas as threads.
  • Cold starts: Funções serverless inicializam novas instâncias de forma imprevisível.
  • Contenção de locks: Requisições concorrentes competindo pelo mesmo recurso.

Como o Nurbak Monitora Essas Métricas

O Nurbak captura todas as métricas deste artigo automaticamente em cada health check. Sem SDK, sem mudanças de código, sem agentes. Você registra seu endpoint e o Nurbak começa a monitorar.

Cada check registra: DNS Lookup Time, TCP Connection Time, TLS Handshake Time, TTFB, Total Response Time e HTTP Status Code. Os health checks rodam de até 4 regiões globais: Virginia, São Paulo, Paris e Tóquio.

O dashboard mostra P50, P95 e P99 ao longo do tempo, permitindo detectar tendências antes que se tornem incidentes.

Exemplos de Debugging Real

TTFB alto, tudo mais normal

DNS: 25ms ✓  |  TLS: 60ms ✓  |  TTFB: 1800ms ✗  |  Total: 1920ms

Diagnóstico: O servidor está lento. Procurar consultas lentas ao banco de dados, padrões N+1, ou chamadas síncronas a APIs externas.

DNS alto, tudo mais normal

DNS: 450ms ✗  |  TLS: 55ms ✓  |  TTFB: 90ms ✓  |  Total: 630ms

Diagnóstico: A resolução DNS leva quase meio segundo. Verificar TTL, considerar provedor DNS anycast.

TLS alto apenas de algumas regiões

Virginia: TLS 65ms ✓  |  Paris: TLS 280ms ✗  |  Tóquio: TLS 310ms ✗

Diagnóstico: Problema de cadeia de certificados ou configuração TLS. Habilitar OCSP stapling, verificar TLS 1.3, considerar CDN para terminar TLS mais perto do cliente.

Resumo

A performance de uma API não é um único número. É uma série de fases — DNS, TCP, TLS, TTFB, transferência — cada uma com seus próprios modos de falha. Monitorar apenas o tempo total é como ver apenas o placar final: você sabe que perdeu, mas não por quê.

Desmembre suas métricas. Rastreie percentis, não médias. Monitore de múltiplas regiões. O Nurbak captura tudo isso automaticamente. Crie uma conta gratuita e comece a ver a imagem completa da performance da sua API.