Preparando-se para um grande aumento no tráfego

Nossa empresa estará aparecendo em um programa de TV no horário nobre esta semana, e eles nos disseram que podemos esperar cerca de 200.000 visitantes em nosso site ao mesmo tempo.

Normalmente, apenas recebemos cerca de 100 visitas por dia, então não faço ideia se podemos lidar com tanto tráfego. Estamos hospedados por 1and1.co.uk.

Existem precauções que podemos tomar para impedir que nosso site seja danificado?

Durante o período de alto tráfego, seu servidor poderá lidar com todas as solicitações feitas pelos visitantes do seu site. Mas existem alguns limites nas conexões simultâneas manipuladas pelo servidor. Portanto, é melhor atender às solicitações da página o mais rápido possível.

Aqui estão algumas sugestões a serem consideradas nessas situações,

Melhorias no nível do aplicativo:

1. Minimize as solicitações HTTP para acelerar os tempos de carregamento da página.

a) Combine todos os arquivos JS juntos em um único arquivo JS combinado e todos os arquivos CSS em um único arquivo CSS combinado.

b) Minimize os arquivos JS e CSS, para que o tamanho do arquivo seja reduzido e baixado mais rapidamente.

c) Use CSS Sprites - Quando você combina a maioria ou todas as suas imagens em um sprite, transforma várias solicitações de imagens em apenas uma. Depois, basta usar a propriedade CSS da imagem de plano de fundo para exibir a seção da imagem necessária.

d) Atraso no download da imagem com carregamento lento, isso será útil para reduzir as solicitações de http.

2. Prepare páginas leves que esperam mais visitas:

a) Exclua elementos decorativos, como imagens ou Flash, sempre que possível; use texto em vez de imagens na navegação do site e no chrome e coloque a maior parte do conteúdo em HTML.

b) Use páginas HTML estáticas em vez de páginas dinâmicas; o último coloca mais carga nos seus servidores. Você também pode armazenar em cache a saída estática de páginas dinâmicas para reduzir a carga do servidor.

Melhorias no nível do servidor:

1. Reduza os valores de tempo limite do servidor consultando seu provedor de hospedagem (não deve ser muito baixo).

Quando o tempo limite for menor, a conexão será liberada em breve, para que o servidor possa lidar com mais conexões.

2. Use serviços de terceiros como o CloudFlare para cache de dados estáticos e para proteger seu site contra usuários maliciosos e ataques como DDOS.

3. Atualize o hardware do servidor - Atualize as memórias físicas e virtuais, aumente os limites dos processos de E / S e de entrada, se necessário. Seu provedor de hospedagem poderá ajudá-lo melhor.

4. Código dinâmico do cache - use o APC para armazenar em cache o código operacional do PHP.

5. Balanceamento de Carga - Distribua a carga entre vários servidores de balanceamento de carga.

• Quando todas as ações necessárias forem tomadas, é hora de verificar se o site está pronto para um grande aumento no tráfego.

  Existem alguns serviços de terceiros, como loadimpact.com, que fornecem testes de carga com tráfego simulado. A análise ajudará você a entender a quantidade de carga que seu site pode suportar e o que pode ser melhorado.

• Além disso, durante o período de pico de tráfego, evite operações de alto uso da CPU, como cronjobs de backup de sites etc.

Primeiro de tudo, eu recomendaria o Cloudflare. Você pode criar uma conta básica gratuita e ele direcionará o tráfego por meio de datacenters locais para minimizar a quantidade de saltos de servidor. O Cloudflare também é ótimo para armazenar conteúdo em cache e possui proteção DDOS.

Fora isso, tente cortar a gordura da sua camada de serviço. Certifique-se de que você não tenha nenhuma consulta de banco de dados sobrecarregada demais que garanta o seu código ou qualquer lógica intensiva da CPU que possa ser simplificada.

Tente também armazenar em cache quaisquer consultas ao banco de dados. Algumas ótimas opções para o cache de consultas são Redis ou Memcache. O OpCaching é outra consideração se você estiver usando um idioma não compilado.

Mas provavelmente o mais importante é manter o conteúdo estático (por exemplo, css, js e imagens) o mais otimizado possível. Minimize todo o seu Javascript, combine-os todos em um arquivo, se possível. Lembre-se de que cada arquivo incluído no seu site precisa fazer vários saltos no servidor para alcançar o usuário final.

Não subestime quanto largura de banda e tempo de carregamento você pode economizar com a compactação de imagens também!

Por fim, considere monitorar o desempenho com ferramentas como a New Relic.

Boa sorte !!

Fonte: um dos desenvolvedores do 12º site mais popular do Reino Unido, de acordo com Alexa.

Considere o teste de carga do seu site. Existem ferramentas gratuitas disponíveis, como JMeter , The Grinder e Gatling , que podem simular um grande número de visitantes do seu site.

Testando o impacto do tráfego pesado com antecedência, você pode determinar se algum ajuste feito foi eficaz e procurar outros ajustes, se não.

Se você está no 1and1, provavelmente está procurando hospedagem barata. Hospedagem barata significa que você tende a fazer tudo sob uma caixa. Um ponto importante da hospedagem é que, quando você hospeda tudo na mesma caixa, está dividindo recursos entre partes importantes do site:

• Seu servidor web (Apache, Nginx, etc)
• Seu banco de dados (MySQL, PostGreSQL, etc)

E sendo 1 e 1, há uma boa chance de você estar usando um painel de controle como o Plesk ou o cPanel, o que significa que você tem uma camada extra de coisas competindo por recursos. E a unha final no seu caixão? Você não tem muitos recursos. Você tem talvez 1 CPU (ou uma CPU virtual) e muito pouca RAM (se você tiver mais de 2 GB, ficarei surpreso).

Quando abandonamos o 1 e o 1, fomos com um provedor de hospedagem escalável (Amazon Web Services no nosso caso) e fizemos várias coisas que não podíamos antes

1. A Amazon tem suas próprias instâncias para bancos de dados (RDS) e, portanto, nosso banco de dados tem recursos para respirar. A maioria dos sistemas RDBMS vive e respira na RAM e isso era algo que poderíamos obter em abundância. Agora você também pode provisionar SSDs com alta E / S, tornando o outro ponto de estrangulamento do banco de dados (gravação de dados) menos doloroso.
2. Temos um balanceador de carga com 2 servidores web. Com um back-end robusto de banco de dados, não precisamos de front-end avançados, por isso temos dois servidores de nível inferior.
3. Mudamos para algo que poderia trazer máquinas totalmente configuradas sob demanda. Usando algo como Chef ou Puppet, você pode facilmente adicionar novos servidores da Web e é 100% transparente para os usuários finais, se bem feito. A AWS também possui Opsworks, para que você possa criar seus scripts diretamente na AWS.
4. Altere o tamanho da instância sob demanda. Esta é uma peça chave para nós. Se o banco de dados ficar atolado, eu posso derrubá-lo e reiniciá-lo como maior em alguns minutos. Sim, isso envolveria tempo de inatividade, mas alguns minutos de inatividade são melhores do que as horas de um site terrivelmente lento. Totalmente com medo do tempo de inatividade? Mantenha uma réplica de leitura nas asas, reduza-a, mude-a para uma instância maior, promova o master e evite qualquer tempo de inatividade pelo custo de uma máquina extra.

A AWS não é o único jogo da cidade (Azure, Rackspace etc.), mas verifique se o 1 e o 1 podem ser dimensionados para atender sua demanda.

Verifique com seu ISP e veja se há um limite na sua largura de banda. Atualize seu plano de hospedagem se a largura de banda for insuficiente para a quantidade de tráfego que você espera. Você não deseja exibir uma mensagem "Limite de largura de banda excedido" para seus visitantes.

Pela minha experiência pessoal, eu sabia que até o melhor VPS tem suas limitações. Vou leigo de verdade aqui.

Um de nosso site de esportes estava hospedado em um VPS. Durante uma partida entre o Paquistão e a Índia, recebemos mais de 70.000 hits. Tínhamos um VPS Inmotinghosting com 4GB de RAM e 2.algo GHz de processamento, 1TB de largura de banda, armazenamento SSD e outras coisas sofisticadas. Também tínhamos uma versão paga do Cloudflare ativada.

Estava a meio da partida e o site caiu. Ele nunca foi ao ar durante a partida e perdemos mais de 70.000 visitantes a mais. Mais tarde, soubemos que nossa largura de banda foi consumida e, sem o host de origem não funcionando, a CDN é na maioria das vezes inútil.

Lição: Além de obter um VPS e sintonizar um CND como o Cloudflare, minimize o tamanho da página. Quanto menor, melhor. Você pode usar o cache da página e a minificação de código, o que é muito útil para lidar com o tráfego.

Você não definiu "tudo de uma vez" muito bem. Digamos que você esteja vendo 200.000 visitantes únicos em meia hora. São 111 solicitações por segundo, sem levar em consideração os visitantes que clicam e abrem mais páginas (o que você deseja, certo?).

A primeira coisa que eu faria seria no Google histórias de pessoas lidando com quantidades semelhantes de tráfego. Muitas pessoas escreverão sobre suas experiências em seus blogs para ajudar outras pessoas. Você notará que é extremamente difícil encontrar uma história sobre alguém fazendo isso em hospedagem compartilhada, e há uma razão para isso. Procure soluções como Digital Ocean ou Amazon Web Services, para iniciantes, usando o data center mais próximo ao seu público. E eu concordo que transferir todos os seus recursos estáticos para o CloudFlare, mesmo uma conta gratuita, é uma excelente idéia.

Além disso, teste seu código adicionando scripts de tempo às partes superior e inferior das suas páginas, supondo que sejam dinâmicos. Supondo que minha suposição sobre números esteja correta, você precisará exibir cada página em menos de 10 milissegundos para manter qualquer tipo de desempenho aceitável. Se você estiver atendendo a todas as solicitações por SSL por padrão, desative-o por alguns dias enquanto a tempestade passa.

Além disso, 200.000 parece muito assustador, mas lembre-se de que você não precisa ter muito medo (embora deva estar um pouco). Por exemplo, quando a revista Paper publicou fotos de Kim Kardashian na NSFW, foram necessários apenas quatro servidores Web de tamanho médio e o Amazon ELB para lidar com a carga, de acordo com este artigo (SFW). Definitivamente, acho que sua configuração atual não será capaz de lidar com isso, mas você não precisa exatamente de dezesseis servidores da Web com 48 núcleos cada, alimentados por seu pequeno gerador nuclear.

Conheça esta pergunta antiga, mas muito boa, e gostaria de ter boas informações sobre o assunto há alguns anos ...

Periodicamente, temos sites (relacionados à atividade escolar) exibidos nas redes de TV. Como operamos com um orçamento muito apertado, o "balanceamento de carga" é a solução. Hoje em dia, as caixas de VPS podem ser bastante baratas e apenas espelhamos / duplicamos nosso conteúdo em 2 a 3 delas.

Veja este artigo e leia sobre "round-robin".

Mais informações sobre o teste de carga podem ser encontradas aqui .

Quando começamos a tentar lidar com picos, simplesmente tínhamos nosso conteúdo em caixas de 2-3 VPS e colocamos o NS nas configurações de registradores.

O melhor é ter servidores dedicados com vários clusters que resolverão seu problema

Boa sorte reescrevendo seu site, trocando de provedor e migrando conteúdo para uma CDN em menos de uma semana.

Como você deve ter percebido com as outras respostas, estas são as coisas mínimas que você precisa fazer para preparar seu site para um grande aumento no tráfego. Embora atualmente você esteja executando o 1and1.co.uk, provavelmente não possui uma equipe forte de engenheiros de rede, DBAs, programadores e otimizadores de front-end trabalhando para você.

Não é provável que aconteça, é?

Você não disse o que faz com o seu site, se ele roda carrinho de compras ou se pode ser implementado com conteúdo estático. Se este for o caso, você poderá sobreviver ao tsunami se juntar todo o site em arquivos estáticos e publicá-los no lugar do site comum (faça backup da versão atual primeiro).

Você também deve falar com 1 e 1 (com seu cartão de crédito na mão).