epoll bthread deal first

[zhengJade]

What problem does this PR solve?

对 brpc 性能做了提升

Problem Summary:
目前的 brpc 网络事件存在两个问题

1. epoll 线程和其他 bthread 具有相同优先级，导致 epoll 线程可能被一小段时间在队列中无响应，引起 worker queue 任务数量分布不均匀，多对一的 steal。
2. 网络事件无差别 signal，增加了系统调用。

What is changed and the side effects?

epoll 线程不在 queue 中，独立出来

Side effects:

• Performance effects(性能影响): 性能平均提升 20%-25%

• Breaking backward compatibility(向后兼容性): 兼容

压测结果

• worker num：9
• core: 64
• arch: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
• 工具 rpc_press
• proto: echo

优化前

• 1w
  
• 5w
  
• 10w
  

优化后

1w

• 5w
  
• 10w
  

压测补充

@chenBright 这里补充了多客户端压测
多客户端压测，使用了 5 个客户端，各发 1w

优化前

5 个采集周期平均值
(370 + 401 + 406 + 392 + 365）/ 5 = 382.2 us

优化后

5 个采集周期平均值
(360 + 324 + 301 + 328 + 319）/ 5 = 326.4

(382.2 - 326.4) / 382.2 = 14.6%

大约有 14.6% 的一个提升

---

Check List:

• Please make sure your changes are compilable(请确保你的更改可以通过编译).
• When providing us with a new feature, it is best to add related tests(如果你向我们增加一个新的功能, 请添加相关测试).
• Please follow Contributor Covenant Code of Conduct.(请遵循贡献者准则).

[wanghenshui]

bool except_state = true;是不是应该在这个循环里

[zhengJade]

是的，之前因为考虑只有一个 tag，设置在外面了，我修改一下

[yanglimingcn]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。
另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

[chenBright]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。

+1。
进一步抽象出一个高优先级队列，使用WorkStealingQueue来实现：

1. 简化实现逻辑。
2. 后续还有高优先级的bthread，只需要设置对应的bthread_attrflags_t即可。

这样是不是更好呢？

[chenBright]

总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

现在只有一个连接，epoll bthread调度不是很频繁。是不是可以起多一些client和epoll bthread再测一下呢？

[wanghenshui]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

1 你说得对，是有点特化，这么改简单点

如果是带优先级的bthread 可能就得改调度了，涉及到任务抢占/饥饿问题，可能麻烦一点

2 你说的也对可能会堆积，但是epoll任务是比较少的

如果改了优先级，会存在你说的优先级高的任务太多导致其他任务饿死

[chenBright]

@zhengJade 延时性能的提升主要是因为epoll bthread优先调度了吗？

[yanglimingcn]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

1 你说得对，是有点特化，这么改简单点

如果是带优先级的bthread 可能就得改调度了，涉及到任务抢占/饥饿问题，可能麻烦一点

这样的特化，可能在一些其它用户哪里有些不适用，要尽量保持和原来的兼容性。

2 你说的也对可能会堆积，但是epoll任务是比较少的

如果改了优先级，会存在你说的优先级高的任务太多导致其他任务饿死

epoll任务的多少，是由客户端那边决定的，这个不太好预期。

[zhengJade]

总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

现在只有一个连接，epoll bthread调度不是很频繁。是不是可以起多一些client和epoll bthread再测一下呢？

[zhengJade]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

@yanglimingcn 我觉得可以增加一个属性来表示高优先级，但是要说明一点，就是 epoll 的 任务被 steal 的前提肯定是有 worker 需要 steal from task_control，所以可证明 worker 自己的 queue 应该没有任务，证明他是空闲的，这个时候应该优先让其响应网络事件，这有两个好处

1. 保证网络任务能够及时响应。
2. 可以让所有的 worker 的 run_q 相对均匀，因为 q 中大量任务来源不是 steal，而是 deal event。
   另一个问题，就是是否会造成堆积：
   如果我们不响应 epoll 就会造成堆积，证明此刻的网络请求数量是大于 brpc 的处理能力的，否则我们不需要通过增加 steal 的次数这种比起 pop queue 更费时间的操作来加快某时刻处理存量 bthread 的能力。这是牺牲了 RT 带来的，感觉不合理。而且 QPS 高时候更容易造成 RT 抖动。

[zhengJade]

总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

现在只有一个连接，epoll bthread调度不是很频繁。是不是可以起多一些client和epoll bthread再测一下呢？

好的，我再测试一下多 client 的效果

[zhengJade]

@zhengJade 延时性能的提升主要是因为epoll bthread优先调度了吗？

@chenBright
从理论上看应该有两方面原因

1. epoll 响应更及时，导致整个 brpc 的处理优先级逻辑发生了变化，以前是所有的 worker 尽量先处理完所有的任务，才能保证有新的 event 进来，当然，没处理完也有会，这取决于是否 steal 到了 epoll 任务，这带来的变化就是，所有空闲的 worker 会立刻拿到 epoll，然后填充自己的 queue，这样可以保证，每个 worker 的 queue 都有一定量的任务，减少 steal 的频率。
2. 任务分布均匀后，wait 的频率降低，可以降低 signal 的频率，只有有任务等待在通知。减少系统调用。

[zhengJade]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

1 你说得对，是有点特化，这么改简单点

如果是带优先级的bthread 可能就得改调度了，涉及到任务抢占/饥饿问题，可能麻烦一点

2 你说的也对可能会堆积，但是epoll任务是比较少的

如果改了优先级，会存在你说的优先级高的任务太多导致其他任务饿死

@wanghenshui
是的，当前的改动是特化的，因为目前我只分析出了 epoll 这种任务同优先级带来的问题，所以就只修改了 epoll。
我们是可以增加一个 priority queue，这样可以对使用 bthread 的人开发增加更多的可能性，但是还需要完善，像你说的，随意使用 priority queue 可能会带来饥饿问题，在这个策略没想好之前，可以通过限制 queue 的大小，来一定程度保证不会饥饿，或者不开放这个接口，是 private 的，只作为内部使用。

[yanglimingcn]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

@yanglimingcn 我觉得可以增加一个属性来表示高优先级，但是要说明一点，就是 epoll 的 任务被 steal 的前提肯定是有 worker 需要 steal from task_control，所以可证明 worker 自己的 queue 应该没有任务，证明他是空闲的，这个时候应该优先让其响应网络事件，这有两个好处

1. 保证网络任务能够及时响应。
2. 可以让所有的 worker 的 run_q 相对均匀，因为 q 中大量任务来源不是 steal，而是 deal event。
   另一个问题，就是是否会造成堆积：
   如果我们不响应 epoll 就会造成堆积，证明此刻的网络请求数量是大于 brpc 的处理能力的，否则我们不需要通过增加 steal 的次数这种比起 pop queue 更费时间的操作来加快某时刻处理存量 bthread 的能力。这是牺牲了 RT 带来的，感觉不合理。而且 QPS 高时候更容易造成 RT 抖动。

// Find next task to run, if none, switch to idle thread of the group.

#ifndef BTHREAD_FAIR_WSQ
const bool popped = g->_rq.pop(&next_tid);
#else
const bool popped = g->_rq.steal(&next_tid);
#endif

我看这块的代码是把任务的调度反转了，能达到先执行epoll的目的？

[wwbmmm]

• epoll 线程和其他 bthread 具有相同优先级，导致 epoll 线程可能被一小段时间在队列中无响应，引起 worker queue 任务数量分布不均匀，多对一的 steal。
• 网络事件无差别 signal，增加了系统调用。

能否分别测一下这两个优化各自提升多少性能呢？
我觉得第二个可能更重要一些，而且也更通用，可以把第二个优化单独提一个PR，这样更容易合入

[zhengJade]

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

@yanglimingcn 我觉得可以增加一个属性来表示高优先级，但是要说明一点，就是 epoll 的 任务被 steal 的前提肯定是有 worker 需要 steal from task_control，所以可证明 worker 自己的 queue 应该没有任务，证明他是空闲的，这个时候应该优先让其响应网络事件，这有两个好处

1. 保证网络任务能够及时响应。
2. 可以让所有的 worker 的 run_q 相对均匀，因为 q 中大量任务来源不是 steal，而是 deal event。
   另一个问题，就是是否会造成堆积：
   如果我们不响应 epoll 就会造成堆积，证明此刻的网络请求数量是大于 brpc 的处理能力的，否则我们不需要通过增加 steal 的次数这种比起 pop queue 更费时间的操作来加快某时刻处理存量 bthread 的能力。这是牺牲了 RT 带来的，感觉不合理。而且 QPS 高时候更容易造成 RT 抖动。

// Find next task to run, if none, switch to idle thread of the group.

#ifndef BTHREAD_FAIR_WSQ const bool popped = g->_rq.pop(&next_tid); #else const bool popped = g->_rq.steal(&next_tid); #endif

我看这块的代码是把任务的调度反转了，能达到先执行epoll的目的？

这里我应该没修改过吧，我是把 epoll 的 tid 单独提取出来了，优先 steal 这个 tid

能否在bthread这个层面上，创建协程的时候设置一个属性，使它具有更高的优先级呢？现在这里专门设置了epoll_XXX，感觉有点特化。 另外，总是让epoll的bthread优先调度的话，会不会造成堆积很多任务的情况呢？

@yanglimingcn 我觉得可以增加一个属性来表示高优先级，但是要说明一点，就是 epoll 的 任务被 steal 的前提肯定是有 worker 需要 steal from task_control，所以可证明 worker 自己的 queue 应该没有任务，证明他是空闲的，这个时候应该优先让其响应网络事件，这有两个好处

1. 保证网络任务能够及时响应。
2. 可以让所有的 worker 的 run_q 相对均匀，因为 q 中大量任务来源不是 steal，而是 deal event。
   另一个问题，就是是否会造成堆积：
   如果我们不响应 epoll 就会造成堆积，证明此刻的网络请求数量是大于 brpc 的处理能力的，否则我们不需要通过增加 steal 的次数这种比起 pop queue 更费时间的操作来加快某时刻处理存量 bthread 的能力。这是牺牲了 RT 带来的，感觉不合理。而且 QPS 高时候更容易造成 RT 抖动。

// Find next task to run, if none, switch to idle thread of the group.

#ifndef BTHREAD_FAIR_WSQ const bool popped = g->_rq.pop(&next_tid); #else const bool popped = g->_rq.steal(&next_tid); #endif

我看这块的代码是把任务的调度反转了，能达到先执行epoll的目的？

我应该没有修改过这个，我是把 epoll 的 tid 提取出来了，然后优先 steal 这个，来达到优先执行 epoll 的目的

[zhengJade]

• epoll 线程和其他 bthread 具有相同优先级，导致 epoll 线程可能被一小段时间在队列中无响应，引起 worker queue 任务数量分布不均匀，多对一的 steal。
• 网络事件无差别 signal，增加了系统调用。

能否分别测一下这两个优化各自提升多少性能呢？ 我觉得第二个可能更重要一些，而且也更通用，可以把第二个优化单独提一个PR，这样更容易合入

较少 signal 这个我单独优化过，基本没什么提升，然后分析了原因才发现是因为压力大的时候，Q 其实是不平均的，直接的一个原因就是 epoll 的 tid 有时候会很难被 steal 到，这导致所有的 worker 呈现出，要做完当前所有的任务才可以进行 epoll，在某一瞬间导致有些 worker 进入了 wait 状态，然后整体就看起来，worker 没有 wait 状态的时间很少很少，所以就是没啥作用，于是才想着更改 epoll 的优先级

[zhengJade]

最近新春，公司太忙了，没时间搞这个 PR (><)，等我这边喘口气，改成优先队列，然后多客户端再测试一次

[wwbmmm]

如果网络事件非常频繁的话，是不是可以直接让epoll thread不切走呢？比如把这里: https://github.com/apache/brpc/blob/master/src/brpc/socket.cpp#L2265
改成bthread_start_background是否也可以提升性能呢？

[rowe0x]

优化前后长尾延迟没看到明显的变化？

[zhengJade]

2. bthread_attrflags_t

如果网络事件非常频繁的话，是不是可以直接让epoll thread不切走呢？比如把这里: https://github.com/apache/brpc/blob/master/src/brpc/socket.cpp#L2265 改成bthread_start_background是否也可以提升性能呢？

如果不切走，那非 epoll worker 是不是只能通过 steal 的方式来执行任务了？，队列更不均匀

[zhengJade]

优化前后长尾延迟没看到明显的变化？

长尾是指？

[zhengJade]

PR #2907 单独实现了第二个优化，看起来更优雅一些。 第一个优化可以再讨论一下 @chenBright

@zhengJade #2907 已经合了，可以rebase master更新一下这个PR吗？

可以再测一下，观察#2897 加的指标，看看epoll调度是否变快了吗？

@chenBright 以下是 5w QPS，3 客户端，压了一段时间后 rt， p9999，readQPS 的表现
更新前

更新后

可以看到的是，rt 上有很小幅度的上升，但是 p9999 会更好也会更稳定，同时 readQPS 也更高，因此 RT 有一点小幅度上升是合理的。

[chenBright]

如果确实希望epoll bthread 优先处理，把它启动的bthread_start_urgent变成可配置的bthread_start_urgent/background可行吗

这里的bthread_start_urgent是精心设计的吧，cache局部性更优。
直接配成bthread_start_backgruond好像不太合适，epoll bthread相当于独占线程了？
最后一个事件处理使用bthread_start_urgent，之前的事件处理使用bthread_start_backgruond，这样是不是好一点？

@chenBright 这里如何得知是最后一个事件呢

目前没法知道。

但是应该也会有类似的问题，bthread_start_backgruond出的bthread和epoll bthread也不一定能得到及时的调度。

[chenBright]

LGTM

@wwbmmm @yanglimingcn 有时间再看看。

[zhengJade]

LGTM

@wwbmmm @yanglimingcn 有时间再看看。

这个还有希望合进去嘛

[chenBright]

LGTM
@wwbmmm @yanglimingcn 有时间再看看。

这个还有希望合进去嘛

@wwbmmm @yanglimingcn ping

[wwbmmm]

所有线程都访问这个是否会造成全局竞争？

[zhengJade]

所有线程都访问这个是否会造成全局竞争？
@wwbmmm
这里的 _priority_qs 我记得本身就是线程安全的

[wwbmmm]

不是说线程安全的问题，我的意思是这个可能影响性能。我不确定，因为实际场景有很多，可能在你的场景里这个性能不是问题，但是在某些场景里可能会有问题，比如event_dispatcher_num很大，有很多epoll thread的情况？

[zhengJade]

同一个 tag 下的 worker 肯定会存在竞争的，这个应该算是预期之内，性能损失量级跟下文的 g->_rq.steal(tid) 相当，原来 steal 的竞争产生的损失约为 N * M（N 为 tag 数量，常数级，M 为 g->_rq.steal(tid) 单次时间），现在为 (N + 1) * M

[chenBright]

@zhengJade 我理解，原来的steal在遍历worker的时候起始点和步长不一样，遍历的worker会错开。但是现在变成了steal同一个，tag内的竞争变激烈了，那么这里的M（g->_rq.steal(tid) 单次时间）也会变大了。

[legionxiong]

多 client 场景中会出现大片 RPC 超时
[E110]Fail to connect Socket ... : Connection timed out
[E1008]Reached timeout=2500ms

[wwbmmm]

LGTM

[yanglimingcn]

LGTM

如果确实希望epoll bthread 优先处理，把它启动的bthread_start_urgent变成可配置的bthread_start_urgent/background可行吗

这里的bthread_start_urgent是精心设计的吧，cache局部性更优。

直接配成bthread_start_backgruond好像不太合适，epoll bthread相当于独占线程了？

最后一个事件处理使用bthread_start_urgent，之前的事件处理使用bthread_start_backgruond，这样是不是好一点？

@zhengJade @chenBright 我问一下，如果把epoll变成bthread_start_urgent和按照优先级队列处理epoll，最终执行的逻辑上看有什么区别呢？

[chenBright]

我问一下，如果把epoll变成bthread_start_urgent和按照优先级队列处理epoll，最终执行的逻辑上看有什么区别呢？

@yanglimingcn ”把epoll变成bthread_start_urgent“指的是哪部分？现在epoll bthread处理都是bthread_start_urgent处理读事件的吧。

[yanglimingcn]

我问一下，如果把epoll变成bthread_start_urgent和按照优先级队列处理epoll，最终执行的逻辑上看有什么区别呢？

@yanglimingcn ”把epoll变成bthread_start_urgent“指的是哪部分？现在epoll bthread处理都是bthread_start_urgent处理读事件的吧。

我大概理解了，如果用bthread_start_background处理读事件，epoll会一直占有一个worker，这个PR不会让epoll一直占用一个worker，但是也会让epoll线程优先调度。

[chenBright]

@zhengJade Thank you for your contribution!

[zhengJade]

多 client 场景中会出现大片 RPC 超时 [E110]Fail to connect Socket ... : Connection timed out [E1008]Reached timeout=2500ms

@legionxiong 这里是多少 client 呢，还有，是否有其他配置变动呢，比如说配置了多少 worker

[zhengJade]

我问一下，如果把epoll变成bthread_start_urgent和按照优先级队列处理epoll，最终执行的逻辑上看有什么区别呢？

@yanglimingcn ”把epoll变成bthread_start_urgent“指的是哪部分？现在epoll bthread处理都是bthread_start_urgent处理读事件的吧。

我大概理解了，如果用bthread_start_background处理读事件，epoll会一直占有一个worker，这个PR不会让epoll一直占用一个worker，但是也会让epoll线程优先调度。

是这样的，要让任务分在不同的 worker 而不能通过 steal 的方式

[zhengJade]

@zhengJade Thank you for your contribution!

PR 有问题直接圈我来修，最近换工作有点忙，才来看

[chenBright]

多 client 场景中会出现大片 RPC 超时 [E110]Fail to connect Socket ... : Connection timed out [E1008]Reached timeout=2500ms

@zhengJade 可能是#3030 这个问题导致的。