On Sun, Sep 03, 2006, Greg Wilson wrote: > Adrian, > > I'm using the defaults for everything in Squid (except cache memory) at this stage so that's > > cache_dir ufs /var/spool/squid 100 16 256 > > I've only just found out that Raid 5 probably isn't the best thing to run Squid on as access isn't particularly fast. RAID5 will be a bit slower but it won't be noticeable under your little load. > I've checked the DNS settings and all looks good. I've done some DNS testing from the Squid server and responses are very quick. > One of the Squid tests I've run on the box is an ISP speed test that downloads a single large file and reports download speed. This is one of the tests that runs 2/3 slower than direct. In this case there is only one DNS lookup and then only if the file isn't on the webserver that does the testing. This indicates that DNS is not the problem. Agreed. > I was suspecting I had a duplex mismatch between the Squid box and the firewall. It's directly connected to a Netscreen and was auto-setting to full-duplex although mii-tool was reporting it's partner as half-duplex. It's a problem for me to physically get to the server as it's at our ISP's POP. I didn't want to lose contact with it so I've set both to half-duplex 100 Mb. I'd rather have full duplex but as the Internet link is only 1.5 Mb that shouldn't be a bottleneck. Cool. > As the problem is severe I'm expecting something major rather than fine-tuning but I can't see anything int he logs that indicates a problem. Server load seems low but Squid is still slow. Please check: * Make sure that squid is compiled with the null fs * change cache_dir to be cache_dir null / That way you're taking the disk storage subsystem out as a possibility * restart squid; * Try the transfer test again * if its still being slow then its not due to the disk configuration! :) It could be other things, like: * Socket send/receive buffers aren't big enough (check what it says during configure; they're normally set at 64k which is enough.) * Could be other transmission errors (try netstat -in, netstat -p -s tcp; see whether there's high numbers of retransmissions and/or errors.) Let me know if you're still stuck. Adrian
