Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Counter.rps sink #1628

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 3 additions & 1 deletion stats/sink.go
Original file line number Diff line number Diff line change
Expand Up @@ -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))
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering, how often is this calculated, what's the scale of t?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because a value of 1 divided by 0.5 seconds will produce rps == 2 which is not optimal 😅

Copy link
Member Author

@na-- na-- Sep 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to mostly agree with you, but not too strongly, so I'm leaving this open and you, @mstoykov and @esquonk can reach a consensus next week and decide if you should merge this or not.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@esquonk esquonk Sep 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't see a "perfect" solution here... let's leave this till Monday, maybe a fresh idea will present itself 😄

}
}

Expand Down
2 changes: 1 addition & 1 deletion stats/sink_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ func TestCounterSink(t *testing.T) {
for _, s := range samples10 {
sink.Add(Sample{Metric: &Metric{}, Value: s, Time: now})
}
assert.Equal(t, map[string]float64{"count": 145, "rate": 145.0}, sink.Format(1*time.Second))
assert.Equal(t, map[string]float64{"count": 145, "rate": 145.0, "rps": 145.0}, sink.Format(1*time.Second))
})
}

Expand Down