Hi Chris, On Fri, Nov 15, 2013 at 01:52:57PM -0500, Chris Burroughs wrote: > I'm trying to track down a problem with "cR" and "CR" timeouts with > haproxy 1.4. A service I thought was nice and stable turns out to have > # 4xx/# 2xx ~= 0.2 according to hatop (which pulls in data from the > stats socket). Close to 20% client timeouts is far higher than I expected. > > The logs look like so: > > NAME/<NOSRV> -1/-1/-1/-1/61001 408 212 - - cR-- 31/31/3/0/0 0/0 "<BADREQ>" > NAME/<NOSRV> -1/-1/-1/-1/5650 400 187 - - CR-- 29/29/3/0/0 0/0 "<BADREQ>" > NAME/<NOSRV> -1/-1/-1/-1/5701 400 187 - - CR-- 28/28/3/0/0 0/0 "<BADREQ>" > NAME/<NOSRV> -1/-1/-1/-1/5716 400 187 - - CR-- 24/24/0/0/0 0/0 "<BADREQ>" > NAME/<NOSRV> -1/-1/-1/-1/5559 400 187 - - CR-- 23/23/0/0/0 0/0 "<BADREQ>" > NAME/<NOSRV> -1/-1/-1/-1/5432 400 187 - - CR-- 22/22/0/0/0 0/0 "<BADREQ>" > > We usually run with configurations like so: > option httpclose > option http-server-close > timeout client 3s > timeout server 3s > timeout connect 5s > timeout http-request 2s > > but have tried much higher timeouts: > option httpclose > timeout client 61s > timeout server 21s > timeout connect 21s > timeout http-request 121s > > Higher timeouts turn most of the of the cR timeouts to CR.
The typical case is a client establishing a connection, not sending anything over it then closing (or expiring with the time out). When you run with very short timeouts, it can be caused by request typed by hand and by network losses. When you see them with large timeouts as above, I suspect these result from some pre-connect features from some recent browsers which try to establish a connection to some servers based on your browsing history and which result in increasing the load of some sites. > The docs for CR say "The client aborted before sending a full HTTP request." > But I'm not sure exactly what that means. Did the client send a RST? > Or a FIN before sending any data? Yes any of these. > The docs also say "The HTTP status code is > likely a 400 here", but I presume it's unlikely the client actually > received that It depends. If the client sends the request and a FIN, it can still receive the response, though it's unlikely that this comes from a normal browser. > I looked at `show errors` but only a few hundred errors were reported > which could not account for the large number of BADREQ log lines. "show errors" reports captures of errors which require investigation due to bad contents (typically to fix an application bug). So connections that are only closed are not captured there. Thus you can be sure that the BADREQ comes from clients aborting after a while, possibly also after a preconnect was considered useless. Regards, Willy
