Re: Restricting RPS to a service

2017-04-19 Thread Krishna Kumar (Engineering)
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  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
>


Re: Restricting RPS to a service

2017-04-19 Thread Holger Just
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



Re: Restricting RPS to a service

2017-04-19 Thread Holger Just
Hi Krishna,

Krishna Kumar (Engineering) wrote:
> What is the way to rate limit on the entire service, without caring 
> about which client is hitting it? Something like "All RPS should be <
> 1000/sec"?

You can set a rate limit per frontend (in a frontend section):

rate-limit sessions 1000

or globally per process [2] (in the global section):

maxsessrate 1000

Cheers,
Holger

[1]
http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4.2-rate-limit%20sessions
[2]
http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-maxsessrate




Restricting RPS to a service

2017-04-19 Thread Krishna Kumar (Engineering)
Hi Willy, others,

I have seen documents  that describe how to rate limit from a single client.
What is the way to rate limit on the entire service, without caring about
which
client is hitting it? Something like "All RPS should be < 1000/sec"?

Thanks,
- Krishna