A forma mais rápida de ver quanto tempo uma chamada de API demora é curl -s -o /dev/null -w '%{time_total}\n' https://api.example.com/, que imprime só o tempo total e nada mais. Esse número sozinho não diz se o atraso está no DNS, na rede, no TLS ou no próprio servidor — para isso é preciso quebrar a requisição em etapas. Aqui vão cinco números em vez de um, e o que fazer com cada um.
1. Quanto tempo a requisição levou de verdade?
$ clai quantos segundos esse endereco demora para responder→ curl -s -o /dev/null -w '%{time_total}\n' https://cliai.tech/1.244094-o /dev/null descarta o corpo da resposta, -s esconde a barra de progresso, e -w imprime só o que foi pedido. Já tem um número, mas ele não explica nada.
2. Quebrar o tempo por etapa
$ clai divide o tempo de resposta por etapa: dns, conexao, tls, primeiro byte→ curl -s -o /dev/null -w 'dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n' https://cliai.tech/dns: 0.000782connect: 0.299098tls: 0.414729ttfb: 1.124750total: 1.244094Os valores são cumulativos, não independentes — o que importa são as diferenças entre eles. O DNS levou 0,0008s, montar a conexão TCP levou 0,298s, o handshake TLS levou 0,116s, e do TLS pronto até o primeiro byte foram 0,71s — isso é o servidor pensando. É aí que mora o problema, se houver algum.
3. Ler as diferenças, não os números absolutos
time_namelookup acima de 0,1s aponta para o resolver ou um cache frio. connect - namelookup é a latência de rede até o servidor, mais ou menos metade do ping de ida e volta. starttransfer - appconnect é quanto tempo o servidor levou pensando na requisição. total - starttransfer é o tempo de transferência do corpo, e depende do tamanho da resposta.
4. Foi mesmo um 200?
$ clai mostra o tempo, o codigo de status e o tamanho do corpo→ curl -s -o /dev/null -w 'code: %{http_code} size: %{size_download} total: %{time_total}\n' https://cliai.tech/code: 200Um tempo sem o código de status não serve para nada — um 500 rápido não significa que está tudo bem. A lista completa de variáveis está em man curl, na seção WRITE-OUT VARIABLES.
5. Uma medição só não basta
$ clai mede o tempo de resposta cinco vezes seguidas→ for i in $(seq 5); do curl -s -o /dev/null -w '%{time_total}\n' https://cliai.tech/; doneUma única medição não significa nada. A primeira requisição quase sempre é mais lenta por causa do DNS frio e da montagem da conexão. Olhe para a variação entre as repetições, não para o primeiro número.
6. Levar o formato para um arquivo
$ clai salva o formato de medicao em um arquivo e reutiliza→ curl -s -o /dev/null -w @curl-format.txt https://cliai.tech/-w @arquivo lê o formato de um arquivo, então a linha longa para de atrapalhar. Esse arquivo geralmente fica no repositório junto com os outros scripts de checagem.
Pegadinhas
- Os valores são cumulativos.
time_appconnectjá inclui o DNS e a conexão. Subtraia a etapa anterior, ou você vai concluir que o TLS levou meio segundo quando isso é na verdade a soma de tudo antes dele. time_appconnecté zero em HTTP puro. Sem TLS essa etapa simplesmente não existe, e o zero aqui não é erro de medição.- curl mede uma requisição, não performance. Para carga, use
hey,wrkouk6. curl responde "para onde vai o tempo", não "quanto tráfego aguenta".
Perguntas relacionadas
O que é TTFB? Tempo até o primeiro byte — o valor time_starttransfer na saída. Geralmente é o sinal mais claro da velocidade do backend.
Por que a primeira requisição é sempre mais lenta? Cache DNS frio, montagem da conexão TCP e o handshake TLS. Uma requisição repetida via keep-alive pula as três.
Como medir só o DNS? %{time_namelookup} sozinho, ou dig +stats, que mostra o tempo de resolução separado do resto.
Veja também
- Triagem de rede em linguagem simples
- JSON na linha de comando
- Verificar se uma porta está aberta em um servidor remoto
Pare de decorar os formatos -w do curl — descreva o que quer medir e o CliAI escreve o comando. Instale em uma linha.