Re: [squid-users] New Accel Reverse Proxy Cache is not caching everything... how to force?

From: Chris Robertson <crobertson_at_gci.net>
Date: Tue, 04 Aug 2009 14:16:11 -0800

Adrian Chadd wrote:
> 2009/8/4 Hery Setiawan <yellowhat89_at_gmail.com>:
>
>
>> maybe in his mind (and my mind too actually), with big mem_cache the
>> file transfer will be transferred faster. But using that big for me
>> it's too much, since I only have 4GB of RAM and thousand workstation
>> connect with my squid.
>>
>
> The squid memory cache doesn't work the way people seem to think it
> does. Once objects leave the memory cache pool they're out for good.
>
> The rule of thumb is quite simple - keep cache_mem large enough to
> handle in-transit objects and a few hot objects; leave the rest to be
> available for general operating system disk buffer caching. Only
> deviate from this if you absolutely, positively require it.
>
> This will occur when your workload has a lot of small objects which
> you frequently hit. Hack up or download something to generate a
> request size vs {hit rate, byte hit rate, service time, cumulative
> traffic} to see exactly how many tiny/small objects you're getting a
> hit off of.
>

I recommend scalar.awk for this (http://scalar.risk.az/). Sample report
segment (which hopefully shows up in a fixed-width font...):

~~~ Objects Size Report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------|------ R E Q U E S T S -------|----------- T R A F F I C
-----------
  SIZE | total | misses | hits |hit%| total | misses |
hits |hit%
---------|--------|--------|--------|----|----------|----------|----------|----
  0-0.1KB 19.426K 18.505K 921 5% 249.893 KB 249.893 KB 0
B 0%
0.1-1.0KB 248.507K 172.422K 76.085K 31% 123.209 MB 93.616 MB 29.593
MB 24%
  1-5 KB 176.308K 156.113K 20.195K 11% 413.161 MB 364.980 MB 48.181
MB 12%
  5-10 KB 51.447K 46.284K 5.163K 10% 352.742 MB 316.625 MB 36.117
MB 10%
 10-50 KB 58.159K 49.855K 8.304K 14% 1.203 GB 1.032 GB 174.937
MB 14%
 50-100KB 8.801K 7.656K 1.145K 13% 594.920 MB 516.522 MB 78.398
MB 13%
100-500KB 6.747K 5.843K 904 13% 1.216 GB 1.066 GB 153.852
MB 12%
0.5-1.0MB 710 654 56 8% 478.407 MB 440.962 MB 37.446
MB 8%
  1-5 MB 558 498 60 11% 1.234 GB 1.105 GB 132.114
MB 10%
  5-10 MB 137 126 11 8% 0.938 GB 883.506 MB 77.182
MB 8%
 10-50 MB 96 73 23 24% 2.109 GB 1.417 GB 708.504
MB 33%
 50-100MB 13 9 4 31% 813.873 MB 561.792 MB 252.082
MB 31%
>100MB 14 12 2 14% 4.650 GB 3.766 GB 905.610
MB 19%
===============================================================================

> If you have a very small set of constantly "hot" traffic that will fit
> in memory, up cache_mem. But be aware of the performance repercussions
> if the "hot" traffic leaves cache_mem and stays on disk.. :)
>
> If you have a set of "hot" traffic that moves over time, upping
> cache_mem may not help.
>
> 2c,
>
>
>
> Adrian
>

Chris
Received on Tue Aug 04 2009 - 22:16:37 MDT

This archive was generated by hypermail 2.2.0 : Wed Aug 05 2009 - 12:00:02 MDT