Hi Holgar, Thanks once again. However, I understand that session means the same as connection. The rate-limit documentation confirms that: "When the frontend reaches the specified number of new sessions per second, it stops accepting *new connections* until the rate drops below the limit again".
As you say, maxconn defines the maximum number of established sessions, but rate-limit tells how much of that can come per second. I really want existing or new sessions to not exceed a particular RPS. Regards, - Krishna On Wed, Apr 19, 2017 at 9:16 PM, Holger Just <[email protected]> wrote: > Hi Krishna, > > Krishna Kumar (Engineering) wrote: > > Thanks for your response. However, I want to restrict the requests > > per second either at the frontend or backend, not session rate. I > > may have only 10 connections from clients, but the backends can > > handle only 100 RPS. How do I deny or delay requests when they > > cross a limit? > > A "session" is this context is equivalent to a request-response pair. It > is not connected to a session of your applciation which might be > represented by a session cookie. > > As such, to restrict the number of requests per second for a frontend, > rate-limit sessions is exactly the option you are looking for. It does > not limit the concurrent number of sessions (as maxconn would do) but > the rate with which the requests are comming in. > > If there are more requests per second than the configured value, haproxy > waits until the session rate drops below the configured value. Once the > socket's backlog backlog is full, requests will not be accepted by the > kernel anymore until it clears. > > If you want to deny requsts with a custom http error instead, you could > use a custom `http-request deny` rule and use the fe_sess_rate or > be_sess_rate values. > > Cheers, > Holger >
