-
Notifications
You must be signed in to change notification settings - Fork 71
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 requests per second graph to the HTML report. #381
Add requests per second graph to the HTML report. #381
Conversation
src/metrics.rs
Outdated
|
||
/// Record request in requests per second metric. | ||
pub(crate) fn record_requests_per_second(&mut self, bucket_size: usize) { | ||
let time_bucket = (Utc::now().timestamp() - self.start_time) as usize / bucket_size; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of the actual time of the request we are using the time when the request metric is reported.
It would be better to collect the time when the request happened, but I think that this data currently isn't reported by the worker.
38c81fc
to
537e093
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fantastic seeing this feature come together!
As we only use the requests-per-second (and tasks-per-second and users-per-second etc) data when writing the html-report, perhaps we simply tie it to the existing --report-file
option.
Specifying a bucket size doesn't seem to scale well, we need a mechanism that works regardless of if the load test runs for 5 minutes or 5 hours.
The code is clean and when it works it looks great -- very nice addition to the load test report!
b87c207
to
f54fc73
Compare
I removed the options that were added in the initial version of this pull request and now we rely on I also changed how the data is stored. Now we are storing the number of requests for each second and the (flawed) concept of "buckets" is now gone. Let me know what you think. Also, what do you think about using something like this for the chart style: https://echarts.apache.org/examples/en/editor.html?c=area-simple. I imagine that it could be quite useful specially for long-running load tests (ability to zoom in, etc.). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is much cleaner, thanks for reworking!
The graph should include ramp-up, running, and ramp-down (and ideally should visually indicate each somehow). I also like the idea of a different graph type that allows you to zoom in.
src/metrics.rs
Outdated
@@ -2415,6 +2434,9 @@ impl GooseAttack { | |||
if self.configuration.status_codes { | |||
merge_request.set_status_code(request_metric.status_code); | |||
} | |||
if !self.configuration.report_file.is_empty() { | |||
merge_request.record_requests_per_second(self.metrics.duration); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have self
, so no need to pass self.metrics.duration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The graph should include ramp-up time and ramp-down time -- in the following test I ran with the following parameters:
cargo run --release --example drupal_memcache -- --host http://apache/ -v -u5 -t10 --report-file report.html --throttle-requests 11
It's not including the ramp-up time, and it needs to. Also, I think we're missing the first second, as we should see 10 seconds of requests for ~11 rps:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have self, so no need to pass self.metrics.duration
record_requests_per_second()
is a function on a different struct so self
represents something else there. And duration
is not available there, so we need to send it.
This is much simpler, I like it! Note that the data is still getting cut off: I ran a load test for 1 hour (3600 seconds) but the data was cut off -- I manually added the missing bit of the report to see the data that was recorded. Likely this is a limitation of the current
I like that idea very much, it would add richness to the charts being able to zoom in. Perhaps the X axis should be actual timestamps though, instead of seconds since the test started? I wonder which is more useful? (The latter would be easier to match up against data in New Relic etc) |
I am still trying to figure out the cutting off problem (I am able to reproduce it). I fell that there is something wrong with JSON serialization or maybe |
I improved the appearance of the graph:
I noticed that there is always a spike of requests exactly at the point when the load test was started up and With
|
I think your graphs in the PR are labeled backwards -- the first one looks like |
1 similar comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking very nice! I like the new charts much better.
- When we are displaying starting/stopping, perhaps we could use "gray" instead of a red shade, as the latter draws more attention to it than it likely should
- It would be ideal to create an automated test that confirms the data in the report is truly accurate
- We either need to preserve a copy of requests made during Startup when running with "--no-reset-metrics" so we can show all data in the chart, or not show that section of time, as it's confusing/wrong to show it blank
- I was able to run an hour long load test and got full data, the report file was only 117k
src/metrics.rs
Outdated
&& Some(stopped) == self.metrics.stopped | ||
{ | ||
let mut count = 0; | ||
for (_path, path_metric) in self.metrics.requests.iter() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If --report-file
is enabled and --no-reset-metrics
is not enabled, we should store a copy of the metrics.requests
"somewhere else" before we reset the metrics so we can generate a complete chart. Alternatively, in this configuration perhaps we should simply not display the "Starting" portion of the chart as it will always be blank.
… default and remove additional options.
…ng and stopping period.
7ec8fc0
to
93fcf3d
Compare
I played with the color scheme and aspect ratio and I think that graph looks better now. Starting phase is only displayed when ScreenshotsWith
|
This is a very nice enhancement, and only affects the HTML report generated when the load test ends. Committing as is: the rest of your TODO will make great followups -- thanks! |
Closes #246.
TODO
Graph color schemeOnly display starting/stopping phase when--no-reset-metrics
is usedScreenshots
With
--no-reset-metrics
Without
--no-reset-metrics