幾種基於HTTP協議的RPC性能比較

有了總體的瞭解後，能夠發現Hessian的這個遠程過程調用，徹底使用動態代理來實現的，其實從客戶端代碼不難看出，HessianProxyFactory的create方法就是建立接口Basic的代理類，該類實現了Basic接口，JDK的proxy類會自動用 InvocationHandler 的實現類（該類在Hessian中表現爲HessianProxy）的invoke方法體 來填充所生成代理類的方法體，從而實現遠程調用，傳輸過程使用的是基於Http的二進制字節流。

RMI與Hessian的調用過程比較：
Java代碼

   1. Hessian：客戶端（basic.hello()）——>序列化寫到輸出流——>遠程方法（服務器端）——>序列化寫到輸出流 ——>客戶端讀取輸入流——>輸出結果  
   2. RMI：客戶端——>stub——>序列化——>skeleton——>遠程方法——>序列化——>stub—— >輸出結果  

Hessian：客戶端（basic.hello()）——>序列化寫到輸出流——>遠程方法（服務器端）——>序列化寫到輸出流 ——>客戶端讀取輸入流——>輸出結果
RMI：客戶端——>stub——>序列化——>skeleton——>遠程方法——>序列化——>stub—— >輸出結果



服務端的是一個簡單的加密、解密方法，各類協議使用同一個實現的代碼。
客戶端是獨立的java程序，分別用各類協議對服務端的方法進行調用。每一種協議循環調用n次，而後取平均值。

循環1,000次的測試
第一次

Java代碼

   1. Axis --------------->> Total time: 11123 ms, Avg time: 11.123 ms  
   2. Burlap ------------->> Total time:   866 ms, Avg time:  0.866 ms  
   3. Hessian ------------>> Total time:   581 ms, Avg time:  0.581 ms  
   4. REST --------------->> Total time:   929 ms, Avg time:  0.929 ms  
   5. AxisUsingWSDL2Java ->> Total time: 11998 ms, Avg time: 11.998 ms  

Axis --------------->> Total time: 11123 ms, Avg time: 11.123 ms
Burlap ------------->> Total time:   866 ms, Avg time:  0.866 ms
Hessian ------------>> Total time:   581 ms, Avg time:  0.581 ms
REST --------------->> Total time:   929 ms, Avg time:  0.929 ms
AxisUsingWSDL2Java ->> Total time: 11998 ms, Avg time: 11.998 ms



第二次

Java代碼

   1. Axis --------------->> Total time: 11256 ms, Avg time: 11.256 ms  
   2. Burlap ------------->> Total time:   816 ms, Avg time:  0.816 ms  
   3. Hessian ------------>> Total time:   582 ms, Avg time:  0.582 ms  
   4. REST --------------->> Total time:   919 ms, Avg time:  0.919 ms  
   5. AxisUsingWSDL2Java ->> Total time: 11908 ms, Avg time: 11.908 ms  

Axis --------------->> Total time: 11256 ms, Avg time: 11.256 ms
Burlap ------------->> Total time:   816 ms, Avg time:  0.816 ms
Hessian ------------>> Total time:   582 ms, Avg time:  0.582 ms
REST --------------->> Total time:   919 ms, Avg time:  0.919 ms
AxisUsingWSDL2Java ->> Total time: 11908 ms, Avg time: 11.908 ms



循環10,000次的測試
第一次

Java代碼

   1. Axis --------------->> Total time:  88013 ms, Avg time:  8.8013 ms  
   2. Burlap ------------->> Total time:   5789 ms, Avg time:  0.5789 ms  
   3. Hessian ------------>> Total time:   5162 ms, Avg time:  0.5162 ms  
   4. REST --------------->> Total time:   8316 ms, Avg time:  0.8316 ms  
   5. AxisUsingWSDL2Java ->> Total time: 112801 ms, Avg time: 11.2801 ms  

Axis --------------->> Total time:  88013 ms, Avg time:  8.8013 ms
Burlap ------------->> Total time:   5789 ms, Avg time:  0.5789 ms
Hessian ------------>> Total time:   5162 ms, Avg time:  0.5162 ms
REST --------------->> Total time:   8316 ms, Avg time:  0.8316 ms
AxisUsingWSDL2Java ->> Total time: 112801 ms, Avg time: 11.2801 ms



第二次

Java代碼

   1. Axis --------------->> Total time:  87359 ms, Avg time:  8.7359 ms  
   2. Burlap ------------->> Total time:   5784 ms, Avg time:  0.5784 ms  
   3. Hessian ------------>> Total time:   5084 ms, Avg time:  0.5084 ms  
   4. REST --------------->> Total time:   7983 ms, Avg time:  0.7983 ms  
   5. AxisUsingWSDL2Java ->> Total time: 113234 ms, Avg time: 11.3234 ms  

Axis --------------->> Total time:  87359 ms, Avg time:  8.7359 ms
Burlap ------------->> Total time:   5784 ms, Avg time:  0.5784 ms
Hessian ------------>> Total time:   5084 ms, Avg time:  0.5084 ms
REST --------------->> Total time:   7983 ms, Avg time:  0.7983 ms
AxisUsingWSDL2Java ->> Total time: 113234 ms, Avg time: 11.3234 ms



測試結果
Hessian最快，Burlap第二，REST第三，Axis最慢。前3種要比Axis快了10倍或者更多。

上面的測試，服務端用的是Resin-3.0.13，出於好奇，我又用Tomcat-5.5.9測試了一把，結果是Resin確實比Tomcat快些。Tomcat-5.5.9 循環10,000次的測試

Java代碼

   1. Axis --------------->> Total time: 122551 ms, Avg time: 12.2551ms  
   2. Burlap ------------->> Total time:   6401 ms, Avg time:  0.6401ms  
   3. Hessian ------------>> Total time:   5745 ms, Avg time:  0.5745ms  
   4. REST --------------->> Total time:   8090 ms, Avg time:  0.809ms  
   5. AxisUsingWSDL2Java ->> Total time: 156908 ms, Avg time: 15.6908ms

 

 

1、綜述
本文比較了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倍。


2、結果分析
一、直接調用
直接調用的全部毫時都接近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。尚未delphi的實現。
另外，Hessian與WEB服務器結合很是好，藉助WEB服務器的成熟功能，在處理大量用戶併發訪問時會有很大優點，在資源分配，線程排隊，異常處理等方面均可以由成熟的WEB服務器保證。而RMI自己並不提供多線程的服務器。並且，RMI須要開防火牆端口，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在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不支持集合類型，只能用數組，不方便。

 

 

 

比較 二進制 + 協議和 xml+協議的話.

web service 用xfire的話編碼也不是十分的麻煩,可是效率實在是很差說,解析xml是瓶頸.可是就由於異構,因此你們都用它.

RMI的話 server端作資源隊列,線程排隊等併發處理其實也不錯.就是要穿越防火牆開端口比較麻煩.

權衡之下,還得Hessian.

HttpInvoker和RMI相比不知效率差在哪裏? 都是二進制的序列化,區別應該就在於協議吧