]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MAJOR: channel: add a new flag CF_WAKE_WRITE to notify the task of writes
authorWilly Tarreau <w@1wt.eu>
Tue, 31 Dec 2013 16:26:25 +0000 (17:26 +0100)
committerWilly Tarreau <w@1wt.eu>
Tue, 31 Dec 2013 17:37:36 +0000 (18:37 +0100)
commitd7ad9f5b0dbc04574781d5a98840180e0c9c4f68
treed2b9d1717593c53af632f2d5e6903032633f435d
parent51437d2c595a0be6aa322111971c1742c83d2a3f
MAJOR: channel: add a new flag CF_WAKE_WRITE to notify the task of writes

Since commit 6b66f3e ([MAJOR] implement autonomous inter-socket forwarding)
introduced in 1.3.16-rc1, we've been relying on a stupid mechanism to wake
up the task after a write, which was an exact copy-paste of the reader side.

The principle was that if we empty a buffer and there's no forwarding
scheduled or if the *producer* is not in a connected state, then we wake
the task up.

That does not make any sense. It happens to wake up too late sometimes (eg,
when the request analyser waits for some room in the buffer to start to
work), and leads to unneeded wakeups in client-side keep-alive, because
the task is woken up when the response is sent, while the analysers are
simply waiting for a new request.

In order to fix this, we introduce a new channel flag : CF_WAKE_WRITE. It
is designed so that an analyser can explicitly request being notified when
some data were written. It is used only when the HTTP request or response
analysers need to wait for more room in the buffers. It is automatically
cleared upon wake up.

The flag is also automatically set by the functions which try to write into
a buffer from an applet when they fail (bi_putblk() etc...).

That allows us to remove the stupid condition above and avoid some wakeups.
In http-server-close and in http-keep-alive modes, this reduces from 4 to 3
the average number of wakeups per request, and increases the overall
performance by about 1.5%.
include/types/channel.h
src/channel.c
src/dumpstats.c
src/proto_http.c
src/session.c
src/stream_interface.c