Com quais considerações técnicas um administrador de sistema/rede deve se preocupar quando um site entra em sites de bookmarking/compartilhamento social?

Question

A razão pela qual pergunto é que o Stack Overflow foi Barra pontilhada, e Redditado.

Primeiro, que tipo de efeito isso tem nos servidores que alimentam um site?Segundo, o que pode ser feito pelos administradores de sistema para garantir que seus sites permaneçam funcionando da melhor forma possível?

Answer 1

Infelizmente, se você não planejou isso antes que aconteça, provavelmente será tarde demais e seus usuários terão uma experiência ruim.

A escalabilidade é sua primeira preocupação imediata.Você pode começar a receber mais acessos por segundo do que por mês.Sua primeira linha de defesa é uma boa programação e design.Certifique-se de não fazer nada estúpido, como recarregar dados de um banco de dados várias vezes por solicitação, em vez de armazená-los em cache.Antes que o pico aconteça, você precisa fazer alguns testes de carga bastante realistas para ver onde estão os gargalos.

Para um tráfego absurdamente alto, considere a possibilidade de mudar algumas páginas dinâmicas para páginas estáticas.

Ter uma arquitetura de servidor escalonável também ajuda.Hosts compartilhados geralmente não são escalonáveis.Uma única máquina dedicada geralmente não é escalável.Usar algo como o EC2 da Amazon para hospedar pode ajudar, especialmente se você planeja um cluster de servidores desde o início (mesmo que o cluster seja um único computador).

Sua próxima grande preocupação é a segurança.De repente você se torna um alvo muito maior para os bandidos.Certifique-se de ter um bom plano de segurança em vigor.Isso é algo que você sempre deve ter, mas se torna mais importante com o alto uso.

Answer 2

Em primeiro lugar, pergunte se você realmente quer gastar semanas e milhares de dólares planejando algo que pode nem acontecer e, se acontecer, dura cerca de 5 horas.

A solução mais fácil é ter uma boa maneira de mudar para uma página simplesmente permitindo uma inscrição.As pessoas se inscreverão e você poderá enviá-las por e-mail quando a tempestade passar.

Soluções mais elaboradas dependem da capacidade de escalabilidade rápida.Em primeiro lugar, isso é um problema de software (você pode se conectar a um banco de dados em outro servidor, pode fazer balanceamento de carga).Em segundo lugar, a sua solução de alojamento precisa de suportar uma expansão rápida.O Amazon EC2 vem à mente, ou talvez o slicehost.Com ambos os serviços você pode facilmente iniciar novas instâncias ("Vamos mover o banco de dados para um servidor diferente") e expandir suas instâncias ("Vamos atualizar o servidor de banco de dados para 4 GB de RAM").

Se você mantiver todos os dados no banco de dados (incluindo sessões), poderá facilmente ter vários servidores front-end.Para o banco de dados eu normalmente tentaria um único servidor com os maiores recursos disponíveis, mas apenas porque não trabalhei com replicação de banco de dados e isso costumava ser muito difícil de fazer, pelo menos com mysql.As coisas poderiam ter melhorado.

Answer 3

O designer do aplicativo precisa pensar em aumentar a escala (máquinas maiores com mais núcleos e maior desempenho) e/ou expandir (distribuir a carga de trabalho entre vários sistemas).O cara de TI precisa descobrir a melhor forma de oferecer suporte a isso.A rede é o que você olha primeiro, porque obviamente tudo depende dela.Começando na fronteira, isso geralmente significa balanceadores de carga de rede e roteadores redundantes atendidos por vários provedores.Você também pode consultar serviços e aplicativos de cache geográfico, como o cachefly.

Você deseja reduzir seus gargalos tanto quanto possível.Você também deseja projetar o ambiente de forma que ele possa ser ampliado conforme necessário, sem muito trabalho.Faça o trabalho de design antecipadamente e isso significará menos dores de cabeça quando você for escavado.

Answer 4

Algumas ideias (do que usei em projetos passados ​​e atuais):Para aumentar o desempenho (se necessário), você pode colocar um squid de cache e proxy reverso na frente do seu servidor.É claro que isso só funciona se você não tiver chaves de sessão e se as páginas forem um tanto estáticas (significa:eles mudam apenas uma vez por hora) e não são personalizados.Com o squid você pode potencializar um CMS inchado e lento como o typo3, tendo assim a performance de sites estáticos com o conforto de um CMS.

Você pode terceirizar arquivos grandes para serviços externos como Amazon S3, economizando largura de banda do seu servidor.

E se você puder gastar algum dinheiro (três dígitos por mês), também poderá usar uma rede de distribuição de conteúdo.Com isso implementado, você terá automaticamente escalonamento, alta disponibilidade e baixas latências para seus usuários.É claro que suas páginas devem poder ser armazenadas em cache, portanto, chaves de sessão e páginas personalizadas são proibidas.Se projetado com cuidado e com CDNs em mente, você pode pelo menos armazenar em cache ALGUM conteúdo, como fotos, vídeos e coisas estáticas.

Answer 5

A carga aumenta, como outras respostas mencionaram.

Você também receberá um fluxo de novos usuários/comentários em blogs/votos de pessoas entediadas que só estão realmente interessadas em vandalismo.Isto é principalmente um problema para blogs que permitem comentários completamente anônimos, onde algumas coisas terríveis serão inseridas.A plataforma do blog pode ter filtros de spam suficientes para bloqueá-la, mas frequentemente é necessária intervenção manual para limpar o lixo restante.

Mesmo uma pequena barreira de entrada, como exigir um nome de usuário ou endereço de e-mail mesmo que nenhuma verificação seja feita, reduzirá drasticamente o volume do vandalismo.