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.
