[caiu] RES: PeerApp

[Provedor Bogus]

Em 1 de abril de 2015 09:24, Liandro Paulo Carniel <
liandro at medianeira.com.br> escreveu:

> Nas primeiras respostas alguém postou que consegue 30% de
> economia.
> Digo que seria um grande felizardo, pois não vejo
> entre vários que conheço que utilizam, que realmente tenham
> economia acima de 20% (com HTTPS pouco cacheia).
>

Certamente 30% de economia no protocolo HTTP. Acho até um número bem baixo.
Deveria dar mais do que isso. Mas o resultado varia de rede para rede. Pode
ser que no seu provedor o tráfego seja difuso o suficiente pra não ter bom
resultado.

Em HTTPS, nenhum cache vai funcionar.
O pessoal da Axcelera me mandou recentemente um e-mail dizendo que eles
pretendem resolver isso através de deduplicação do tráfego. Até onde eu
sei, é a única empresa que abordou o problema até agora.



> Com
> relação à velocidade mencionada abaixo, também
> deixa dúvidas, pois ele só vai conseguir agilizar a
> navegação se o conteúdo estiver em cache.
> E como
> pouco conteúdo é cacheável hoje em dia, até
> essa velocidade deixa de existir.
>

Ou a solução da PeerApp é ineficiente ou a implementação do cache não foi
adequada.

Não é questão apenas do conteúdo ser cacheável, mas qualquer boa aplicação
de cache faz paralelismo das requisições, como se fosse um pre-cache dos
objetos da página. Vamos dar um exemplo. Quando o usuário solicita
www.globo.com, o cache inicia diversas threads em paralelo pra buscar o
conteúdo que o browser do cliente ainda nem solicitou, mas que ele já terá
na RAM para fornecer. Uma vez que o browser fechar a conexão, ele guardará
o conteúdo cacheável e descartará o não-cacheável. Pelo menos assim
funciona a solução que usamos aqui e a experiência do usuário com cache é
estupidamente melhor do que sem ele.