We may have more accurate information about the error in the logs. Please turn on logging and report the error here. Maybe issueing a "show errors" on HAProxy socket may give some interesting clue as well.
And then we'll see if playing with tune.bufsize makes sense or not. cheers Baptiste On Mon, Sep 10, 2012 at 9:28 PM, Lange, Kevin M. (GSFC-423.0)[RAYTHEON COMPANY] <[email protected]> wrote: > The documentation recommends against changing the default value for concern > of memory consumption. I will assume that if we have sufficient memory, > this should not be an issue. We would have to test in our DEV/TEST stack > first, which we can do this wednesday. > > Qs: > If we're hitting a limit of ~8k, why does the 16k tune.bufsize pose a > problem for us? > > If this parameter does govern maximum URI/URL length, then I would certainly > think clearer documentation of this parameters effect, as REST APIs are > becoming commonplace, with lengthy arguments passed. In this case, long > cookies/session-ids are not as much an issue as REST is consuming the bulk > of the URL. > > Comments: > It would be nice to have a more aptly named parameter/construct that > allocates a larger buffer only for particular front-ends, not a global > buffer for every connection to every service. My point here is that HAPROXY > should be more capable when handling RESTful services (long GETs/PUTs, etc). > > > tune.bufsize <number> > Sets the buffer size to this size (in bytes). Lower values allow more > sessions to coexist in the same amount of RAM, and higher values allow > some > applications with very large cookies to work. The default value is 16384 > and > can be changed at build time. It is strongly recommended not to change > this > from the default value, as very low values will break some services such > as > statistics, and values larger than default size will increase memory > usage, > possibly causing the system to run out of memory. At least the global > maxconn > parameter should be decreased by the same factor as this one is increased. > > On Sep 10, 2012, at 1:41 PM, Richard Stanford wrote: > > We regularly get individual REST GET requests significantly over that > length; the only tuning parameter we've done in that regard is: > > tune.bufsize 128000 > > I don't actually recall if this was mandatory to address the issue, but I'm > thinking that it was. > > -Richard > > Richard Stanford > CTO | KIMBIA > > 512-474-4447 x777 > > On Sep 10, 2012, at 12:24 PM, Lange, Kevin M. (GSFC-423.0)[RAYTHEON COMPANY] > wrote: > > Hi, > Our public-facing service provides a REST api to search for products > (geospatial science data), which requires in many cases very long URLs to > craft the search. We seem to be hitting a limit of around 8K before we > receive a 400 Bad request from lighttpd. We're trying to determine if > lighttpd is causing this, or haproxy. We have a dev/test stack > (lighttpd/haproxy on Linux) and an OPS stack of the same. Our OPS stack we > thought we had test results of the URL length maximum, but after we upgraded > haproxy to the latest on our OPS stack, we noticed that people began > complaining about the URL length issue (maximum 8k). Is there a > configurable item in haproxy which would limit a URL length to ~8k? > Suggestions from searches show that tune.bufsize might control this. We'd > like to offer our customers a 10k length for REST api calls. > - Kevin > > 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 > > > > 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 >
