[GTER] SQUID squid-3.1.0.14 + TPROXY

Renato Murilo Langona renato at linuxsecurity.com.br
Thu Nov 19 16:54:57 -02 2009


Luzivan, necessariamente vc nao precisa passar todos os seus clientes 
por um unico proxy/cache, pode utilizar estrutura de caches multiplos 
(pais e filhos), distribuidos em pontos de roteamento ou de concentracao 
de redes, aliviando a carga em seu proxy/cache principal ou de saida do 
link...

Abs!

Luzivan escreveu:
> Marcelus, compreendi, Obrigado pela rápida resposta.
>
> Aqui já pretendo começar com 5500 clientes simultaneos passando pelo CACHE.
> Vi que no seu Number of clients accessing cache:      1445
>
> são apenas 1445 clientes, uma quantidade baixa e ja tem estes problemas.
> Agora me preocupei :(.
>
>
> 2009/11/19 Marcelus Trojahn <mtrojahn at gmail.com>
>
>   
>> Sim, tproxy...
>>
>> Em horarios entre 17h ate as 23h passa por ele cerca de 80Mbps de
>> trafego HTTP... Por este motivo, se voce prestar atencao abaixo, ele
>> nao tem cache em disco...
>>
>> O servidor tem 8GB de memoria (que pretendo aumentar para 16) e
>> trabalha apenas com cache_mem com objetos com maximo de 500K.
>>
>> Com este trafego todo, foi impossivel fazer o Squid nao ter problema
>> de I/O de disco... Depois de testar as mais variadas tecnicas (raid0,
>> filesystems diferentes, caches grandes, caches pequenos, varios
>> caches, etc) optamos por simplesmente nao fazer nada em disco... O
>> Squid nao dava conta de fazer a rotacao dos arquivos em disco... Assim
>> que o cache enchia e ele tinha que comecar a deletar objetos antigos
>> para armazenar novos ele ficava lento... Arquivos eram criados muito
>> mais rapido do que ele podia apagar ate o ponto onde ele parava de
>> fazer proxy e se dedicava apenas a limpar o cache...
>>
>> Obviamente minha economia de banda nao eh tanta desta forma, mas mesmo
>> assim se ecomiza mais de 10Mbs no meu link... Em um link de 100Mbs, eu
>> diria que 10% de economia ja esta de bom tamanho.
>>
>>     
(...)



More information about the gter mailing list