Como determinar o gargalo de um servidor, corrigir esse problema rapidamente, melhorar o desempenho e evitar regressões.
Visão geral
Este guia mostra como corrigir um servidor sobrecarregado em quatro etapas:
- Avaliar: determinar o gargalo do servidor.
- Estabilizar: implemente correções rápidas para reduzir o impacto.
- Melhoria: aprimore e otimize os recursos do servidor.
- Monitorar: use ferramentas automatizadas para evitar problemas futuros.
Avaliar
Quando o tráfego sobrecarrega um servidor, um ou mais dos seguintes podem se tornar gargalos: CPU, rede, memória ou E/S de disco. Identificar qual delas é o gargalo permite concentrar os esforços nas mitigações mais impactantes.
- CPU: o uso da CPU que é consistentemente superior a 80% precisa ser investigado e corrigido. A performance do servidor geralmente piora quando o uso da CPU chega a cerca de 80 a 90% e fica mais acentuado quando o uso se aproxima de 100%. A utilização da CPU para atender uma única solicitação é insignificante, mas fazer isso na escala encontrada durante picos de tráfego às vezes pode sobrecarregar um servidor. O descarregamento da veiculação para outra infraestrutura, a redução de operações caras e a limitação da quantidade de solicitações reduzem a utilização da CPU.
- Rede: durante períodos de tráfego intenso, a capacidade de rede necessária para atender às solicitações do usuário pode exceder a capacidade. Alguns sites, dependendo do provedor de hospedagem, também podem atingir limites de transferência de dados cumulativos. Reduzir o tamanho e a quantidade de dados transferidos de e para o servidor vai eliminar esse gargalo.
- Memória: quando um sistema não tem memória suficiente, os dados precisam ser transferidos para o disco para armazenamento. O acesso ao disco é consideravelmente mais lento do que à memória, o que pode desacelerar um aplicativo inteiro. Se a memória ficar completamente esgotada, isso pode resultar em erros de falta de memória (OOM). Ajustar a alocação de memória, corrigir vazamentos de memória e fazer upgrade da memória pode remover esse gargalo.
- E/S de disco: a taxa em que os dados podem ser lidos ou gravados em disco é limitada pelo próprio disco. Se a E/S de disco for um gargalo, aumentar a quantidade de dados armazenados em cache na memória pode aliviar esse problema (com o custo de maior utilização da memória). Se isso não funcionar, talvez seja necessário atualizar os discos.
As técnicas deste guia se concentram em resolver gargalos de CPU e de rede. Na maioria dos sites, a CPU e a rede são os gargalos mais relevantes durante um pico de tráfego.
A execução de top
no servidor afetado é um bom ponto de partida para investigar gargalos. Se disponível, complemente com dados históricos do seu provedor de hospedagem ou ferramentas de monitoramento.
Estabilizar
Um servidor sobrecarregado pode levar rapidamente a falhas em cascata em outras partes do sistema. Portanto, é importante estabilizar o servidor antes de tentar fazer mudanças mais significativas.
Limitação de taxa
A limitação de taxa protege a infraestrutura ao limitar o número de solicitações recebidas. Isso é cada vez mais importante à medida que a performance do servidor se degrada: à medida que os tempos de resposta aumentam, os usuários tendem a atualizar a página de forma agressiva, aumentando ainda mais a carga do servidor.
Corrigir
Embora a rejeição de uma solicitação seja relativamente barata, a melhor maneira de proteger seu servidor é processar a limitação de taxa em algum lugar upstream dele, por exemplo, usando um balanceador de carga, um proxy reverso ou um CDN.
Instruções:
Para saber mais:
Cache HTTP
Procure maneiras de armazenar conteúdo em cache de forma mais agressiva. Se um recurso puder ser veiculado de um cache HTTP (seja o cache do navegador ou uma CDN), ele não precisará ser solicitado no servidor de origem, o que reduz a carga do servidor.
Cabeçalhos HTTP como Cache-Control
, Expires
e ETag
indicam como um recurso deve ser armazenado em cache por um cache HTTP. A auditoria e a correção desses cabeçalhos vão melhorar o armazenamento em cache.
Embora os service workers também possam ser usados para armazenamento em cache, eles usam um cache separado e são um complemento, e não uma substituição, para o armazenamento em cache HTTP adequado. Por esse motivo, ao lidar com um servidor sobrecarregado, os esforços devem ser focados na otimização do armazenamento em cache HTTP.
Diagnóstico
Execute o Lighthouse e confira a auditoria Servir recursos estáticos com uma política de cache eficiente para conferir uma lista de recursos com um time to live (TTL) curto a médio. Para cada recurso listado, considere se o TTL precisa ser aumentado. Como orientação geral:
- Os recursos estáticos precisam ser armazenados em cache com um TTL longo (um ano).
- Os recursos dinâmicos precisam ser armazenados em cache com um TTL curto (3 horas).
Corrigir
Defina a diretiva max-age
do cabeçalho Cache-Control
como o número adequado de segundos.
Instruções:
Degradação suave
A degradação suave é a estratégia de reduzir temporariamente a funcionalidade para eliminar o excesso de carga de um sistema. Esse conceito pode ser aplicado de várias maneiras: por exemplo, exibindo uma página de texto estático em vez de um aplicativo com recursos completos, desativando a pesquisa ou retornando menos resultados de pesquisa ou desativando determinados recursos caros ou não essenciais. A ênfase deve ser colocada na remoção de funcionalidades que podem ser removidas com segurança e facilidade com o mínimo impacto nos negócios.
Melhorar
Usar uma rede de fornecimento de conteúdo (CDN)
A disponibilização de recursos estáticos pode ser transferida do servidor para uma rede de fornecimento de conteúdo (CDN), reduzindo a carga.
A principal função de uma CDN é fornecer conteúdo aos usuários rapidamente, oferecendo uma grande rede de servidores localizada perto deles. No entanto, a maioria das CDNs também oferece outros recursos relacionados ao desempenho, como compactação, balanceamento de carga e otimização de mídia.
Configurar um CDN
As CDNs se beneficiam da escala, então operar sua própria CDN raramente faz sentido. Uma configuração básica de CDN é bastante rápida de configurar (cerca de 30 minutos) e consiste em atualizar os registros DNS para apontar para o CDN.
Otimizar o uso do CDN
Diagnóstico
Identifique os recursos que não estão sendo veiculados de um CDN (mas deveriam ser) executando o WebPageTest. Na página de resultados, clique no quadrado acima de "Uso eficaz da CDN" para conferir a lista de recursos que precisam ser veiculados por uma CDN.

Corrigir
Se um recurso não estiver sendo armazenado em cache pelo CDN, verifique se as seguintes condições são atendidas:
- Ele tem um cabeçalho
Cache-Control: public
. - Ele tem um cabeçalho
Cache-Control: s-maxage
,Cache-Control: max-age
ouExpires
. - Ele tem um
Content-Length
,Content-Range
ouTransfer-Encoding header
.
Escalonar recursos de computação
A decisão de dimensionar os recursos de computação precisa ser tomada com cuidado. Embora seja necessário dimensionar os recursos de computação com frequência, fazer isso prematuramente pode gerar complexidade arquitetônica e custos financeiros desnecessários.
Diagnóstico
Um Tempo até o primeiro byte (TTFB) alto pode ser um sinal de que um servidor está chegando à capacidade máxima. Essas informações estão disponíveis na auditoria Reduzir o tempo de resposta do servidor (TTFB) do Lighthouse.
Para investigar mais, use uma ferramenta de monitoramento para avaliar o uso da CPU. Se o uso atual ou previsto da CPU exceder 80%, aumente o número de servidores.
Corrigir
A adição de um balanceador de carga permite distribuir o tráfego entre vários servidores. Um balanceador de carga fica na frente de um pool de servidores e encaminha o tráfego para o servidor apropriado. Os provedores de nuvem oferecem balanceadores de carga próprios (GCP, AWS, Azure) ou você pode configurar o seu usando HAProxy ou NGINX. Depois que um balanceador de carga estiver em funcionamento, será possível adicionar outros servidores.
Além do balanceamento de carga, a maioria dos provedores de nuvem oferece escalonamento automático (GCP, AWS, Azure). O escalonamento automático funciona em conjunto com o balanceamento de carga. Ele aumenta ou diminui os recursos de computação de acordo com a demanda em um determinado momento. O escalonamento automático não é mágico. Leva tempo para novas instâncias ficarem on-line e exige uma configuração significativa. Devido à complexidade adicional que o escalonamento automático envolve, uma configuração mais simples baseada no balanceador de carga deve ser considerada primeiro.
Ativar compactação
Os recursos baseados em texto precisam ser compactados usando gzip ou brotli. O Gzip pode reduzir o tamanho da transferência desses recursos em cerca de 70%.
Diagnóstico
Use a auditoria Ativar a compactação de texto do Lighthouse para identificar os recursos que precisam ser compactados.
Corrigir
Ative a compactação atualizando a configuração do servidor. Instruções:
Otimizar imagens e mídia
As imagens representam a maior parte do tamanho do arquivo da maioria dos sites. A otimização de imagens pode reduzir o tamanho de um site de forma rápida e significativa.
Diagnóstico
O Lighthouse tem várias auditorias que sinalizam possíveis otimizações de imagem. Outra estratégia é usar as Ferramentas do desenvolvedor para identificar os arquivos de imagem maiores. Essas imagens provavelmente são boas candidatas para otimização.
Auditorias relevantes do Lighthouse:
- Defina um tamanho adequado para as imagens
- Adie a exibição de imagens fora da tela
- Codificar imagens com eficiência
- Exibir imagens em formatos de última geração
- Usar formatos de vídeo para conteúdo animado
Fluxo de trabalho do Chrome DevTools:
- Registrar atividade de rede
- Clique em Img para filtrar recursos que não são imagens.
- Clique na coluna Tamanho para classificar os arquivos de imagem por tamanho.
Corrigir
Se você tiver pouco tempo…
Concentre seu tempo em identificar imagens grandes e carregadas com frequência e otimize-as manualmente com uma ferramenta como o Squoosh. As imagens principais geralmente são boas candidatas para otimização.
Alguns lembretes:
- Tamanho: as imagens não podem ser maiores do que o necessário.
- Compactação: em geral, um nível de qualidade de 80 a 85 tem um efeito mínimo na qualidade da imagem, mas reduz o tamanho do arquivo em 30 a 40%.
- Formato: use JPEGs para fotos em vez de PNG e MP4 para conteúdo animado em vez de GIF.
Se você tiver mais tempo:
Considere configurar um CDN de imagens se elas forem uma parte significativa do seu site. As CDNs de imagem foram projetadas para veicular e otimizar imagens, e elas vão desafogar a veiculação de imagens do servidor de origem. A configuração de uma CDN de imagem é simples, mas exige a atualização dos URLs das imagens para que eles apontem para a CDN.
Para saber mais:
Compactar JS e CSS
A minificação remove caracteres desnecessários do JavaScript e do CSS.
Diagnóstico
Use as verificações Minify CSS e Minify JavaScript do Lighthouse para identificar recursos que precisam de minificação.
Corrigir
Se você tiver pouco tempo, concentre-se na minificação do JavaScript. A maioria dos sites tem mais JavaScript do que CSS, então isso vai ter mais impacto.
Monitoramento
As ferramentas de monitoramento de servidor fornecem coleta de dados, painéis e alertas sobre o desempenho do servidor. O uso deles pode ajudar a evitar e atenuar problemas de desempenho do servidor no futuro.
A configuração de monitoramento deve ser mantida o mais simples possível. A coleta e o alerta excessivos de dados têm custos: quanto maior o escopo ou a frequência da coleta de dados, mais caro é coletar e armazenar. O alerta excessivo leva inevitavelmente a páginas ignoradas.
O alerta precisa usar métricas que detectem problemas de forma consistente e precisa. O tempo de resposta do servidor (latência) é uma métrica que funciona muito bem para isso: ela detecta uma grande variedade de problemas e tem correlação direta com a experiência do usuário. Os alertas com base em métricas de nível inferior, como o uso da CPU, podem ser um complemento útil, mas vão detectar um subconjunto menor de problemas. Além disso, os alertas devem ser baseados na performance observada na cauda (ou seja, os percentis 95 ou 99), em vez de médias. Caso contrário, as médias podem facilmente obscurecer problemas que não afetam todos os usuários.
Corrigir
Todos os principais provedores de nuvem oferecem as próprias ferramentas de monitoramento (GCP, AWS, Azure). Além disso, o Netdata é uma excelente alternativa sem custo financeiro e de código aberto. Independentemente da ferramenta escolhida, você precisará instalar o agente de monitoramento dela em cada servidor que você quer monitorar. Quando terminar, configure os alertas.
Instruções: