One thought is to turn on debug with parent routing enable then compare against debug with parent routing disabled. Do you see any extra or missing steps while cache is being looked up(read) or when the open write lock is created ?
On Thu, Mar 8, 2018 at 1:25 PM, Dunkin, Nick <[email protected]> wrote: > HI Sudheer, > > I’m not sure we’re quite on the same page but I’m grateful for your > input. This is all for ATS ver 7.0 and the documentation I’m talking about > is on this page > > https://docs.trafficserver.apache.org/en/7.0.x/admin- > guide/configuration/cache-basics.en.html > > In the section "*Reducing Origin Server Requests (Avoiding the Thundering > Herd)*” > > There is nothing in that section about these settings being associated > with the Collapsed Forwarding plugin. In fact there is no mention of the > Collapsed Forwarding plugin at all. Now I’m a little confused. > > Is anyone able to clarify this for me? I thought I understood but maybe I > don’t. > > Thanks, > > Nick > > > From: Sudheer Vinukonda <[email protected]> > Date: Thursday, March 8, 2018 at 1:36 PM > To: "[email protected]" <[email protected]>, > Nick Dunkin <[email protected]> > > Subject: Re: Parent.config and thundering herd. > > Hmm..I'm not sure that collapsed_forwarding plugin is deprecated. The > plugin in fact is based on the settings you mentioned below and allows to > block multiple parallel requests for the same object from leaking upstream. > > Using the settings alone, without the plugin would not actually achieve > any request coalescing for cache miss scenarios -- it'd simply result in > returning an error back to the client. Is that what you meant by "seeing > request coalescing"? Or is your use case, not involving cache misses, but, > stale cache (e.g VOD)? > > records.config — Apache Traffic Server 6.2.1 documentation > <https://docs.trafficserver.apache.org/en/6.2.x/admin-guide/files/records.config.en.html#proxy-config-http-cache-open-write-fail-action> > > records.config — Apache Traffic Server 6.2.1 documentation > > > <https://docs.trafficserver.apache.org/en/6.2.x/admin-guide/files/records.config.en.html#proxy-config-http-cache-open-write-fail-action> > > proxy.config.http.cache.open_write_fail_action > Scope: CONFIG > Type: INT > Default: 0 > Reloadable: Yes > Overridable: Yes > > This setting indicates the action taken on failing to obtain the cache > open write lock on either a cache miss or a cache hit stale. This typically > happens when there is more than one request to the same cache object > simultaneously. During such a scenario, all but one (which goes to the > origin) request is served either a stale copy or an error depending on this > setting. > > > - 0 = default, disable cache and goto origin server > - 1 = return a 502 error on a cache miss > - 2 = serve stale if object’s age is under proxy.config.http.cache. > max_stale_age > > <https://docs.trafficserver.apache.org/en/6.2.x/admin-guide/files/records.config.en.html#proxy-config-http-cache-max-stale-age>, > else go to origin server > - 3 = return a 502 error on a cache miss or serve stale on a cache > revalidate if object’s age is under proxy.config.http.cache. > max_stale_age > > <https://docs.trafficserver.apache.org/en/6.2.x/admin-guide/files/records.config.en.html#proxy-config-http-cache-max-stale-age>, > else go to origin server > - 4 = return a 502 error on either a cache miss or on a revalidation > > > > > > > Thanks, > > Sudheer > > > > On Thursday, March 8, 2018, 8:58:46 AM PST, Dunkin, Nick < > [email protected]> wrote: > > > HI Sudheer, > > Thanks for the reply. I couldn’t think of any reason either, but I wanted > to check with the community. > > Just for clarification. We’re not using the Collapsed-Forwarding plugin > explicitly, I understood that that plugin was deprecated in favor of the > three configuration areas I mentioned: > > - Read While Writer > - Open Read Retry Timeout > - Open Write Fail Action > > We certainly don’t have the Collapsed-Forwarding plugin in the > plugin.config and we are seeing request coalescing. > > Thanks, > > Nick > > From: Sudheer Vinukonda <[email protected]> > Reply-To: "[email protected]" <[email protected] > > > Date: Thursday, March 8, 2018 at 11:49 AM > To: "[email protected]" <[email protected]> > Subject: Re: Parent.config and thundering herd. > > I haven’t looked at parent proxy setup much, but at a high level, I can’t > think of any reason why an origin failover mechanism would impact request > coalescing using collapsed forwarding plugin. The open write fail action > works based on the cache key for the object and as long as that doesn’t > change, it shouldn’t matter which origin it is pulled from. As a matter of > fact, we have had origin failover setup using a custom plugin as well as > request coalescing enabled in our HLS delivery servers and didn’t see any > problems with it. > > Is it possible the access failures are resulting in preventing the object > from being downloaded or being cached somehow? If the object is never > cached, then you will see problems with request coalescing. > > Thanks, > > Sudheer > > On Mar 8, 2018, at 7:25 AM, Dunkin, Nick <[email protected]> wrote: > > Hi, > > We’ve been using the Thundering Herd protection provided by *Read While > Writer*, *Open Read Retry Timeout* and *Open Write Fail Action* and have > been getting some great results. However the behavior seems to change when > we start using *parent.config* in order to provide some simple origin > failover (I.e simple Primary/Secondary Origin kind of thing). My initial > tests are showing multiple access failures and not very much in the way of > request coalescing. > > I don’t all have the details with me now, but at a high level, should we > expect Read While Writer, Open Read Retry Timeout and Open Write Fail > Action to all work in the same way when > *proxy.config.http.parent_proxy_routing_enable > *is enabled and we have a simple Primary/Secondary Origin configured with > "parent_is_proxy=false”? Especially when most of the time the Primary > Origin will be up and available. Are there any gotchas we should be > aware of? > > All this testing is with ATS 7.0 currently. > > Thanks for your insight. > > Nick > > *Nick Dunkin* > > *Principal Engineer* > > *o:* 678.258.4071 <(678)%20258-4071> > > *e:* [email protected] <[email protected]> > > 4375 River Green Pkwy # 100, Duluth, GA > <https://maps.google.com/?q=4375+River+Green+Pkwy+%23+100,+Duluth,+GA+30096,+USA&entry=gmail&source=g> > 30096, USA > <https://maps.google.com/?q=4375+River+Green+Pkwy+%23+100,+Duluth,+GA+30096,+USA&entry=gmail&source=g> > > <319E5E02-1647-4542-836C-D389403ADE5F.png> >
