-
Notifications
You must be signed in to change notification settings - Fork 241
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
when doing continuous runs, export stats periodically #278
Comments
expecting this feature。 |
While periodic export for long run is useful, I don't think it is related to:
Set the timeout lower? |
If we have periodic export, we can get the real qps. And you mean the client timeout option -- the 15s default ?
|
I would try to understand why you are getting timeouts and why that impacts your expected QPS? Periodically reporting would not change the math; the qps is how many requests were completed (ie finished, including the reply or the timeout) divided by the time; if it's constant whether you have 1200 requests in 20 minutes or 600 requests in 10 minute it's still 1.0 qps - the goal of this feature is to report maybe every few minutes for say a 1h run; it wouldn't change your 120s test. |
Timeouts always happen as the pressure, but just a little connect, the majority finish in time. If Periodically reporting, Maybe it with show first half period is huge, then little the next half? |
increase the -c if you have a few bad requests blocking the other ones. or figure out why that's happening? but either it's unrelated to this specific issue. thanks. |
The timeout bugs, we will try to figure out. If there is a periodically report, we can find the bug effectively. |
I agree! in the meantime remember, you can see errors output in the log as they occur |
also now available through fortiotel's traces/spans |
when running with constant traffic, no stats are emitted until "the end" which isn't that useful
it's also related to #134
The text was updated successfully, but these errors were encountered: