Java性能分析比较：远程调用方法

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

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

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

　　测试项目：

　　①RMI:用Spring3集成发布。

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

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

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

　　测试结果：

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

　　结论：

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

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

　　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倍。

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

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

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

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

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

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

　　测试项目：

　　①RMI:用Spring3集成发布。

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

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

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

　　测试结果：

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

　　结论：

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

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

　　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倍。

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

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

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

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

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