[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption
The rate-limit was applied to the smoothed value which does a special
case for frequencies below 2 events per period. This caused irregular
limitations when set to 1 session per second.
The proper way to handle this is to compute the number of remaining
events that can occur without reaching the limit. This is what has
been added. It also has the benefit that the frequency calculation
is now done once when entering event_accept(), before the accept()
loop, and not once per accept() loop anymore, thus saving a few CPU
cycles during very high loads.
With this fix, rate limits of 1/s are perfectly respected.
diff --git a/src/proxy.c b/src/proxy.c
index 420c1ab..018ce78 100644
--- a/src/proxy.c
+++ b/src/proxy.c
@@ -370,6 +370,7 @@
{
struct proxy *p;
struct listener *l;
+ unsigned int wait;
p = proxy;
@@ -380,15 +381,14 @@
if (p->feconn >= p->maxconn)
goto do_block;
- if (p->fe_maxsps && read_freq_ctr(&p->fe_sess_per_sec) >= p->fe_maxsps) {
+ if (p->fe_maxsps &&
+ (wait = next_event_delay(&p->fe_sess_per_sec, p->fe_maxsps, 0))) {
/* we're blocking because a limit was reached on the number of
* requests/s on the frontend. We want to re-check ASAP, which
* means in 1 ms before estimated expiration date, because the
* timer will have settled down. Note that we may already be in
* IDLE state here.
*/
- int wait = 1000 / p->fe_maxsps - 1;
- wait = MAX(wait, 1);
*next = tick_first(*next, tick_add(now_ms, wait));
goto do_block;
}