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. > haproxy process CPU usage is about 15-20%. And the rest is for the system ? Willy
