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. ... View more