Re: [squid-users] A few questions about squid

On Wed, 15 Sep 2010 17:50:03 -0500, Jordon Bedwell <jordon_at_envygeeks.com>
wrote:
> I have a few questions about squid that the documentation doesn't seem
> to cover easily, and some people don't seem to cover it when I do a
> Google search, I hope I don't have to adjust the upstream source to get
> what I want easily.
>
> 1.) When I use Squid as an accelerator it didn't accelerate anything, as
> a matter of fact, I got less latency from PHP and Apache and even less
> latency when I used NGINX and PHP vs. Squid accelerators. Even under
> high loads.

Yes. A problem with the meaning of the word "accelerate". What people tend
to mean when they say that is "reverse-proxy" which has more in relation to
a router than a race horse.

What the speed differences are depends on which version of Squid you use,
how its configured and where it's running. The rule-of-thumbs for config
performance are all about avoiding speed-slow ACL. I've recently had a
conversation on IRC with several people seeing a 1-2 order or magnitude
slower Squid simply because the ran it in a VM clone (as versus an
identical VM).

So far we have records of Squid-2.7 pushing 990 req/sec. Squid-3.1 has not
been put to the same test, but sits roughly 5% behind it on others. I have
not yet seen any numbers for 3.2 beta which has multi-CPU support.

Which brings back into memory the catch-22 when comparing Squid with
Apache or Nginx. To get a genuine fair comparison you have to hobble those
others down to a single CPU and single worker process just like Squid. Last
I tried single-threaded Apache could handle under 20 req/sec and Nginx not
much more than 100 with variation on file size.

>
> 2.) Is there a way I can force it to reduce latency? The entire goal of
> the accelerator is to cache and reduce latency or to see if we could
> reduce latency more. Before we were using homegrown solutions to
> balance mixed with some patched Memcached severs to sync PHP Sessions.

In general roughly approximations cache_mem directive is Squid acts like
memcached and the disk cache acts like static files on the proxy machine.
The newer Squid you can get the better its HTTP/1.1 compliance and
reverse-proxy controls. I'll comment on your config below if anything
stands out.

>
> 3.) Is there a way to easily clear the cache? The entire cache? While
> Squid claims it's not possible, we can clear it manually but I was
> wondering if there might be a client that can do it?

It's not. The cache has an index which is split between memory and disk,
and constantly in use.
There are tricks around with creating an empty disk cache updating
squid.conf and restarting or reconfiguring Squid to swap it over to the new
location.

Be aware that for a period after starting with no cached items the full
traffic load hits the backend web server. When using more than one proxy
this can DoS the origin server. Look at your proxy HIT ratios to see the
amount of traffic reduction Squid is doing in bytes and req/sec.

>
> We get the same latency from squid we do from Apache 2 so maybe I have
> the configuration file wrong? I mean I might have it a bit confused
> since I've just started working with squid extensively to see if we can
> reduce latency more than we already have it reduced.
>
> Squid can't blame the origin servers since they are accessed through the
> local network with a local switch and each region has a matching
> accelerator that attaches itself to local origin servers. Example: UK
> has acc04, EU General has acc05-06 and US has acc01-03 each acc0* is a
> squid server with several origin servers under it, previously it was our
> homegrown balancer.

Sounds very normal.

>
> Squid CONF:
>
> acl our_sites dstdomain example.com
> http_access allow our_sites
> http_port 0.0.0.0:80 accel defaultsite=example.com
> cache_peer 0.0.0.1 parent 80 0 no-query originserver name=acc01
> cache_peer 0.0.0.2 sibling 80 0 no-query originserver name=acc01
> cache_peer 0.0.0.3 sibling 80 0 no-query originserver name=acc01
> cache_peer 0.0.0.4 sibling 80 0 no-query originserver name=acc01
> cache_peer 0.0.0.5 sibling 80 0 no-query originserver name=acc01

name= MUST be unique for each entry.

> cache_peer_access acc01 allow our_sites

Duplicate for each peer.

> refresh_pattern . 60 100% 4320

refresh_pattern is used to *extend* the caching times when no Expires: or
Cache-Control max-age are provided by the server. ie when squid has to
calculate and guess a good storage time it uses refresh_pattern to make
better guesses.

> hosts_file /etc/hosts
> coredump_dir /var/spool/squid3
> visible_hostname example.com
> dns_defnames off
> reply_header_access X-Cache deny all
> reply_header_access X-Cache-Lookup deny all
> reply_header_access Via deny all

These are sibling proxy communication headers used to optimize and trace
success/failure and routing loops.
If you have to, limit the removal to port 80 replies and change the
sibling-sibling peerage off port 80 to some other port, 3128 is the default
for anything-to-proxy HTTP communications.

> cache_effective_user 101
> cache_effective_group 103
> minimum_object_size 0 KB
> cache_mem 1000 MB
>
>
> Hopefully somebody can help me figure out what's going on before I flip
> the switch and go back to the way we used to have it, it's sad that I
> can't figure out how to get it to accelerate...

I suspect its those name= screwing things over.

Check that Squid netdb is enabled and working. This will let Squid pick
the fastest path for each request, which should clearly bring up the close
origin

One thing to look into is HTCP instead of ICP and cache digests on top.
This will let each proxy know much more details about what its siblings can
provide and reduce the time spent waiting for their replies before
fetching.

If you are really needing nauseatingly high request rates look into the
"ExtremeCarpFrontend" pages of the Squid wiki and be prepared for buying
4-core / 8-core servers. The TCP stacks will need tuning for higher speed
as well.

Amos
Received on Wed Sep 15 2010 - 23:54:55 MDT