mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-23 21:22:17 +00:00
BUG/MINOR: freq_ctr: fix a wrong delay calculation in next_event_delay()
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:
parent
e66ee1a651
commit
e4d247e217
@ -156,7 +156,13 @@ unsigned int next_event_delay(struct freq_ctr *ctr, unsigned int freq, unsigned
|
|||||||
if (curr < freq)
|
if (curr < freq)
|
||||||
return 0;
|
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);
|
return MAX(wait, 1);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user