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
>
Received on Wed Feb 12 2014 - 16:23:35 MST
This archive was generated by hypermail 2.2.0 : Thu Feb 13 2014 - 12:00:05 MST