RMI、Hessian、Burlap、Httpinvoker、WebService的比較

一、綜述

本文比較了rmi、hessian、burlap、httpinvoker、webservice5這種通訊協定的在不同的資料結構和不同資料量時的傳輸性能。

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在webservice領域相對成熟老牌。

為了僅測試資料傳輸和編碼、解碼的時間，用戶端和服務端都使用了緩存，對象隻需執行個體化一次。但是，測試結果顯示，webservice的效率還是要比其他通訊協定慢10倍。

如果考慮到多個引用指向同一對象的傳輸情況，web service要落後更多。因為rmi，hessian等協定都可以傳遞引用，而web service有多少個引用，就要複制多少份對象實體。

web service傳輸的備援資訊過多是其速度慢的原因之一，監控發現，同樣的通路請求，描述相同的資料，webservice傳回的資料量是hessian協定的6.5倍。另外，web service的處理也很毫時，目前的xml解析器效率普遍不高，處理xml <-> bean很毫資源。從測試結果看，異地調用比本地調用要快，也從側面說明了其毫時主要用在編碼和解碼xml檔案上。這比備援資訊更為嚴重，備援資訊占用的 隻是網絡帶寬，而每次調用的資源耗費直接影響到伺服器的負載能力。（ms的工程師曾說過，用web service不能負載100個以上的并發使用者。）

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

三、hession機制

特别說明：尊重作者的勞動成果，轉載請注明出處哦~~~http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt366