1. 从Github master主干上获得最新版本，按照说明文件进行编译。如上所述，网络框架是Netty5，基于最新的HTTP/2.

2. 测试例子为 RouteGuideClient

3. IDL为 route_guide.proto

4. 选择其中getFeature方法，去除不用的语句和屏幕输出，进行10,000次同步调用。

   TestClientSync client = new TestClientSync("localhost", 8980);  try {    final long startTime = System.nanoTime();      for (int i = 0; i < 10000; i++)      client.getFeature(409146138, -746188906);      final long endTime = System.nanoTime();    info("method 1 : " + (endTime - startTime));  }

   
   

   public void getFeature(int lat, int lon) {    try {      Point request = Point.newBuilder().setLatitude(lat).setLongitude(lon).build();      Feature feature = blockingStub.getFeature(request);    } catch (RuntimeException e) {      logger.log(Level.WARNING, "RPC failed", e);      throw e;    }  }

   
   

多次执行，记录需要的时间。

gRPC还有一种非阻塞的调用方法，不过因为时间有限，为了简化测试，我只用标准的server启动的方式，asyncStub在大并发访问时出错，用时也较长，故这次测试没有这种方法的结果数据。

Thrift http://thrift.apache.org

1. 从Apache网站获得最新的0.9.2版本，本机编译获得C的编译器和Java运行环境。

2. 测试例子为 JavaClient.java

3. IDL tutorial.thrift

   int diff;  final long startTime = System.nanoTime();  try {    for (int i = 0; i < 10000; i++)       diff = client.calculate(1, work);  } catch (InvalidOperation io) {    System.out.println("Invalid operation: " + io.why);  }  final long endTime = System.nanoTime();  System.out.println("method 1 : " + (endTime - startTime));

   
   

Thrift采用经典的基于网络端口的RPC，效率最高，在最后的总结数据可以看到。

</div> </div>

Wildfly 8.2.0 http://www.wildfly.org

Wildfly是JBossAS改名后的JBoss应用服务器，实现了完整的JavaEE规范。我们知道JavaEE中远程RPC调用是在EJB规范中定义的。我们这里就是要测试Wildlfy中的远程EJB调用能力， 选用的Wildfly8.2是目前发布的最新稳定版本。这个版本也支持端口多路服用，也就是EJB远程调用是通过HTTP端口复用来进行的，利用HTTP的Upgrade机制做到二进制运行时刻协商升级。 尽管不是纯粹的HTTP/2，但也运行机理也相差无几。

1. 测试例子选用jboss-eap-quickstarts项目中的远程ejb调用例子 RemoteEJBClient.java

2. 纯Java的RPC方案好处是不需要再有IDL文件定义和编译生成代码的过程，只要商议好接口就可以了

   public interface RemoteCalculator {      int add(int a, int b);  }

   
   

   int sum=0;  final long startTime = System.nanoTime();    for (int i = 0; i < 10000; i++) {           sum = statelessRemoteCalculator.add(a, b);  }    final long endTime = System.nanoTime();  System.out.println("method 1 : " + (endTime - startTime));

   
   

调用无状态的SessionBean方法10,000次,对应的远程EJB服务是部署在Wildfly应用服务器中的EJB。

</div> </div>

Dubbo 2.5.4-SNAPSHOT https://github.com/alibaba/dubbo

Dubbo是阿里集团开源的一个极为成员的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样 的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。

1. 采用github中master主干，目前版本是 2.5.4-SNAPSHOT

2. 测试例子选用其中的demo进行修改 DemoAction.java

   public interface DemoService {   String sayHello(String name);  }

   
   

   final long startTime = System.nanoTime();    for (int i = 0; i < 10000; i ++) {      try {       String hello = demoService.sayHello("world" + i);      } catch (Exception e) {          e.printStackTrace();      }  }  final long endTime = System.nanoTime();  System.out.println("method 1 : " + (endTime - startTime));

   
   

调用完毕后查看输入log文件获得运行时间。

</div> </div>

数据结果。

最终经过4轮测试，不间断运行10,000次远程RPC调用后的结果如下：

</div>

我们可以看到Thrift的效率最高，大概领先一个数量级。而其他三个项目的性能数据在同数量级中，由高到低分别为dubbo, wildfly和gRPC。

需要说明的有以下几点：

1. 为了简化测试，我并没有选择同样的调用接口，而是顺手用了项目自带的，方便修改的示例程序。其中gRPC和Thrift的接口有对象传递，稍微复杂一些。

2. 不是严格的性能测试流程，比如没有做预热过程，以及测试都运行在我的桌面用机上，没有完全恢复成“干净”的状态。

3. 都是简单的服务器单一进程实例，标准示范例子，没有做特别优化和设置多个线程池之类的。而客户端调用也是最简单的阻塞式多次调用压力测试。应该是用多个机器多连接，多个线程，以及异步非阻塞的调用多种环境进行测试更为客观，有机会再继续完善。

4. 之前没有看到过基于HTTP/2的RPC调用性能比较，理论上是应该低于经典的基于端口的RPC方案的。这个测试结果可以简单印证这个猜想。 Thrift的数据遥遥领先.gRPC还在开发之中，基于的Netty还是alpha版本，而且非阻塞的方式还没有最后的数据。我想耐心一些，给gRPC 一些时间，它会让我们惊艳的。

5. Wildfly表现良好，要知道它的服务端可是完整的JavaEE服务器啊。不过有时间的化，我试试看经典RMI连接的效率如何，要是能和thrift一个数量级就更好了。

6. dubbo性能也很出色，而且协议层可以更换的话，应该还能有更大提升。

7. 我的测试在一台过时的笔记本上，受条件限制，没有先进的G级网络和多台服务器进行标准化性能测试。如果哪位在互联网或者企业工作的朋友有条件，也愿意充分完成这个测试，请和我联系，我会完整介绍我的测试搭建环境，共享代码，并帮助完成。我想那个结果会更有意义。

</div> </div> 来自：http://www.useopen.net/blog/2015/rpc-performance.html

 本文由用户 f663x 自行上传分享，仅供网友学习交流。所有权归原作者，若您的权利被侵害，请联系管理员。

 转载本站原创文章，请注明出处，并保留原始链接、图片水印。

 本站是一个以用户分享为主的开源技术平台，欢迎各类分享！

 本文地址：https://www.open-open.com/lib/view/open1426302068107.html

RPC WEB服务/RPC/SOA