configuration - Hot reconfiguration of HAProxy still lead to failed request, any suggestions? -


i found there still failed request when traffic high using command this

haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) 

to hot reload updated config file.

here below presure testing result using webbench :

/usr/local/bin/webbench -c 10 -t 30 targethproxyip:1080 webbench – simple web benchmark 1.5 copyright (c) radim kolar 1997-2004, gpl open source software.  benchmarking: targethproxyip:1080 10 clients, running 30 sec.  speed=70586 pages/min, 13372974 bytes/sec. **requests: 35289 susceed, 4 failed.** 

i run command

haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) 

several times during pressure testing.

in haproxy documentation, mentioned

they receive sigttou 611 signal ask them temporarily stop listening ports new 612 process can grab them

so there time period old process not listening on port(say 80) , new process haven’t start listen port (say 80), , during specific time period, cause new connections failed, make sense?

so there approach makes configuration reload of haproxy not impact both existing connections , new connections?

on recent kernels so_reuseport implemented (3.9+), dead period not exist anymore. while patch has been available older kernels 10 years, it's obvious many users cannot patch kernels. if system more recent, new process succeed attempt bind() before asking previous 1 release port, there's period both processes bound port instead of no process.

there still tiny possibility connection arrived in leaving process' queue @ moment closes it. there no reliable way stop happening though.


Comments

Popular posts from this blog

python - Subclassed QStyledItemDelegate ignores Stylesheet -

java - HttpClient 3.1 Connection pooling vs HttpClient 4.3.2 -

SQL: Divide the sum of values in one table with the count of rows in another -