Add a Counter.rps sink #1628
Add a Counter.rps sink #1628
Conversation
| @@ -56,9 +56,11 @@ func (c *CounterSink) Add(s Sample) { | |||
| func (c *CounterSink) Calc() {} | |||
|
|
|||
| func (c *CounterSink) Format(t time.Duration) map[string]float64 { | |||
| rps := c.Value / (float64(t) / float64(time.Second)) | |||
There was a problem hiding this comment.
I am wondering, how often is this calculated, what's the scale of t?
There was a problem hiding this comment.
Because a value of 1 divided by 0.5 seconds will produce rps == 2 which is not optimal 😅
There was a problem hiding this comment.
It is executed every 2 seconds currently, so that can't happen: https://github.com/loadimpact/k6/blob/4f45b8fd009c846429e84804de1c019055c00a87/core/engine.go#L41
But yeah, that is something we have to fix in the new architecture as well...
| return map[string]float64{ | ||
| "count": c.Value, | ||
| "rate": c.Value / (float64(t) / float64(time.Second)), | ||
| "rate": rps, | ||
| "rps": rps, |
There was a problem hiding this comment.
I finally read through all discussion on Slack, and naming this "rps" sounds confusing to me. Like you guys were discussing, RPS implies "request per second", while "rate per second" is meaningless... If anything this should probably be "cps"/"count per second".
I don't want to start a huge discussion about such a nitpick again, but as a user I would find "rps" even more confusing than "rate". At least with "rate" we can document that this means "counts per second", instead of trying to explain what "Counter.rps" means.
There was a problem hiding this comment.
hmm actually, thinking about this some more, I am withdrawing this PR. Completely ignoring whether Counter.rps is easier to grok than Counter.rate, adding Counter.rps in k6 v0.28.0 when it wasn't present in old k6 versions is a problem and for sure an extra complexity... So, I am again back on the opinion we should simply document rate better and fix the whole issue with better names in thresholds v2.
There was a problem hiding this comment.
If adding a different property is an issue for k6 then I guess we'll have to stick with rate, although I would prefer to have a different, less-ambiguous name name (cps?). Or drop this method completely.
There was a problem hiding this comment.
We can't not have rate, given that we've had it and documented it for so long, and having another one, even with the perfect name, will just add extra confusion. We should document its peculiarity, support it everywhere, and figure out a better alternative in the future, when we're not burdened by the limitations we currently have.
There was a problem hiding this comment.
Yeah, I don't see a "perfect" solution here... let's leave this till Monday, maybe a fresh idea will present itself 😄
This is an alias to the
Counter.ratesink we recently re-discovered exists, which has a totally different meaning toRate.rate... 🤦♂️ It's a minor UX improvement, until we can design a better thresholds architecture and fix all of the issues (#1443 (comment)) properly.