]> git.ipfire.org Git - thirdparty/haproxy.git/commit
[BUG] global.tune.maxaccept must be limited even in mono-process mode
authorWilly Tarreau <w@1wt.eu>
Sun, 1 Mar 2009 07:35:41 +0000 (08:35 +0100)
committerWilly Tarreau <w@1wt.eu>
Sun, 1 Mar 2009 07:35:41 +0000 (08:35 +0100)
commitf49d1df25cf794b8801d919fda20266d90981c78
tree3192e3c2166775dcb1c87f9df276bede32a51b81
parent368480cf4570a0d6448741c704aebd53ac467aa9
[BUG] global.tune.maxaccept must be limited even in mono-process mode

On overloaded systems, it sometimes happens that hundreds or thousands
of incoming connections are queued in the system's backlog, and all get
dequeued at once. The problem is that when haproxy processes them and
does not apply any limit, this can take some time and the internal date
does not progress, resulting in wrong timer measures for all sessions.

The most common effect of this is that all of these sessions report a
large request time (around several hundreds of ms) which is in fact
caused by the time spent accepting other connections. This might happen
on shared systems when the machine swaps.

For this reason, we finally apply a reasonable limit even in mono-process
mode. Accepting 100 connections at once is fast enough for extreme cases
and will not cause that much of a trouble when the system is saturated.
doc/configuration.txt
src/haproxy.c