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

結果分析

傳輸資料：

RMI             ：二進制資料

Hessian       ：二進制資料

Burlap          ：XML

Httpinvoker  ：XML

Web service ：XML

具體比較

直接調用

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

RMI

與設想的一樣，RMI理所當然是最快的，在幾乎所有的情況下，它的耗時都是最少的。特别是在資料結構複雜，資料量大的情況下，與其他協定的差距尤為明顯。

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

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

Hessian

caucho 公司的resin伺服器号稱是最快的伺服器，在java領域有一定的知名度。Hessian做為resin的組成部分，其設計也非常精簡高效，實際運作情況也證明了這一點。平均來看，Hessian較RMI要慢20%左右，但這隻是在資料量特别大，資料結構很複雜的情況下；中等或少量資料時，Hessian并不比RMI慢。

Hessian的好處是精簡高效，可以跨語言使用，而且協定規範公開，我們可以針對任意語言開發對其協定的實作。目前已有實作的語言有：java, c++, .net, python, ruby。

另外，Hessian與WEB伺服器結合非常好，借助WEB伺服器的成熟功能，在處理大量使用者并發通路時會有很大優勢，在資源配置設定，線程排隊，異常處理等方面都可以由成熟的WEB伺服器保證。而RMI本身并不提供多線程的伺服器。而且，RMI需要開防火牆端口，Hessian不用。

這裡有對Hessian的詳細介紹。

Burlap

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

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

其效率低可能有兩方面的原因。一方面，XML資料描述内容太多，同樣的資料結構，其傳輸量要大很多；另一方面，xml的解析比較費資源，特别對于大資料量情況下更是如此。

HttpInvoker

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

不過，它隻能用于JAVA語言之間的通訊，而且，要求用戶端和服務端都使用SPRING架構；另外，HttpInvoker 并沒有經過實踐的檢驗，目前還沒有找到應用該協定的項目。

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不支援集合類型，隻能用數組，不友善。

參考：

http://blog.csdn.net/anerou/article/details/6715584