You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brpc.apache.org by GitBox <gi...@apache.org> on 2021/06/15 03:13:22 UTC
[GitHub] [incubator-brpc] rpbear88 opened a new issue #1434: 如何使用brpc实现run-to-completion模型？
rpbear88 opened a new issue #1434:
URL: https://github.com/apache/incubator-brpc/issues/1434
按我的理解，bthread是brpc设计的核心，而正如[bthread or not](https://github.com/apache/incubator-brpc/blob/master/docs/cn/bthread_or_not.md)中提到的，由于bthread本身的开销大概在10us左右，如果计算任务只要不足10us那么使用bthread就是一件不太值得的事情。
目前存储IO在闪存介质上已经进入到了10-100us的性能水平，这还是底层IO的耗时，如果使用SPDK等异步IO框架，实际上在io submit这一阶段的耗时已经远远低于10us了，所以业界普遍采用了在一个线程内使用run-to-completion的模型来处理如下某个用户请求所涉及的各个步骤：
1. 查询RDMA接收/发送队列是否有报文要处理，如果有则在当前线程直接处理
2. 查询SPDK的completion queue是否有任务处理， 如果有则在当前线程直接处理
3. 任务如果有IO需求，则提交给SPDK队列后返回
4. 任务结束后提交回应给RDMA队列后返回
整个的操作是在一个线程上运行的，虽然不能利用多核的处理能力，但单核的处理能力可以跑满，在保证上述多个步骤都以极低延迟进行时，整个请求的处理时间将非常短。
我们在使用brpc的过程中确实遇到了一些问题，在将某个任务从接入层传递给存储层时至少消耗10-20us的bthread开销，由于我们追求极低的存储延迟，这是不可接受的。而这一情况在我们使用`-usercode_in_pthread`后也没有好转。
所以如果我们希望在brpc框架上使用run-to-completion模型的话，官方是否有建议的方式呢？我们计划的方式是在接入层收到请求后(此时还是运行在bthread中)，将创建的状态机扔进一个高性能的消息队列TaskQueue，我们会为每一个core创建一个pthread来looping这个TaskQueue，至少除了数据接收/发送(RDMA处理)部分以外的其他部分都可以运行在一个thread内采用run-to-completion的方式完成。
还有一种方式，我们想基于brpc实现一种poller的注册机制，比如braft中，各个apply的task可以注册到我们的poller thread上，当事件触发后在poller thread上进行原地调用，但是目前来看对源码的改动会比较大。
很想倾听下百度的朋友在这个问题上的解决方案，谢谢。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org
[GitHub] [incubator-brpc] sitr666 commented on issue #1434: 如何使用brpc实现run-to-completion模型？
Posted by GitBox <gi...@apache.org>.
sitr666 commented on issue #1434:
URL: https://github.com/apache/incubator-brpc/issues/1434#issuecomment-946646116
同样的需求。希望能够实现这样一种模型：brpc的每个io thread上实现run-to-completion模型，rpc call 不推到worker thread，把灵活性留个用户，用户可以自己控制什么时候切线程，控制线程的负载均衡，自己保证调用都是非阻塞的，这样用户能获得极致的性能，还可以在线程上集成N:1的协程。对于追求us级别极致延迟的服务很有用。 不知道这个模型在brpc中如何实现？brpc在线程模型的策略上是可以定制扩展的吗？有兴趣的朋友可以讨论一下。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org
[GitHub] [incubator-brpc] jamesge edited a comment on issue #1434: 如何使用brpc实现run-to-completion模型？
Posted by GitBox <gi...@apache.org>.
jamesge edited a comment on issue #1434:
URL: https://github.com/apache/incubator-brpc/issues/1434#issuecomment-946979448
> 同样的需求。希望能够实现这样一种模型：brpc的每个io thread上实现run-to-completion模型，rpc call 不推到worker thread，把灵活性留个用户，用户可以自己控制什么时候切线程，控制线程的负载均衡，自己保证调用都是非阻塞的，这样用户能获得极致的性能，还可以在线程上集成N:1的协程。对于追求us级别极致延迟的服务很有用。 不知道这个模型在brpc中如何实现？brpc在线程模型的策略上是可以定制扩展的吗？有兴趣的朋友可以讨论一下。
这个也许可以在启动的那个bthread上扩展一下bthread_attr_t，通过特殊flag让bthread原地运行。不过brpc整体上是为偏应用层面的场景设计的，如果是底层存储（如虚机云磁盘）或是高频交易等特别在意延时的场景，要冲击硬件极限估计有点困难，从epoll/kqueue直接开始写可能上限更高。不过，我也想说明一下，如果实际执行的worker代码不能做到完全异步（linux的IO就不行），其实在一个线程中从头到尾运行未必是最优的，也许在测试环境中不卡不拥塞时各种指标很好，但实际运行时不一定完全是这样。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org
[GitHub] [incubator-brpc] jamesge commented on issue #1434: 如何使用brpc实现run-to-completion模型？
Posted by GitBox <gi...@apache.org>.
jamesge commented on issue #1434:
URL: https://github.com/apache/incubator-brpc/issues/1434#issuecomment-946979448
> 同样的需求。希望能够实现这样一种模型：brpc的每个io thread上实现run-to-completion模型，rpc call 不推到worker thread，把灵活性留个用户，用户可以自己控制什么时候切线程，控制线程的负载均衡，自己保证调用都是非阻塞的，这样用户能获得极致的性能，还可以在线程上集成N:1的协程。对于追求us级别极致延迟的服务很有用。 不知道这个模型在brpc中如何实现？brpc在线程模型的策略上是可以定制扩展的吗？有兴趣的朋友可以讨论一下。
这个也许可以在启动的那个bthread上扩展一下bthread_attr_t，通过特殊flag让bthread原地运行。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org
[GitHub] [incubator-brpc] sitr666 commented on issue #1434: 如何使用brpc实现run-to-completion模型？
Posted by GitBox <gi...@apache.org>.
sitr666 commented on issue #1434:
URL: https://github.com/apache/incubator-brpc/issues/1434#issuecomment-948314578
> > 同样的需求。希望能够实现这样一种模型：brpc的每个io thread上实现run-to-completion模型，rpc call 不推到worker thread，把灵活性留个用户，用户可以自己控制什么时候切线程，控制线程的负载均衡，自己保证调用都是非阻塞的，这样用户能获得极致的性能，还可以在线程上集成N:1的协程。对于追求us级别极致延迟的服务很有用。 不知道这个模型在brpc中如何实现？brpc在线程模型的策略上是可以定制扩展的吗？有兴趣的朋友可以讨论一下。
>
> 这个也许可以在启动的那个bthread上扩展一下bthread_attr_t，通过特殊flag让bthread原地运行。不过brpc整体上是为偏应用层面的场景设计的，如果是底层存储（如虚机云磁盘）或是高频交易等特别在意延时的场景，要冲击硬件极限估计有点困难，从epoll/kqueue直接开始写可能上限更高。不过，我也想说明一下，如果实际执行的worker代码不能做到完全异步（linux的IO就不行），其实在一个线程中从头到尾运行未必是最优的，也许在测试环境中不卡不拥塞时各种指标很好，但实际运行时不一定完全是这样。
谢谢回复，如果可以让bthread在指定的线程原地运行，不跨线程，是不是就相当于N:1的协程了？这的确和业务场景有关。RPC的Interface用起来还是很舒服省心的，从epoll开始写做到生产级别稳定好用也并非易事。业内有一些实践已经证明，用户态写裸盘可以做到完全无阻塞调用，在每个IO线程中集成run-to-completion线程模型，one loop per thread，很适合高性能低延迟的场景，毕竟一次nvme io已经不足10 us了，这个尺度下线程调度加上cache miss的综合开销显得就很大了。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org