wwbmmm commented on PR #1763: URL: https://github.com/apache/incubator-brpc/pull/1763#issuecomment-1129515233
这个问题可以复用，启动echo_server，然后用rpc_press压，当传`-thread_num=12 -qps=0`（同步发送）时，qps大概是100000，且cpu使用稳定在2左右。 当传`-thread_num=12 -qps=100000`（异步发送）时，可以看到，虽然rpc_press显示的qps一直在100000左右，但是server的cpu使用率会一路下降到1以下。如果重启rpc_press，cpu使用率会再次升到2（图中时间粒度太粗，被平均了），然后又逐步下降到1以下。 <img width="832" alt="image" src="https://user-images.githubusercontent.com/3894631/168946958-787d2d28-8a1a-4d91-a028-3e4f92db6b43.png";> 我推测的原因是这样的： 1. 如 @jamesge 指出的，sleep的精度一般远大于60us，那么在qps较大的时候，每次计算出来要sleep的时间间隔是比较短的，比如本来只需sleep 10us，每隔10us发一个请求，结果sleep实际花了100us，接着会立即发出10个请求，这就造成了抖动 2. 如 @bumingchun 指出的，抖动会在队列中一直存在，那么过了一个完整的窗口之后，会计算出应该sleep 100us，这时调用sleep，可能实际的sleep时间变成了200us，如此反复抖动会不断积累变大 3. 最终导致的结果是，server端收到的瞬时qps是不均匀的（以毫秒为尺度来看），可能某段时间一个请求都没有，某段时间收到大量请求，但是以秒的尺度来看，qps的数值是均匀的 4. 由于单连接会合并同一时间的IO，瞬时qps越高，合并效果越好，cpu使用率越低。在echo_server的例子中，随着瞬时qps越来越不均衡，cpu使用率也越来越低。但对于其它的业务场景，比如在业务代码中使用到很多锁的话，有可能会出现瞬时qps越高、cpu使用越高的情况，那么就会出现压测过程中服务性能越变越差的现象。 -- 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]
![https://user-images.githubusercontent.com/3894631/168946958-787d2d28-8a1a-4d91-a028-3e4f92db6b43.png"](https://user-images.githubusercontent.com/3894631/168946958-787d2d28-8a1a-4d91-a028-3e4f92db6b43.png"){kind=link}