《Java常用的通信協(xié)議效率比較.docx》由會(huì)員分享，可在線閱讀，更多相關(guān)《Java常用的通信協(xié)議效率比較.docx（3頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

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