turn on read_while_wirter: upsides: 1, the read_while_writer is working in most common case 2, it will help you control the origin side connections and traffic.
downsides: 1, it may not perform better in some situation, such as the retry in waiting 2, how is the case if you get a very slow connection to one of your origin IP? 3, how to handle if you get some client very slow, but some very fast? 4, when it is big file, is it safe? 5, is it ok to let thousands of clients waiting for one response? our team is working on the improvement on the cluster performance, and read_while_writer is a key point for us, we have some progress on the whole project, will update after the mess of deployments. the read_while_writer is a complex feature indeed, it may have some edge effects, as Igor said. turn it on may need more testing. the good news is we are not satisfied with it too, and we are working on improve it. thanks 在 2013-7-17，下午8:09，Igor Galić <i.ga...@brainsware.org> 写道： > > > ----- 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 >
