brpc 没向用户暴露 RPC 从 socket 读取的时间， 我们应该暴露这个信息

[liupengs]

现在，brpc 的用户函数里（CallMethod ）无法获取 RPC 在 socket 被读取的时间点，所以存在几个问题：

1. 无法在用户代码里统计出 RPC 正确的处理总耗时：因为在用户代码里只能从 RPC 开始被处理时开始统计时间， 而实际耗时还应该包含 RPC 在 bthread 队列里的等待时间
2. 无法直接抛弃超时的RPC： 如果 RPC 在 bthread 调度队列等待的时间过长（也就是从 socket 读取到被 bthread 开始处理这个 RPC 的排队时间，我们线上偶发）， 且超过了超时时间， 这个请求应该直接被抛弃， 但是用户无法获取 RPC 到达时间， 导致无法实现这功能

[TousakaRin]

for 2, you can consider increasing flag: event_dispatcher_num

[liupengs]

for 2, you can consider increasing flag: event_dispatcher_num

Yes, increasing the event_dispatcher_num can increase the bthreads of epoll, which can reduce pressure under high load conditions. However, in some scenarios, the bottleneck is not the number of dispatchers, but the execution speed of user code. If the user code executes slowly and the RPC QPS is extremely high, bthreads can easily pile up. There are multiple solutions for such cases, the most effective one being rate limiting. Discarding RPCs that have timeout is also one of the strategies.