以下分享幾種java語言常用的通訊協定及協定效能的比較
1.RMI
##RMI調用就像設想的一樣，RMI理所當然是最快的，在幾乎所有的情況下，它的毫時都是最少的。特別是在資料結構複雜，資料量大的情況下，與其他協定的差距尤為明顯。為了充分發揮RMI的效能，另外做了測試類，不使用Spring，用原始的RMI形式（繼承UnicastRemoteObject物件）提供服務並遠端調用，與Spring對POJO包裝成的RMI進行效率比較。結果顯示：兩者基本上持平，Spring提供的服務還稍快。初步認為，這是因為Spring的代理和快取機制比較強大，節省了物件重新取得的時間。2.Hessian
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不用。3.Burlap
Burlap與Hessian都是caucho公司的開源產品，只不過Hessian採用二進位的方式，而Burlap採用xml的格式。測試結果顯示，Burlap在資料結構不複雜，資料量中等的情況下，效率還是可以接受的，但如果資料量大，效率會急劇下降。平均計算，Burlap的呼叫毫時是RMI的3倍。我認為，其效率低有兩方面的原因，一個是XML資料描述內容太多，同樣的資料結構，其傳輸量要大很多；另一方面，眾所周知，對xml的解析是比較費資源的，特別對於大數據量情況下更是如此。4.HttpInvoker
HttpInvoker是SpringFramework提供的JAVA遠端呼叫方法，使用java的序列化機制處理物件的傳輸。從測試結果來看，其效率還是可以的，與RMI基本持平。不過，它只能用於JAVA語言之間的通訊，而且，要求客戶端和服務端都使用SPRING框架。另外，HttpInvoker 並沒有經過實踐的檢驗，目前還沒有找到應用該協議的項目。5.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不支援集合類型，只能用數組，不方便。以上是java語言支援什麼協議的詳細內容。更多資訊請關注PHP中文網其他相關文章！
