bumingchun commented on PR #1763: URL: https://github.com/apache/incubator-brpc/pull/1763#issuecomment-1130963674
> > 新代码计算expected_time的方式为(start_time + n * interval)，其中start_time是发第一个请求的时间，n是请求个数，并不是依赖上一次的访问时延，程序启动的时间就决定了每个请求发送的expected_time，这种实现方式中expected_time不受抖动影响。旧的实现方式中抖动是会累计的，本次抖动会影响一个窗口过后请求的发送时间，并一直传递，所以我才有“随程序运行时间变长，抖动出现的次数越来越多，发送地请求会越来越不均匀”的结论。 > > 新方法中一旦某段时间发送特别慢（如线程不被调度了），恢复后实际时间就会远大于预期时间，之后会不做任何sleep以最大速率连续发送，直到预期时间追上？这个其实timeq针对的问题，只受之前一段请求的影响。 > 我理解新方法和原有实现都有这个问题，且原有实现抖动会被累计，影响之后的窗口，这才是最大的问题。 以4000qps举例，分析两种情况 情况一：假设end_time - expected_time = 0.5s时，两种方式都会已最大速率连续发送约2000个请求，但原有实现连续发送2000个请求的时间都记录在窗口中，会导致下一个窗口中2000个请求还是连续发送。新的方式中只要expected_time追上end_time后，对后续请求没有影响。 情况二：假设end_time - expected_time = 2s时，新的方式会连续发送8000个请求，旧方式会连续发送2000个请求，这个情况下原有实现是可以减少连续发送请求数，但是原有实现之后的所有请求都是以2000一组连续发送的，以后发送请求都是不均匀的。 我刚刚研究了一下jmeter的实现方式，[代码如下](https://github.com/apache/jmeter/blob/master/src/components/src/main/java/org/apache/jmeter/timers/ConstantThroughputTimer.java)，它的实现是用上一次发送请求的延时来计算sleep时间，这个方式可以避免你提到的连续发送问题，但弊端是因为抖动qps会小于预设值。我提交的新实现方式则是会在抖动后连续发送请求来尽量保证qps准确。大家可以看看我们采用哪种方式更合适。  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
