-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Open
Description
在我们的场景中,通过 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 数实际上是不一样的。之前 当event_dispatcher_num 大于 num_threads 时,ctrl c失效 #1120 中提到过,event_dispatcher_num 的大小不能大于等于 brpc_worker 的数量,否则会存在问题。导致在多 tag 场景下设置 event_dispatcher_num 不太灵活,是不是应该有类似于分别设置或者每 n 个 brpc_worker 初始化一个 event_dispatcher 的参数。
Metadata
Metadata
Assignees
Labels
No labels