On Thu, 19 Feb 2004, Xia Hongtao wrote:
> Maybe in my test environment, the response time not effected by fs I/O so much.
> I used polygraph 2.6.7, 1000 robots * 0.2 req/sec * 13KB , cacheable=100%,
> recurrence=100%.
> So the content will always in memory.
What does access.log say about the hit
On Thu, 19 Feb 2004, Xia Hongtao wrote:
> So in current 2.5.STABLE4 version, just the first 4KB fs I/O was done by
> asyncronous threads? If the content is larger then 4KB, the main squid thread
> will do the fs I/O remained ?
The functions in disk.c is not at all used for aufs disk I/O. These
On Wed, 18 Feb 2004, Xia Hongtao wrote:
> Dear Henrik Nordstrom:
>
> I had get the final result of comparing three version.In my new test
> environment, the response time:
> orig 14.227ms no_pipe 13.550ms pipe_patch 13.905ms
What test did you run?
And have you verified the results are cons
Dear Henrik Nordstrom:
I had get the final result of comparing three version.In my new test
environment, the response time:
orig 14.227ms no_pipe 13.550ms pipe_patch 13.905ms
I have one questions below.
=== 2004-02-17 12:26:00 you wroted :===
>On Tue, 17 Feb 200
Thank you for your reply! I still had some questions below. :-)
>On Mon, 16 Feb 2004, [GB2312] 夏洪涛 wrote:
>
>> I had take a experiment today, and fund that the pipe mechanism is not
>> necessary for aufs.
>
>It is a tradeoff for aufs to not degrade heavily when there is only little
>wor
On Tue, 17 Feb 2004, [GB2312] ÏĺéÌÎ wrote:
> Oh, I get it. Do you mean: When poll/select syscall wait on the ready
> FDs, the pipe can wake up poll/select syscall, and enter another loop.
> At each loop, storeDirCallback() will be called first. It will poll the
> disk I/O status.
Yes.
> 1. Dose
