Sorry, Amos, not to waste too much time here for an off-topic issue, but
interesting matter anyways:
I ACK your remarks regarding disk controller activity. But, AFAIK, squid
does NOT directly access the disk controller for raw disk I/O, the FS is
always in-between instead. And, that means, that a (lot of) buffering can
occure, before real disk-I/O is done. Which might even lead to spurious high
reponse times, when all of a sudden the OS decides, to really flush large
disk-buffers to disk. In a good file system (or disk controller,
downstream), request-reordering should happen, to allow elevator-style head
movements. Or merging file accesses, referencing the same disk blocks.
And all this should happen after squids activities are completed, but before
the real disk driver/controller starts its work.
BTW, I did some private measurements, not regarding response times because
of various types of cache_dirs, but regarding reponse times/disk thruput
because of various FS and options thereof. And found, that a "crippled" ext4
works best for me. Default journaling etc. in ext4 has a definite hit on
disk-I/O. Giving up some safety features has a drastic positive influence.
Should be valid, for all types of cache_dirs, though.
-- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-monitoring-access-report-shows-upto-5-to-7-cache-usage-tp4661301p4661442.html Sent from the Squid - Users mailing list archive at Nabble.com.Received on Mon Aug 05 2013 - 11:14:53 MDT
This archive was generated by hypermail 2.2.0 : Tue Aug 06 2013 - 12:00:15 MDT