expleeve

> 这个时间就是在等待server端处理请求返回结果吧，看看server端的处理时间是多少？ 多谢回复，server端在brpc的status面板上看耗时平均是10ms左右，剩下的大概27ms，不确定是花在哪了 另外，我直接用example里的echo的client和server测试的话，相同的发压配置，这部分的平均耗时（去除server端耗时后）大概在250us左右，QPS在20w以上。 但是对比上面有问题的case，相当于，序列化完且调用完了pwritev_func或writev才打印的开始时间，接受时也是OnNewMessages第一时间打印的结束时间，不知道具体咋定位问题出在哪了，请求体和返回体大小也和echo的demo差不多

> 当qps很低的时候，也会增加27ms的延时吗？还是只有在高qps的时候出现 只有高的时候，2w以下的时候也和echo的demo表现类似的，300us左右

> 看起来是某个地方遇到瓶颈了，有以下可能： > > 1. pthread worker数量不足，导致bthread堆积：可增加pthread worker数量（调大gflag bthread_concurrency） > 2. 单连接上的网络传输速率瓶颈：可切换成连接池试试 > 3. cpu负载过高，导致执行变慢：可为服务分配更多cpu > 4. event dispatcher任务过多达到瓶颈：可增加event dispatcher数量（调大gflag event_dispatcher_num) 好的，非常感谢