After running with Squid for a few days, a couple of problems came to light when the network was quite heavily loaded. Firstly Squid was running at about 40% of available memory, secondly when two or more people were downloading large files or streaming video then the video streams would stutter and rebuffer. Although this wasn’t a major problem most of the time (there are only five potential concurrent users of the network!) it was time to start poking around in squid.conf again.

There is a fair amount of tuning information around on the web, but most of it is aimed at large scale operations and scaling up the proxy, rather than squeezing as much as possible out of a little box. Also the most obvious move for most users is to add more RAM, an option not open to me in this case (I’m not ready to wield the soldering iron just yet). Nevertheless there seemed to be a few things worth trying.

Firstly I moved the squid cache to my faster hard disk, and upped the size to 1Gb. I was tempted to go higher, but exercised some caution as allocating more space here also increases the RAM usage slightly. I also DECREASED the number of level 1 sub-directories to 8. Therefore the squid.conf entry becomes:

cache_dir ufs /mnt/sdb1/squidcache 1000 8 256

Obviously the squidcache directory needs to be created beforehand and the squid user given RW access to it. After editing squid.conf it was necessary to stop Squid

/etc/init.d/squid stop

and then call it from root with the -z option to initialise the new cache files

squid -z

which took only a couple of seconds, and then restart Squid

/etc/init.d/squid start

This seems to have been very successful, with the memory usage sticking at a max of 18% under heavy load, which is fine.

Now on to the streaming issue. There are mixed views as to whether large files should be cached or not. Clearly there will be advantages if they are going to be accessed by more than one user, or more than once, but on balance I decided it was just too much work for the poor little slug, and so in Squid terminology ‘created an access rule to deny caching to typical large or streamed filetypes’. I couldn’t find any info on whether or not filenames are case sensitive so rather than laboriously try it out I just played safe, with the following in squid.conf:

acl streamorlarge urlpath_regex -i \.swf$ \.SWF$ \.asf$ \.asx$ \.wmv$ \.mpg$ \.rm$ \.mov$ \.flv$ \.mpeg$ \.FLV$ \.rar$ \.zip$ \.ZIP$ \.iso$

no_cache deny streamorlarge

Restarted squid, and the streaming problem was solved. Now we have memory usage peaking at 18%, streaming working fine, and noticeably snappier browsing, especially on busy sites such as ebay, the BBC and the Apple store.

So there we have it, I’m sure there is more performance to be found with more effort, and YMMV, but worth giving it a go to get the best out of this amazing little box.

Post Script:

In a spare moment I installed Squid on my Sun Ultra 10, which dual-boots Solaris and Debian. I gave it a 10Gb cache file, and in a fairly unscientific study swapped proxies between various PCs and Macs and compared Internet response times across various websites with busy pages - ebay, Amazon, Apple Discussions, the Register, digg, etc. I had intended to chart the average response times for Slug, Sun and No proxies, but to be honest they were all so quick it was almost impossible to measure. There was a small but noticeable improvement with any proxy over none, but no noticeable difference between Sun and Slug based proxies even with five simultaneous users. Thats with 10Mb  broadband, 100Mb wired and 108Mb Wireless network. OK you would expect that with more users, and/or more complex rules, the Sun would come into its own, but for a home or small business network the Slug seems to be outstanding.