Hi,
Le 20/02/2012 00:50, Vaibhav Arora a écrit :
Hey Cyril,
Thanks a lot for the reply. I had a few questions about it :
So when u say that the processes gracefully stop , so do expect the
backend queue at haproxy will show 0 queued requests, as there is a new
process now ?
I ask this because my backend queue goes to 0 as soon as connections
are dropped.
Exactly, here you only see the queue of the new process, you won't see
the values of the old process anymore.
->And continuing on the question , do you mean that the requests would
complete their functionality or requests that they are supposed to
before being killed ?
Yes.
You can verify it with a simple test case :
listen test :8080
mode http
server s1 localhost:80 maxconn 1
then imagine a request that takes 5 seconds to reply :
./haproxy -D -p /tmp/haproxy.pid -f ./haproxy.cfg
time curl http://localhost:8080/sleep.php &
time curl http://localhost:8080/sleep.php &
sleep 1
./haproxy -D -p /tmp/haproxy.pid -f ./haproxy.cfg -sf $(cat
/tmp/haproxy.pid)
1. The first request will be sent to the server, haproxy then waits for
the response.
2. The second request is queued
3. 1 second later, haproxy is reloaded :
- Now you can see 2 haproxy processes
- You'll see that the first request is successfully processed in 5 seconds.
- And the second one is also processed after leaving the queue, wich
results in a 10 seconds response time.
Because my ab sends command to nginx and then when haproxy reloads I
see some failed connections , which I think are because of queued
requests at haproxy being dropped at time of restart .
During the process switch, nobody is listening anymore, for a very short
time :
the old process must release the listening port to let the new one bind
a new socket on it. This is likely where the error occurs in your test.
--
Cyril Bonté
