-
Notifications
You must be signed in to change notification settings - Fork 17
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
fix: qps is not correct #221
Conversation
Codecov Report
@@ Coverage Diff @@
## main #221 +/- ##
==========================================
+ Coverage 39.16% 39.52% +0.35%
==========================================
Files 8 8
Lines 526 544 +18
==========================================
+ Hits 206 215 +9
- Misses 315 323 +8
- Partials 5 6 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
我记得当初有要求完成 在 server 应用端 验证 请求数,这个用例 没验证出 这大bug 么 ?如果没有,请闭环 用例 |
a1b1708
to
a7768a9
Compare
之前的用例是实际请求与期望请求差值在 10%就可以,现在已经更改为实际与期望相等才可通过。 |
pr 描述中 , “如期望发送 15 个请求,10 个并发协程执行,当完成 10 个请求后,剩余 5 个请求被 5 个协程分配,但剩下的 5 个协程没有被分配到 依然会去请求,影响期望结果” 而 之前e2e 偏差容忍是 10%, 那 PR 描述 不准确,还是 E2E 有 bug 没测试出来 |
之前的e2e 设置的 qps 以及并发量正好偏差在 10%以内所以用例通过了,现在已经将e2e 用例更改为固定期望数值了。 |
a7768a9
to
d65736d
Compare
如果是用绝对值 比较,是否 可能会出现一些 边际效应,例如超时时间的偏差,导致实际多一个或者少一个请求,导致 用例 时过时不过 |
client 是根据 qps 来进行发送请求,超时时间内会发送完所有请求,所有请求返回完毕才会结束,若因为超时原因失败,那是否可以考虑是 server 不满足我的任务需求,请求是协程在做,不会阻塞,除非超时时间设置的不合理,才会导致少发请求,但我们在 webhook 中对超时时间进行了检查,不会出现这种情况。 |
client 是根据 qps 来进行发送请求,超时时间内会发送完所有请求,所有请求返回完毕才会结束 |
本pr是否需要改进 |
需要改进,等复用daemonset 的需求搞完,弄此pr |
8d0370d
to
e14ccf8
Compare
已改进完成,通过根据 qps 设置定时器发送 channel 控制请求发送,拿到 token 的并发协程才去请求,未拿到 token 的协程继续等待,用例请求误差容忍改为5%。 |
@@ -64,6 +67,7 @@ type Work struct { | |||
initOnce sync.Once | |||
results chan *result | |||
stopCh chan struct{} | |||
runCh chan struct{} |
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.
-> qosTokenBucket
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.
done
b.Stop() | ||
return | ||
case <-ticker.C: | ||
b.runCh <- struct{}{} |
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.
投放的 debug 日志
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.
done
70bea9f
to
174a717
Compare
b.Stop() | ||
return | ||
case <-ticker.C: | ||
b.Logger.Sugar().Debugf("request token channel len: %d", len(b.qosTokenBucket)) |
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.
需要 len > 0 有错误日志
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.
done
select { | ||
case <-c: | ||
// Reach request duration stop request | ||
b.Logger.Sugar().Debugf("request finish remaining number of tokens len: %d", len(b.qosTokenBucket)) |
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.
需要 len > 0 有错误日志 ,且任务失败
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.
done
aa0488a
to
868c9d6
Compare
Signed-off-by: ii2day <ji.li@daocloud.io>
868c9d6
to
1139931
Compare
fix #95
原方法:每个并发协程平均分配请求,这样会导致,请求数量大于期望的请求数量,影响结果,如期望发送 15 个请求,10 个并发协程执行,当完成 10 个请求后,剩余 5 个请求被 5 个协程分配,但剩下的 5 个协程没有被分配到 依然会去请求,影响期望结果。
现方法:将请求的数量放入一个 channel 中,每个并发协程去channel 中拿请求的许可,拿到许可才进行请求。