I tried to update squid from 2.5.9.1 to 2.6.3-1 using Debian's apt-get with "testing". I had to allow it to over-ride program compatibility to get it to install and it didn't work anyway. I then did a remove and purge, deleted the cache files and did a reinstall of the 2.5 version. It's working much faster now. I don't know if it's because of the dependencies that were upgraded (library files etc) or if there was a problem with the original installation. Anyway, it looks like problem solved. Thanks for your help. Cheers, Greg. -- Greg Wilson Systems & Network Administrator Summerland Credit Union, Lismore Ph 02 6620 7010 Fax 02 6622 6433 gwilson@xxxxxxxxxxxxxxxxx -- This email and any attachments or annexure hereto are confidential and subject to copyright and no use may be made of them without the consent of, or pursuant to a written agreement with, The Summerland Credit Union Limited. To the extent possible by law, The Summerland Credit Union disclaims all liability in relation to any loss or damage suffered by the use or reliance upon any information contained or in any attachment or annexure hereto by any person. -----Original Message----- From: Adrian Chadd [mailto:adrian@xxxxxxxxxxxxxxx] Sent: Sunday, 3 September 2006 11:43pm To: Greg Wilson Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: Squid 2/3 slower than direct access 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
