RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-19 10:14:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

BUG/MINOR: freq_ctr: fix a wrong delay calculation in next_event_delay()

Browse Source 
The sleep time calculation in next_event_delay() was wrong because it
was dividing 999 by the number of pending events, and was directly
responsible for an observation made a long time ago that listeners
would eat all the CPU when hammered while globally rate-limited,
because the more the queued events, the least it would wait, and would
ignore the configured frequency to compute the delay.

This was addressed in various ways in listeners through the switch to
the FULL state and the wakeup of manage_global_listener_queue() that
avoids this fast loop, but the calculation made there remained wrong
nevertheless. It's even visible with this patch that the accept
frequency is much more accurate at low values now; for example,
configuring a maxconrate of 10 would give between 8.99 and 11.0 cps
before this patch and between 9.99 and 10.0 with it.

Better fix it now in case it's reused anywhere else and causes confusion
again. It maybe be backported but is probably not worth it.
This commit is contained in:
Willy Tarreau 2021-02-09 17:39:08 +01:00
parent e66ee1a651
commit e4d247e217
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/freq_ctr.c
View File

@ -156,7 +156,13 @@ unsigned int next_event_delay(struct freq_ctr *ctr, unsigned int freq, unsigned
if (curr < freq)
return 0;
wait = 999 / curr;
/* too many events already, let's count how long to wait before they're
* processed. For this we'll subtract from the number of pending events
* the ones programmed for the current period, to know how long to wait
* for the next period. Each event takes 1/freq sec, thus 1000/freq ms.
*/
curr -= freq;
wait = curr * 1000 / (freq ? freq : 1);
return MAX(wait, 1);
}