Site pesado de largura de banda ... usar co-localização?


11

Estou trabalhando em um site que provavelmente terá muita largura de banda. Um recurso importante do site quando em uso ativo pode obter até 1 Mbps para uma única sessão. Felizmente, uma vez que os usuários superam o novo fator de brinquedo, o uso desse recurso provavelmente será de 1 a 5% ou menos (provavelmente muito menos) do tempo da sessão.

No entanto, é provável que novos usuários usem esse recurso um pouco, especialmente no lançamento. Estou muito preocupado com o uso da largura de banda.

Este é mais ou menos um nicho de mercado, por isso nunca precisarei escalar para níveis loucos como o YouTube. No entanto, é inteiramente possível que sejam alguns terabytes / mês.

A co-localização é a minha melhor opção? Quais serviços de largura de banda baratos (colocation / host / cloud / o que quer que seja) existem por aí?


Quanta largura de banda estamos falando (picos), que determina o seu nível de comprometimento, o que influencia fortemente se um colo é uma boa ideia ou não (dado que o faturamento de mosaico de 95% é bastante comum)
Tim Post

1
Ok, acho que estou inclinado a estabelecer um limite rígido de 10 Mbps. Eu posso ter uma fase beta limitada. Eu começaria com tudo aberto e mudaria para contas de visualização limitada se eu fosse inundada. Isso deve funcionar.
darron

Muito curioso que tipo de conteúdo dinâmico você está gerando e precisa de 1 Mbps para fazer o download! Vídeo ao vivo? De qualquer forma que você pode querer verificar para fora esta questão relacionada: serverfault.com/questions/148629
Greg Bray

Respostas:


6

Depende muito de quantas sessões simultâneas você espera. Se mais do que algumas sessões simultâneas são prováveis, você precisará de algo que lhe conceda uma conexão de 100Mbit, 1Gbit, se você espera mais de 50.

Também dependerá de que tipo de resiliência você precisa - se você deve ter garantias de tempo de atividade e outros SLAs e / ou sistemas de failover para assumir no caso de um problema (porque o projeto é importante o suficiente por um curto período de tempo de inatividade) embaraçoso), então suas opções são mais limitadas e seus custos serão mais altos.

Se você pode separar os grandes dados do restante do aplicativo, não precisa mover tudo para uma nova solução de hospedagem. Por exemplo, se os itens de largura de banda grande são arquivos de vídeo, você pode alugar um servidor dedicado com boa largura de banda em algum lugar e hospedá-los - você pode obter servidores em bons hosts com largura de banda decente e conexões de 100mbit surpreendentemente mais baratos hoje em dia (pago 50 dólares / mês) para um servidor pequeno com um link de 10 Mbits que eu poderia saturar nas duas direções 24 horas por dia, 7 dias por semana, se necessário, portanto, um link de 100 Mbits com um servidor mais robusto conectado não será caro, a menos que você precise de tempo de atividade garantido e outros SLAs e / ou servidores gerenciamento do provedor de hospedagem). Se o servidor estiver apenas servindo arquivos estáticos (mesmo os grandes), você não precisará de muita máquina em termos de CPU e RAM, apenas unidades rápidas e largura de banda. Também pode valer a pena analisar soluções hospedadas em "nuvem" ou uma rede de entrega de conteúdo - elas podem ser mais fáceis de dimensionar, caso você subestime a quantidade de largura de banda necessária, em teoria, é muito mais resistente (para obter uma garantia de tempo de atividade decente compensação se eles não cumprirem esse SLA). Manter a ação de reduzir a largura de banda separada dessa maneira tem a vantagem adicional de que, se o recurso de largura de banda alta atrair atenção suficiente para fazê-lo rastrear, não bloqueará todos os outros recursos ao mesmo tempo.


Sem SLAs, sem requisitos loucos de tempo de atividade. Atualmente, ele usa um pedaço decente de CPU / RAM por sessão. Uma única caixa robusta deve lidar com um bom número de sessões simultâneas.
darron 6/08/10

1

Puramente historicamente:
nos dias que antecederam os jogos do Facebook, todas as pessoas usavam MMO em formato de texto com base em navegador.

Um relativamente novo foi Ogame. Era um gráfico pesado e um sistema de mapas de 9 vezes 999 páginas (9 universos com 999 setores, com espaço para 15 planetas cada, e cada planeta poderia ter uma lua).

A quantidade de usuários que ingressou foi insana e a quantidade de tráfego ainda mais.

Então, o que eles fizeram para resolver isso? Eles começaram a usar um sistema de modelos PHP e permitiram que os usuários hospedassem as imagens e os arquivos CSS. Tudo o que você precisava fazer era clicar em uma caixa de seleção e inserir o caminho absoluto para a pasta base. Eles salvariam isso em seu banco de dados, usariam o <base>elemento HTML e o sistema de modelos definiria o URI de http: // caminho / para / imagem para arquivo: /// caminho / para / imagem

Depois disso, todos os links img poderiam permanecer os mesmos. Nada precisava ser baixado, porque os usuários já o tinham. O que significa carregamento de página mais rápido para o usuário (o que significa melhores avaliações de produtos) e também menor uso de largura de banda para a empresa que hospeda o site.

E, como um bônus adicional, eles o venderam como "faça você possuir fundos e imagens personalizados, não somos caras legais por deixar você fazer isso?"


1

Temos um site de alto tráfego e muitas fotos são carregadas em cada página. Temos servidores dedicados, mas decidimos colocar as fotos no Amazon S3 . Parece que você pode estar falando sobre arquivos de vídeo ou algum outro tipo de arquivo grande que eu acho que ainda se aplicaria aqui. Aqui estão alguns prós e contras (para nós)

Prós

  • Menos espaço em disco necessário em nossos servidores
  • Menos largura de banda para nossos servidores
  • Nossos arquivos de log são significativamente menores
  • Podemos integrá-lo facilmente ao Amazon CloudFront para tornar o carregamento ainda mais rápido para os visitantes

Contras

  • Custa um pouco mais. Poderíamos economizar um pouco de dinheiro com ele em nossos próprios servidores
  • Menos controle sobre eles (Amazônia) caindo ... para nossa sorte, eles realmente não caem. :)

outros pensamentos

Se você não está falando sobre arquivos de mídia ou downloads de arquivos grandes, minha resposta e várias outras podem não fazer sentido. Dê-nos mais alguns detalhes e faremos o possível para ajudar.


0

Um colo pode realmente fazer mais sentido, se ele puder justificar o commit mínimo (geralmente 5mb) com o faturamento do 95º percentil. Isso significa que ele nunca pagará pelos 5% mais altos, o que acaba sendo mais barato que uma CDN de terceiros. É difícil dizer, realmente precisamos ver exatamente quanto ele está usando.
Tim Post

Meu uso será um conteúdo quase totalmente dinâmico, com uma forte presença de CPU / memória por sessão. Depois de jogar com a ferramenta de estimativa de preços da AWS, parece ser muito mais barato optar pela colocação.
darron

Ah, eu presumi que as peças pesadas da largura de banda seriam mídias que você poderia colocar em uma CDN, parece que eu presumi errado. Embora se você tiver blocos dinâmicos processados ​​de maneira previsível (um conjunto finito de possíveis blocos de dados), ainda assim poderá colocar tudo isso em uma CDN. Vou parar de tentar adivinhar seu aplicativo agora. :-)
artlung

0

Dependendo do estado / país de destino (ou do mundo), eu usaria muitas soluções de cluster ("Nuvem") em locais diferentes (as redes de localização devem ser visualizadas ;-)). Por um lado, você tem controle total sobre sua CDN, mas, por outro, muito o que fazer (como monitorar, cuidar da infraestrutura de software e hardware e muito mais).

Soluções "gerenciadas", como a AWS ou algo assim. Existem muitos fornecedores de CDN / Cloud, que oferecem uma grande variedade de recursos.

OFFTOPIC: Dê uma olhada no Puppet [1] :-)

[1] http://www.puppetlabs.com/


0

Sim, você deve usar o Amazon AWS de forma semelhante.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.