Créditos: Carlos E. Morimoto

A configuração dos caches é o parâmetro da configuração que afeta mais diretamente o desempenho do servidor proxy e por isso deve ser sempre definida com cuidado em qualquer servidor que irá atender a um grande volume de usuários. Embora a configuração pareça simples, ela na verdade esconde diversos detalhes pouco intuitivos.
Como comentei a pouco, em um servidor de rede local que atende um pequeno volume de clientes, você pode reservar apenas 32 ou 64 MB de memória RAM para o cache do Squid (de forma que ele não consuma toda a memória do servidor, prejudicando seu desempenho em outras tarefas) e, em um servidor dedicado para uma rede de maior porte você pode reservar até 1/3 da memória total do servidor. Você deve ter se perguntado por que reservar apenas 1/3 da memória, se a função do servidor será rodar apenas o proxy. Porque não reservar logo toda a memória para o Squid?
A resposta é que além da RAM reservada ao cache em memória, o Squid precisa de memória RAM para diversas outras tarefas, incluindo o gerenciamento das conexões e armazenamento da metadata dos arquivos armazenados no cache em disco, sem falar da memória RAM consumida pelo sistema operacional para fazer cache de disco e outras atividades. Reservando muita memória para o cache, o sistema é obrigado a utilizar memória swap, o que acaba reduzindo o desempenho em vez de aumentar.
Em uma pequena rede, raramente o desempenho do HD será um gargalo, já que o proxy precisará atender a um pequeno volume de requisições. Entretanto, em uma grande rede, com mais do que 100 ou 200 clientes o desempenho do proxy é freqüentemente gargalado pelo volume de leituras que o HD é capaz de realizar.
Uma dica nesse caso é utilizar HDs SATA (ou SCSI) com suporte a NCQ; neles a controladora pode realizar leituras fora de ordem, levando em conta a posição dos arquivos nos discos magnéticos. Isso faz com que eles sejam capazes de realizar um volume de leituras de pequenos arquivos muito maior do que HDs IDE e HDs SATA sem NCQ (em algumas situações específicas, até duas vezes mais), o que melhora assustadoramente o desempenho em servidores proxy. Verifique também a possibilidade de adicionar mais memória RAM ao servidor, já que com um cache maior na memória RAM, menos arquivos precisarão ser lidos a partir do HD.
Outra dica é que você pode reduzir bastante o volume de operações de acesso a disco fazendo com que o cache despreze arquivos muito pequenos (menores do que 2 KB, por exemplo) através da opção “minimum_object_size”, como em:
maximum_object_size 512 MB
minimum_object_size 2 KB
Isso faz com que pequenas imagens e outros tipos de arquivos muito pequenos, usados em profusão em muitas páginas web sejam simplesmente baixados novamente a cada acesso, em vez de precisarem ser lidos no cache do HD. Como os arquivos são muito pequenos, o aumento no uso do link não deve ser considerável.
Continuando, se você precisar alterar a localização da pasta do cache na linha “cache_dir” (para colocá-lo em uma pasta em uma partição separada, por exemplo), você vai logo perceber que o Squid deixará de inicializar, acusando um erro de permissão no diretório do cache, como nesse exemplo:
Restarting Squid HTTP proxy: squid* Creating squid spool directory structure
2008/06/31 16:35:46| Creating Swap Directories
FATAL: Failed to make swap directory /mnt/sda2/squid/00: (13) Permission denied
Squid Cache (Version 2.6.STABLE5): Terminated abnormally.
CPU Usage: 0.000 seconds = 0.000 user + 0.000 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0

Para solucionar o problema, pare o Squid, ajuste as permissões da nova pasta, de forma que a posse seja transferida para o usuário “proxy” e o grupo “proxy” (usados pelo Squid) e, para concluir, execute o comando “squid -z”, que faz com que ele reformate o diretório do cache, criando a estrutura apropriada:
# /etc/init.d/squid stop
# chown -R proxy.proxy /mnt/sda2/squid
# squid -z
# /etc/init.d/squid start
Em versões antigas do Squid você ficava limitado a um único diretório de cache, de forma que a única forma de adicionar uma nova partição era realmente movendo o cache para ela. Nas versões atuais (desde o Squid 2.0) existe a opção de simplesmente adicionar novas linhas “cache_dir” na configuração, sem apagar as antigas. Isso permite que você simplesmente adicione novas pastas e partições ao cache, mantendo as antigas, como em:
cache_dir ufs /var/spool/squid 2048 16 256
cache_dir ufs /mnt/sda2/squid 5120 16 256
cache_dir ufs /mnt/sda3/squid 10240 16 256
Não esqueça de que, ao adicionar uma nova pasta, você deve parar o proxy, ajustar as permissões de acesso e rodar o comando “squid -z” para que o Squid crie as estruturas necessárias, como no exemplo anterior.
Note que, mesmo ao usar uma partição separada só para o cache, você não deve reservar mais do que 80% do espaço total da partição para ele, pois o Squid precisa de um pouco de espaço extra para manter um arquivo com o status do cache e para operações de organização em geral, sem falar que é importante manter uma pequena percentagem de espaço livre na partição para reduzir a fragmentação. Se você tiver uma partição de 10 GB e usar na configuração “cache_dir ufs /var/spool/squid 10480 16 256” (reservando exatamente 10 GB para o cache), o Squid vai travar depois de algum tempo, por falta de espaço em disco. O correto no caso seria usar “cache_dir ufs /var/spool/squid 8192 16 256”, reservando 8 GB em vez de 10.
Uma observação final é que o volume de espaço em disco reservado ao cache tem efeito sobre o volume de memória RAM consumido pelo Squid (em adição ao cache na memória), pois o Squid precisa manter carregadas informações sobre os arquivos armazenados no cache para localizá-los de forma eficiente.
De uma forma geral, para cada gigabyte de espaço em disco reservado para o cache, o Squid consome cerca de 10 MB a mais de memória RAM (o valor real varia de acordo com o tamanho dos arquivos armazenados no cache), de forma que um cache de 20 GB, por exemplo, aumenta o volume de memória usado pelo Squid em aproximadamente 200 MB.
Devido a isso, não é recomendável usar um cache em disco muito grande, a menos que o servidor realmente possua muita memória disponível e precise atender a um volume muito grande de clientes. Para um servidor de rede local, um cache de 5 ou 10 GB já é mais do que suficiente.