Corrigir um servidor sobrecarregado

Como determinar o gargalo de um servidor, corrigir rapidamente o gargalo, melhorar o desempenho do servidor e evitar regressões.

Katie Hempenius
Katie Hempenius
X

Visão geral

Neste guia, mostramos como corrigir um servidor sobrecarregado em quatro etapas:

  1. Avaliar: determine o gargalo do servidor.
  2. Estabilizar: implemente correções rápidas para reduzir o impacto.
  3. Melhoria: aumente e otimize os recursos do servidor.
  4. Monitoramento: use ferramentas automatizadas para evitar problemas futuros.

Avaliar

Quando o tráfego sobrecarrega um servidor, um ou mais destes itens podem se tornar um gargalo: CPU, rede, memória ou E/S de disco. Identificar qual desses é o gargalo possibilita concentrar os esforços nas mitigações mais impactantes.

  • CPU: o uso de CPU consistentemente acima de 80% deve ser investigado e corrigido. O desempenho do servidor geralmente diminui quando o uso da CPU atinge cerca de 80% a 90%, e aumenta à medida que a utilização se aproxima de 100%. O uso da CPU para atender a uma única solicitação é insignificante, mas às vezes sobrecarregar um servidor fazer isso na escala encontrada durante os picos de tráfego. Descarregar a disponibilização para outra infraestrutura, reduzir operações caras e limitar a quantidade de solicitações reduzirá a utilização da CPU.
  • Rede: durante períodos de alto tráfego, a capacidade de processamento da rede necessária para atender às solicitações dos usuários pode exceder a capacidade. Alguns sites, dependendo do provedor de hospedagem, também podem atingir limites relativos à transferência de dados cumulativos. Reduzir o tamanho e a quantidade de dados transferidos de e para o servidor vai remover esse afunilamento.
  • Memória: quando um sistema não tem memória suficiente, os dados precisam ser descarregados no disco para armazenamento. O acesso ao disco é consideravelmente mais lento do que o acesso à memória, e isso pode deixar o aplicativo inteiro mais lento. Se a memória ficar completamente esgotada, isso pode resultar em erros de falta de memória (OOM, na sigla em inglês). Ajustar a alocação de memória, corrigir vazamentos e fazer upgrade da memória pode remover esse afunilamento.
  • E/S do disco: a taxa em que os dados podem ser lidos ou gravados no disco é restrita 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 (ao custo de uma maior utilização da memória). Se isso não funcionar, talvez seja necessário fazer upgrade dos discos.

As técnicas deste guia são voltadas para resolver gargalos de CPU e rede. Para a maioria dos sites, a CPU e a rede serão os gargalos mais relevantes durante um pico de tráfego.

Executar o top no servidor afetado é um bom ponto de partida para investigar os gargalos. Se disponíveis, complemente com dados históricos do provedor de hospedagem ou das ferramentas de monitoramento.

Estabilizar

Um servidor sobrecarregado pode levar rapidamente a falhas em cascata em outros lugares do sistema. Portanto, é importante estabilizar o servidor antes de tentar fazer alterações mais significativas.

Limitação de taxa

A limitação de taxa protege a infraestrutura limitando o número de solicitações recebidas. Isso é cada vez mais importante à medida que o desempenho do servidor diminui: à 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 rejeitar uma solicitação seja relativamente barata, a melhor maneira de proteger seu servidor é lidar com a limitação de taxa em algum lugar upstream, como um balanceador de carga, proxy reverso ou CDN.

Instruções:

Para saber mais:

Armazenamento em cache HTTP

Procure formas de armazenar conteúdo em cache de forma mais agressiva. Se um recurso puder ser disponibilizado a partir de um cache HTTP (seja o cache do navegador ou uma CDN), ele não precisará ser solicitado ao 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. Auditar e corrigir esses cabeçalhos melhora o armazenamento em cache.

Embora os service workers também possam ser usados para armazenamento em cache, eles utilizam um cache separado e são um complemento, não substituto, para o armazenamento em cache HTTP adequado. Por esse motivo, ao lidar com um servidor sobrecarregado, os esforços devem ser concentrados na otimização do armazenamento em cache HTTP.

Diagnóstico

Execute o Lighthouse e consulte a auditoria Veicular recursos estáticos com uma política de cache eficiente para ver uma lista de recursos com time to live (TTL) curto ou 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 (três horas).

Corrigir

Defina a diretiva max-age do cabeçalho Cache-Control como o número adequado de segundos.

Instruções:

Degradação graciosa

A degradação graciosa é a estratégia de reduzir temporariamente a funcionalidade para eliminar o excesso de carga de um sistema. Esse conceito pode ser aplicado de muitas maneiras diferentes: por exemplo, veicular uma página de texto estático em vez de um aplicativo completo, desativar a pesquisa ou retornar menos resultados de pesquisa ou desativar determinados recursos caros ou não essenciais. É preciso dar ênfase à remoção de funcionalidades que possam ser removidas de forma segura e fácil com impacto mínimo nos negócios.

Melhorar

Usar uma rede de fornecimento de conteúdo (CDN)

A disponibilização de ativos estáticos pode ser descarregada do seu servidor para uma rede de fornecimento de conteúdo (CDN), reduzindo a carga.

A principal função de uma CDN é entregar conteúdo aos usuários rapidamente, fornecendo uma grande rede de servidores localizados próximos aos usuários. 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 uma CDN

As CDNs se beneficiam do escalonamento, portanto operar sua própria CDN raramente faz sentido. A configuração básica da CDN é rápida (cerca de 30 minutos) e consiste em atualizar os registros DNS para apontar para a CDN.

Otimizar o uso da CDN

Diagnóstico

Identifique os recursos que não são veiculados por uma CDN, mas deveriam estar, executando WebPageTest. Na página de resultados, clique no quadrado acima de "Uso eficaz do CDN" para ver a lista de recursos que devem ser exibidos por um CDN.

Seta apontando para o botão "Uso eficaz da CDN"
Resultados do WebPageTest

Corrigir

Se um recurso não estiver sendo armazenado em cache pela CDN, verifique se as seguintes condições são atendidas:

Escalonar recursos de computação

A decisão de escalonar recursos de computação precisa ser feita com cuidado. Embora muitas vezes seja necessário escalonar recursos de computação, fazer isso prematuramente pode gerar complexidade arquitetônica e custos financeiros desnecessários.

Diagnóstico

Um tempo até o primeiro byte (TTFB, na sigla em inglês) alto pode ser um sinal de que um servidor está se aproximando da capacidade. Você encontra essas informações na auditoria Reduzir os tempos de resposta do servidor (TTFB, na sigla em inglês) do Lighthouse.

Para investigar mais, use uma ferramenta de monitoramento para avaliar o uso da CPU. Se o uso de CPU atual ou previsto exceder 80%, considere aumentar seus servidores.

Corrigir

Adicionar 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 roteia o tráfego para o servidor adequado. Os provedores de nuvem oferecem os próprios balanceadores de carga (GCP, AWS, Azure) ou você pode configurar seu próprio com HAProxy ou NGINX. Quando um balanceador de carga estiver em vigor, outros servidores poderão ser adicionados.

Além do balanceamento de carga, a maioria dos provedores de nuvem oferece escalonamento automático (GCP, AWS, Azure). O escalonamento automático funciona com o balanceamento de carga: o escalonamento automático aumenta e diminui os recursos de computação de acordo com a demanda em um determinado momento. Mas o escalonamento automático não é mágico. Leva tempo para que novas instâncias fiquem on-line e isso requer configuração significativa. Devido à complexidade adicional do escalonamento automático, uma configuração mais simples baseada em um balanceador de carga deve ser considerada primeiro.

Ativar compactação

Os recursos baseados em texto devem 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 compactação de texto do Lighthouse para identificar recursos que precisam ser compactados.

Corrigir

Ative a compactação atualizando a configuração do seu servidor. Instruções:

Otimizar imagens e mídia

As imagens representam a maior parte do tamanho do arquivo da maioria dos sites. Otimizar imagens pode reduzir o tamanho de um site de maneira rápida e significativa.

Diagnóstico

O Lighthouse tem uma variedade de auditorias que sinalizam possíveis otimizações de imagem. Como alternativa, outra estratégia é usar o DevTools para identificar os maiores arquivos de imagem. Essas imagens provavelmente serão boas candidatas para otimização.

Auditorias relevantes do Lighthouse:

Fluxo de trabalho do Chrome DevTools:

Corrigir

Se você tiver pouco tempo...

Tenha mais tempo para identificar imagens grandes e carregadas com frequência e otimizá-las manualmente com uma ferramenta como o Squoosh. 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, produzindo uma redução de 30 a 40% no tamanho do arquivo.
  • Formato: use JPEGs em fotos em vez de PNG. Use MP4 para conteúdo animado em vez de GIF.

Se você tiver mais tempo...

Configure uma CDN de imagem se as imagens forem responsáveis por uma parte substancial do seu site. As CDNs de imagens são projetadas para exibir e otimizar imagens e descarregarão a veiculação de imagens do servidor de origem. Configurar uma CDN de imagem é simples, mas exige a atualização dos URLs de imagens existentes para que apontem para a CDN de imagem.

Para saber mais:

Reduzir JS e CSS

A minificação remove caracteres desnecessários do JavaScript e CSS.

Diagnóstico

Use as auditorias do Lighthouse Minificar CSS e Minificar JavaScript para identificar recursos que precisam de minificação.

Corrigir

Se você tiver pouco tempo, concentre-se em minificar seu JavaScript. A maioria dos sites tem mais JavaScript do que CSS, então o impacto será maior.

Monitorar

As ferramentas de monitoramento de servidor oferecem coleta de dados, painéis e alertas relacionados ao desempenho do servidor. O uso deles pode ajudar a evitar e reduzir futuros problemas de desempenho do servidor.

A configuração de monitoramento precisa ser o mais simples possível. A coleta excessiva de dados e a geração de alertas tem seus custos: quanto maior o escopo ou a frequência da coleta de dados, mais caro é para coletar e armazenar. O excesso de alertas inevitavelmente leva a páginas ignoradas.

Os alertas precisam usar métricas que detectem problemas de maneira consistente e precisa. O tempo de resposta do servidor (latência) é uma métrica que funciona particularmente bem para isso: detecta uma grande variedade de problemas e se relaciona diretamente 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 captam um subconjunto menor de problemas. Além disso, os alertas devem ser baseados no desempenho observado na cauda (ou seja, no 95o ou 99o percentis), em vez de nas médias. Caso contrário, as médias podem ocultar facilmente 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 da ferramenta em cada servidor a ser monitorado. Depois da conclusão, configure os alertas.

Instruções: