event_dispatcher 数量设置咨询

在我们的场景中，通过 brpc 框架传输数据量较大。单个客户端可能会和多个服务端建立连接。在流量较小时(大量 brpc_worker 都阻塞在 parking log上)，如果单次发送大量请求后返回。极端情况下分为两种可能，会影响系统长尾时延
- 通过一个 fd 接收所有的 repsonse，此时虽然能产生 n 个 bthread，但是加了nosignal的flag。最后的 bthread_flush 只能唤醒最多 2 个 brpc_worker 消费。其实大量的 response 都是在串行消费。 这里是 signal_task 为了权衡性能和​​调度及时性，所以设置成了2。目前来看好像已经是最优设置？
- 如果 response 通过多个 fd 接收。fd 的 消费在一个 event_dispatcher 中是串行的，此时也会存在大量response 串行消费的问题。但是这种场景下，可以通过增加 event_dispatcher 的数量，来提升唤醒并消费任务的 brpc_worker 数量， 实测可以提升一些性能。

这里有几个问题咨询一下
- event_dispatcher 数量设置有什么建议参考吗？event_dispatcher 较多对性能有副影响么？
- 当前 event_dispatcher_num 设置是不区分 tag 的，即每个 tagged group 都会初始化 event_dispatcher_num 个 bthread。但是基于实际需求，每个 tagged group 中的 brpc_worker 数实际上是不一样的。之前 https://github.com/apache/brpc/issues/1120 中提到过，event_dispatcher_num 的大小不能大于等于 brpc_worker 的数量，否则会存在问题。导致在多 tag 场景下设置 event_dispatcher_num 不太灵活，是不是应该有类似于分别设置或者每 n 个 brpc_worker 初始化一个 event_dispatcher 的参数。

Start by reviewing the event_dispatcher_num setting, signal_task behavior, and the constraints discussed in issue #1120. Measure the impact of different dispatcher counts across tagged groups and document whether per-group or worker-based configuration is needed. Done means an agreed configuration recommendation or a clearly scoped feature proposal.

Written by the indexing model from the issue text.