最近对rpcx做的一些优化以及一些优化尝试

[utterances-bot]

最近对rpcx做的一些优化以及一些优化尝试

最近在做2022 Go生态圈 rpc 框架 Benchmark之前，专门花了一星期时间，对rpcx进行了重点的优化，这篇文章专门记录一下几个重要的优化点，供大家参考。

https://colobu.com/2022/08/25/some-small-optimizations-of-rpcx/

[wzhsh90]

线程池 ants 比较可以

[fengqi]

handler的方式好处确实挺多的，在我这里有个需求就是，服务从单体到拆分过渡，从http json到tcp rpc过渡，过渡期想提供http json+tcp rpc双协议，handler方式就会简单很多，90%的代码是可以复用的，router层简单变动下就可以了，代码组织方式不会有太大的差异

[fengqi]

线程池 ants 比较可以

较高版本golang，ants已经没有性能优势了，而且怕高并发时触发一些临界bug

有数据支撑吗

[lesismal]

rpcx或许还可以做一些zero copy的优化。 现在是bufio reader，每个message都是新的内存。 每次读取一个message，都是先读到bufio reader的buffer里，然后再copy到message自己的buffer里。如果优化，可以for { read to same buffer }，读到一个完整message直接用这个 same buffer 的 sub buffer 去 unmarshal，然后传递给handler。这样的话仍然需要一点reflect.New但是影响不大，却可以节约一些copy。当然，same buffer每次取出1-n个message后，如果剩余字节不足1个message、需要移动到buffer头部，但可能也比copy要省一些。 这样优化下来，其实arpc这种handler形式可能就没有性能优势了。

arpc的读取跟rpcx现在是类似的，也是先读到bufio reader里然后每次新的message、copy过去。我最近琢磨要不要优化，但是arpc的功能不限于rpc，而且之前已经支持了异步call、notify、不限于单一种类序列化之类的，handler返回也不等于context的生命周期结束，所以不好去做、暂时打算放弃了。 但如果只专注于rpc场景、为了性能定制则不会被这些通用功能限制，性能或许还有一些提升空间。

[guded]

我倒是不喜欢handler的方式，入参出参不明确了