On 2014-07-08 16:41, winetbox wrote:
sorry for being out of topic, since my squid configuration is here, and
squid's experts are already here, i'd like to ask about my cache
config.
NP: "here" is an email mailing list. All posted mails get to "the
experts". It helps us a lot to manage the flow of requests if they are
all titled/threaded properly. Worst-case if the question that earlier
started this thread is resolved is that I have my mailer auto-delete
closed threads side-trails and you then lose all help on this hijack
request.
*. how efficient is my cache config?
cache_mem 1024 MB
maximum_object_size_in_memory 2048 KB
memory_replacement_policy heap LFUDA
cache_replacement_policy heap LRU
cache_dir ufs /mnt/cache/cache1 8000 16 256
cache_dir ufs /mnt/cache/cache2 8000 16 256
cache_dir ufs /mnt/cache/cache3 8000 16 256
cache_dir ufs /mnt/cache/cache4 8000 16 256
maximum_object_size 1024 MB
IMO, having global object limit smaller than the in-memory object size
limit is not a good idea. It prevents many useful but large memory
cached objects being pushed to disk temporarily when the memory cache
fills up.
If you have a version of Squid with rock cache type available you will
see much faster disk hits by using a rock cache for small objects.
*. is there anything i should adjust? because i mostly get
TCP_MEM_HIT/200,
and TCP_HIT are so extremely rare(which i believe cached on object on
disk).
This is kind of good. It means most of your HIT are extremely fast.
Knowing whether you could improve the HIT ratio based on that alone is
difficult to answer, because disk objects able to memory cache will get
loaded into memory cache on first TCP_HIT and further uses become
TCP_MEM_HIT.
IMHO, you get better results concentrating more on the HIT/MISS ratio
than the HIT/MEM_HIT ratio.
*. and even if i do make an adjustment on cache_replacement_policy
later, do
this mean i have to rebuild cache dirs?
No, just a restart of Squid is required. The replacement policy data is
generated when loading the cache_dir indexes. The locations of objects
on disk is not changed.
Amos