[squid-users] some questions concerning cache_mem, L1, L2,...

Hi,
I searched for some time the archives, but still I have some questions
concerning the choice of
cache_mem and L1, L2. maybe someone can help me understand:

a) is this formula still correct: L1 = cache_size *2*1024 /
(L2*L2*average_object_size)
   with a saftey margin of factor 2?
   in the L2 directories: will there always be a number of L2 files (as a
maximum)?

b) is it correct that L2 should be 254 instead of 256 on linux/ext2 systems?
what about reiser fs?

c) is ist correct that for one object squid holds 72 Bytes (intel,sparc)
data in memory for metadata?
   somewhere i read, squid uses only the hashlist of the md5 checksums in
order to find the objects,
   somewhere else i read, squid uses the metadata + md5 checksum in memory.
what is right?
   given 72 bytes - there is about 10 MB metadata memory used for 1 GB file
cache. right?

d) in squid.conf, there is the default entry cache_dir ... 100 16 256
   but by the formula in a), given these values (100 mb and L2=256, 13 kb
av_ob_si), L1 should be
   about only 1.
   why then these values are chosen as defaults?

e) what about the value of cache_mem (default: 8mb)? since it is only used
for hot, intransit, and
   negative-cached objects, what is the best value?
   given cache_size = 1gb and ram size = 1gb, what should be the value of
cache_mem?
   somewhere i read, that if cache_mem is too high, there might be swapping
with negative effects for
   squid - why would this be so?
   if i reserve 512 mb of 1gb ram for squid - then 10 mb would be for
metadata, maybe another 20 mb for
   other squid needs. should i then use (512-10-20) mb for cache_mem in
order to increase performance?

f) at last: the low and high watermarks - are they only used for file cache
or also for the memory used
   for cache_mem?
   can i chooce any of the 4 cache replacement policies for file cache also
for cache_mem?

you see, there are a lot of things i still do not fully understand.

thx in advance,
Received on Sun Feb 02 2003 - 02:29:39 MST