search

baidu / sofa-pbrpc

A light-weight RPC implement of google protobuf RPC framework.
Other
2.13k stars 655 forks source link

About ioService #166

Closed DerrickChina closed 7 years ago

DerrickChina commented 7 years ago

  1. 从v1.1.0到v1.1.1版本中，我发现把共用的ioService修改成了pool，想咨询下修改的初衷是什么？性能优化？之前公用是否要加strand才更安全

  2. 查看修改后的pool，有点疑问。现在是每次来一个请求就从pool中取一个ioservice来，然后这个ioService来处理这条链路。对于大量短链接的请求，如果短链接断链不均匀，那么最后有可能存在某个ioService上的链路多，其它少

  3. 对于boost了解不多，理解有误请指正，谢谢

cyshi commented 7 years ago
  1. 增加了io_service_pool主要是出于对吞吐要求比较高的场景设计，但需要注意的是io_service的线程之间并没有请求的负载均衡，所以可能会造成线程任务调配不均，用户需要针对使用场景去斟酌。一般对吞吐要求在百万QPS以下时，使用单个io_service即可，这样对存在长尾请求的场景最友好，延迟分布最合理
  2. 我理解你的意思是一个连接被一个io_service的线程处理？负载不均的情况见1的说明
zd-double commented 7 years ago

strand是保证多个线程并发时回调会被同步执行。rpc通过代码保证了线程安全，所以没有加strand。

DerrickChina commented 7 years ago
  1. 非常感谢两位的解释
  2. 我看到代码中有token的获取，不加strand是安全的 3.我现在的场景是短链接大图片上传处理，大小在200k到2m之间，并发数最多50tps，我觉得我这种场景共用tps就可以了。虽然事件到来的时候有可能出现一哄而上。我自己先测试下，看看效果
cyshi commented 7 years ago

@zd-double 有时间的话 是不是在wiki中补充一个单io_service和多io_service的延迟CDF

请求中最好能模拟一些场景，比如存在长尾请求，链接不断的断开释放等