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 >> kevin.m.la...@nasa.gov >> kla...@raytheon.com >> W: +1 (301) 851-8450 >> Raytheon | NASA | ECS Evolution Development Program >> https://www.echo.nasa.gov | https://www.raytheon.com >> > Kevin Lange kevin.m.la...@nasa.gov kla...@raytheon.com 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
