[caiu] Youtube via GVT

[Provedor Bogus]

A solução que eu uso foi desenvolvida do zero, tanto P2P quando HTTP, e não
usa nenhuma linha de código open source, até porque, não estou certo que
alguma dessas que você listou (ou alguma outra open source) consiga
suportar a nossa quantidade de tráfego no hardware que utilizamos. Há
tempos atrás, nós fizemos uma cotação com a PeerApp e só de hardware Dell
pediram US$ 90 mil. Os dois servidores Supermicro que usamos hoje não
chegaram a R$ 40.000 de investimento e chegam a fornecer 5 Gbps em dias de
tráfego excepcional como atualizações de Playstation, Xbox, iPhone ou
episódio novo de Game of Thrones no Torrent.
No passado, usamos Squid durante muitos anos e falando sinceramente, tenho
pouco (ou quase nada) a reclamar. A coisa só desandou com ele depois que
migramos a rede de rádios para PON. Na época nós contratamos o Adrian Chadd
(que desenvolve o Lusca) para nos ajudar com otimizações no Squid, mas não
deu certo, foi aí que trocamos para uma solução profissional. Mas em linhas
gerais, o Squid sempre foi bom e ajudou muito enquanto pôde.
Para tráfegos menores, todas essas que você enumerou devem ser melhores do
que não ter nenhum cache, ainda que tenham graves limitações para um
provedor, como não lidar com tráfego de partial content (HTTP 206), faltar
um cluster centralizado de conteúdo, etc.


Em 6 de setembro de 2013 13:11, Lucas Willian Bocchi <lucas.bocchi at gmail.com
> escreveu:

> E outra: hoje nao existe mais so squid como solucao de cache. So para falar
> da pontinha do iceberg podemos falar do apache traffic server (publicado na
> GTER), ngix, o lusca... Pra quem derbuma boa pesquisada consegue achar boas
> solucoes para estes problemas. O problema eh ter o conhecimento, vontade ou
> recursos para montar a solucao pois a grande maioria dessas solucoes de
> caixa fechada sao baseados em solucoes ja conhecidas (ninguem mais anda
> inventando a roda hoje em dia) com alguma customizacao.
>