...to clarify the question:
frontend http
mode http
bind *:8888
stick-table type ip size 100k expire 1000s store conn_cur
tcp-request inspect-delay 1000s
tcp-request content track-sc1 src
tcp-request content accept if { src_conn_cur le 1 }
tcp-request content accept if WAIT_END
1. In 1st console: "telnet localhost 8888" and leave it opened & connected.
2. In 2nd console at the same time: "wget http://localhost:8888/"; - it
hangs (because of "le 1").
3. Then at the 1st console: ^C (terminate the first connection).
4. Wget still hangs! So I conclude that "src_conn_cur le 1" is NOT
rechecked for the 2nd connection when the 1st one dies.
So is there a way (or a work-around) to make it rechecking or something?..
On Fri, Aug 22, 2014 at 9:45 PM, Dmitry Koterov <dmitry.kote...@gmail.com>
wrote:
> Hello.
>
> I need to limit the number of simultaneous HTTP requests PER CLIENT (e.g.
> no more than 5 HTTP requests in progress per client); but DO NOT REJECT
> exceeded request, just enqueue them until the current number of concurrent
> requests from this client drops below 5.
>
> So, assume I run ab -n 1000 -c 10. I want to receive NO 503 errors at all
> in this command. The exceeding connections should be enqueued and will be
> processed sooner or later. No reject for suspicious guys, just enqueue
> their requests. It would be transparent for them, and they will think that
> the service is just slowed down.
>
> THE QUESTION IS: how to do it with haproxy (if possible at all)?
>
> I've dug in the docs and saw "tcp-request content" & "WAIT_END", but looks
> like they are inappropriate for my case, because "ACL-based rules are
> evaluated every time the request contents are updated". In my situation, I
> suspect the ACLs need to be recalculated each time a neighbor request from
> the same client is terminated (when a request terminates, it gives an
> enqueued request from the same client a chance to proceed). So one requests
> needs to "unfreeze" another one possibly.
>
> Or maybe my idea of "per-client non-rejecting enqueueing request limiting"
> is not good in practice, and I should switch to a more traditional limiting
> scheme? What do you think?
>
>
