Re: [squid-users] question about filesystems and directories for cache.

Chris Robertson wrote:
> First of all, thanks for sharing the write-up. There are a number of
> high-load squid installations (Wikipedia, and Flikr are two of the
> largest I know of), but not much information on what tweaks to make in
> the interest of performance.
No problem. =] I encountered the same problem when trying to figure out
how to get more performance so I figured once I'd cracked it, the least
I could do was document it for the other people having the same issue
(and to give myself a reference for later).
>
> After perusing your posting, I'm wondering if you would run a
> "squidclient -p 80 mgr:info |grep method". I'm making the assumption
> that your squid is listening on port 80, so please change the argument
> to -p if needed. Your configuration options included "--enable-poll",
> but with a 2.6 kernel and 2.6 sources, I would be surprised if you are
> not actually using epoll. It might be a superfluous compile option.
[root@cache1 ~]# squidclient -p 8081 mgr:info |grep method
        IO loop method: poll
> Cache digests are not the only method of sharing between peers. ICP
> is an alternative and I have read that multicast works well for
> scaling beyond a handful of peers. I can't seem to find the posting
> now that I want to reference it. I'd trust your experience over my
> memory of someone else's posting, but I thought I would raise the
> possibility.
I was under the impression that when utilizing cache peering, it worked
better if the squids had a digest of what was on X squid server, before
asking for it. I could be wrong on that though - Adrian, care to
comment on this one? It's now redundant in my situation though, as
every peering mechanism is slower than going back to parent in our use case.
> I'm surprised you had to specify your hosts file in your squid.conf.
> /etc/hosts is the default.
There are a couple of bugs in squid that seem to cause issues if you
don't actually specify the hosts file within the squid conf... worst
case, it's an extra line of config to parse on startup.
>
> Lastly, I'd be wary of specifying dns_nameservers as a squid.conf
> option. Squid will use the servers specified in /etc/resolv.conf if
> this option is not specified. Now you have to maintain name servers
> in two locations.
Same goes here; DNS lookups were taking 200-1000ms without specifying
dns_nameservers in the config (the nameservers specified there are the
same ones within /etc/resolv.conf), now they're sub 1ms. There isn't
much chance of us re-ip-ing internally, so it's a pretty safe config
option for us. I definitely agree that it could cause problems for
people using public DNS resolution though.

-- 
Tony Dodd, Systems Administrator
Last.fm | http://www.last.fm
Karen House 1-11 Baches Street
London N1 6DL
check out my music taste at:
http://www.last.fm/user/hawkeviper