几种通讯协议的比较

几种通讯协议的比较 
一、综述
 
本文比较了RMIHessianBurlapHttpinvokerweb service5种通讯协议的在不同的数据结构和不同数据量时的传输性能。
 
RMI
java语言本身提供的远程通讯协议,稳定高效,是EJB的基础。但它只能用于JAVA程序之间的通讯。
 
Hessian
Burlapcaucho公司提供的开源协议,基于HTTP传输,服务端不用开防火墙端口。协议的规范公开,可以用于任意语言。
 
Httpinvoker
SpringFramework提供的远程通讯协议,只能用于JAVA程序间的通讯,且服务端和客户端必须使用SpringFramework
 
Web service
是连接异构系统或异构语言的首选协议,它使用SOAP形式通讯,可以用于任何语言,目前的许多开发工具对其的支持也很好。
 

测试结果显示,几种协议的通讯效率依次为:
 
RMI > Httpinvoker >= Hessian >> Burlap >> web service 
RMI
不愧是JAVA的首选远程调用协议,非常高效稳定,特别是在大数据量的情况下,与其他通讯协议的差距尤为明显。
 
HttpInvoker
使用java的序列化技术传输对象,与RMI在本质上是一致的。从效率上看,两者也相差无几,HttpInvokerRMI的传输时间基本持平。
 
Hessian
在传输少量对象时,比RMI还要快速高效,但传输数据结构复杂的对象或大量数据对象时,较RMI要慢20%左右。
 
Burlap
仅在传输1条数据时速度尚可,通常情况下,它的毫时是RMI3倍。
 
Web Service
的效率低下是众所周知的,平均来看,Web Service的通讯毫时是RMI10倍。
 




二、结果分析
 
1
、直接调用
 
直接调用的所有毫时都接近0,这说明程序处理几乎没有花费时间,记录的全部时间都是远程调用耗费的。
 
2
RMI调用
 
与设想的一样,RMI理所当然是最快的,在几乎所有的情况下,它的毫时都是最少的。特别是在数据结构复杂,数据量大的情况下,与其他协议的差距尤为明显。
 
为了充分发挥RMI的性能,另外做了测试类,不使用Spring,用原始的RMI形式(继承UnicastRemoteObject对象)提供服务并远程调用,与SpringPOJO包装成的RMI进行效率比较。结果显示:两者基本持平,Spring提供的服务还稍快些。
 
初步认为,这是因为Spring的代理和缓存机制比较强大,节省了对象重新获取的时间。
 
3
Hessian调用
 
caucho
公司的resin服务器号称是最快的服务器,在java领域有一定的知名度。Hessian做为resin的组成部分,其设计也非常精简高效,实际运行情况也证明了这一点。平均来看,HessianRMI要慢20%左右,但这只是在数据量特别大,数据结构很复杂的情况下才能体现出来,中等或少量数据时,Hessian并不比RMI慢。
 
Hessian
的好处是精简高效,可以跨语言使用,而且协议规范公开,我们可以针对任意语言开发对其协议的实现。目前已有实现的语言有:java, c++, .net, python, ruby。还没有delphi的实现。
 
另外,HessianWEB服务器结合非常好,借助WEB服务器的成熟功能,在处理大量用户并发访问时会有很大优势,在资源分配,线程排队,异常处理等方面都可以由成熟的WEB服务器保证。而RMI本身并不提供多线程的服务器。而且,RMI需要开防火墙端口,Hessian不用。
 
4
Burlap调用
 
Burlap
Hessian都是caucho公司的开源产品,只不过Hessian采用二进制的方式,而Burlap采用xml的格式。
 
测试结果显示,Burlap在数据结构不复杂,数据量中等的情况下,效率还是可以接受的,但如果数据量大,效率会急剧下降。平均计算,Burlap的调用毫时是RMI3倍。
 
我认为,其效率低有两方面的原因,一个是XML数据描述内容太多,同样的数据结构,其传输量要大很多;另一方面,众所周知,对xml的解析是比较费资源的,特别对于大数据量情况下更是如此。
 
5
HttpInvoker调用
 
HttpInvoker
SpringFramework提供的JAVA远程调用方法,使用java的序列化机制处理对象的传输。从测试结果看,其效率还是可以的,与RMI基本持平。
 
不过,它只能用于JAVA语言之间的通讯,而且,要求客户端和服务端都使用SPRING框架。
 
另外,HttpInvoker 并没有经过实践的检验,目前还没有找到应用该协议的项目。
 
6
web service调用
 
       
本次测试选用了apacheAXIS组件作为WEB SERVICE的实现,AXISWEB SERVICE领域相对成熟老牌。
 
为了仅测试数据传输和编码、解码的时间,客户端和服务端都使用了缓存,对象只需实例化一次。但是,测试结果显示,web service的效率还是要比其他通讯协议慢10倍。
 
如果考虑到多个引用指向同一对象的传输情况,web service要落后更多。因为RMIHessian等协议都可以传递引用,而web service有多少个引用,就要复制多少份对象实体。
 
Web service
传输的冗余信息过多是其速度慢的原因之一,监控发现,同样的访问请求,描述相同的数据,web service返回的数据量是hessian协议的6.5倍。另外,WEB SERVICE的处理也很毫时,目前的xml解析器效率普遍不高,处理xml <-> bean很毫资源。从测试结果看,异地调用比本地调用要快,也从侧面说明了其毫时主要用在编码和解码xml文件上。这比冗余信息更为严重,冗余信息占用的只是网络带宽,而每次调用的资源耗费直接影响到服务器的负载能力。(MS的工程师曾说过,用WEB SERVICE不能负载100个以上的并发用户。)
 
测试过程中还发现,web service编码不甚方便,对非基本类型需要逐个注册序列化和反序列化类,很麻烦,生成stub更累,不如spring + RMI/hessian处理那么流畅简洁。而且,web service不支持集合类型,只能用数组,不方便。

 

 

基于HTTP的轻量级远程调用协议- hessian

 简单就是美,介绍基于HTTP的轻量级远程调用协议- hessian

远程方法调用有很多途径:RMIHTTP InvokerXML-RPCwebservice)等。这里再介绍一个由caucho公司开发的hessian协议,比起上面所列的协议它的特点是:简单,高效。它采用apache授权。


它有多简单?请看下面例子:

服务端
1
)为服务创建一个接口:
  public interface BasicAPI {
      public String hello();
  }

2
)实现这个接口,注意它是作为一个servlet实现的:
  public class BasicService extends HessianServlet 
  implements BasicAPI {
      public String hello() {
          return "Hello, world";
      }
  }

3
)发布这个服务:
web.xml中登记并映射BasicService ,比如映射到 /hello 这个url。这个过程与普通的servlet没有区别。
注意:服务端需要Hessian.jar类库
客户端的调用
   String url = " http://localhost/hello";
  HessianProxyFactory factory = new HessianProxyFactory();
  BasicAPI basic = (BasicAPI) factory.create(BasicAPI.class, url);
  System.out.println(basic.hello());

    
注意:客户端需要BasicAPI.classHessian.jar类库。

 

 

序列化:serializable,hessian,protobuf性能对比

通信调用 2010-06-13 14:02:40 阅读202 评论0   字号:大中小 订阅

分布式应用系统中,系统之间的通讯的质量决定了系统的可用性,当然很多可以选择的技术:XML-RPCRMISOAPCORBAJMSEJBNIO等。在传输数据的过程中,数据包越小,占用的带宽就越少,同等条件下资源利用就会越小。目前基于SOAESB系统中,很多采用NIO来传输数据,就涉及到对象的序列化的问题。

    本文主要讨论jdk自带序列化,hessianGoogleprotobuf之间的性能比较,主要指标有以下三个:(执行序列化测试1;1个数据对象,100个,1000个)

1.        序列化文件大小

2.        序列化的读取读取性能

3.        序列化的平均写入性能

    性能指标结果(纵坐标为耗时)

 

    文件大小:hessian最小,传输带宽方面占有优势。

 

    写操作:写操作在大批量的时候,protobufhessianjdk有优势。

 

    读操作:读取方面protobuf仍然占有优势,但是总体上来书,hessianprotobuf差距不大。

    性能外的问题:

1:易用性:hessianprotobuf使用起来要简单的多,google需要预先生成一个*.proto文件,使用的时候需要依赖它的build接口,和GAE中的web.py的模板文件一样,预处理真是方便的框架,并没有让用户觉得爽。这方面hessian占优势。

2:学习成本:老牌hessianjava平台上广结良缘,文档和FAQ相当齐全,学习成本相对较低。google搜索protobuf google显示21.1W条,而hessian java却有54.4W条。

3:跨平台:hessian支持的语言:java,c++,python,php,erlang,ruby等,主要是针对java平台的,C++版本是05年的和python版本是07年的,更新都较慢;protobuf这块做的就比较好,如果系统中需要不同语言的就选择protobuf了,单java语言的还是选择hessian比较好。

    其他方面的知识:

    二进制协议比基于xml协议(Burlapapache XML-RPC)的效率要高的多(ORMIHTTP隧道启用除外),XML-RPC经过测试无论是文件大小和速度都没有优势。

原文链接http://www.longtask.com/blog/?p=542

你可能感兴趣的:(几种通讯协议的比较)