Thanks so much for your time/response. We're trying adjusted settings this morning in our DEV/Test environment. - Kevin
On Sep 20, 2012, at 1:05 AM, Willy Tarreau wrote: > 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 > Kevin Lange [email protected] [email protected] W: +1 (301) 851-8450 Raytheon | NASA | ECS Evolution Development Program https://www.echo.nasa.gov | https://www.raytheon.com
smime.p7s
Description: S/MIME cryptographic signature
