作者 | Eugene Retunsky

譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

以下為譯文：

我發現一旦計算機沒了網際網路，我就無所事事。大多數時候，我們都使用筆記本電腦和智慧型手機訪問其他地方存儲或生成的信息。我們很難想像如果沒有了網絡通信，不面向用戶的應用還有什麼用處。儘管I/O操作與數據處理的比例可能有所不同，但此類操作可能會引發服務延遲。

實現後端服務的程式語言有許多。因此，人們對於比較這些語言的性能有著一種天然的好奇心，而比較的基準也各種各樣。例如，有一個基準可以比較不同語言在解決不同的離線任務時的性能。還有一個基準TechEmpower，可以衡量Web框架的性能。這些度量非常實用，我們可以通過它們大致了解語言的性能。然而，一般這些基準都有特定的使用場合和特定的操作，所以不一定具有代表性。

因此，我對各個平台上基本I/O的不可降低的成本非常好奇。對TCP代理進行基準測試可能是最簡單的情況。其中不涉及數據處理，只處理傳入/傳出連接，並中繼原始的字節數據。微服務的速度基本上不可能比TCP代理更快，因為微服務所需做的處理不可能少於TCP代理，它的功能只會更多，比如在此基礎上構建的其他功能：解析、驗證、遍歷、打包、計算等等。

在本文中，我們將比較以下解決方案：

HAProxy：TCP代理模式。這是一個使用C語言編寫的成熟解決方案。http://www.haproxy.org/
draft-http-tunnel：一個使用C++的解決方案（以TCP模式運行），只有最基本的功能（trantor）：https://github.com/cmello/draft-http-tunnel/（
http-tunnel：使用Rust（tokio）編寫的簡單的HTTP隧道 / TCP代理（在TCP模式下運行）：https：//github.com/xnuter/http-tunnel/
tcp-proxy：Golang解決方案：https：//github.com/jpillora/go-tcp-proxy
NetCrusher：Java解決方案（Java NIO）。使用G1在JDK 11上運行基準測試：https：//github.com/NetCrusherOrg/NetCrusher-java/
pproxy：基於asyncio的Python解決方案（以TCP代理模式運行）：https://pypi.org/project/pproxy/

以上所有的解決方案均使用非阻塞I / O。

注意：我盡力挑選了Golang、Java和Python的最佳解決方案，如果你知道更好的解決方案，請在下方留言。

實際的後端是Nginx，具體配置為：以HTTP模式發送10kb的數據。

基準結果分為兩組：

基準、C、C++、Rust：高性能語言。
Rust、Golang、Java、Python：內存安全的語言。

沒錯，兩組中都包含Rust。

方法的簡要說明

為TCP代理分配了兩個核心（使用cpuset）。
為後端分配了兩個核心（Nginx）。
請求速率從10k開始，最高至每秒25k請求。
每50個請求共用一個連接（每個請求10kb）。
測試在同一台虛擬機上運行，為的是避免網絡噪音。
VM選擇了針對計算優化的實例類型（獨占所有分配到的CPU），為的是避免出現「嘈雜的鄰居」問題。
延遲測量解析度為微秒（µs）。

我們比較的統計數據包括：

百分位數（從p50到p99）：關鍵統計數據。
離群值（p99.9和p99.99）：對於大型分布式系統的組件非常關鍵。
最大延遲：最壞的情況永遠不容忽視。
修整後的均值tm99.9：去除0.1%的最佳/最差值後得到的均值，為的是捕捉中心趨勢（不考慮離群值）。
標準偏差：評估延遲的穩定性。

為了收集數據，我使用了perf-gauge。

下面，我們來看看結果！

高性能語言：C、C++、Rust

我經常聽人說，Rust的性能可與C / C ++媲美。下面我們就來看一看在處理網絡I/O時，Rust是否能夠表現出同等的水平。

以下四個圖分別是：基準、C、C++、Rust：

圖：綠色：p50；黃色：p90；藍色：p99（以µs為單位）（左圖）；橙色-速率（右圖）

將每個統計信息的後端也加上去，所得到的微秒數如下所示。以下數字是在最大請求速率下間隔的平均值（不包括加速）：

圖：開銷（微秒）

相對結果（開銷占基準的百分比）：

圖：基準統計的開銷（％）

有趣的是，儘管在p99.9級別上，用C++編寫的代理比HAProxy和Rust都快一點，但在p99.99和max上的表現卻最糟。但這可能是由於實現導致的，在這裡是非常基本的（而且通過回調實現，沒有通過處理future實現）。

此外，我測量了CPU和內存消耗，詳情請看這裡（https://github.com/xnuter/perf-gauge/wiki/Moderate-request-rate#cpu-and-memory-consumption）。

總的來說，使用C、C++和Rust編寫的三個TCP代理表現出的性能不相上下：精簡且穩定。

比較內存安全語言：Rust、Golang、Java和Python

下面，我們來比較一下內存安全語言。不幸的是，Java和Python的解決方案無法僅通過兩個核心處理25,000 rps，因此Java的基準測試為15,000 rps，而Python的基準測試為10,000 rps。

下列四個圖分別是：Rust、Golang、Java和Python。

圖：綠色：p50；黃色：p90；藍色：p99（以µs為單位）（左圖）；橙色-速率（右圖）

我們看到了巨大的差異。對於Rust，上一張圖中的「噪聲」似乎很多，但在這張圖中非常穩定。另外，請注意Java的冷啟動高峰。以下數字是在最大請求速率下間隔的平均值（不包括加速）：

如你所見，Golang在p50 / p90級別上也具備一定的競爭力。但是，在更高的百分位上，差異急劇增加，標準偏差充分反映了這一點。但是，請再看一下Java的數字！

離群值（p99.9和p99.99）百分位非常耐人尋味。與Rust的差異肉眼可見：

圖：綠色：p99.9；藍色：p99.99（µs）（左圖）；橙色-速率（右圖）

相對結果（開銷占基準的百分比）：

圖：基準統計的開銷（％）

總的來看，Rust的延遲差異遠低於Golang、Python，尤其是Java。在p50 / p90的延遲級別上， Golang可與Rust並肩。

最大吞吐量

還有一個問題：每個代理可以處理的最大請求速率是多少？

Nginx能夠處理的請求量超過60,000 rps。如果我們在客戶端和後端之間建立一個代理，就會降低吞吐量。如下所示，C、C ++、Rust和Golang服務的請求量可以達到Nginx的70%～80%，而Java和Python的表現則比較差：

圖：左軸：延遲開銷；右軸：吞吐量

藍線是tail延遲（Y軸在左側）：越低越好。
灰色代表吞吐量（Y軸在右側）：越高越好。

總結

這些基準測試並不全面，我的目標是比較各個語言基本的I / O。

根據以上測試結果，再結合Benchmarks Game和TechEmpower的結果表明，如果性能對你的服務來說非常重要，那麼與Golang、Java或Python相比，Rust可能是更好的替代方案。另外，在使用C或C++編寫新服務之前，可以考慮一下Rust。因為Rust不僅具有可與C / C++同等出色的性能，而且還具備以下優勢：

內存安全。
無數據競爭。
易於編寫方便理解的代碼。
與Python一樣易於訪問和靈活。
它會迫使工程師在投入生產之前，提前設計和理解數據的所有權。
它有一個了不起的社區和一個龐大的組件庫。
所有試過的人很多人说好！

原文連結：https://medium.com/star-gazers/benchmarking-low-level-i-o-c-c-rust-golang-java-python-9a0d505f85f7

聲明：本文由CSDN翻譯，轉載請說明來源。