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

From: Jordon Bedwell <jordon_at_envygeeks.com>
Date: Wed, 15 Sep 2010 19:24:40 -0500

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.

> name= MUST be unique for each entry.
>

Even if they are meant to balance?

> 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
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.

> 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.
Received on Thu Sep 16 2010 - 00:25:00 MDT

This archive was generated by hypermail 2.2.0 : Thu Sep 16 2010 - 12:00:03 MDT