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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
