apache
Responses spent a lot of time（响应花费了很长时间）
Describe the bug (描述bug) When I test a brpc client and a brpc server, about 50k QPS, the Avg latency is over 44ms. I found the most of the time spent between finish write and start read，avg cost is about 37ms，I don't know why? (当我用一个brpc的client和server测试时，大概5w QPS，平均延迟44ms。我发现主要耗时在发送完成后到开始读取的时间上，平均37ms，我不清楚为什么？)
To Reproduce (复现方法) client：20*pthread，async call，sofa-pbrpc，single connection, no retry server: default config add a bvar::LatencyRecorder：$2-$1 as below
- Socket::ReturnSuccessfulWriteRequest: butil::cpuwide_time_us()，setting a self-defined property in a Controller object, per request.
- InputMessenger::OnNewMessages: butil::cpuwide_time_us() (使用了一个延迟记录，记录了发送后到开始接受时延迟，每个请求是单独记录的)
Expected behavior (期望行为) I want to know what cause it, or give me some advises，THX (我想知道原因，或者提供给我一些指导意见，谢谢各位老师)
Versions (各种版本) OS: CentOS 6.5 Compiler: GCC 4.8 brpc: 1.0.0 protobuf: 2.5
Additional context/screenshots (更多上下文/截图)
这个时间就是在等待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左右
看起来是某个地方遇到瓶颈了，有以下可能：
- pthread worker数量不足，导致bthread堆积：可增加pthread worker数量（调大gflag bthread_concurrency）
- 单连接上的网络传输速率瓶颈：可切换成连接池试试
- cpu负载过高，导致执行变慢：可为服务分配更多cpu
- event dispatcher任务过多达到瓶颈：可增加event dispatcher数量（调大gflag event_dispatcher_num)
看起来是某个地方遇到瓶颈了，有以下可能：
- pthread worker数量不足，导致bthread堆积：可增加pthread worker数量（调大gflag bthread_concurrency）
- 单连接上的网络传输速率瓶颈：可切换成连接池试试
- cpu负载过高，导致执行变慢：可为服务分配更多cpu
- event dispatcher任务过多达到瓶颈：可增加event dispatcher数量（调大gflag event_dispatcher_num)
好的，非常感谢