我们可以看到Thrift的效率最高，大概领先一个数量级。而其他三个项目的性能数据在同数量级中，由高到低分别为JBossEAP, dubbo, wildfly和gRPC。
需要说明的有以下几点：
- 为了简化测试，我并没有选择同样的调用接口，而是顺手用了项目自带的，方便修改的示例程序。其中gRPC和Thrift的接口有对象传递，稍微复杂一些。
- 不是严格的性能测试流程，比如没有做预热过程，以及测试都运行在我的桌面用机上，没有完全恢复成"干净"的状态。
- 都是简单的服务器单一进程实例，标准示范例子，没有做特别优化和设置多个线程池之类的。而客户端调用也是最简单的阻塞式多次调用压力测试。应该是用多个机器多连接，多个线程，以及异步非阻塞的调用多种环境进行测试更为客观，有机会再继续完善。
- 之前没有看到过基于HTTP/2的RPC调用性能比较，理论上是应该低于经典的基于端口的RPC方案的。这个测试结果可以简单印证这个猜想。Thrift的数据遥遥领先.gRPC还在开发之中，基于的Netty还是alpha版本，而且非阻塞的方式还没有最后的数据。我想耐心一些，给gRPC一些时间，它会让我们惊艳的。
- Wildfly表现良好，要知道它的服务端可是完整的JavaEE服务器啊。不过有时间的化，我试试看经典RMI连接的效率如何，要是能和thrift一个数量级就更好了。
- dubbo性能也很出色，而且协议层可以更换的话，应该还能有更大提升。
- 我的测试在一台过时的笔记本上，受条件限制，没有先进的G级网络和多台服务器进行标准化性能测试。如果哪位在互联网或者企业工作的朋友有条件，也愿意充分完成这个测试，请和我联系，我会完整介绍我的测试搭建环境，共享代码，并帮助完成。我想那个结果会更有意义。
Read full article from RPC框架的性能比较 | 鸟窝
No comments:
Post a Comment