Java常用的通信協(xié)議效率比較.docx

《Java常用的通信協(xié)議效率比較.docx》由會員分享，可在線閱讀，更多相關《Java常用的通信協(xié)議效率比較.docx（3頁珍藏版）》請在裝配圖網上搜索。

本文比較了RMI，Hessian，Burlap，Httpinvoker，Web service等5種通訊協(xié)議的在不同的數據結構和不同數據量時的傳輸性能。 1. 簡介 RMI是java語言本身提供的遠程通訊協(xié)議，穩(wěn)定高效，是EJB的基礎。但它只能用于JAVA程序之間的通訊。 Hessian和Burlap是caucho公司提供的開源協(xié)議，基于HTTP傳輸，服務端不用開防火墻端口。協(xié)議的規(guī)范公開，可以用于任意語言。 Httpinvoker是SpringFramework提供的遠程通訊協(xié)議，只能用于JAVA程序間的通訊，且服務端和客戶端必須使用SpringFramework。 Web service是連接異構系統(tǒng)或異構語言的首選協(xié)議，它使用SOAP形式通訊，可以用于任何語言，目前的許多開發(fā)工具對其的支持也很好。 2. 測試結果 測試結果顯示，幾種協(xié)議的通訊效率依次為： RMI > Httpinvoker >= Hessian >> Burlap >> Web service RMI不愧是JAVA的首選遠程調用協(xié)議，非常高效穩(wěn)定，特別是在大數據量的情況下，與其他通訊協(xié)議的差距尤為明顯。 Httpinvoker使用java的序列化技術傳輸對象，與RMI在本質上是一致的。 從效率上看，兩者也相差無幾，Httpinvoker與RMI的傳輸時間基本持平。 Hessian在傳輸少量對象時，比RMI還要快速高效，但傳輸數據結構復雜的對象或大量數據對象時，較RMI要慢20%左右。 Burlap僅在傳輸1條數據時速度尚可，通常情況下，它的耗時是RMI的3倍。 Web Service的效率低下是眾所周知的，平均來看，Web Service的通訊毫時是RMI的10倍。 3. 結果分析 1、直接調用 直接調用的所有毫時都接近0，這說明程序處理幾乎沒有花費時間，記錄的全部時間都是遠程調用耗費的。 2、RMI調用 與設想的一樣，RMI理所當然是最快的，在幾乎所有的情況下，它的耗時都是最少的。特別是在數據結構復雜，數據量大的情況下，與其他協(xié)議的差距尤為明顯。 3、Hessian調用 caucho公司的resin服務器號稱是最快的服務器，在java領域有一定的知名度。Hessian做為resin的組成部分，其設計也非常精簡高效，實際運行情況也證明了這一點。平均來看，Hessian較RMI要慢20%左右，但這只是在數據量特別大，數據結構很復雜的情況下才能體現出 來，中等或少量數據時，Hessian并不比RMI慢。 Hessian的好處是精簡高效，可以跨語言使用，而且協(xié)議規(guī)范公開，我們可以針對任意語言開發(fā)對其協(xié)議的實現。目前已有實現的語言有：java, c++, .net, python, ruby。 另外，Hessian與WEB服務器結合非常好，借助WEB服務器的成熟功能，在處理大量用戶并發(fā)訪問時會有很大優(yōu)勢，在資源分配，線程排隊， 異常處理等方面都可以由成熟的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 并沒有經過實踐的檢驗，目前還沒有找到應用該協(xié)議的項目。 6、Web service調用 本次測試選用了apache的AXIS組件作為 Web service的實現，AXIS在Web service領域相對成熟老牌。 為了僅測試數據傳輸和編碼、解碼的時間，客戶端和服務端都使用了緩存，對象只需實例化一次。但是，測試結果顯示，Web service的效率還是要比其他通訊協(xié)議慢10倍。 如果考慮到多個引用指向同一對象的傳輸情況，Web service要落后更多。因為RMI，Hessian等協(xié)議都可以傳遞引用，而web service有多少個引用，就要復制多少份對象實體。 Web service傳輸的冗余信息過多是其速度慢的原因之一，監(jiān)控發(fā)現，同樣的訪問請求，描述相同的數據，Web service返回的數據量是hessian協(xié)議的6.5倍。另外，Web service的處理也很耗時，目前的xml解析器效率普遍不高，處理xml <-> bean很毫資源。從測試結果看，異地調用比本地調用要快，也從側面說明了其毫時主要用在編碼和解碼xml文件上。這比冗余信息更為嚴重，冗余信息占用的 只是網絡帶寬，而每次調用的資源耗費直接影響到服務器的負載能力。