ice-dubbo-thrift-grpc性能測試對比
測試說明
本測試只是個人爲了對rpc進行技術選型，測試可能不夠嚴謹，對某些rpc的參數可能也不是最優，如果你知道更優的參數配置或者改進意見等，歡迎反饋給我[email protected]。另外代碼有些地方只是爲了測試方便，不作爲平時編程的範例。所有測試源碼和運行均一起提供在附件裏。
測試源碼工程可用idea打開 http://git.oschina.net/whzhaochao/RPC-DEMO，其中dubbo，grpc需要maven支持。運行只需要運行對應bat腳本。如果想測試更多場景，可以直接改腳本的併發數和調用次數。
測試人
南哥 mycat核心commiter http://mycat.io/
測試環境
測試程序
由於各rpc所自帶的基準測試大多跟自己的rpc耦合性比較高，不太適合拿來對多個rpc同時進行公平的測試。所以寫了個簡單的併發測試程序，且對個rpc保持一致性。
系統環境
Jdk：jdk1.8.0_51x64
Ice：ice3.6
Dubbo：dubbox 2.8.4
Thrift：0.9.2
Grpc：0.7.1
測試準備
Ice：提前安裝好ZeroC ICE 3.6，在path中設置好bin的路徑。
Dubbo：準備好zookeeper
關閉殺毒軟件防火牆之類以及其他一些後臺程序
測試參數
所有jvm參數均設置爲java -Xms2G -Xmx2G
Ice：
Dubbo：<dubbo:protocol name="dubbo" serialization="kryo" threads="200"/>
Thrift：
Grpc：
測試場景
分別併發1、5、20、50、100個客戶端程序，每個客戶端程序執行300000次調用。
服務方法均通過傳入一個Order對象然後原樣返回。
structOrder {
1: i64 orderId
2: string phone
3: string name
4: string orderNum
5: i32 orderDate
6: i32 ticketType
7: double amount
8: i32 orderStatus
}
service MobileService {
Order hello(1:Order order),
}
測試步驟
ice
Ø 運行registry.bat啓動iceregistry
Ø 運行gridnode.bat啓動icegrid節點
Ø 分別執行
進行測試，測試結果在對應的benchmark*.log裏
dubbo
Ø 啓動好zk
Ø 運行startProvider.bat啓動服務
Ø 分別運行
測試，測試結果在對應的benchmark*.log裏
thrift
Ø 運行startServer.bat啓動服務
Ø 分別運行
測試，測試結果在對應的benchmark*.log裏
grpc
Ø 運行startServer.bat啓動服務
Ø 分別運行
測試，測試結果在對應的benchmark*.log裏
測試結果
1客戶端
測試結果如下所示：
|
Rpc |
併發客戶端 |
每客戶端調用次數 |
總調用次數 |
執行時間 |
每秒調用數tps |
|
ice |
1 |
300000 |
300000 |
16s |
18329 |
|
dubbo |
1 |
300000 |
300000 |
52s |
5675 |
|
thrift |
1 |
300000 |
300000 |
23s |
12832 |
|
grpc |
1 |
300000 |
300000 |
77s |
3896 |
從數據可以看出ice，thrift的tps最高，ice是thrift的1.4倍，是dubbo的3.2倍，是grpc的4.7倍
5客戶端併發
測試結果如下所示：
|
Rpc |
併發客戶端 |
每客戶端調用次數 |
總調用次數 |
執行時間 |
每秒調用數tps |
|
ice |
5 |
300000 |
1500000 |
20s |
71575 |
|
dubbo |
5 |
300000 |
1500000 |
77s |
19371 |
|
thrift |
5 |
300000 |
1500000 |
31s |
47041 |
|
grpc |
5 |
300000 |
1500000 |
95s |
15722 |
從數據可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的3.6倍，是grpc的4.5倍
20客戶端併發
測試結果如下所示：
|
Rpc |
併發客戶端 |
每客戶端調用次數 |
總調用次數 |
執行時間 |
每秒調用數tps |
|
ice |
20 |
300000 |
6000000 |
68s |
87375 |
|
dubbo |
20 |
300000 |
6000000 |
256s |
23354 |
|
thrift |
20 |
300000 |
6000000 |
94s |
63708 |
|
grpc |
20 |
300000 |
6000000 |
382s |
15675 |
從數據可以看出ice，thrift的tps最高，ice是thrift的1.3倍，是dubbo的3.7倍，是grpc的5.5倍
50客戶端併發
測試結果如下所示：
|
Rpc |
併發客戶端 |
每客戶端調用次數 |
總調用次數 |
執行時間 |
每秒調用數tps |
|
ice |
50 |
300000 |
15000000 |
165s |
90679 |
|
dubbo |
50 |
300000 |
15000000 |
676s |
22157 |
|
thrift |
50 |
300000 |
15000000 |
255s |
58765 |
|
grpc |
50 |
300000 |
15000000 |
987s |
15186 |
從數據可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的4倍，是grpc的5.9倍
100客戶端併發
測試結果如下所示：
|
Rpc |
併發客戶端 |
每客戶端調用次數 |
總調用次數 |
執行時間 |
每秒調用數tps |
|
ice |
100 |
300000 |
30000000 |
361s |
83014 |
|
dubbo |
100 |
300000 |
30000000 |
1599s |
18760 |
|
thrift |
100 |
300000 |
30000000 |
597s |
50211 |
|
grpc |
100 |
300000 |
30000000 |
2186s |
13721 |
從數據可以看出ice，thrift的tps最高，ice是thrift的1.6倍，是dubbo的4.4倍，是grpc的6倍
總結
從測試結果可以看出ice的tps遙遙領先，而且併發越高tps比其他越高，其次thrift，dubbo和grpc則差了很多。Grpc最差估計跟用了HTTP2有關。
另外dubbox還支持rest，官方測試rest比kyro要慢1.5倍，本次未對rest測試。
從功能完備性來說ice和dubbo都算比較完備，都有大型生產案例，thrift的服務化功能比較缺失，grpc可能還不夠成熟。
Dubbo的插件化機制的確不錯，ice初次接觸有些概念比較晦澀，經過封裝和有詳細的資料後要好上許多。
另外《Zeroc Ice權威指南》作者Leader-us對ice的測試結果如下：
Leader-us測試結果Ice則是2.5萬，性能差不多是Avro的一倍，綜合起來看Avro和thrift的性能應該差不多。
• Apache Avro框架簡單，非接口編譯的模式靈活度很高，用Json定義的RPC消息結構和方法簡單並容易理解
•Http協議的編碼和傳輸機制效率遠遠低於長連接的Socket模式，本機對比了Avro的Http協議與Netty實現的Socket協議，請求應答消息相同的情況下，HTTP的TPS是500左右，而Netty Socket模式則是1.5萬左右，相差很懸殊
•多語言客戶端支持並不是那麼容易的事情，Avro的Python客戶端目前只實現了基本的Http協議，（Java的同時實現了Netty客戶端協議），這種情況下，服務端只能也採用Http協議，從而導致併發性能問題
支付寶的一個驚人祕密
在測試icegrid的過程中發現性能比較直接連server的方式性能下降了40%，通過幾天的調測，調過各種參數配置均未發現原因。直到一次測試過程中偶然打開任務管理器，看到了這貨
Alipay security business service佔用cpu異常偏高，把這個服務停掉，再測試，刷刷性能恢復正常了。
再反覆測試幾次，用dubbo等測，均是如此。
Alipay securitybusiness service應該了攔截了所有的網絡流量，攔截程序可能寫的有問題，但是。。。。。。你攔截跟支付寶淘寶有關的流量就好，爲啥其他流量全攔截呢，至於有沒有把流量偷偷傳回服務器這個有待進一步監測。