Hi, On Mon, Jul 18, 2011 at 11:46:12PM +0300, P.R. wrote: > Hi all, > I am having a similar problem as this guy: > http://forums.rightscale.com/showthread.php?t=665 > > Basically, when sending chunked response, and not ending the connection, > haproxy will buffer initial chunks for 3 seconds, after that chunks go out > instantly.
It does not specifically buffer for any length of time, but sets the MSG_MORE flag on output so that the system avoids sending incomplete frames. > I tinkered with buffer size settings (tune.*) but that didn't help. One > solution to work is manually sending about 8k. > > How to fix this the right way? Thanks. Please note that the right way to fix it is to use HTTP the correct way. There must be no assumption on the way chunks are delivered, and any intermediary between the server and the client is free to re-chunk them and even to wait for the whole message to be buffered before sending it at once. So fixing it the right way means fixing the application or the way it's used. One workaround for such applications was recently introduced in haproxy. You can use "option http-no-delay" either in the frontend or the backend, and it will instruct the system not to buffer requests/responses and to send them without waiting. This means that incomplete TCP segments might be sent over the network and that more ACKs will be sent by the client, but it can allow you to get a more acceptable behaviour during the time it takes to fix the application. Please also note that doing so will only workaround the problem at the haproxy level, but will not change anything for other network components along the path. Any proxy (transparent or no) may do the same thing. If you're interested on the subject, this wrong use has been explicitly covered by the HTTP-bis working group, because such breakage has already been reported with other applications and intermediaries : http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-2.2 Regards, Willy
