Hi, I am seeing the same thing (ats 3.2.4). I use background_fill_completed_threshhold = 0 and read_while_write works = 1 works as expected. In my test the origin waits for a few seconds before it sends content. That's why I need to use 0 (I think).
However, in my opinion this is one part of the solution because the secondary clients continue to block until the primary request is completed. I'd like to see proxy.config.connection_collapsing.revalidate_window_period resurrected, I guess it did not work and it was removed from the code. The rfc5861 plugin is supposed to address that in the standard way, but it is still not there (at least for stale-while-revalidate) because every request is still hitting the origin. -Igor On Wed, Jul 17, 2013 at 10:47 AM, Miles Libbey <mlib...@apache.org> wrote: > Hi Shaun- > I agree that the documentation suggests that they are not related. > However, in practice, they do appear to be related. I grabbed a few > hundred MB object, turned on read_while_write, and fetched it twice in > quick succession. The second fetch also hit the origin. Then, after > dropping background_fill_completed_threshold to a small percentage > (clearing the cache), and repeating, only the first request hit the origin. > (tests run on 3.3.4, mac osx, with httpd as origin, and ~400MB object). > > miles > > > ----- Original Message ----- > From: Shaun McGinnity <shaun.mcginn...@owmobility.com> > To: "dev@trafficserver.apache.org" <dev@trafficserver.apache.org>; Miles > Libbey <mlib...@apache.org> > Cc: > Sent: Wednesday, July 17, 2013 6:31 AM > Subject: RE: background fill threshold default? > > Hi Miles, > > Background fill is not related to serving from cache. The docs describe > proxy.config.http.background_fill_completed_threshold as "The proportion of > total document size already transferred when a client aborts at which the > proxy continues fetching the document from the origin server to get it into > the cache (a background fill)." The key here is "when a client aborts". If > the client doesn't abort early then background fill will not be active. > > Shaun > > > -----Original Message----- > From: Igor Galić [mailto:i.ga...@brainsware.org] > Sent: Wednesday, July 17, 2013 1:09 PM > To: dev@trafficserver.apache.org; Miles Libbey > Subject: Re: background fill threshold default? > > > > ----- Original Message ----- > > Hi folks- > > I have frequently heard the complaint that ATS does not do read while > > write -- that, as a reverse proxy, while an object is not yet in > > cache, it forwards all connections to the origin until a version > > exists in the cache. The complaint is of a thundering herd -- a new > > popular object becomes available, and the origin gets immediately > > flooded with requests. Part of this is likely because there are 2 > > relevant configs (if not more) that need to be set in tandem for it > > to work: proxy.config.cache.enable_read_while_writer (which the > > documentation says is set to off by default), and > > proxy.config.http.background_fill_completed_threshold, which is set > > to 50% (eg, 50% of the object needs to be downloaded before it can be > > used to serve other requests. > > > > Should we consider both turning on read while write on by default, and > > reducing the background_fill_completed_threshold down to a smaller > > number (5%? 1%)? What are the upsides of the current defaults and > > downsides of changing them? > > The main downside is that the feature isn't widely enough tested in the > field by our developers, or that we haven't had enough (positive or > otherwise) feedback from users. > > re smaller numbers: Depending on > a) object size > b) bandwidth of users > c) size of the herd > > 5% or 1% may be way to small. But this is my gut speaking, I too don't > have the experience in that regard. > > > miles > > > > -- > Igor Galić > > Tel: +43 (0) 664 886 22 883 > Mail: i.ga...@brainsware.org > URL: http://brainsware.org/ > GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE >
