On 28 нояб. 2012 г., at 18:10, Dmitry Sivachenko <trtrmi...@gmail.com> wrote:
> Hello! > > If haproxy can't send a request to the backend server, it will retry the same > backend 'retries' times waiting 1 second between retries, and if 'option > redispatch' is used, the last retry will go to another backend. > > There is (I think very common) usage scenario when > 1) all requests are independent of each other and all backends are equal, so > there is no need to try to route requests to the same backend (if it failed, > we > will try dead one again and again while another backend could serve the > request > right now) > > 2) there is response time policy for requests and 1 second wait time is just > too long (all requests are handled faster than 500ms and client software will > not wait any longer). > > I propose to introduce new parameters in config file: > 1) "redispatch always": when set, haproxy will always retry different backend > after connection to the first one fails. > 2) Allow to override 1 second wait time between redispatches in config file > (including the value of 0 == immediate). > > Right now I use the attached patch to overcome these restrictions. It is ugly > hack right now, but if you could include it into distribution in better form > with tuning via config file I think everyone would benefit from it. > > Thanks. > <redispatch.txt> On 26 мая 2014 г., at 18:21, Willy Tarreau <w...@1wt.eu> wrote: > I think it definitely makes some sense. Probably not in its exact form but > as something to work on. In fact, I think we should only apply the 1s retry > delay when remaining on the same server, and avoid as much a possible to > remain on the same server. For hashes or when there's a single server, we > have no choice, but when doing round robin for example, we can pick another > one. This is especially true for static servers or ad servers for example > where fastest response time is preferred over sticking to the same server. > Yes, that was exactly my point. In many situations it is better to ask another server immediately to get fastest response rather than trying to stick to the same server as much as possible. > > Thanks, > Willy
