Hi,Alex: I tested rock storage again with real traffic. It's about 300req/s, 60-80Mbit/s. Squid verison is 3.3.11 and on freebsd 10-stable box. I create a 16GB size "rock" and limit the swap rate to 200, swap timeout to 300. When it's full filled, I reconfigured it. Iostat display the disk rps is about 200/s and throughput about 4MBytes/s. It's spent 61 minutes to rebuilding sucessfully, but the worker report it "register failed" 30 minutes ago. Rebuliding waste too long time, it's really a problem for the forward proxy, and I am interested in what's "many factors" I can realize or tuning it. Regards Simon > On 01/27/2014 05:26 AM, k simon wrote: > >> I noticed large rock have merged to squid 3.5, I have some question >> about your large rock patch. > > > Hello Simon, > >> 1,Does large rock support non-SMP instance? > > Yes. Rock store can be used in non-SMP mode (as defined at [1]). Rock > store uses blocking disk I/O in non-SMP mode. > > Please note that if your Squid is SMP-capable (e.g., atomics are > supported) and SMP is allowed (e.g., no -N), then Squid will start one > disker process per Rock cache_dir and, hence, will use SMP mode, even if > you have a single worker. > > >> I know the rock store must used with worker. > > Not sure what you mean. Squid cannot work without a worker. Diskers are > not required for Rock store. Without diskers, the performance should be > significantly worse though because blocking disk I/O will block the > entire worker process. For SMP terminology, please see [1]. > > >> 2,Does large rock solve rebuilding time too long issue? > > Current large rock has about the same cache index building time as small > rock. Whether that time is "too long" depends on many factors, but we > have not optimized anything in that area (yet). > > >> 3,Can large rock support range splice? > > I do not think Squid itself supports range splicing. If Squid supports > them, Rock store should support them as well. > > > HTH, > > Alex. > [1] http://wiki.squid-cache.org/Features/SmpScale >
