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 consistent if the test is run again?
> I read the code, and found that in disk.c, function diskHandleWrite()
> and diskHandleRead() had call commSetSelect() to poll the file
> descriptors. Then if poll/select can not check the readiness of local
> files, the purpose to call commSetSelect() is just divide write or read
> operation into pieces , so that other request can be processed. This can
> increase the throughput.Am I right?
The use of commSetSelect() here is mostly as a convenient way of making
the callback triggered by the select loop rater than immediately. Due to
the limitations of UNIX/POSIX the filedescriptor will immediately indicate
readiness for I/O on the next select loop even if this I/O will block the
Squid process.
The use of select here is not related to performance, just the design of
Squid with callbacks. These functions are prepared to be asyncronous and
in Squid-2.2 this was actually where async-io operated.
Regards
Henrik
Received on Wed Feb 18 2004 - 04:13:44 MST
This archive was generated by hypermail pre-2.1.9 : Mon Mar 01 2004 - 12:00:04 MST