On Wed, 15 Sep 2010 19:24:40 -0500, Jordon Bedwell <jordon@xxxxxxxxxxxxx> 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
