Go Web 架構效能比拼 2017 春季版

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

誰是最快的Go Web架構?, 這是我去年發布的Go web 架構的評測。現在一年過去了，有些架構因為缺乏維護而被放棄了，又有新的輪子被創造出來，既有的輪子也在不停的演化升級，來去之間，Go的版本也已經升級的1.8了。 青年節前， kirillDanshin提了一個issue,希望能更新最新的測試結果，現在這篇文章就記錄了最新的測試結果。

測試環境

• CPU: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 32 cores
• Memory: 32G
• Go: 1.8.0
• OS: CentOS 7 / 3.10.0-229.el7.x86_64

所有的評測的 web 架構都已經更新到 2017-04-01 的最新版本。

說明
Julien Schmidt實現的 go-http-routing-benchmark 是對 router的一個評測，但是作為完整的web架構，從接收使用者請求到發送給用戶端／瀏覽器，中間會經過多個組件的處理， router的效能影響到底在整體的web請求處理中影像多大呢？看測試結果。

本項目的代碼在 go-web-framework-benchmark, 你可以查看，也歡迎提 pull request。

測試中的 gear 測試代碼有問題，沒有加上router中介軟體， 你可以在這次測試中忽略它的benchmark。參看 # 33

類比業務不同的處理時間架構的效能

使用 5000 個用戶端類比請求，比較各web架構在不同的處理時間下的效能。

1、0ms

0ms類比理想的業務處理。在這種處理時間下， 每個請求基本只耗費小於1毫秒的處理時間，這是理想的極端的情況，比如訪問記憶體中緩衝的對象就返回。

2、10ms

10ms類比比較好的業務處理。在這種情況下，伺服器只需在極短的情況下(10ms)處理完請求，如果業務不是太複雜，沒有訪問本地磁碟、資料庫或者其它遠程服務的情況下，比較符合這種測試。

3、100ms

100ms類比一般的業務處理。一般接收請求後，可能訪問本地磁碟上的檔案、資料庫或者調用一個或多個遠程服務，在這種情況下，完成一次請求可能要花費較少的時間。

pipelining

這個測試是類比在 pipelining 情況下 web 架構的表現。

HTTP管線化（HTTP pipelining）是將多個HTTP請求（request）整批提交的技術，而在發送過程中不需先等待服務端的回應。
請求結果管線化使得 HTML 網頁載入時間動態提升，特別是在具體有高延遲的串連環境下，如衛星上網。在寬頻連線中，加速不是那麼顯著的，因為需要伺服器端應用 HTTP/1.1 協議:伺服器端必須按照用戶端的請求順序恢複請求，這樣整個串連還是先進先出的，對頭阻塞（HOL blocking）可能會發生，造成延遲。未來的 HTTP/2.0 或者SPDY中的非同步作業將會解決這個問題。因為它可能將多個 HTTP 要求填充在一個TCP資料包內，HTTP 管線化需要在網路上傳輸較少的 TCP 資料包，減少了網路負載。

是使用 5000 用戶端 測試不同的處理時間的效能比較圖。

並發

下面這組測試是在業務處理時間限定在30ms的情況下， 使用100、1000、5000的並發client的吞吐情況。

1、100並發

2、1000並發

3、5000並發

總結

Go Web架構目前已經非常多了，不斷的有人造輪子，這是Go Web的設計簡單易擴充有關。如果我覺得官方的路由不方便，我就可以很容易的再造一個輪子，這也是go web 架構／router泛濫的緣故， 以至於有人呼籲不要再早輪子了。

從目前既有的web架構看，根據架構的低層看，可以分為兩類。一類是基於官方 net/http標準庫開發的web架構，一類是基於fasthttp開發的標準庫架構。很明顯基於fasthttp有更好的效能，但是這類架構也有它們的缺點，不完全支援HTTP協議，比如不支援HEAD，不支援 HTTP2， 各有優缺點，如何選擇交給使用者，結合自己實際的情況來選擇。比如Echo架構，在最新版中就把對fasthttp的支援去掉了。

另外，julienschmidt的httprouter有著良好的效能，這也是很幾個web架構的路由器使用它的原因。

為什麼沒有關注量很高iris？這是一個複雜而又有爭議的問題，參照issue #29、issue #16， 暫時把iris去掉了。

測試代碼和最新結果都在 go-web-framework-benchmark