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

when doing continuous runs, export stats periodically #278

Open
ldemailly opened this issue Aug 10, 2018 · 9 comments
Open

when doing continuous runs, export stats periodically #278

ldemailly opened this issue Aug 10, 2018 · 9 comments

Comments

@ldemailly
Copy link
Member

when running with constant traffic, no stats are emitted until "the end" which isn't that useful

it's also related to #134

@nkuacac
Copy link

nkuacac commented Mar 16, 2021

expecting this feature。
we encounted a problem. Testing short connection though loadbalancer for 120s, with some connection 'time out' after 4min,the final summary qps is half of the exact qps

@ldemailly
Copy link
Member Author

While periodic export for long run is useful, I don't think it is related to:

we encounted a problem. Testing short connection though loadbalancer for 120s, with some connection 'time out' after 4min,the final summary qps is half of the exact qps

Set the timeout lower?

@nkuacac
Copy link

nkuacac commented Mar 17, 2021

If we have periodic export, we can get the real qps. And you mean the client timeout option -- the 15s default ?

While periodic export for long run is useful, I don't think it is related to:

we encounted a problem. Testing short connection though loadbalancer for 120s, with some connection 'time out' after 4min,the final summary qps is half of the exact qps

Set the timeout lower?

@ldemailly
Copy link
Member Author

ldemailly commented Mar 17, 2021

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.

@nkuacac
Copy link

nkuacac commented Mar 19, 2021

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?

@ldemailly
Copy link
Member Author

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.

@nkuacac
Copy link

nkuacac commented Mar 19, 2021

The timeout bugs, we will try to figure out. If there is a periodically report, we can find the bug effectively.

@ldemailly
Copy link
Member Author

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

@ldemailly
Copy link
Member Author

also now available through fortiotel's traces/spans

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants