Como verificar o tempo de resposta do servidor

Tempo de resposta, TTFB e carregamento de página não são o mesmo número

Eles são usados de forma intercambiável e respondem a perguntas diferentes:

• Tempo de conexão é a resolução de DNS mais o handshake TCP mais o handshake TLS. É principalmente distância e qualidade de rede, e o próprio código do servidor não tem nada a ver com isso.
• Tempo até o primeiro byte (TTFB) é o momento em que o primeiro byte da resposta chega, medido a partir do início da requisição. Inclui o tempo de conexão mais o processamento do servidor: roteamento, consultas de banco de dados, renderização de template, qualquer chamada de API upstream.
• Tempo de processamento do servidor é o TTFB menos o tempo de conexão. Essa é a parte que você pode corrigir na sua aplicação.
• Tempo de carregamento de página é tudo: o HTML, depois toda imagem, folha de estilo, script e fonte que o navegador busca, mais o trabalho de renderizar tudo isso. Uma página pode ter um TTFB excelente e ainda assim levar oito segundos para carregar.

Confundi-los leva as pessoas a otimizar a coisa errada. Comprimir imagens não faz nada por uma consulta de banco de dados lenta, e um banco de dados mais rápido não faz nada por uma página carregando quatro megabytes de JavaScript.

Medindo com curl

O curl reporta cada fase separadamente, o que permite separar o custo de conexão do custo de servidor em um único comando:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Todos os valores são segundos a partir do início da requisição, então cada um inclui os anteriores a ele. O processamento do servidor é ttfb menos tls, ou menos connect em HTTP puro. Rode três ou quatro vezes: a primeira requisição pode pagar por um cache frio ou uma conexão nova, e uma amostra não é uma medição.

Duas coisas para manter em mente. Isso mede só o documento HTML, não a página, então sempre vai parecer mais rápido do que um teste de navegador. E uma página sem cache, logada ou de busca costuma ser dramaticamente mais lenta do que a página inicial, então meça a URL que importa para você, não /.

O que conta como normal

Não há um limite universal. Essas faixas são um guia de trabalho razoável para uma requisição de documento medida a partir de uma localidade próxima dos seus visitantes:

• Abaixo de 200 ms. Rápido. Típico de conteúdo estático, um cache quente, ou uma borda de CDN respondendo diretamente.
• 200 a 500 ms. Normal para uma página dinâmica que consulta um banco de dados. Ninguém percebe isso.
• 500 ms a 1 s. Perceptível. Geralmente uma consulta que precisa de um índice, um template sem cache, ou uma chamada upstream lenta.
• 1 a 3 s. Os usuários sentem, e os buscadores medem. Vale a pena tratar como um defeito.
• Acima de 3 s. Algo está errado: um servidor saturado, um lock, um serviço upstream dando timeout, ou uma requisição fazendo muito mais trabalho do que deveria.

A comparação muito mais útil é contra você mesmo. Uma página que respondia em 300 ms no mês passado e responde em 900 ms hoje tem uma causa específica introduzida no meio do caminho, e saber isso vale mais do que qualquer benchmark publicado.

Por que varia por localidade

A distância custa tempo e não pode ser otimizada para desaparecer. Toda ida e volta entre cliente e servidor leva pelo menos o tempo que o caminho físico permite, e uma conexão TLS precisa de várias idas e voltas antes mesmo de o primeiro byte da resposta poder começar. É por isso que o mesmo servidor pode responder em 150 ms localmente e 700 ms de outro continente fazendo exatamente o mesmo trabalho.

O roteamento também importa, e é menos previsível do que a distância: o tráfego entre duas redes pode seguir uma rota ruim que adiciona latência para uma região e para mais ninguém. Se você usa uma CDN, algumas localidades são servidas a partir de uma cópia em cache próxima enquanto outras erram o cache e pagam a viagem completa até a origem, o que produz uma dispersão ampla entre localidades para a mesma URL.

Então meça de onde os seus usuários estão, não de onde o seu servidor está, e compare o igual com o igual. Um número sem uma localidade associada não é comparável a nada.

Quando lento significa quebrado

Alguma lentidão é um aviso, não um problema de desempenho:

• Um tempo de resposta que cresce de forma constante sob carga significa que o servidor está saturado. Termina em timeouts, não só páginas lentas.
• Tempos agrupados exatamente em 30 ou 60 segundos são timeouts, não lentidão. Algo upstream não está respondendo e um proxy está esperando seu limite se esgotar antes de desistir com um 504.
• Rápido na maior parte do tempo com picos enormes ocasionais geralmente aponta para um lock, um cron job, um backup, ou um cache expirando e toda requisição reconstruindo ele de uma vez.
• Lento só para usuários logados significa que o cache está carregando o tráfego anônimo e escondendo uma aplicação genuinamente lenta por baixo.
• Lento só a partir de uma região é um problema de rede ou CDN, não um problema de aplicação, e nenhuma quantidade de trabalho no backend vai corrigir isso.

Percebendo o dia em que mudou

Uma única medição diz o que aconteceu para uma requisição, de um lugar, em um momento, e o tempo de resposta é exatamente o tipo de métrica que se desvia aos poucos em vez de quebrar de repente. Verificações agendadas medem a mesma URL a partir das mesmas localidades continuamente, mantêm o histórico para que você consiga apontar o dia em que mudou, e alertam quando o tempo ultrapassa um limite em vez de quando um cliente reclama. A HostTracker roda essas verificações a partir de mais de 300 pontos de verificação em 158 cidades, então uma lentidão regional aparece como tal. Rode uma verificação agora com a ferramenta de verificação HTTP. Quando o servidor está rápido e a página ainda não está, o restante da resposta está em como verificar a velocidade do site.