dubbo vs mac-rpc 性能評測之異步調用

前言

筆者在此前發表的《dubbo vs mac-rpc 之性能評測 之 同步調用》一文中將dubbo和mac-rpc在同步調用方面的性能作了簡單的對比和分析。原本不打算對異步調用這一塊進行評測，由於雙方在異步方法調用上差距有點大，並不太對稱。但前面有不少同窗和我討論關於mac-rpc的線程模型，以及底層通信的實現問題，筆者思來想去仍是寫一寫比較好。歡迎你們繼續和我討論。

mac-rpc是我新近發佈的做品，瞭解詳情請訪問：http://www.boarsoft.com

Dubbo的異步調用的實現

關於異步調用，Dubbo官方文檔上這樣寫到「基於 NIO 的非阻塞實現並行調用，客戶端不須要啓動多線程便可完成並行調用多個遠程服務，相對多線程開銷較小。」事實真的是這樣嗎？

筆者給被測試方法的dubbo:method標籤的如下屬性：

async="true" sent="false" return="true" timeout="6000"

爲了觀察服務提供者和服務消費者雙方的資源消耗狀況，咱們須要將dubbo的線程池設置爲cached，而後用300個線程並行的發起調用，每線程執行5000次異步調用,服務方法模擬延時10ms，結果以下：

服務消費者一方：

服務提供者一方：

對，沒有看錯，實際上服務消費者一方是額外啓動了一個線程來發起異步處理。最終的處理時間會比同步方法調用要慢一些，CPU使用率也明顯增長。服務提供者一方則不受影響。

因爲Dubbo不支持在一個線程內發起同時發起多個異步調用，這意味着是在前一個異步調用未返回前，不容許再發起下一個。所以，很難象測試同步方法調用同樣經過循環來發起壓力測試。

mac-rpc的異步調用的實現

一樣，爲了能看出mac-rpc在異步調用時線程的使用狀況，筆者將mac-rpc所用線程池大小設置爲0~600，隊列設置爲SynchronousQueue，也用300個線程並行的發起調用，每線程執行5000次異步調用,服務方法模擬延時10ms，結果以下：

服務消費者一方：

服務提供者一方：

與dubbo不一樣，mac-rpc在異步調用時，服務消費者一方並不額外去啓線程來執行。那麼爲何服務消費者一方的線程數是400而不是300也不是600呢？這是由於mac-rpc在收RPC調用的返回時，啓動了額外的線程去處理。這個設計使得mac-rpc在大量並行的執行低延時、低數據量的同步調用時更慢，但在處理高延時、大數據量的場景則更快。mac-rpc的下一版將考慮優化此處。

性能對比測試

測試方法

爲了進行對比測試，並排除沒必要要的因素，咱們讓服務雙方均使用600大小的固定線程池，配合600大小的LinkedBlockingQueue隊列，並讓服務方法模擬100ms的延時，且只返回10字符，再使用300線程並行地發起調用，每線程調用2000次，並將得到的Future對象保留起來，在程序的最後一併get，而後觀察總的耗時和資源消耗狀況。

測試結果

當使用固定600大小的線程池時，Dubbo的服務提供者一方出現Thread pool is EXHAUSTED警告，服務消費者一方出現 Client session timed out, have not heard from server in 37125ms 警告。意味着如何服務消費者一方遲遲不get結果，會形成服務提供者一方線程一直被佔用直到超時。這應該算是dubbo的一個嚴重的設計缺陷。

當使用cached線程池時，Dubbo徹底沒法工做，服務提供者狀態以下：

服務消費者狀態以下：

在超時時間同爲6秒的狀況下，不管使用何種線程池，mac-rpc都能成功完成，使用固定600大小的線程池時，成績最好，平均耗時爲104206ms，比同步執行時快了一倍。

服務提供者狀態以下：

注意：能夠看出當服務消費方的RPC請求發送完成，服務提供方在一段時間後完成了全部請求，CPU降到0%，而服務消費方還在獲取並處理服務方返回的響應。

服務消費者狀態以下：

測試結論

mac-rpc在異步方法調用上完勝。不管從性能、抗壓能力，仍是穩定性上都更勝一籌。此外，除了基本的異步方法調用外，mac-rpc還支持異步通知，異步回調等多種異步形式，值得一試。