Hello,
Thanks for the lucid explain, understood it now. Anyway I find that haproxy slow down the requests to alive server when there is a server down. Still take the test I made before, ruby -run -ehttpd . -p8001 and ruby -run -ehttpd . -p8000 and i start haproxy then do a ab ab -n 20000 -c 10 http://127.0.0.1:8080/ So both ruby servers start to log requests, very fast(say 100 request per second), meaning that haproxy forwards request very fast. Then I killed ruby 8001, the strange thing is that ruby 8000's log becomes very slow(say 10 requests per seconds) for a while. I understand that there will be some check against 8001, but why it will slow down the request to 8000? Why is that? Thanks ----- Original Message ----- >From: Lukas Tribus <lu...@ltri.eu> >To: flamese...@yahoo.co.jp >Cc: "haproxy@formilux.org" <haproxy@formilux.org>; "cyril.bo...@free.fr" ><cyril.bo...@free.fr>; "lu...@ltri.eu" <lu...@ltri.eu> >Date: 2018/2/1, Thu 17:45 >Subject: Re: redispatch still cause error response > >Hello, > > >On 1 February 2018 at 04:43, <flamese...@yahoo.co.jp> wrote: >> Thanks for reply, any plan to support this requirement? >> >> If a backend server get killed when processing request, that haproxy >> re-forwarad the request to another backend server? > >No, this is problematic for a number of reasons. First of all this can >only be done for idempotent methods, and yet it could still trigger >applications bugs. Then we would need to keep a copy of the request in >memory, until we know for sure the response is "valid". Then we would >need to validate the response, where every users wants something >different. Some may ask to resend the request to another server on a >404 response ... > >So no, I don't see how this can easily be achieved. > > >cheers, >Lukas > > > >
