> On 8 сент. 2015 г., at 18:33, Willy Tarreau <w...@1wt.eu> wrote: > > Hi Dmitry, > > On Tue, Sep 08, 2015 at 05:25:33PM +0300, Dmitry Sivachenko wrote: >> >>> 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. > > This is not huge, it's smaller than what can be achieved in pure HTTP mode, > where I could achieve about 180k req/s end-to-end, which means at least > 180kpps > in both directions on both sides, so 360kpps in each direction. >
For reference: I tracked this down to be FreeBSD-specific problem: https://lists.freebsd.org/pipermail/freebsd-net/2015-September/043314.html Thanks all for your help.
