Hi ,
Currently everyday at peak hours im seeing on the Stingray LB the following :
maxclientbufferdrop | Dropped connection from xxx.xxx.xxx.xxx to port 80, re |
quest exceeded max_client_buffer limit (65536 bytes).
What i would like to know how i could increase this value and what could be the impact of increasing this value? Will it consume for CPU, cause more load?
Im not very familiar and checked some documentation but haven't seen where i could tune this value.
Apologize if this is a stupid question but would help to get some more info.
Thanks ,
HP
Solved! Go to Solution.
Hi Harsh,
From memory, this is most likely to happen when Stingray is reading an HTTP request and the HTTP headers exceed the max_client_buffer limit. At 64k, this is a high limit for HTTP headers, so it's possible that you are encountering either a possible DoS attack (some webservers were vulnerable to large HTTP headers), a badly-behaved client or a request with a very large number of cookies.
The biggest effect of increasing this limit is increased memory usage, followed by reduced ability to detect and discard bad HTTP requests. Unless you are running at very high levels of CPU or using very large amounts of memory*, it's perfectly safe to increase this value.
When the system is running stably, you can use the Connections report to examine GET requests (i.e. those without a request body) that are unusually large (client data read). You'll find it useful to identify which sorts of requests are approaching or exceeding the 64k buffer limit.
Owen
* memory usage is hard to judge because Stingray will grab much of the free memory and reserve it for cache space. Our support team will help you interpret the memory profile of Stingray (hint - the client_buffer is allocated from the zeus.zxtm processes' heap). You can probably just increase the buffer limit and check that Stingray is not using significantly more memory and is not swapping to disk.
Hi Harsh,
From memory, this is most likely to happen when Stingray is reading an HTTP request and the HTTP headers exceed the max_client_buffer limit. At 64k, this is a high limit for HTTP headers, so it's possible that you are encountering either a possible DoS attack (some webservers were vulnerable to large HTTP headers), a badly-behaved client or a request with a very large number of cookies.
The biggest effect of increasing this limit is increased memory usage, followed by reduced ability to detect and discard bad HTTP requests. Unless you are running at very high levels of CPU or using very large amounts of memory*, it's perfectly safe to increase this value.
When the system is running stably, you can use the Connections report to examine GET requests (i.e. those without a request body) that are unusually large (client data read). You'll find it useful to identify which sorts of requests are approaching or exceeding the 64k buffer limit.
Owen
* memory usage is hard to judge because Stingray will grab much of the free memory and reserve it for cache space. Our support team will help you interpret the memory profile of Stingray (hint - the client_buffer is allocated from the zeus.zxtm processes' heap). You can probably just increase the buffer limit and check that Stingray is not using significantly more memory and is not swapping to disk.