直接調用的所有毫時都接近0，這說明程序處理幾乎沒有花費時間，記錄的全部時間都是遠程調用耗費的。
2、RMI調用
與設想的壹樣，RMI理所當然是最快的，在幾乎所有的情況下，它的毫時都是最少的。特別是在數據結構復雜，數據量大的情況下，與其他協議的差距尤為明顯。
為了充分發揮RMI的性能，另外做了測試類，不使用Spring，用原始的RMI形式（繼承UnicastRemoteObject對象）提供服務並遠程調用，與Spring對POJO包裝成的RMI進行效率比較。結果顯示：兩者基本持平，Spring提供的服務還稍快些。
初步認為，這是因為Spring的代理和緩存機制比較強大，節省了對象重新獲取的時間。
3、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不用。
4、Burlap調用
Burlap與Hessian都是caucho公司的開源產品，只不過Hessian采用二進制的方式，而Burlap采用xml的格式。
測試結果顯示，Burlap在數據結構不復雜，數據量中等的情況下，效率還是可以接受的，但如果數據量大，效率會急劇下降。平均計算，Burlap的調用毫時是RMI的3倍。
我認為，其效率低有兩方面的原因，壹個是XML數據描述內容太多，同樣的數據結構，其傳輸量要大很多；另壹方面，眾所周知，對xml的解析是比較費資源的，特別對於大數據量情況下更是如此。
5、HttpInvoker調用
HttpInvoker是SpringFramework提供的JAVA遠程調用方法，使用java的序列化機制處理對象的傳輸。從測試結果看，其效率還是可以的，與RMI基本持平。
不過，它只能用於JAVA語言之間的通訊，而且，要求客戶端和服務端都使用SPRING框架。
另外，HttpInvoker 並沒有經過實踐的檢驗，目前還沒有找到應用該協議的項目。
6、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個以上的並發用戶。）