Por que sua API está lenta: medir p95, consultas SQL e chamadas externas
Publicado em 2026-10-26 por frfrand
Investigar latência real com logs, tracing e percentis
«A API leva 120 ms de média» pode soar excelente, até que um em cada vinte usuários demora vários segundos. O percentil 95 (p95) ajuda a ver essa cauda lenta que a média esconde.
Vamos baixar a bola: o que significa, como testar e o que acontece quando você usa com clientes ou informações reais. A maioria dos problemas não se resolve com um botão mágico, mas com passos que você pode repetir e medir.
O que é Latência p95 de uma API e por que importa
A latência total de uma API pode incluir conexão, autenticação, consultas SQL, chamadas a provedores externos e serialização. O p95 indica o valor abaixo do qual caem aproximadamente 95% das observações do conjunto medido. É preciso analisá-lo por endpoint e janela.
Uma coisa é uma demonstração funcionar cinco minutos e outra é manter um serviço todos os dias. Para isso, você precisa de limites, permissões, registros de atividade e procedimentos para resolver falhas sem improvisar.
Exemplo de implementação ou diagnóstico
# Medición puntual desde cliente; no reemplaza observabilidad
curl -sS -o /dev/null -w 'total=%{time_total} code=%{http_code}\n' https://api.ejemplo.com/health
# En backend registrar, sin datos sensibles:
# request_id, ruta_normalizada, status, duracion_ms
# Investigar queries con EXPLAIN ANALYZE en SELECTÉ uma referência didática, não um modelo que você deve executar às cegas em produção. Substitua os valores de exemplo, escolha identidades com permissões mínimas e certifique-se de que nenhuma chave sensível termine em um log ou repositório.
Como eu colocaria isso para funcionar
- Meça p50, p95, p99, taxa de erro e volume de solicitações por rota.
- Registre tempos de SQL e de chamadas externas com IDs de solicitação sem expor tokens.
- Reproduza a carga real: uma rota vazia
/healthnão mede o checkout. - Ataque o componente mais lento e compare antes e depois.
- Verifique se otimizar uma rota não piorou o consumo de memória ou gravação.
Após cada etapa, verifique um resultado concreto: uma ação autorizada, um status HTTP, uma tarefa processada, um custo registrado ou uma métrica estável. Se algo não funcionar, verifique qual foi a primeira falha antes de tentar novamente em loop.
Um exemplo que pode aparecer em um projeto real
Um site de aluguéis responde rápido ao listar propriedades, mas confirmar reservas leva 2 segundos devido a uma API externa de pagamento. Trocar de VPS não resolve essa chamada; pode ser conveniente desacoplar trabalhos e controlar timeouts.
Se esse aplicativo tiver vários clientes, separe contextos e recursos. É especialmente importante quando um chatbot ou um agente pode consultar dados: a facilidade de conectar ferramentas não deve pular os limites de privacidade e autorização.
O erro mais comum
Não compare p95 calculado com 10 solicitações com outro de 100.000 e conclua que o segundo é pior. Requer uma janela, tráfego e distribuição adequados.
Uma configuração com bons padrões ajuda, mas não elimina a necessidade de testes. Para serviços que gravam dados ou disparam ações, considere retentativas, duplicatas e falhas no meio do caminho.
Onde entra o ArduMaker?
Com o ArduMaker você pode administrar API e PostgreSQL em VPS, e combinar logs e métricas para decidir se otimiza SQL, altera concorrência ou amplia recursos.
Com o ArduMaker você pode hospedar o backend em um VPS, implantar via Git, configurar domínio HTTPS e utilizar ferramentas de bases, serviços e MCP conforme o projeto. Isso facilita reunir operações em um ambiente, embora as regras de negócio e de segurança continuem sendo responsabilidade do software.
O que mediria para saber se melhorou
Não mediria apenas «funciona/não funciona». Também revisaria consumo de recursos, erros, tempos de resposta ou gasto de API, conforme a funcionalidade. Defina uma medida de sucesso antes da mudança e compare com o mesmo cenário depois.
Se um dado parecer estranho, verifique a amostra e a janela temporal. Uma média pode esconder casos extremos, e uma única execução bem-sucedida não demonstra que uma automação suporte milhares de solicitações.
Perguntas frequentes
Preciso de uma infraestrutura grande para começar? Não necessariamente. Primeiro resolva o problema com uma arquitetura simples e meça o ponto onde começa a ficar aquém.
O que acontece se o provedor externo falhar? Você precisa de timeouts, política de tentativas e uma resposta útil para o usuário. Não assuma que as APIs externas estão sempre disponíveis.
Como mantenho o controle? Registre eventos importantes, separe permissões e conserve um procedimento testado para desfazer alterações ou recuperar informações.
Referências para seguir
A ideia final: automatizar e medir vale a pena quando você também sabe detectar um erro, limitar seus efeitos e se recuperar.