Primeiros dias online: como não matar seu site

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

Como posso mitigar esse risco?

Eu pensei em

• indo ao ar gradualmente, como SO e SF: beta "privado", beta público, público
• permitir X conexões sessões simultaneamente, para que o usuário conectado ainda tenha uma boa experiência do site e os outros tenham uma boa mensagem de desculpas

Não posso:

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

1. Faça o cache o máximo que puder. Todas as páginas 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 devem ser armazenados em cache.
2. Tente usar um serviço externo como o Amazon S3 para veicular imagens e multimídia (ou prepare-o para uso se o site for atingido repentinamente por uma tonelada de tráfego).

A entrada gradual ao vivo pode funcionar para SOF e SF, porque eles já tinham publicidade e demanda integradas, devido à popularidade dos blogs de Jeff e Joel. Se você não tiver uma base de usuários quase garantida como eles, entrar no ar gradualmente pode ser fatal.

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

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

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

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

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

Às vezes, um sistema de convite pode ser uma boa maneira de controlar a aceitação de um site pelo usuário. 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 terá muitas pessoas acessando o site no início e não terá um pico enorme de tráfego.

A desvantagem, é claro, é que você pode afastar muitos usuários no começo que não têm convites e que podem não retornar mais tarde. A menos que você tenha um site realmente bom que as pessoas estejam muito empolgadas para usar, isso pode ser uma péssima jogada. Depende do site realmente. Além disso, você precisaria ter um tempo extra de desenvolvimento para adicionar um sistema de convite.

Eu garantiria que você tivesse uma infraestrutura de monitoramento robusta em vigor 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 igualmente entre as caixas e que, se algo derretido, você sabe qual era.

Saber onde está o problema reduzirá drasticamente o tempo necessário para responder. Eu já vi muitos sites sendo lançados sem nenhum tipo de monitoramento, com a intenção de que seja configurado mais tarde ... depois que o incêndio terminar. Isso é profundamente errado.

Convém procurar na hospedagem de terceiros de conteúdo estático, como o Amazon S3. Pode valer a pena, dependendo do seu aplicativo, também obscurecer alguns (por mais que eu odeie a palavra da moda) usando o Amazon EC2.

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:
http://www.dreamhost.com/hosting-vps.html