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

Restrict unneccessary calculation of unused threshold/summary metrics #764

Closed
na-- opened this issue Sep 12, 2018 · 1 comment
Closed

Restrict unneccessary calculation of unused threshold/summary metrics #764

na-- opened this issue Sep 12, 2018 · 1 comment

Comments

@na--
Copy link
Member

na-- commented Sep 12, 2018

Sometimes it may be a waste time and memory to calculate the summary stats for some or all of the metrics. For example, if there are no percentile-based thresholds for a metric and the user doesn't care about the end-of-test summary (because they use an external output like InfluxDB or Load Impact Cloud or they use the LI cloud execution). Adding an option that allows users to specify whether they want to calculate those stats could lighten the CPU and memory load in those situations.

Depending on the performance and memory characteristics of HdrHistogram, implementing this may end up being unnecessary, but I decided to add it as an issue so we consider it as well. And it's somewhat of a lightweight version of the full metric filtering, though there are use cases where you might want one but not the other.

na-- added a commit that referenced this issue Oct 12, 2018
This, when used in conjunction with --no-thresholds, should reduce the k6 memory usage for long-running tests. This is something like an all-or-nothing approach to #764 - even though it's not the best solution, it's pretty easy to implement and support and we can always extend it later.
na-- added a commit that referenced this issue Oct 16, 2018
This, when used in conjunction with --no-thresholds, should reduce the k6 memory usage for long-running tests. This is something like an all-or-nothing approach to #764 - even though it's not the best solution, it's pretty easy to implement and support and we can always extend it later.
@na--
Copy link
Member Author

na-- commented Jan 28, 2020

Closing this in favor of #1321

@na-- na-- closed this as completed Jan 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant