bumingchun commented on PR #1763: URL: https://github.com/apache/incubator-brpc/pull/1763#issuecomment-1131236413
> > 我理解新方法和原有实现都有这个问题，且原有实现抖动会被累计，影响之后的窗口，这才是最大的问题。 以4000qps举例，分析两种情况 情况一：假设end_time - expected_time = 0.5s时，两种方式都会已最大速率连续发送约2000个请求，但原有实现连续发送2000个请求的时间都记录在窗口中，会导致下一个窗口中2000个请求还是连续发送。新的方式中只要expected_time追上end_time后，对后续请求没有影响。 情况二：假设end_time - expected_time = 2s时，新的方式会连续发送8000个请求，旧方式会连续发送2000个请求，这个情况下原有实现是可以减少连续发送请求数，但是原有实现之后的所有请求都是以2000一组连续发送的，以后发送请求都是不均匀的。 > > ”原有实现连续发送2000个请求的时间都记录在窗口中“，发送2000个请求后导致缓慢的那个请求已经出队列了吧，并不会导致后面连续发送，这个判断是有问题的。新方法相当于老方法中的timeq无限大，jmeter的方法类似于timeq容量为1。jmeter的方法就如你说的，在很多情况下会导致实际qps低于指定qps，相当于压力总是打了个折扣。老方法就是注意到这一点做了折中。 > > 我本地观察了一些cases，”抖动“问题的主要原因我认为是：1. 高qps导致usleep精度不足； 2. 线程不够。这两个问题会交织在一起：现在代码中默认一个线程可以承担10000qps，可以达到，但会导致usleep精度不足，现象就是qps明显低于预期。把单个线程承担的qps调低，以及对timeq容量上限、usleep逻辑做些调整，应该可以解决问题。 > > 我理解新方法和原有实现都有这个问题，且原有实现抖动会被累计，影响之后的窗口，这才是最大的问题。 以4000qps举例，分析两种情况 情况一：假设end_time - expected_time = 0.5s时，两种方式都会已最大速率连续发送约2000个请求，但原有实现连续发送2000个请求的时间都记录在窗口中，会导致下一个窗口中2000个请求还是连续发送。新的方式中只要expected_time追上end_time后，对后续请求没有影响。 情况二：假设end_time - expected_time = 2s时，新的方式会连续发送8000个请求，旧方式会连续发送2000个请求，这个情况下原有实现是可以减少连续发送请求数，但是原有实现之后的所有请求都是以2000一组连续发送的，以后发送请求都是不均匀的。 > > ”原有实现连续发送2000个请求的时间都记录在窗口中“，发送2000个请求后导致缓慢的那个请求已经出队列了吧，并不会导致后面连续发送，这个判断是有问题的。新方法相当于老方法中的timeq无限大，jmeter的方法类似于timeq容量为1。jmeter的方法就如你说的，在很多情况下会导致实际qps低于指定qps，相当于压力总是打了个折扣。老方法就是注意到这一点做了折中。 > > 我本地观察了一些cases，”抖动“问题的主要原因我认为是：1. 高qps导致usleep精度不足； 2. 线程不够。这两个问题会交织在一起：现在代码中默认一个线程可以承担10000qps，可以达到，但会导致usleep精度不足，现象就是qps明显低于预期。把单个线程承担的qps调低，以及对timeq容量上限、usleep逻辑做些调整，应该可以解决问题。 "发送2000个请求后导致缓慢的那个请求已经出队列了吧，并不会导致后面连续发送"，我理解是会影响后面请求发送的，我把这个过程画了个图，你看我的图有问题吗？是不是可以说明这个问题。  -- 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]
