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

On Wed, 15 Sep 2010 19:24:40 -0500, Jordon Bedwell <jordon_at_envygeeks.com>
wrote:
> On 09/15/2010 06:54 PM, Amos Jeffries wrote:
>>
>> 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.
>
> That's intriguing, but understood now.
>
>>
>> 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.
>
> The only time I would really worry about a DDOS is if said person is
> trying to saturate the network, which our firewall and IDS systems
> handle, as far as the cache creating a DOS situation on the origin
> servers, it would take a lot, since each region has dedicated origin
> servers under it. So acc01 would not share the same origin servers as
> acc02, we designed it like that because it's not a single site, it's
> actually several loaded clients who need power without control.

Not DDoS in the malicious sense.

Imagine that you had 4 proxies each handling say 500req/T on behalf of a
web app which had a maximum capacity of 1000req/T. At a 75% HIT ratio
(relatively low for reverse proxies) that means 2000req/T coming in from
the Internet and 500req/sec hitting the web app.
Now turn off caching in any one of the proxies and the web app suddenly
faces 875req/T. Mighty close to its capacity. Disable caching in two and
it's overloaded.

>
>> name= MUST be unique for each entry.
>>
>
> Even if they are meant to balance?

Yes. It's a peer ID. The balancing algorithms depend on being able to do
accounting for each peerage.

Siblings are unbalanced and by default chosen based on which responds with
an "i have it" ICP message (if ICP is on), if none then the parent is
chosen. You can alter that by adding specific algorithm flags to the
cache_peer line. See "PEER SELECTION METHODS" in here:
 http://www.squid-cache.org/Doc/config/cache_peer

From your description I suspect the siblings are in fact the remote
proxies which can be chosen as alternatives? In that type of topology you
want a selection method to pick the close web server and use the siblings
as fallback. (the following assumes that is the case.)

It's not clear how to reliably do that from the config available. Squid
will split them into a parent and a sibling groups before applying the
selection algorithms, with a preference for asking siblings first (a
by-product of being optimized for use in clusters).

I think having all as parents with the web server listed first. The
default first-up algorithm causes most requests go straight to the first
listed cache_peer, falling back to the other sources in sequence if they
get overloaded or die.

>
>> 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.
>>
>
> We don't send caching headers with our content on the server, even
> static content (unless it comes from the CDN) but a good case of what we
> want to do is force HIT/HIT not MISS/HIT, we don't want the clients

"HIT/HIT" ? "MISS/HIT"? you mean hit on the proxy, hit on the web server?

> caching any content we want the server to cache the final output and
> serve it, not hitting the origin servers and we only want to do it this
> way so we can reduce latency and TTL, not load.

You contradict yourself there. The ultimate in low-latency is for the
clients browser to fetch the object out of its own cache (some
nanoseconds). The next best is for it to be cached by their ISP (very low
milliseconds), then by their national proxies, then your CDN frontend
(whole ms may have passed at this stage, maybe even hundreds), then a cache
on your web server, then generated dynamically by your web server. Worst
case is for client browser to have to generate the page via scripts after
waiting for multiple non-cacheable bits to download first.
Load is only a nice by-product of reducing the latency, which is directly
linked to distance between client browser and the data.

With Cache-Control: the s-maxage can set caching time for proxies (yours
and the ISP ones) separate from browsers which use max-age (proxies will
use max-age if s-maxage is not present). emitting "cache-Control:
stale-while-revalidate" (Squid-2.7 only at present sadly) is also a
powerful tool in reducing client-visible delays on the requests which need
to re-check for updated content.

If the Squid support Surrogate/1.0 protocol extensions (Squid-3.1+); the
Surrogate-Control headers can provide a full alternative version of
Cache-Control which applies to a specific reverse-proxy.

As a corollary to this; if you follow several big providers policy of
globally emitting no-cache no-store headers to clients you provide a great
incentive for all the ISP admins to fight back and cache things (often far
longer than is good for your site) in order to reduce their own latency and
related bandwidth costs.

>
>> 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.
>>
>
> Way ahead of the curve, some of these servers have 32 cores and oddly
> enough 32GB of ram too. Others have only 16 cores but they're still
> considered beefy today. TCP is already optimized. Even my personal site
> has 16 cores, though if this works out, I might put my own site on this
> setup if my client will let me. Talk about power.

Cool. Then you can plan on dedicating whole cores to Squid :)

Amos
Received on Thu Sep 16 2010 - 03:24:15 MDT