O que devo fazer para ampliar um site de tráfego intenso?

14

Quais práticas recomendadas devem ser tomadas para um site que precisa ser "expandido" para lidar com a capacidade? Isso é especialmente relevante agora que as pessoas estão considerando a nuvem, mas podem estar perdendo os fundamentos.

Estou interessado em ouvir sobre qualquer coisa que você considera uma prática recomendada, desde tarefas de nível de desenvolvimento, até infraestrutura, até gerenciamento.

    
por random65537 08.09.2010 / 04:49
fonte

6 respostas

16

Design para simultaneidade

Ou seja, como você está codificando, planeje ter vários segmentos em andamento. Planeje o estado compartilhado (geralmente apenas o db). Planeje vários processos. Planeje a distribuição física.

Isso permite distribuir seu sistema em várias máquinas e em vários processos com balanceamento de carga. Ele permite que você tenha processos redundantes em execução em caso de falha e, caso precise modificar o sistema no local, não é necessário eliminar todos os serviços para fazer isso.

    
por 08.09.2010 / 07:37
fonte
13

Algumas coisas que você pode considerar:

  • Separando os lados de leitura e gravação do seu armazenamento de dados.
    • CQRS / Event Sourcing
    • CQS
    • Passagem de mensagens / Atores
  • Evitando o processo compartilhado e o estado do encadeamento
    • Portanto, evitando bloquear
    • Você pode evitar isso através do sistema de tipos, criando suas classes, estruturas e outros tipos de dados para serem imutáveis, ou seja, sem alterações após a construção. Especialmente para tipos de dados abstratos complexos, funciona surpreendentemente bem (por exemplo, a implementação do jQuery)
  • Não está bloqueando os encadeamentos do servidor da web no IO. Se você estiver usando o ASP.Net use páginas / ações assíncronas com o padrão de APM / biblioteca paralela de tarefas (TPL)
  • Não está salvando cargas de estado no dicionário da sessão do usuário
    • Isso precisa ser movido por threads quando ocorrem migrações de thread no IIS.
    • Ter roteamento inteligente, de modo que os recursos não seguros / estáticos não sejam exibidos com a mesma estrutura de aplicativo (por exemplo, ASP.Net) que adiciona sobrecarga. Olhe para ter servidores da web diferentes, por exemplo.
  • Escrevendo código de passagem de continuação com um padrão de fluxo de trabalho assíncrono (por exemplo, bind (haskell) /callcc/Tasks.ContinueWith/F#s async)
  • Use a teoria de enfileiramento para calcular onde seus gargalos podem acontecer
  • Use atualizações push-em vez de baseadas em pull para modelos de leitura e outros estados de aplicativos. Por exemplo. através do RabbitMQ / nServiceBus
  • Use os recursos mínimos aplicáveis "manipulador http"
  • Para arquivos estáticos, veiculem e-tags e políticas de expiração de cache para permitir que a infraestrutura da Web funcione como deveria (por exemplo, com o proxy do squid)
  • (Contrate-me para resolver seus problemas de dimensionamento e obtenha tutoriais no site;))
por 10.02.2011 / 23:06
fonte
4

Compartilhar arquitetura de nada.

Com isso em mente, e ao contrário do que você pode pensar, não entre imediatamente em uma solução de scale-out. A sobrecarga fora do sistema versus uma chamada no sistema não deve ser sub-ponderada. Por exemplo, leva muito mais tempo para fazer uma conexão de banco de dados em qualquer interface de rede do que para fazer uma chamada local. Faça um orçamento de quanto tempo em gerenciamento, energia e esforço de ajuste é necessário em scale-out versus o $ extra para um verdadeiro sistema grande.

Independentemente disso, ainda há grande valor nas arquiteturas "share nothing" e você pode dimensionar e dimensionar seus sistemas quando chegar a hora.

    
por 20.10.2010 / 06:32
fonte
0

Paralelize solicitações em vários nomes de host

Parte do padrão HTTP é uma seção que diz que os webclients solicitarão no máximo 2 sessões por host DNS. Aqui está uma solução na qual você alias seu www.domain.com e obtém uma maior simultaneidade de solicitações, tornando sua página mais rápida:

link

Basicamente, envolve a edição do seu Manipulador HTTP ASP.NET para alternar os hosts de destino para os quais você envia clientes, onde cada host é um CNAME para "www".

    
por 08.09.2010 / 05:02
fonte
0

DNS seguro, rápido e confiável

Encontrei alguns sites de alta capacidade usando o servidor DNS do registrador, que não tinha nenhum SLA para tempo de atividade ou desempenho. Além disso, seus servidores estavam localizados na Índia e a latência por si só aumenta a chance de um falsificador de DNS envenenar o cache do seu provedor, ou ISP intermediário. Isso faria com que até mesmo seu tráfego protegido por SSL fosse redirecionado sem que ninguém soubesse.

A velocidade do DNS também afeta o tempo de carregamento inicial do seu servidor, antes que os registros sejam armazenados em cache.

Eu uso o DynDNS ou Neustar para a maioria dos meus clientes, pois eles têm uma infra-estrutura DNS bastante sólida (embora seja cara e eu não tenha nenhuma outra afiliação com essas empresas).

    
por 08.09.2010 / 04:57
fonte
0

Acho que a chave será simples:

Tenha um código simples. Isso significa algo que você olha e entende. À medida que você expande e altera servidores, precisa saber o que está acontecendo. Você também pode precisar adicionar codificadores que precisam entender rapidamente. Ganchos e arquivos XML que chamam código aleatório que não é óbvio são muito ruins.

Então você pode testar e encontrar os problemas.

Veja aqui: link

Nós da stellarbuild tentamos garantir que nossos sites sejam dimensionados sem tempo de inatividade. Isso significa que você precisa saber o que seu código faz. e onde isso acontece. Mesmo se você estiver testando uma máquina diferente, não poderá demorar muito para dimensionar. A maioria das pessoas só começa quando é quase tarde demais, infelizmente. Você pode otimizar apenas quando fizer isso na minha opinião.

    
por 18.11.2014 / 01:35
fonte