Squid Proxy Optimizations

Geso. The tweaks described here are based on a Squid 3.1.x implementation, but should be valid on newer versions (3.2 currently in Beta), Squid 2.7 and 2.6 too. Just check the respective documentation on the Squid website.

To give you a little background on the involved environment, the Squid proxies I am referring to here are used in a simple proxy-sandwich configuration. Downstream of the Squids are our “main proxies” of which provide load balancing, high availability and caching logic. Those direct all traffic to our friends the Squids, responsible for content filtering. Now behind the Squids is another set of upstream proxies which provides AV scanning of web traffic. (Now don’t you dare to ask why this is 3-layered like this).
On an average day (90% of the traffic is generated between around 07am and 15pm), we’re pushing around 200-250GB of “ordinary” HTTP(S) and FTP traffic, consisting of 7-8 million requests through this configuration.

The Squids run as VMs on ESXi5 by the way, with 2 vCPUs  and 2GB of RAM. Seeing the actual resource consumption, they could probably perform equally well with even less, especially considering how they are running on older pre-Nehalem Xeon 54xx hosts. There isn’t much to consider on the ESX side besides general performance recommendations applying to pretty much any workload. Obviously, vmxnet3 should be the vNIC of choice here too.

General OS /proc/ tweaks via /etc/sysctl.conf

# We don’t use IPv6, so no point in having it enabled really
net.ipv6.conf.all.disable_ipv6 = 1

# Increase local port range to support more concurrent connections
# cat /proc/sys/net/ipv4/ip_local_port_range – defaults to 32768 – 61000
net.ipv4.ip_local_port_range = 1025 65535

# Increase limit of system-wide file descriptors
# cat /proc/sys/fs/file-max
fs.file-max = 372925

# Allow a greater number of half-opened TCP connections, mitigate “possible SYN flooding” warnings in the messages log
# cat /proc/sys/net/ipv4/tcp_max_syn_backlog – defaults to 1024
net.ipv4.tcp_max_syn_backlog = 2048

# Make sure syn cookies are enabled too
net.ipv4.tcp_syncookies = 1

There is an abundance of other parameters you have at your disposal for further fine-tuning the OS TCP/IP stack, but these and the CentOS/Redhat 6 defaults should do the job pretty well in most cases.

Squid tweaks via squid.conf directives

I will not go into details on all each and every directives set in our config, but here are the ones we didn’t consider at first and which are supposed to benefit us in one way or another. Note that as we don’t use the Squids for caching purposes, there are no directives for content-cache optimization.
A complete reference over all available configuration directives can be found here:

ipcache_size 10240
Squid by default caches only 1024 DNS-records, not quite a lot. This causes even popular names like “www.google.com” to be purged from the cache frequently every few seconds, resulting in Squid to constantly hammer on your DNS-server and waiting for name resolutions constantly before serving requests. I would actually consider setting this to an even higher value.

negative_dns_ttl 5 minutes
Another setting to on the DNS-caching front. The default of 1 minute which might seem fine for most environments, but we’re also seeing lot’s of bogus requests from time to time. Besides our downstream proxies implement a negative TTL of 5 minutes too.

never_direct allow all
To prevent Squid from fetching Requests directly from source servers on the internet. As stated above, this is how our sandwich-config is supposed to work. Without this, even though we set proper cache_peer settings for the upstreams, Squid would more or less randomly retrieve a large number of requests directly.

forwarded_for delete
Disables appending the X-Forwarded-For in every request. Nobody needs to know our internal IPs.

via off
Disables appending the hostname of the proxy forwarding a request in the Via header. Again nobody really needs to know our internal server names (we don’t need it for toubleshooting either), though this can probably be negligible in most cases.

ignore_expect_100 on
Now this one was a bit of a bummer I stumbled upon when troubleshooting issues with a certain site after upgrading from Squid 2.5 to 3.1. I will explain the issue and this option in more detail in another post.

A good number of other things to consider on the topic of optimizing Squid can be found on these posts:

One thought on “Squid Proxy Optimizations

  1. Pingback: Squid Expect: 100-continue header issues « alpacapowered

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s