> On 30 авг. 2015 г., at 22:29, Willy Tarreau <w...@1wt.eu> wrote: > > On Fri, Aug 28, 2015 at 11:40:18AM +0200, Lukas Tribus wrote: >>>> Ok, you may be hitting a bug. Can you provide haproxy -vv output? >>>> >>> >>> >>> What do you mean? I get the following warning when trying to use this >>> option in tcp backend/frontend: >> >> Yes I know (I didn't realize you are using tcp mode). I don't mean the >> warning is the bug, I mean the tcp mode is supposed to not cause any >> delays by default, if I'm not mistaken. > > You're not mistaken, tcp_nodelay is unconditional in TCP mode and MSG_MORE > is not used there since we never know if more data follows. In fact there's > only one case where it can happen, it's when data wrap at the end of the > buffer and we want to send them together. >
Hello, yes, you are right, the problem is not TCP_NODELAY. I performed some testing: Under low network load, passing TCP connection through haproxy involves almost zero overhead. When load grows, at some point haproxy starts to slow things down. In our testing scenario the application establishes long-lived TCP connection to server and sends many small requests. Typical traffic at which adding haproxy in the middle causes measurable slowdown is ~30MB/sec, ~100kpps. haproxy process CPU usage is about 15-20%.
