[FUG-BR] RES: Thundercache para conteúdos dinâmicos [OFF - TOPIC]
Ciro Cardoso de Meneses
cirodemeneses em gmail.com
Sábado Janeiro 4 14:38:26 BRST 2014
Meu melhor site com o thundercache é este:
924 clientes
Gateway:
xeon dell quadcore (antigo)
8G Mem
6Hds (1 sistema, 3 lusca, 2 thunder)
Freebsd 9.2
unbound
lusca
thundercache
Controlador de Banda: core i7 (xinglig) com placa intel dual giga +
Freebsd 8.4
unbound
dummynet
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||||||
Interface Traffic Peak Total
tun16 in 0.000 Mb/s 0.001 Mb/s 24.848 KB
out 0.000 Mb/s 0.000 Mb/s 51.946 MB
tun0 in 0.000 Mb/s 0.000 Mb/s 72.280 MB
out 0.000 Mb/s 0.000 Mb/s 84.155 MB
lo0 in 31.293 Mb/s 42.755 Mb/s 3.588 TB
out 31.293 Mb/s 42.755 Mb/s 3.588 TB
bge0 in 86.964 Mb/s 93.284 Mb/s 6.892 TB
out 8.955 Mb/s 9.078 Mb/s 1.018 TB
igb0 in 9.008 Mb/s 10.272 Mb/s 1.083 TB
out 191.210 Mb/s 205.633 Mb/s 16.764 TB
last pid: 16702; load averages: 1.14, 1.20,
1.10
up 16+19:19:32 13:28:47
61 processes: 2 running, 58 sleeping, 1 waiting
CPU 0: 2.2% user, 0.0% nice, 12.7% system, 6.0% interrupt, 79.0% idle
CPU 1: 1.5% user, 0.0% nice, 24.0% system, 8.2% interrupt, 66.3% idle
CPU 2: 4.9% user, 0.0% nice, 12.7% system, 5.2% interrupt, 77.2% idle
CPU 3: 3.7% user, 0.0% nice, 13.9% system, 7.5% interrupt, 74.9% idle
Mem: 4230M Active, 1400M Inact, 1443M Wired, 95M Cache, 827M Buf, 743M Free
ARC: 243M Total, 1008K MFU, 114M MRU, 23M Anon, 4177K Header, 101M Other
Swap: 4096M Total, 9616K Used, 4086M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND
11 root 4 171 ki31 0K 64K RUN 0 1403.9 322.51% idle
12 root 27 -60 - 0K 432K WAIT 0 57.7H 22.90% intr
0 root 885 -8 0 0K 14160K - 0 49.6H 18.95% kernel
49295 squid 37 44 0 4520M 4414M ucond 0 256:40 18.36% squid
49258 root 216 47 0 727M 647M ucond 2 180:14 0.98%
thunder71_f64_r972
Em 4 de janeiro de 2014 11:16, Márcio Elias <marcioelias em gmail.com>escreveu:
> Já usei o SpeedBR (uma MERDA SEM TAMANHO), o Thunder íamos usar
> inicialmente mais este não tinha implementação para WCCP e queríamos
> redirecionar o tráfego do nosso border router pra ele, ai chegamos ao
> Thagos que usamos hoje. O nome da solução deles é Hyper Cache.
>
> Para terem uma ideia já que mencionaram a mudança no youtube, a alguns dias
> (quando isso ocorreu) notei que meu percentual de economia diminuiu muito,
> e voltou a crescer, ai entrei em contato com o suporte deles (24x7) e me
> disseram que tinham tirado o youtube (o que causou a diminuição da
> economia), fizeram a implementação de acordo com o novo protocolo deles,
> limparam o conteúdo em cache antigo (somente referente ao youtube) e
> colocaram o mesmo para funcionar novamente, sem eu nem ficar sabendo.
>
> Ou seja, vc paga a licença pra eles, tem suporte 24x7, e desenvolvimento
> constante, vc nem sabe que precisa se preocupar com isso, eles se preocupam
> por vc.
>
> Quanto a filtros de conteúdo, pelo que ví não tem no Hyper da Thagos, mais
> acho que isso hoje em dia, não sei seu cenário, mais é um tanto complicado,
> até mesmo o google nas buscas usa protocolo HTTPS, sendo assim o proxy tem
> que interceptar as conexões na porta 443, fazer uma nova requisição como se
> fosse o cliente, (para ter acesso aos dados da conexão) e então devolver o
> resultado ao cliente original usando um certificado SSL do próprio proxy,
> que não é o certificado original do endereço visitado, o que para o Chrome
> por exemplo é o bastante para impedir a navegação, outros browsers como
> Firefox ou IE até permitem, mais o cliente fica louco de tanto ter que
> aceitar certificados não assinados.
>
> Quanto a filtragem, acredito que tería que ser feita por um firewall, (do
> meu ponto de vista).
>
> Um ultimo concelho, o tráfego de dados entre todos seus usuários e a
> internet pode ser demasiadamente grande para colocar uma máquina em bridge
> no meio e esperar que funcione, (acima de 50M de link já não aconcelho),
> por que vai ser muito fácil essa máquina entrar em colapso e deixar todos
> seus usuários sem acesso, por isso, continue com a ideia de
> redirecionamento de tráfego.
>
> Uma coisa que posso dizer (e que um colega citou acima) é que o
> redirecionamento de tráfego consome muita CPU, nosso router (um Cisco 7200)
> subiu certa de 25% o processamento a partir do momento que foi habilitado o
> protocolo WCCP para o redirecionamento de pacotes.
>
> Bom isso é um apanhado geral entre meus conhecimentos e experiências,
> espero que ajude, e se notarem que estou equivocado em algum ponto, é só
> falar.
>
> --
> Att.
> __________________________________
> Márcio Elias Hahn do Nascimento
>
> Araranguá - SC
> Cel: (55) 48-9661-0233
> msn: marcioeliashahn em hotmail.com
>
>
> 2014/1/4 Cobausque <cobausque em ig.com.br>
>
> > Realmente utilizo ele aqui é show de bola consigo um ótimo desempenho e
> um
> > retorno considerável.
> > Mas estou usando ele com Tproxy e com plataforma LINUX
> > Havia postado um exemplo na underlinux
> > https://under-linux.org/showthread.php?t=160329
> >
> > -----Mensagem original-----
> > De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> nome
> > de Alexandre Silva Nano
> > Enviada em: sexta-feira, 3 de janeiro de 2014 17:50
> > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > Assunto: Re: [FUG-BR] Thundercache para conteúdos dinâmicos [OFF - TOPIC]
> >
> > Em 3 de janeiro de 2014 16:36, Lucas FL <lucas.f.lotaif em gmail.com>
> > escreveu:
> >
> > > Olá,
> > >
> > > Também existe o InComum:
> > > http://sourceforge.net/projects/incomum/
> > > https://lists.sourceforge.net/lists/listinfo/incomum-users
> > >
> > > Apesar da recente mudança do youtube, que dificulta ainda mais o
> > > cache, acredito que seja a opção mais transparente, leve e funcional
> > > que podemos encontrar.
> > >
> > > Att.
> > >
> > > Lucas F. Lotaif
> > >
> >
> > Verdade! Esqueci de mencionar o inComum, porém o mesmo não funciona mais
> > com
> > o Youtube depois da mudança do método de streaming. Já usei bastante e
> com
> > sucesso em vários locais.
> >
> > Ele ainda é excelente para fazer cache de outros conteúdos.
> >
> > --
> > Att, Alexandre Silva Nano
> > Nanotec Consultoria TIC
> > Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified
> > Specialist - NAC, Switching
> >
> > Analista de Tecnologia da Informação e Comunicação
> >
> > Perfil LinkedIn:
> http://br.linkedin.com/pub/alexandre-silva-nano/33/59/77a
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
--
_______________________________________________________________________________
Ciro Cardoso de Meneses
Analista de TI
(79) 9894-8250 (vivo)
(79) 9115-0561 (tim)
(79) 8151-1390 (claro)
(79) 8853-0017 (oi)
Mais detalhes sobre a lista de discussão freebsd