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

show request average duration for each group on end of test summary #2778

Open
MooseSaeed opened this issue Nov 18, 2022 · 1 comment
Open
Labels
enhancement evaluation needed proposal needs to be validated or tested before fully implementing it in k6 feature

Comments

@MooseSaeed
Copy link

Feature Description

I believe it would make a lot of sense if we can see the average request duration for each group by end of test.

Currently, only the checks shows for each group, If k6 team can add average duration as well it would be perfect.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

@na-- na-- added evaluation needed proposal needs to be validated or tested before fully implementing it in k6 enhancement labels Nov 21, 2022
@na--
Copy link
Member

na-- commented Nov 21, 2022

Something like this can currently be manually done by setting bogus (or real) thresholds on the relevant sub-metrics, though it's not very well documented (grafana/k6-docs#205). We also have an open issue for creating an API to make it easier (#1321).

All of that said, I am not sure our users will always want k6 to start doing what you suggest automatically 🤔 With a lot of groups, it will start to have serious performance implications, and it may not even be what everyone desires, since it will make the end-of-test summary quite noisy and more over-crowded than it already is 🤔 So, explicitly exposing the groups the user is interested might be the better UX...

One implementation obstacle to either approach is that sub-metrics need to be defined in the init context, while group() calls happen in the VU context... So, the "simplest" manual solution would probably require some duplication in the user scripts 😞

Another problem with groups in general is that the "parent" groups don't actually contain the values from their "children" (#2309), though that probably can be solved independently by making threshold / sub-group definitions more flexible (#1313).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement evaluation needed proposal needs to be validated or tested before fully implementing it in k6 feature
Projects
None yet
Development

No branches or pull requests

2 participants