RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/src/freq_ctr.c

120 lines
3.1 KiB
C
Raw Normal View History

[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
/*
* Event rate calculation functions.
*
* Copyright 2000-2009 Willy Tarreau <w@1wt.eu>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
#include <common/config.h>
#include <common/standard.h>
#include <common/time.h>
[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.
2009-03-06 08:18:27 +00:00
#include <common/tools.h>
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
#include <proto/freq_ctr.h>
/* Read a frequency counter taking history into account for missing time in
* current period. Current second is sub-divided in 1000 chunks of one ms,
* and the missing ones are read proportionally from previous value. The
* return value has the same precision as one input data sample, so low rates
* will be inaccurate still appropriate for max checking. One trick we use for
* low values is to specially handle the case where the rate is between 0 and 1
* in order to avoid flapping while waiting for the next event.
[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.
2009-03-06 08:18:27 +00:00
*
* For immediate limit checking, it's recommended to use freq_ctr_remain() and
* next_event_delay() instead which do not have the flapping correction, so
* that even frequencies as low as one event/period are properly handled.
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
*/
unsigned int read_freq_ctr(struct freq_ctr *ctr)
{
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
unsigned int curr, past;
unsigned int age;
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
age = now.tv_sec - ctr->curr_sec;
if (unlikely(age > 1))
return 0;
curr = 0;
past = ctr->curr_ctr;
if (likely(!age)) {
curr = past;
past = ctr->prev_ctr;
}
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (past <= 1 && !curr)
return past; /* very low rate, avoid flapping */
return curr + mul32hi(past, ~curr_sec_ms_scaled);
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
}
[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.
2009-03-06 08:18:27 +00:00
/* returns the number of remaining events that can occur on this freq counter
* while respecting <freq> and taking into account that <pend> events are
* already known to be pending. Returns 0 if limit was reached.
*/
unsigned int freq_ctr_remain(struct freq_ctr *ctr, unsigned int freq, unsigned int pend)
{
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
unsigned int curr, past;
unsigned int age;
past = 0;
curr = 0;
age = now.tv_sec - ctr->curr_sec;
[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.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (likely(age <= 1)) {
past = ctr->curr_ctr;
if (likely(!age)) {
curr = past;
past = ctr->prev_ctr;
}
curr += mul32hi(past, ~curr_sec_ms_scaled);
}
curr += pend;
[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.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (curr >= freq)
[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.
2009-03-06 08:18:27 +00:00
return 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
return freq - curr;
[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.
2009-03-06 08:18:27 +00:00
}
/* return the expected wait time in ms before the next event may occur,
* respecting frequency <freq>, and assuming there may already be some pending
* events. It returns zero if we can proceed immediately, otherwise the wait
* time, which will be rounded down 1ms for better accuracy, with a minimum
* of one ms.
*/
unsigned int next_event_delay(struct freq_ctr *ctr, unsigned int freq, unsigned int pend)
{
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
unsigned int curr, past;
unsigned int wait, age;
[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.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
past = 0;
curr = 0;
age = now.tv_sec - ctr->curr_sec;
[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.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (likely(age <= 1)) {
past = ctr->curr_ctr;
if (likely(!age)) {
curr = past;
past = ctr->prev_ctr;
}
curr += mul32hi(past, ~curr_sec_ms_scaled);
}
curr += pend;
[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.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (curr < freq)
[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.
2009-03-06 08:18:27 +00:00
return 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
wait = 999 / curr;
[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.
2009-03-06 08:18:27 +00:00
return MAX(wait, 1);
}
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/