Hi Lukas, Thanks for the quick answer. I am using haproxy on another service which consists of GET requests with very small query parameters. It load balances to a backend with 4 servers with 3K-20K requests per second. This time I see 3400K goroutines waiting for reading the request, although there are no POST bodies to stream this time. That is why I am thinking it is something other than slow uploading clients.
The concurrency is not really the problem, but I want to save the application resources for application purposes only and want to handle everything low-level on load balancing side. On Thu, Nov 16, 2017 at 2:03 PM Lukas Tribus <[email protected]> wrote: > Hello, > > > 2017-11-15 15:58 GMT+01:00 omer kirkagaclioglu <[email protected]>: > > I am just trying to understand the difference in behaviour between NGINX > and > > haproxy and if is there any setting I can tweak to fix this issue. > > Nginx buffers the entire client request body and even writes it > temporarily to disk: > > http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size > > Haproxy never writes to the disk and forwards the traffic as soon as > possible. > > > I'm not sure you are approaching this front the correct angle. What is > the problems with 1200 active go-routines? They are supposed to scale > just fine, while blocking IO calls of hundreds of slow uploads in > nginx - probably without threading, stall the entire (event-loop > based) nginx process. > > Really it is a good thing to see 1200 active go-routines, this means > your design will scale. > > > If you prefer to hide concurrency from the backend and move "the > problem" to the load-balancer, then at least use nginx with threading, > so that it doesn't block the event-loop. But haproxy is not a > webserver and it is not the right tool to buffer entire post bodies > for the sole purpose of hiding slow uploads from the backend. > > > > cheers, > lukas >
