[FUGSPBR] particao squid

[João Carlos Mendes Luís]

eksffa em freebsdbrasil.com.br wrote:
>>/dev/ad0s1h             /squid          ufs     rw,async,nosuid,noexec,nodev
>>2       2
>>
>>Gostaria de saber a opinião dos mesmo, para uma possível melhora na
>>performance do mesmo e também para a segurança.
> 
> Na minha sincera e atrasada opinião, das opções de montagem todas, faltou a mais
> importante, "noatime". Não atualizar o tempo de acesso aos milhoes de arquivos
> que constituem seu Cache vai render algum desempenho a mais.

Isso!!!

E a opção buffered logs também é ótima, ainda mais para discos IDE.   ;-)

> Bom, entre em qualquer hierarquia de cache do Squid ja existente, e faca uma
> analise do tamanho dos arquivos que sao gerados no cacheamento. Voce vai
> concluir que a grande maioria deles sao bem, bem pequenos. Alguns ultrapassam
> os 100k, mas estes seriam (chutando) sempre menos que 30% dos arquivos no
> cache.

Se forem 30%, o ganho de rede vai ser aburdo.

Pense o seguinte: em vez de gastar zilhoes em um software de geência e 
atualização de antivirus corporativo, use antivirus comum, com atualização pela 
web, e deixe tudo ficar no cache.  Isso é ótimo!   ;-)

Tambem vale para o Windows Update, netscape, etc.

Ou seja, por causa dessas coisas, eu tento deixar o cache aceitando arquivos de 
até 32M, feliz da vida.

> Por razoes que nos poderiamos ficar discutindo horas, voce pode concluir que os
> argumentos padrao de criacao do sistema de arquivo, no FreeBSD, nao sao
> otimizados para cache do Squid, ou seja blocos de 16K por unidades de
> fragmentacao de 2k sao grandes demais =) Pode ganhar performance diminuindo
> estes blocos. Isso pode ser feito com a opcao "Newfs Args" em cada slice
> (dentro do sysinstall) ou voce pode meter um newfs novo ai na sua ad0s1h com os
> parametros alterados (-b e -f respectivamente). Nunca se esqueca da regra que a
> relacao blocos/fragmentacao deve ser sempre 8:1 ("man newfs" deixa isso
> claro).

Não sei se são grandes demais, não.  O tamanho médio de um arquivo é 13k (medido 
em vários caches no mundo).  O tamanho 8/1 talvez tenha um desemepenho melhor, 
mas depende muito do perfil de tráfego.  E tamanhos menores devem dar mais 
perdas, nao só de espaço mas tambem de desempenho, uma vez que o SO tranfere o 
bloco todo numa única operação de I/O.


_______________________________________________________________
Sair da Lista: http://lists.fugspbr.org/listinfo.cgi
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/