Java远程调用性能测试

Java远程调用性能测试

http://zwbill.iteye.com/

- by zvane

现在，Java远程调用方法很多，各种方法的优缺点网络上也有很多的参考文章，这次我对几个典型的Java远程调用方法做了一个简单的性能分析比较，可供大家参考。

 

测试环境：CPU：奔腾双核 T4500，内存：DDR3-1067 2G，Web容器：Tomcat6.0.33，操作系统：WinXP-sp3

 

测试项目：

1.RMI:用Spring3集成发布。

2.hessian：用Spring3集成发布到Tomcat容器。

3.Java6 WebService：使用Java6原生WebService和注解，直接用Endpoint.publish发布服务。

4.CXF：用Spring3集成发布到Tomcat容器。

 

测试结果：

 

测试案例	单线程访问	并发访问
请求数	耗时(s)	吞吐量 (每秒处理请求数)	总请求数 （每个线程1000）	并发线程数	耗时(s)	吞吐量 (每秒处理请求数)
RMI	10000	5.91	1693	100000	100	31.77	3148
Hessian	10000	11.13	899	100000	100	/	/
Java6 WebService	10000	18.52	540	100000	100	134.52	743
CXF	10000	27.58	363	100000	100	194.74	514

 

说明：以上测试虽不是非常的精确，但基本能说明一定的问题。每项案例的服务端方法，都是简单方法，接收客户端传递的一个String类型参数，并打印到console。每轮测试取三次时间的平均值。所有单线程访问测试全部完成并正常处理请求，没有请求拒绝情况发生。而并发访问测试，除hessian中途抛异常无法完成，其余均正常完成测试。

 

结论：

1.RMI的性能最高，这已是公认，RMI底层基于Java远程方法协议(JRMP)和对象序列化技术，而JRMP是直接基于TCP/IP协议的封装，在网络上传输2 byte的有效数据，对于TCP而言，总共有478 byte被额外传输，而对于RMI, 1645byte被额外传输。可见RMI的效率还是相当不错的。JavaEE标准的EJB就是基于RMI的调用。

2. hessian是一个轻量级的remoting on http框架。Hessian没有采用WebService标准的SOAP协议，而是自己实现了一种二进制RPC（Remote Procedure Call Protocol，远程过程调用协议）协议。Hessian的设计理念就是简单高效，使用 Hessian 传输数据量比Soap协议要小很多。这也是为什么Hessian的性能要高于WebService。但是，尽管它再简单高效，它始终是基于Http协议上封装的，所以还是比Java的RMI效率要差一些。我看过其他的一些研究测试报告称Hessian在传输少量对象时，比RMI还要快速高效，但传输数据结构复杂的对象或大量数据对象时，较RMI要慢20%左右。这个结论在我的测试中还真没有发现，也许与测试环境或方法有关系吧。

 

3.Java6WebService 和 CXF的性能应该说是基本同级别，前者略高于后者。众所周知WebService是基于Soap协议实现的，而Soap协议是在Http协议基础上的XML定义和封装。所有的请求和响应都要被转化成符合SOAP标准的XML格式。显然这直接会导致效率的降低。

XML格式的协议是一种易读易理解的协议，但并不高效。解析和组装XML协议数据流都需要耗费系统的处理时间，所以，WebService的性能不如Hessian。这里要说一下的是Java6原生的WebService，开发起来非常方便，而且无需额外引入一大堆的Jar包。性能又强于CXF，至于Axis2和Axis1就更不用说，已经有很多测试表明CXF的性能是Axis2的2倍以上，是Axis1的2-6倍。

 

4.那么既然RMI性能那么好，为什么我们需要那么多其他的远程调用方式呢？这个问题又引发到了一个原始的真理。越原始越底层的技术效率就越高，但局限性也就越大。RMI是Java的特性，那么它必须基于JVM运行，也就是说RMI无法跨语言运行。而WebService就不同了，Soap是基于标准Http协议的，是一种与语言无关的字符级协议，所以它可以更好的实现异构系统的通信。这在我们现实环境中是非常有用的，相信大家还是WebService用的比较多点吧。

 

不足：这次的测试，还是存在很多不足之处。

1.Hessian的并发测试时，跑到中途大约300-400次调用时就抛异常中断了，具体原因还没来得及仔细分析。不知道是否与Spring集成或测试方法有关系。

2.另外，这次的远程方法都是简单处理方法，而在复杂方法调用环境下测试情况如何还需更进一步研究。

3.下一步，如果有时间，可以发布到Linux环境测试一下各项性能。

评论

8 楼 rkikbs 2013-04-16  

一般都用apache-jmeter或者soapui

7 楼 Sean220 2012-05-07  

1.Hessian的并发测试时，跑到中途大约300-400次调用时就抛异常中断了，具体原因还没来得及仔细分析。不知道是否与Spring集成或测试方法有关系。

Hessian是http短连接，这种异常应该是大量并发线程下达到了系统可开的最大连接数，调低服务端的SO_LINGER数字，否则大量短连接在TIME_WAIT状态等待关闭。

6 楼 zwbill 2011-12-14  

这个我是直接写的测试用例代码进行测试的，这里引用另一篇文章中的结论补充一下，该文中说道：为了仅测试数据传输和编码、解码的时间，客户端和服务端都使用了缓存，对象只需实例化一次。但是，测试结果显示，web service的效率还是要比其他通讯协议慢10倍。
如果考虑到多个引用指向同一对象的传输情况，web service要落后更多。因为RMI，Hessian等协议都可以传递引用，而web service有多少个引用，就要复制多少份对象实体。
Web service传输的冗余信息过多是其速度慢的原因之一，监控发现，同样的访问请求，描述相同的数据，web service返回的数据量是hessian协议的6.5倍。另外，WEB SERVICE的处理也很毫时，目前的xml解析器效率普遍不高，处理xml <-> bean很毫资源。从测试结果看，异地调用比本地调用要快，也从侧面说明了其毫时主要用在编码和解码xml文件上。这比冗余信息更为严重，冗余信息占用的 只是网络带宽，而每次调用的资源耗费直接影响到服务器的负载能力。（MS的工程师曾说过，用WEB SERVICE不能负载100个以上的并发用户。）

5 楼 gjlping 2011-12-12  

如果lz能共享测试用例那就更好了。

4 楼 完善自我 2011-12-12  

不错

3 楼 minxinxin2010 2011-12-12  

[u][/u]

引用

[img][/img][url][/url]uo0;/pi9;/p[b][/b][i][/i]

2 楼 hngmduyi 2011-12-12  

楼主是用什么测试工具啊？？

1 楼 hngmduyi 2011-12-12