Leif, just wanted to drop a line and let you know what I've been up to. Whenever you get a chance, please look over that Wiki page again and let me know if there's anything else you see that's just plain wrong. It's not complete by any means but I've been doing my best to keep it up-to-date as I make changes.
I've no idea whether it was the thread setting, or perhaps lack of a RAM cache that had me seeing lots of problems early on, but happily they're all gone now. I've removed the related config hacks. I'm still testing proxy.config.http.chunking.size in the hopes I can increase it, then I'll take another look at the page and try to integrate your comments better. Also, apologies for spamming your inbox, GMail has a nasty habit of keeping recipients that I didn't quite notice. Regards, Adam P.S. You were right about the shared session setting. It is a little faster to have a global connection pool, but not really worth it to override the default setting. On Tue, Nov 26, 2013 at 5:42 PM, Adam W. Dace <[email protected]>wrote: > Once again, thanks for looking at all this. I'll try to address these one > at a time, improving the Wiki where possible. > Got crud for sleep last night, so I'll send this response today and most > likely get to the Wiki updates tomorrow. > > Leif wrote: > > 1. Fuzzy logic: As described here, is not what it does, at all. Fuzzy > logic is there to allow (random chance) a client to go to origin > > *before* the object is stale in cache. The idea is that you would (for > some reasonably active objects) prefetch the object such that > > you always have it fresh in cache. > > Right. Sorry I got the definition just plain wrong on this one, what > stuck out to me was the idea that 50% of the time this would happen. A > great feature I'm sure, but one I'm not that interested in. > > TODO: Update Wiki, this has nothing to do with reverse proxy at all. > > > 2. Session sharing. I’m very worried about your “performance problems” > with session sharing set to “2”. In all respects, “2” should > > be better for performance on a reasonably busy system. On a system with > *very* few connections, setting it to “1” might be better, > > but in such a setup, I’d run with a single net-thread anyways (see > below, because I think you didn’t configure that correctly). > > Since I didn't even get the thread configuration right, I'm somewhat > unsure of this one. I'll check into it. > > TODO: Retest > > > 3. The “CPU cores” configuration is not what that setting means, at all. > It has nothing to do with the CPUs. The default is 1.5 > > worker threads (net-threads) per CPU, and setting just > proxy.config.exec_thread.limit has no effect whatsoever, without also > > setting proxy.config.exec_thread.autoconfig to 0. > > > I’d be curious to hear if you actually did see a different with changing > exect_thread_limit like the document said, because it should > > have no impact. If you did indeed set the actual number of net-threads > to “1”, and noticed a difference in some behavior > > (performance, stability etc.), please file a bug on it. > > I'll update the description on this. I just think in terms of CPU cores > as I'm guessing that's how the threads get mapped by the OS. > > TODO: Update Wiki setting and description, this is a threads setting...not > a CPU setting. > > > 4. HTTP connections: The config recommendations talks about the two > pipelining configurations. These actually have no effect on > > the server at all. In fact, they should be removed. See > https://issues.apache.org/jira/browse/TS-2077 for some details. > > We should probably move discussion about this one to Jira. When I first > looked at it, it did seem as though these settings > are on the way out...but I also remember finding some source that looked > active. > > > 5. Background fill. This recommendation is wrong, it should be set to > 0.0 for it to always kick in. It allows the server to continue > > fetching / caching a large object even if the client disconnects. This > setting (with a value of 0.0) is a prerequisite for getting > > read-while-writer to kick in. > > Thanks, I guessed wrong on this one. > > TODO: Update Wiki setting. > > > 6. HTTP cache options. PLEASE, do no set this to 0 unless you own both > the cache and the origin. In “0”, it allows everything to > > be cached, unless it’s explicitly denied. This is a direct violation of > RFC2616, and will in forward proxy, will certainty break things > > where more than one user is behind the cache. Set it to “1”, which can > still break for poorly behaved web sites (e.g. amazon.com > > used to break with it set to “1”, which is why we set it to “2”. > > > The only times you should set this to “0” is a) If you are testing > something or b) you own all the origin content, such that you know > > everything can be cached for arbitrary amounts of time. > > Whoops. My bad on this one, I had no idea that this explicitly violates > an RFC. At the time, I was simply looking for a way to cache websites that > aren't configured to be cached with additional HTTP headers. > > TODO: Update Wiki setting. > > > 7. The description for proxy.config.http.cache.max_stale_age is not > accurate. It has nothing to do with flushing the cache, in fact, > > we never flush the cache. What this setting says is, if an object is > stale in cache, and you can *not* get a connection to the origin > > server, you are allowed to use the staled object in cache for this long. > I would not change this from the defaults personally. > > TODO: Update Wiki description. > > > 8 . Turning off proxy.config.http.cache.range.lookup (range requests) > does not tell ATS that it can’t use Range: requests. It > > completely disabled Range: support for all clients. This is almost never > what you want :). Leave it on. > > At the time, for some reason I don't understand both Apple's AppStore and > iTunes Store pages > were loading an order of magnitude slower with this enabled. I'll check > it again, though. > > TODO: Retest > > > 9. The proxy.config.http.cache.heuristic_max_lifetime is mostly correct, > except for two things: 1) It does not get “flushed”, it merely > > says how long (max) it can cache objects under the heuristics rules. 2) > It’s not a fixed setting, what it does is together with the > > “min” setting is to get a range for the Expire time, the effective TTL > will be a value between min-max, based on how old the object > > is (based on Last-Modified). Since you set lm_factor=1.0, you did > effectively set min == max == 3 months. This seems very > > aggressive, and counteracts how the heuristics system is supposed to > work. The idea is that objects which are changing > > frequently you should cache much shorter than those which change > infrequently. > > True, these settings may not be for everyone. My goal, though, is to give > myself the most aggressive caching at the highest throughput possible. > While I like the idea that frequently changing objects be cached over less > time than those that change infrequently, it seems simpler that objects > just expire(or are overwritten?) based on Last-Modified. > > > 10. Your setting for proxy.config.cache.min_average_object_size seems > wrong. If your average object size is 32KB, you should > > set this to, hem, 32KB :). However, to give some headroom, my personal > recommendation is to 2x the number of directory entries, > > so set the configuration to 16KB. > > > The math is mostly correct, except the calculation for "Disk Cache > Object Capacity” is in fact the max number of directory entries > > the cache can hold. Each object on disk consumes *at least* one > directory entry, but can consume more (amc, what’s our current > > guideline here?). > > TODO: Update Wiki setting and description. > > > 11. The text around proxy.config.cache.mutex_retry_delay is confusing. > Setting this higher would increase latency, not reduce it, at > > the expense of possibly consuming more CPU. If you experience something > different, I think it’d be worthwhile to file a Jira. > > I haven't looked at this one lately. I will. > > TODO: Retest > > > 12. The descriptions of proxy.config.hostdb.timeout is wrong. This > setting is used in conduction with proxy.config.hostdb.ttl_mode. > > By default (0), the TTL from the DNS entry is obeyed, and then > hostdb.timeout has no meaning whatsoever. If set to 2 or 3, the > > timeout setting can be used to override what the server said. In almost > all case, you should set proxy.config.hostdb.ttl_mode to 0, > > and then there’s no reason to muck with the hostdb.timeout. > > > Note that hostdb.timeout does *not* say anything about flushing or > evicting entries from the DNS cache. It can only be used to > > override what the TTL on the RR was. > > TODO: Update Wiki setting and description. Defaults are correct. > > Thanks, > > > > On Tue, Nov 26, 2013 at 9:37 AM, Alan M. Carroll < > [email protected]> wrote: > >> Monday, November 25, 2013, 5:06:57 AM, you wrote: >> >> >> > Alan, it’d be great to get a better understanding on how many directory >> entries someone *really* needs to allocate. Since you know everything in >> the cache now, can you maybe write something up, or explain it to use mere >> mortals? >> >> Worst case (which is common) is 1 root entry plus 1 entry for every >> target fragment size chunk in each alternate (rounded up). >> >> I will note that there is a very preliminary write up in the ATS docs on >> how the cache works, in the architecture section. That is where I put >> things I have learned about the cache. >> >> > > > -- > ____________________________________________________________ > Adam W. Dace <[email protected]> > > Phone: (815) 355-5848 > Instant Messenger: AIM & Yahoo! IM - colonelforbin74 | ICQ - #39374451 > Microsoft Messenger - [email protected] <[email protected]> > > Google Profile: https://plus.google.com/u/0/109309036874332290399/about > -- ____________________________________________________________ Adam W. Dace <[email protected]> Phone: (815) 355-5848 Instant Messenger: AIM & Yahoo! IM - colonelforbin74 | ICQ - #39374451 Microsoft Messenger - [email protected] <[email protected]> Google Profile: https://plus.google.com/u/0/109309036874332290399/about
