Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar feature requirement.

Apache Dubbo Component

Java SDK (apache/dubbo)

Descriptions

Subject: Very Confused About org.apache.dubbo.rpc.AdaptiveMetrics#getLoad, Delay Penalty, and Decay Design
主题：非常疑惑org.apache.dubbo.rpc.AdaptiveMetrics#getLoad，延迟惩罚和衰减的设计

Question:

1. As long as the server responds normally, the currentProviderTime and currentTime will be updated to serviceTime. Then there will be a call to trigger getLoad. As long as there is no clock back, the branch if (metrics. currentProviderTime==metrics. currentTime) will be reached. Then it will be satisfied. The lastLatency will be set to timeout * 2L. Is this branch a maximum probability? So the actual RT will be overwritten, so is the design here reasonable?
2. As long as getLoad is called once, metrics. CurrentProvider Time==metrics. CurrentTime will not be satisfied, so what is the design purpose of this branch?
3. metrics. lastLatency = metrics. lastLatency >> multiple; Does the decay rate occur too quickly?

中文：
1.只要服务端正常响应时，那么currentProviderTime和currentTime就被更新成serviceTime，那么紧接着有一次调用，触发getLoad，只要不发生时钟倒退一定会走到if (metrics.currentProviderTime == metrics.currentTime) 这个分支，那么也一定会满足，就会将lastLatency 置为 timeout * 2L，这个分支是极大概率的吧？那么实际的rt就会被覆盖掉，所以这里设计的是合理吗？
2. 只要调用一次getLoad，那么metrics.currentProviderTime == metrics.currentTime就不会满足，所以这个分支的设计目的是什么？
3.metrics.lastLatency = metrics.lastLatency >> multiple衰减程度是否过快

I hope the experts can help clarify my doubts. clasped fist salute

Related issues

No response

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct