Joining the party a bit late... On 08/06/2016 10:37 μμ, Willy Tarreau wrote: > On Wed, Jun 08, 2016 at 04:17:58PM -0400, CJ Ess wrote: >> I personally don't have a need to limit requests the haproxy side at the >> moment, I'm just thought I'd try to help Manas make his case. Hes basically >> saying that he wants the option to close the client connection after the >> nth request and that seems pretty reasonable to me. > > But quite frankly it's not a use case. Believe me, we're quite used to > get requests from people *thinking* they need a certain feature while > in fact they need something totally different, just because they think > that it's the last missing piece of their puzzle. Implementing something > specific like this which will definitely cause new issues and bug reports > here is not going to happen without a really good reason, and for now all > I can read is "I'd like to close after N request". We could also implement > just a sample fetch to return the request number so that it's possible to > add an ACL to block past some point but all of this seems very fishy for > now :-/ >
That fetch would be helpful indeed. But, we could have an option like http-max-keepalive-requests which adds 'max' parameter in the response and HAProxy will close the TCP connection when user exceeds the limit. But then we depend on the client to honor that, thus the the fetcher with an ACL is more helpful as it will force the closure of the connection. Some people have already expressed their use cases, but I also would like to mention my use case. HAProxy has this one2one relationship between client and backend server connection, where a connection established between haproxy and the backend server belongs to the client that initiated it. When the client is a bot or a program which establishes 2 connections on startup and will only reestablish those 2 TCP connections after a reload or failure, then all HTTP requests from that client will be delivered to the same backend server. http-reuse can help a bit to spread those HTTP requests over multiple backend servers. But, in case of a reload there is nothing in place to terminate the TCP connection and the 'old' processes stay alive until client decides to close the connection. When clients have a continuous stream of HTTP requests, timeout setting can't help that much. Thus, you need to have a limit on HAProxy to kick those clients by closing their TCP connections when requests exceed a limit. The same scenario is applicable when you have a frontend/backend in tcp mode and clients have long-lived TCP connections. I have in production 15K rsyslogd clients which open 1 TCP connections on startup and will only reestablish a TCP connection after X mins of inactivity (no logging messages), but some systems(web servers, hadoop, load balancers) have a continuous stream of log messages and as a result rsyslogd never tries to reconnect. A fetcher which will return the amount of in-bytes(as a counter) will help in this case to kick the connection. In this specific case(rsyslogd with RELP protocol) it is safe to drop the connection as client will retry to send the log message. I hope I was clear enough. Cheers, Pavlos
signature.asc
Description: OpenPGP digital signature
