> He is asking about the ' cache_mem ' parameter in
> squid.conf, and according to your rule described he
> must set this to a value of about 360MB because he is
> going to use 2x18 GB drives which will be a huge value
> for this parameter, Squid is in the habit of using two
> or three times more than the cache_mem defined.
>
> Your rule is Ok as far as adding physical RAM in
> machine is concern but not in the case of cache_mem
> parameter.
It is impossible to make a general rule about cache sizing. In general the answer to "how big should my cache be" is: it depends on your traffic and your budget.
There are limits, though. At some point, cache management overhead exceeds the speedup that the cache provides. The more practical consideration is that the speedup that the cache provides drops off beyond a certain point, so money spent on memory or disk is wasted. If squid is swapping, then you should reduce cache_mem or add real memory. Making cache_mem too small can affect saving objects to disk.
The in-memory cache provided by cache_mem has faster access time that the on-disk cache, saving somewhere around 10-20ms per in-memory hit.
The optimum sizes of your disk (cache_dir) and memory (cache_mem) caches depends entirely on your budget and traffic patterns. Optimally sizing them is a trial and error process.
The squid cache that I run is a 233MHz Pentium II with 384MB memory and an 18GB cache disk. I have cache_mem set to 192MB and cache_dir set to 4GB. The original configuration had 64MB cache_mem and 16GB cache_dir, but a gradual tuning process has resulted in the current configuration.
The network here has ~1600 users. The traffic pattern seems to be a small set of "hot" items, that tails off very quickly. Reducing cache_dir from 16GB to 4GB has not affected the hit rate in any statistically significant way. Increasing cache_mem has improved response times, but the increase from 128MB to 196MB gave such a small increase that I don't believe that going any further would do any good. My squid process hovers around the 300MB size. During the day I get an average request rate of around 100 requests per minute (a very lightly loaded system).
The metric that I tune against is taken from these cachemgr statistics:
Median Service Times (seconds) 5 min 60 min:
HTTP Requests (All): 0.61549 0.89858 (1)
Cache Misses: 1.62803 1.91442 (2)
Cache Hits: 0.03622 0.03066
I take speedup to be
(cache_misses - all_requests)/all_requests
where cache_misses is figure (2) above, and all_requests is figure (1) above. This metric is not generally recognized, and almost certainly doesn't measure the real impact of Squid, but as a target to tune against I personally believe it is the best available measure.
The effect I saw by increasing cache_mem was that the overall hit rate stayed roughly the same, but the median service time for cache hits dropped, giving an improvement in "speedup".
I don't believe it is possible to specify a generally applicable rule for cache sizing. The best you can do is to find a rule of thumb that gives you a starting point, and then to tune empirically. The best metrics to tune against depend on the system: some people may use a cache to improve performance, in which case a figure like I use is appropriate. Others use the cache to reduce volume charges on their internet connection, in which case the byte hit rate is the most appropriate. Make a tuning change at most once a day (better once a week), and measure and graph the results, then pick the optimal configuration.
Robin
---------------------------------------------------
Get free personalized email at http://www.iname.com
Received on Wed May 23 2001 - 20:46:13 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:00:16 MST