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.
