Como preparamos um website de notícias para um pico.
O negócio de um website de notícias são os picos. Este é o método com que o preparamos: lemos os logs certos, sabemos onde está o limite, verificamos cada camada antes de gastar, e fazemos a aritmética.
Neste artigo 4 secções
- O tráfego expõe limites. A configuração define os limites. Preparar um pico significa encontrá-los antes de o público os encontrar.
- Primeiro, confirme que log transporta realmente o tráfego do website. Um log predefinido do servidor pode guardar uma pequena parte, enquanto o log do vhost do próprio website guarda o resto.
- Verifique cada camada antes de gastar. A base de dados está muitas vezes parada e rápida, enquanto o trabalho se acumula uma camada acima.
- Depois a aritmética: workers a dividir por segundos por pedido é o seu limite real em pedidos por segundo. Dimensione o pool para o pico que vai realmente atingir, mais margem.
O negócio de um website de notícias são os picos: quando a notícia rebenta, o público chega todo ao mesmo tempo. Preparar isso raramente é uma questão de hardware. É uma questão de configuração: o número de workers, os timeouts, os logs, a cache. Eis como preparamos um.
Leia primeiro o log certo
A primeira disciplina é contar corretamente. Num web server típico, o log predefinido e o log do vhost do próprio website são ficheiros diferentes, e o predefinido pode guardar apenas uma pequena parte do tráfego. Dimensione seja o que for a partir do log errado e está a dimensionar para a carga errada.
Saiba onde está o limite
Sob carga, os tempos dos pedidos dizem-lhe onde está o limite. A lentidão orgânica dispersa-se: alguns pedidos um pouco lentos, alguns muito lentos. Pedidos lentos que se concentram exatamente no timeout do gateway significam que a camada por trás do gateway está a ficar sem workers dentro do seu orçamento. Essa é uma assinatura de saturação, e aponta diretamente para a definição a dimensionar.
Verifique cada camada antes de gastar
Antes de alguém comprar RAM ou atualizar a camada de dados, verifique-a. Uma base de dados que está parada e rápida, sem queries lentas, a responder a tudo no momento em que é interrogada, não é a camada a dimensionar. A camada a dimensionar é aquela cujos workers estão todos ocupados. Esse padrão tem artigo próprio em dimensionar para baixo, não para cima.
O seu limite é aritmética
WORKERS
SEC / REQUEST
REQ / SEC
A preparação é dimensionamento, não compras: o pool de workers calculado a partir do pico que um website de notícias vai realmente atingir, mais margem, dentro de um orçamento de memória por worker medido. Depois uma camada de cache que serve conteúdo stale quando o backend abranda, para que um backend ocupado degrade para páginas ligeiramente antigas em vez de páginas de erro. A plataforma absorve o pico.
“O tráfego encontra o limite que define. Defina-o de propósito.”
Respostas diretas
Porque é que um website devolve erros 502 com muito tráfego?+
Normalmente a camada por trás do gateway ficou sem workers e o gateway desiste no seu timeout. A assinatura são pedidos lentos presos exatamente num número. Conte primeiro os erros no log do vhost correto, porque o log predefinido pode guardar apenas uma fração do seu tráfego.
Quantos workers deve ter o meu servidor de aplicação?+
Calcule: workers a dividir pela média de segundos por pedido é o seu limite em pedidos por segundo. Dimensione para o pico que vai realmente atingir mais margem, dentro de um orçamento de memória por worker medido, em vez de confiar na predefinição do pacote.
A base de dados é o estrangulamento quando o tráfego dispara?+
Verifique antes de gastar. Veja se está parada ou ocupada e se existem queries lentas. Muitas vezes a base de dados está parada e rápida, e o trabalho acumula-se uma camada acima. Verifique primeiro cada camada.
Como preparo um website para um pico de tráfego?+
Faça a aritmética dos workers contra o seu pico realista, confirme que logs transportam realmente o seu tráfego, faça um teste de carga até ao limite calculado, e coloque à frente caching do tipo stale-on-error para que um backend lento sirva páginas antigas em vez de erros.
Mais tráfego não exige simplesmente mais servidores?+
Eventualmente, mas quase nunca primeiro. Primeiro use a capacidade que a sua configuração está a reter: pools corretamente dimensionados, timeouts sensatos, caching que absorve a tempestade de leituras. Hardware comprado para cobrir uma definição de configuração é a alteração de configuração mais cara que existe.
Espera o seu melhor dia em breve?
Lançamento, imprensa, pico sazonal: traga-nos a data. Fazemos a aritmética dos workers, lemos os logs certos, e tornamos o pico apenas mais um gráfico.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro