Hi,

Le 31/01/2018 à 03:00, flamese...@yahoo.co.jp a écrit :
Hello,

What exactly does option redispatch do?

It gives a chance to retry on another server if the connection can't be established on the one chosen by the loadbalancing algorithm. It's important to understand that it concerns only the connection establishment step. See below for details.

I have a haproxy in front of two web servers, if one web server get killed when haproxy is forwarding a request to that server,

will this request get re-forwarded to another server?

So I had an test.

In one server, I run

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/

while the ab is running, I killed 8001 ruby, then after some time I started it again.

here is the ab result:

Complete requests:      20000
Failed requests:        5
    (Connect: 0, Receive: 0, Length: 5, Exceptions: 0)


And haproxy.log

grep -c GET haproxy.log
20000

grep GET haproxy.log | grep -v 200
Jan 31 10:48:12 localhost haproxy[5948]: 127.0.0.1:45516 [31/Jan/2018:10:48:12.386] web1 app1/b 0/0/0/-1/5 -1 0 - - SD-- 10/10/8/3/0 0/0 "GET / HTTP/1.0" Jan 31 10:48:12 localhost haproxy[5948]: 127.0.0.1:45538 [31/Jan/2018:10:48:12.391] web1 app1/b 0/0/1/-1/1 -1 0 - - SD-- 10/10/8/4/0 0/0 "GET / HTTP/1.0" Jan 31 10:48:12 localhost haproxy[5948]: 127.0.0.1:45528 [31/Jan/2018:10:48:12.389] web1 app1/b 0/0/1/-1/3 -1 0 - - SD-- 9/9/8/3/0 0/0 "GET / HTTP/1.0" Jan 31 10:48:12 localhost haproxy[5948]: 127.0.0.1:45524 [31/Jan/2018:10:48:12.388] web1 app1/b 0/0/1/-1/4 -1 0 - - SD-- 8/8/7/2/0 0/0 "GET / HTTP/1.0" Jan 31 10:48:12 localhost haproxy[5948]: 127.0.0.1:45544 [31/Jan/2018:10:48:12.392] web1 app1/b 0/0/0/-1/1 -1 0 - - SD-- 7/7/6/0/0 0/0 "GET / HTTP/1.0"

Here, your logs indicate that the connection was already established and the request was also already sent to the server app1/b, but the connection was dropped in the middle (the server was stopped in the middle as you previously said). It's too late to redispatch a connection, so the behaviour is expected.


Here is the config:

global
     maxconn         5000
log             127.0.0.1 local2 debug
     daemon
defaults
     log global
     option httplog
     retries 3
     option redispatch
     timeout client  30s
     timeout connect 30s
     timeout server  30s
     timeout http-request 30s
     timeout http-keep-alive 30s
frontend web1
     bind *:8080
     mode http
     default_backend app1
backend app1
     balance     roundrobin
     mode http
     server a 127.0.0.1:8000 check
     server b 127.0.0.1:8001 check

I have tried v1.8.3 and v1.7.10

And I missing something?

Thanks


--
Cyril Bonté

Reply via email to