MVPASM Too many concurrent long requests
Hello everyone!
I have come across this error at an ASM customer recently:
Too many concurrent long requests allowed 289 ,current 289 needed request length: 5120168
This led me to this article: https://my.f5.com/manage/s/article/K8292
Where a lot of parameters where mentioned:
request_buffer_size
max_concurrent_long_request
long_request_buffer_size
Can anyone point to somewhere documenting these values properly or can describe the to me? What is the definition of a "long request"?
What is puzzling me is that to my understanding these are all values limiting the amount of data which can be pushed towards ASM and onto the backend. But the application in question doesn't work in this way. So, could it be that it is all about clients having extremely large headers in the GET requests that these value are reached?
This all happend during what looks like an attack on the application.
I think K8292 defines it all as well as you're going to find anywhere, to be honest.
In ASM, a long request is simply any request (headers and content) which is larger than the request_buffer_size (10Kb by default). As soon as the buffered content reaches that size, ASM allocates a "long request buffer" (roughly 10Mb) from the pool and moves the entire request there (freeing the original request buffer)
On any modern (supported!) version the maximum number of long request buffers (10Mb each, remember) is a function of how much memory is available to ASM overall (the calculation is in K01235989 but you can ignore that as your system has already told you 298 is the number it allows).
For each (long) request, the long request buffer is only going to be freed once ASM has processed the transaction and handed it off to the back end system, so what this means is that you had 298 "long" requests (over 10Kb) in flight at that moment and the 299th request that came in was 5Mb in length. The fact that ASM knew that up front implies this wasn't a chunked request or headers (which ASM can only caculate the length of at the end of buffering, after it has allocated the long_request_buffer) but rather body content with a defined Content-Length.
That only applies for that specific request, though - for all we know the other 298 were, as you suggest, GET requests with enormous headers. You'd need logging or captures to figure that part out, unfortunately.
