Hi Kevin, On Wed, Sep 19, 2012 at 10:02:07PM -0500, Lange, Kevin M. (GSFC-423.0)[RAYTHEON COMPANY] wrote: > Hi, > Got a few cycles to do some testing/verification. > Sure enough when we pass a long URL through haproxy/lighttpd, we see this in > the haproxy log: > > Sep 19 22:45:14 127.0.0.1 haproxy[4195]: 172.28.xx.xx:55500 > [19/Sep/2012:22:45:14.428] kernel_partner_ft kernel_partner_ft/<NOSRV> > -1/-1/-1/-1/0 400 187 - - PR-- 0/0/0/0/0 0/0 "<BADREQ>" > > From your message, you say that haproxy will be marked with PR if blocked by > haproxy, so this looks like haproxy is confirmed to be the cause of our > problem. Correct?
Exactly ! > We're going to draft and test a configuration that increases maxrewrite, and > perhaps bufsize. You should do the opposite. A buffer is sized to contain a full request plus a small space needed to add some headers or rewrite them. So haproxy refrains from filling a buffer. The maximum request length it accepts is then (bufsize-maxrewrite). The default values are 16384 for bufsize, and 8192 for maxrewrite, which results in 8192 bytes max for a received request. Start by simply reducing maxrewrite to 1024 and you'll automatically get 15kB for an incoming request. And if that's not enough, then you'll have to increase bufsize. But be careful. Experience tells us that quite often when you hit any component's limit along a path, you're close to getting trouble with other components. > Any thoughts to modifying haproxy to limit allocating such large buffer areas > for only certain frontends, instead of being only a global tunable? Tuning > haproxy globally to solve a problem with processing only one frontend/backend > seems rough. That's planned but not with high priority. In fact I'd like to have 3 buffer sizes, the default ones, the small ones (for idle connections) and the large ones (for large requests and for high speed transfers). But we need to go with 1.6 first which goal will be to let a task sleep waiting for resources. Regards, Willy
