Primeiros dias on-line: como não matar seu site

Question

Suponha que você tenha esse novo site sofisticado, com muitos dados (como imagens grandes) e esteja prestes a colocá-lo on-line. Se você fizer publicidade "em excesso", durante os primeiros dias, o site ficará sobrecarregado com solicitações.

Como posso reduzir esse risco?

Eu pensei em

• vai ao vivo gradualmente, como SO e SF: beta "privada", beta pública, pública
• permitem sessões X conexões simultaneamente, então o usuário conectado ainda tem uma boa experiência do site e os outros têm uma boa mensagem de desculpas

Eu não posso:

• compre mais servidores, pois após os primeiros dias, o site terá muito menos tráfego:)

Answer 1

1. Cache tanto quanto você puder. Todas as páginas que são criadas dinamicamente devem ser armazenadas em cache para que os usuários obtenham uma versão estática. Nos componentes da página que consultam o banco de dados, também deve ser armazenado em cache.
2. Tente usar um serviço externo como o Amazon S3 para exibir imagens e multimídia (ou tê-lo pronto para uso se o site for atingido de repente com uma tonelada de tráfego).

Ir ao vivo gradualmente pode funcionar para SOF e SF porque eles já tiveram publicidade e demanda embutidas, devido à popularidade dos blogs de Jeff e Joel. Se você não tem uma base de usuários quase garantida como eles, então ir ao vivo gradualmente pode ser fatal.

Eu evitaria limitar por sessões simultâneas, pois é difícil definir o final de uma sessão causada por inatividade. Se um usuário sair por 15 minutos e tentar recarregar a página, apenas para receber uma mensagem de erro, você acaba de perder um usuário.

    

Answer 2

Quanta planejamento entrou em seu modelo de dados? Você criou um esquema que permitirá aumentar o volume de consultas sem classificações caras, colunas binárias ou junções complexas? Você ajustou seu back-end de banco de dados (supondo que você tenha um)?

Como você está servindo suas "imagens grandes"? Você pode dividir isso em um processo de servidor da Web separado, mesmo em um domínio separado?

Você testou seu sistema? Ferramentas como ApacheBench e Siege são inestimáveis.

Toda a sua configuração está no svn? Sua implantação é automatizada? Você ficará feliz com isso quando tiver que transferir nosso aplicativo para o segundo servidor.

    

Answer 3

Um sistema de convite pode, às vezes, ser uma boa maneira de controlar a aceitação do usuário de um site. Distribua um certo número de convites no início, para que o site não fique sobrecarregado. Em seguida, dê a cada usuário alguns convites para passar para outros, aumentando lentamente o número de usuários no site. Dessa forma, você não conseguirá muitas pessoas acessando o site no começo, e você não terá um pico enorme de tráfego.

A desvantagem, é claro, é que você pode estar afastando muitos usuários no início que não têm convites e que podem não retornar mais tarde. A menos que você tenha um site realmente bom e que as pessoas estejam muito animadas para usar, isso pode ser uma má jogada. Depende do site realmente. Além disso, você realmente precisa ter algum tempo extra de desenvolvimento para adicionar um sistema de convite.

    

Answer 4

Eu me certificaria de ter uma infraestrutura robusta de monitoramento antes do lançamento. Você precisa ter dados para basear suas decisões - isso significa medir a carga da CPU nos servidores, verificar se a carga está distribuída uniformemente entre as caixas e se algo se derrete, você sabe qual delas era.

Saber onde está o problema reduzirá drasticamente o tempo necessário para responder. Já vi muitos sites serem lançados sem monitoramento de qualquer tipo, com a intenção de que ele seja configurado depois ... depois que o incêndio acabar. Isso está profundamente errado.

    

Answer 5

Você pode querer procurar hospedagem de conteúdo estático de terceiros, como o Amazon S3. Pode valer a pena depender do seu aplicativo para também nublar alguns (tanto quanto eu odeio o chavão) usando o Amazon EC2.

    

Answer 6

Alguns provedores de hospedagem permitem testar servidores privados com capacidade máxima por um tempo e, em seguida, estabelecer uma capacidade razoável após o período de avaliação.

O DreamHost é um exemplo: link