On Aug 6, 2016 00:54, "CJ Ess" <[email protected]> wrote: > > Not the tarpit feature, that will deny access to the content with 500 status. I don't want to kill the request, just delay it,
A hack that I have done in various permutations is to create an extra back-end pointing to the same servers but with maxconn configured artificially low and and maxqueue configured high ... and then use that backend instead of the "real" one for requests I want to throttle without actually denying service. For example, I have a client where I have determined that the infrastructure they use for sending "batch" updates to a certain API endpoint on my side can actually send me up to 64 simultaneous (!?) requests... not very useful since those requests briefly contend for a global mutex on my side at one point in processing. So those "batch" requests (i.e. not speed-sensitive, not related to a real-time web user, they're the functional equivalent of uploading a spreadsheet one line at a time x 64) are handled with a second backend declaration in HAProxy with maxconn 10 maxqueue 200 that points to the same servers as the real/normal backend, but naturally "shapes" the requests to an arrival rate the target system can easily handle. This is hacky because I am effectively "pretending" that the requests are going to a different backend, so it skews my stats... but it's very effective. HAProxy's concept of requests being in a queue is excellent for this, but it would be great if it were somehow possible to leverage it with something a little bit more "native" and granular, similar to the way requests can be natively throttled by denying them outright, based on counters... but I don't know the internals well enough yet to know whether such a thing is even practical.
