幾種通訊協議的比較RMI > Httpinvoker >= Hessian >> Burlap >> web service

一、綜述

本文比較了RMI,Hessian,Burlap,Httpinvoker,web service等5種通訊協議的在不同的數據結構和不同數據量時的傳輸性能。

RMI是java語言本身提供的遠程通訊協議,穩定高效,是EJB的基礎。但它只能用于JAVA程序之間的通訊。

Hessian和Burlap是caucho公司提供的開源協議,基于HTTP傳輸,服務端不用開防火墻端口。協議的規范公開,可以用于任意語言。

Httpinvoker是SpringFramework提供的遠程通訊協議,只能用于JAVA程序間的通訊,且服務端和客戶端必須使用SpringFramework。

Web service是連接異構系統或異構語言的首選協議,它使用SOAP形式通訊,可以用于任何語言,目前的許多開發工具對其的支持也很好。

測試結果顯示,幾種協議的通訊效率依次為:

RMI > Httpinvoker >= Hessian >> Burlap >> web service

RMI不愧是JAVA的首選遠程調用協議,非常高效穩定,特別是在大數據量的情況下,與其他通訊協議的差距尤為明顯。

HttpInvoker使用java的序列化技術傳輸對象,與RMI在本質上是一致的。從效率上看,兩者也相差無幾,HttpInvoker與RMI的傳輸時間基本持平。

Hessian在傳輸少量對象時,比RMI還要快速高效,但傳輸數據結構復雜的對象或大量數據對象時,較RMI要慢20%左右。

Burlap僅在傳輸1條數據時速度尚可,通常情況下,它的毫時是RMI的3倍。

Web Service的效率低下是眾所周知的,平均來看,Web Service的通訊毫時是RMI的10倍。

二、結果分析

1、直接調用

直接調用的所有毫時都接近0,這說明程序處理幾乎沒有花費時間,記錄的全部時間都是遠程調用耗費的。

2、RMI調用

與設想的一樣,RMI理所當然是最快的,在幾乎所有的情況下,它的毫時都是最少的。特別是在數據結構復雜,數據量大的情況下,與其他協議的差距尤為明顯。

為了充分發揮RMI的性能,另外做了測試類,不使用Spring,用原始的RMI形式(繼承UnicastRemoteObject對象)提供服務并遠程調用,與Spring對POJO包裝成的RMI進行效率比較。結果顯示:兩者基本持平,Spring提供的服務還稍快些。

初步認為,這是因為Spring的代理和緩存機制比較強大,節省了對象重新獲取的時間。

3、Hessian調用

caucho公司的resin服務器號稱是最快的服務器,在java領域有一定的知名度。Hessian做為resin的組成部分,其設計也非常精簡高效,實際運行情況也證明了這一點。平均來看,Hessian較RMI要慢20%左右,但這只是在數據量特別大,數據結構很復雜的情況下才能體現出來,中等或少量數據時,Hessian并不比RMI慢。

Hessian的好處是精簡高效,可以跨語言使用,而且協議規范公開,我們可以針對任意語言開發對其協議的實現。目前已有實現的語言有:java, c++, .net, python, ruby。還沒有delphi的實現。

另外,Hessian與WEB服務器結合非常好,借助WEB服務器的成熟功能,在處理大量用戶并發訪問時會有很大優勢,在資源分配,線程排隊,異常處理等方面都可以由成熟的WEB服務器保證。而RMI本身并不提供多線程的服務器。而且,RMI需要開防火墻端口,Hessian不用。

4、Burlap調用

Burlap與Hessian都是caucho公司的開源產品,只不過Hessian采用二進制的方式,而Burlap采用xml的格式。

測試結果顯示,Burlap在數據結構不復雜,數據量中等的情況下,效率還是可以接受的,但如果數據量大,效率會急劇下降。平均計算,Burlap的調用毫時是RMI的3倍。

我認為,其效率低有兩方面的原因,一個是XML數據描述內容太多,同樣的數據結構,其傳輸量要大很多;另一方面,眾所周知,對xml的解析是比較費資源的,特別對于大數據量情況下更是如此。

5、HttpInvoker調用

HttpInvoker是SpringFramework提供的JAVA遠程調用方法,使用java的序列化機制處理對象的傳輸。從測試結果看,其效率還是可以的,與RMI基本持平。

不過,它只能用于JAVA語言之間的通訊,而且,要求客戶端和服務端都使用SPRING框架。

另外,HttpInvoker 并沒有經過實踐的檢驗,目前還沒有找到應用該協議的項目。

6、web service調用

本次測試選用了apache的AXIS組件作為WEB SERVICE的實現,AXIS在WEB SERVICE領域相對成熟老牌。

為了僅測試數據傳輸和編碼、解碼的時間,客戶端和服務端都使用了緩存,對象只需實例化一次。但是,測試結果顯示,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個以上的并發用戶。)

測試過程中還發現,web service編碼不甚方便,對非基本類型需要逐個注冊序列化和反序列化類,很麻煩,生成stub更累,不如spring + RMI/hessian處理那么流暢簡潔。而且,web service不支持集合類型,只能用數組,不方便。

免責聲明:本文僅代表文章作者的個人觀點,與本站無關。其原創性、真實性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容文字的真實性、完整性和原創性本站不作任何保證或承諾,請讀者僅作參考,并自行核實相關內容。

http://www.uswqb.club/style/images/nopic.gif
分享
評論
首頁
高速公路之王电子游艺
直播吧排球比分直播 吉林麻将下载 五排列开奖结果查询 如何破解捷报比分APP的推荐 配置类管理人 手机娱乐棋牌 云南11选5胆拖 好运经纪人 微信哈尔滨麻将群一毛 有彩金捕鱼 科乐麻将吉林版 山东十一选五直播视 今晚3d的试机号和 无网络免费单机麻将 广东11选5开奖历史结果 南粤36选7大赢家