Go 網絡庫併發吞吐量測試

github.com/Allenxuxu/g…

本文主要測試 gev 網絡庫和其餘三方 Go 網絡庫以及標準庫的吞吐量對比。

測試對象

• gev ：一個輕量、快速的基於 Reactor 模式的非阻塞 TCP 網絡庫
• eviop ：evio 的優化版本
• evio ：Fast event-loop networking for Go
• gnet ：eviop 的網絡模型替換版本
• net 標準庫

測試方法

採用陳碩測試 muduo 使用的 ping pong 協議來測試吞吐量。

簡單地說，ping pong 協議是客戶端和服務器都實現 echo 協議。當 TCP 鏈接創建時，客戶端向服務器發送一些數據，服務器會 echo 回這些數據，而後客戶端再 echo 回服務器。這些數據就會像乒乓球同樣在客戶端和服務器之間來回傳送，直到有一方斷開鏈接爲止。這是用來測試吞吐量的經常使用辦法。

測試的客戶端代碼： github.com/Allenxuxu/g…

測試腳本：github.com/Allenxuxu/g…

主要作兩項測試：

• 單線程單個 work 協程測試，測試併發鏈接數爲 10/100/1000/10000 時的吞吐量
• 4線程4個 work 協程測試，測試併發鏈接數爲 10/100/1000/10000 時的吞吐量

全部測試中，ping pong 消息的大小均爲 4096 bytes，客戶端始終是4線程運行。

測試結果

總結與思考

不管是單線程，仍是多線程模式下，gev 都比其餘網絡庫吞吐量略高出一些。

evio 由於 epoll 使用一些 bug 和可優化之處，因此在 linux 環境中的吞吐量遠不如優化版本 eviop 。

eviop 是我對 evio bug 修復和優化的版本，因此其性能也是比 evio 提高很多。我曾嘗試在 eviop 中替換 evio 的網絡模型（evio 利用 accpet 的驚羣現象工做），可是由於其代碼耦合度太高，修改爲本過大，最終決定一邊完善 eviop（維持網絡模型不變）一邊本身借鑑muduo 的網絡模型從新擼一個新的 -- gev 。

gnet 是研究了 eviop 的代碼，繼續在其之上替換網絡模型的版本。可是網絡模型的優點在單線程模式中並無體現出來，吞吐量反而比 eviop 小一些。在多線程模式下，網絡模型的優點得以體現。

gev 與其餘使用 epoll 構建的基於事件驅動的網絡庫在逐步的優化中，相信性能都差很少。由於做者目的不一樣，網絡庫不一樣的設計，優點點都會不一樣。我研究 evio，最終本身擼了 gev ，也是由於想要一個在內存佔用低前提下，速度足夠快，能負載更多鏈接的網絡庫。

若是對 gev 網絡庫感興趣，歡迎提意見和 PR 。➡️ github.com/Allenxuxu/g…