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

Generalize resulting request duration name #3403

Closed
bedefaced opened this issue Oct 19, 2023 · 2 comments
Closed

Generalize resulting request duration name #3403

bedefaced opened this issue Oct 19, 2023 · 2 comments
Labels

Comments

@bedefaced
Copy link

Feature Description

Hello,

  1. There are several built-in metrics' names for different protocols (http_req_duration, grpc_req_duration and something like these in third-party extensions for other protocols). Wouldn't be better to use generalized name like req_duration to describe main metric name?
  2. Wouldn't be better to create built-in custom metric and provide function which users (or third-party extensions developers) could use to save custom metrics (requests' duration and status) in results (like "lr_set_transaction" in LoadRunner / Dummy Sampler in Jmeter)?

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

@codebien
Copy link
Contributor

codebien commented Oct 20, 2023

Hey @bedefaced,

Wouldn't be better to use generalized name like req_duration to describe main metric name?

I'm not against this in principle, but they are a very important part of the product and a change to them will be a big change with a relevant impact. There are a lot of details to consider in a change like this, for example, if you have a test with both, how do you differentiate between them? If something like this will be implemented, I don't think is realistic to be considered before #1321 that introduces a granular control over each metric to compute and expose.

Wouldn't be better to create built-in custom metric and provide function which users (or third-party extensions developers) could use to save custom metrics

This is why custom metrics exist, and what the built-in metrics are exporting should be possible to be recreated in a specific custom metric writing some JavaScript code or in very specific and/or advanced cases via extensions. Just an example from the custom metric documentation.

In any case, they both sound to me like solution proposals, but before it is relevant for us to understand the problems with the current implementation. What are the use cases you're trying to improve?

@codebien codebien added awaiting user waiting for user to respond and removed triage labels Oct 20, 2023
@codebien
Copy link
Contributor

At the moment, this is not planned, feel free to re-open or add more details.

@codebien codebien removed the awaiting user waiting for user to respond label Nov 22, 2023
@codebien codebien removed their assignment Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants