|
|
|
// Copyright 2013 The Prometheus Authors
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
package remote
|
|
|
|
|
|
|
|
import (
|
|
|
|
"sync"
|
|
|
|
"time"
|
|
|
|
|
|
|
|
"go.uber.org/atomic"
|
|
|
|
)
|
|
|
|
|
|
|
|
// ewmaRate tracks an exponentially weighted moving average of a per-second rate.
|
|
|
|
type ewmaRate struct {
|
|
|
|
newEvents atomic.Int64
|
|
|
|
|
|
|
|
alpha float64
|
|
|
|
interval time.Duration
|
|
|
|
lastRate float64
|
|
|
|
init bool
|
|
|
|
mutex sync.Mutex
|
|
|
|
}
|
|
|
|
|
|
|
|
// newEWMARate always allocates a new ewmaRate, as this guarantees the atomically
|
|
|
|
// accessed int64 will be aligned on ARM. See prometheus#2666.
|
|
|
|
func newEWMARate(alpha float64, interval time.Duration) *ewmaRate {
|
|
|
|
return &ewmaRate{
|
|
|
|
alpha: alpha,
|
|
|
|
interval: interval,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// rate returns the per-second rate.
|
|
|
|
func (r *ewmaRate) rate() float64 {
|
|
|
|
r.mutex.Lock()
|
|
|
|
defer r.mutex.Unlock()
|
|
|
|
return r.lastRate
|
|
|
|
}
|
|
|
|
|
|
|
|
// tick assumes to be called every r.interval.
|
|
|
|
func (r *ewmaRate) tick() {
|
|
|
|
newEvents := r.newEvents.Swap(0)
|
|
|
|
instantRate := float64(newEvents) / r.interval.Seconds()
|
|
|
|
|
|
|
|
r.mutex.Lock()
|
|
|
|
defer r.mutex.Unlock()
|
|
|
|
|
style: Replace `else if` cascades with `switch`
Wiser coders than myself have come to the conclusion that a `switch`
statement is almost always superior to a statement that includes any
`else if`.
The exceptions that I have found in our codebase are just these two:
* The `if else` is followed by an additional statement before the next
condition (separated by a `;`).
* The whole thing is within a `for` loop and `break` statements are
used. In this case, using `switch` would require tagging the `for`
loop, which probably tips the balance.
Why are `switch` statements more readable?
For one, fewer curly braces. But more importantly, the conditions all
have the same alignment, so the whole thing follows the natural flow
of going down a list of conditions. With `else if`, in contrast, all
conditions but the first are "hidden" behind `} else if `, harder to
spot and (for no good reason) presented differently from the first
condition.
I'm sure the aforemention wise coders can list even more reasons.
In any case, I like it so much that I have found myself recommending
it in code reviews. I would like to make it a habit in our code base,
without making it a hard requirement that we would test on the CI. But
for that, there has to be a role model, so this commit eliminates all
`if else` occurrences, unless it is autogenerated code or fits one of
the exceptions above.
Signed-off-by: beorn7 <beorn@grafana.com>
2 years ago
|
|
|
switch {
|
|
|
|
case r.init:
|
|
|
|
r.lastRate += r.alpha * (instantRate - r.lastRate)
|
style: Replace `else if` cascades with `switch`
Wiser coders than myself have come to the conclusion that a `switch`
statement is almost always superior to a statement that includes any
`else if`.
The exceptions that I have found in our codebase are just these two:
* The `if else` is followed by an additional statement before the next
condition (separated by a `;`).
* The whole thing is within a `for` loop and `break` statements are
used. In this case, using `switch` would require tagging the `for`
loop, which probably tips the balance.
Why are `switch` statements more readable?
For one, fewer curly braces. But more importantly, the conditions all
have the same alignment, so the whole thing follows the natural flow
of going down a list of conditions. With `else if`, in contrast, all
conditions but the first are "hidden" behind `} else if `, harder to
spot and (for no good reason) presented differently from the first
condition.
I'm sure the aforemention wise coders can list even more reasons.
In any case, I like it so much that I have found myself recommending
it in code reviews. I would like to make it a habit in our code base,
without making it a hard requirement that we would test on the CI. But
for that, there has to be a role model, so this commit eliminates all
`if else` occurrences, unless it is autogenerated code or fits one of
the exceptions above.
Signed-off-by: beorn7 <beorn@grafana.com>
2 years ago
|
|
|
case newEvents > 0:
|
|
|
|
r.init = true
|
|
|
|
r.lastRate = instantRate
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// inc counts one event.
|
|
|
|
func (r *ewmaRate) incr(incr int64) {
|
|
|
|
r.newEvents.Add(incr)
|
|
|
|
}
|