Re: [squid-users] REported 3 months of slowness

On 11/09/11 05:21, The Doctor wrote:
> Get customer complains about slowness in squid.
>
> I did update yesterday but still slow performance is being reported.

Remember, users will always complain about slowness, what really matters
are the actual measurable numbers.

That said there are a few things in your config that can be improved.

>
> Config file.
>
> ##acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> ##acl manager proto cache_object
> acl domain src 204.209.81.0/24
> acl domain2 src 208.118.93.0/24
> acl domain3 src 208.118.94.0/24
> acl SSL_ports port 443 563 10000 20000

NP: port 563 exists here but is blocked by the Safe_ports. Consider
whether you need it and remove entirely or add to Safe_ports.

> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 22 # ssh
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 110 # pop3
> acl Safe_ports port 119 # nntp
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl Safe_ports port 10000 # multiling http
> acl Safe_ports port 20000 # multiling http

NP: the port range 1025-65535 already accepts 10000 and 20000. They can
be removed from here.

> acl CONNECT method CONNECT
> http_access allow manager localhost

Problem #1.

The block starting here (point A) ...
> http_access allow localnet
> http_access allow domain
> http_access allow domain2
> http_access allow domain3

... to here. Are your local forward proxy configuration. Which allows
unlimited access from your LAN *or* to a bunch of external networks.

This is because the block from here...

> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports

... to here are the security measure to prevent LAN clients and others
abusing your proxy as an open relay (read people allowed to suck out the
proxy resources you need for speed on acceptible traffic). These need to
be *above* the local forward proxy config.

http://wiki.squid-cache.org/SquidFaq/OrderIsImportant

> http_access deny all
> http_port 3128
> hierarchy_stoplist cgi-bin ?

You can safely drop hierarchy_stoplist.

> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> http_port 80 accel defaultsite=www.nk.ca
> cache_peer 204.209.81.1 parent 80 0 no-query originserver name=myAccel
> acl our_sites dstdomain www.nk.ca
> http_access allow our_sites
> cache_peer_access myAccel allow our_sites
> cache_peer_access myAccel deny all

see
http://wiki.squid-cache.org/ConfigExamples/Reverse/BasicAccelerator#Squid_Configuration_File

particularly notice the first line of text about how to configure
accelerators.

ie, move this to the *top* of your config file (or at least to above the
other http_access lines), and your external visitors will not have to
wait for any DNS lookups.

>
> coredump_dir /usr/local/squid3/var/cache
>
> Is there any reason for this slowness?

* Reverse-proxy/Accelerator config being disabled by your forward-proxy
config deny rules.

* Bypassing of security rules preventing abuse by clients.

* DNS lookups required by your access controls.

Fix the things I pointed at above. Then re-check what response times get
logged.

Extra thing to optimize after the above:

1) You may be able to entirely drop the domain, domain2, domain3 ACLs.
  If not, consider changing them to dstdomain to avoid DNS lookups and
possibly add multiple cache_peer reverse-proxy blocks of config.

2) persistent connections are your friends. Particularly server
persistent connections in reverse proxy setups. This can drop TCP wait
times a lot in the more recent Squid release (less so in the older ones,
but still better than no savings at all).

3) browsers put some fairly big limits on number of connections per
host. Domains often use the trick of spreading their content over
multiple FQDN to get around these. But the browser considers everything
through a proxy as one host. These limits can be bumped up to improve
overall page load times. More details at
http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.15
   Beta testers wanted for 3.2.0.11