CS Benchmark

這個 repo 是一組兩台 Mini PC 之間的 server-to-client benchmark 實驗紀錄與自動化腳本。核心問題是：

在 1Gbps Ethernet 環境中，能不能用簡單的工程實作把頻寬打滿？在 HTTP workload 下，RPS、payload size、concurrency、CPU、latency 與 C10K 之間的關係是什麼？

主計劃放在 Plan.md。各階段測試計劃、runner、raw console output 與報告分別放在 00-iperf3 到 03-c10k 目錄。手動執行 Step by Step 的腳本放在 rehearsal 裡。

視覺摘要

以下圖檔為 report/ 目錄中由 ChatGPT 產生的視覺整理。

Repo 結構

路徑	內容
Plan.md	上層實驗計劃
00-iperf3/	Ethernet / TCP baseline
01-http-baseline/	最小 Go HTTP server + wrk baseline
02-http-matrix/	oha payload / concurrency matrix
03-c10k/	C10K、20K idle / low-rate 延伸測試
report/	視覺化整理、簡報或圖像輸出
rehearsal/	手動執行的手冊

實驗環境

本 repo 目前的實證結果來自兩台 Ubuntu 24.04 Mini PC：

角色	Host	SSH / Mgmt IP	Ethernet IP	NIC
Server	gtinfra02	192.168.51.115	192.168.5.121	enp1s0
Client	gtinfra03	192.168.51.199	192.168.5.152	enp86s0

操作流量走 Wi-Fi / management network，benchmark 流量指定走 Ethernet 192.168.5.0/24。

實證結果摘要

Phase 0: iperf3 baseline

報告：00-iperf3/results/2026-05-17_iperf3-run/Report_00-iperf3.md

兩台 Mini PC 之間的裸 TCP throughput 正常：

• 單連線與 4 streams 雙方向皆約 941 Mbits/sec
• retransmits 皆為 0
• 後續 HTTP 測試若未達理論值，優先分析 application、client、server、OS stack，而不是先懷疑底層網路頻寬

Phase 1: HTTP baseline

報告：01-http-baseline/results/2026-05-17_151921_http-baseline/Report_01-http-baseline.md

使用最小 Go net/http fixed-payload server 搭配 wrk：

• 1KB payload 約 101k RPS，transfer 約 110 MB/s
• 10KB payload 約 11.3k RPS，transfer 約 111 MB/s
• 100KB payload 約 1.15k RPS，transfer 約 112 MB/s
• 結論：HTTP response 已可接近 1Gbps usable throughput

Phase 2: HTTP matrix

報告：02-http-matrix/results/2026-05-17_154119_http-matrix/Report_02-http-matrix.md

使用 oha 測試 1KB / 4KB / 10KB / 100KB 與 concurrency 16 / 64 / 128 / 256 / 512 / 1024：

• 1KB 約在 c64 達到 plateau，約 101k RPS
• 4KB 約在 c64 穩定進入 plateau
• 10KB 與 100KB 從 c16 開始就已 network-bound
• 提高 concurrency 幾乎不增加 throughput，主要增加 p95 / p99 latency
• c1024 受到 client file descriptor limit 影響，不適合作為乾淨的 server 上限判讀

Phase 3: C10K

報告：03-c10k/results/2026-05-18_095143_c10k/Report_03-c10k.md

結論：這組 Mini PC 可以做到 C10K。

• 10k idle keep-alive 成功，server RSS 約 209 MB，CPU 幾乎閒置
• 10k low-rate 約 1k RPS 成功，p99 約 1 ms，server CPU 約 13-15%
• 10k low-rate 約 2k RPS 成功，p99 約 1.5 ms，server CPU 約 26%
• 10k active /payload/1k 約 100k RPS，但 p99 拉高到約 0.77-0.79s
• 20k idle 成功
• 20k low-rate /healthz 在 TIME_WAIT 冷卻後成功，約 2k RPS

主要瓶頸不是 server 能不能 accept 10k connections，而是在 active 高壓下 throughput plateau 後的 queueing latency。往 20K 以上延伸時，最早遇到的是 client-side ephemeral port / TIME_WAIT 管理問題。

如何自行執行

1. 準備環境

需要兩台 Linux 機器，建議一台當 server、一台當 client，並準備：

• passwordless SSH
• Go
• iperf3
• wrk
• oha
• sysstat，提供 sar、mpstat、pidstat
• 可提高的 ulimit -n，C10K 測試需要高於 10,000 的 file descriptor limit

如果你的 IP、host、NIC 與本 repo 不同，請先調整各 runner script 內的設定值。

2. 依階段執行

從 repo 根目錄執行：

bash 00-iperf3/run_iperf3_baseline.sh
bash 01-http-baseline/run_http_baseline.sh
bash 02-http-matrix/run_http_matrix.sh
bash 03-c10k/run_c10k.sh

C10K 之後若要探索 20K：

bash 03-c10k/run_c10k_beyond.sh
bash 03-c10k/run_c10k_beyond_lowrate_retry.sh

每個 runner 會把 console output、系統觀測資料與 summary 放到該階段的 results/<timestamp>.../ 目錄下。

3. 閱讀結果

每個階段的最終整理報告是：

00-iperf3/results/.../Report_00-iperf3.md
01-http-baseline/results/.../Report_01-http-baseline.md
02-http-matrix/results/.../Report_02-http-matrix.md
03-c10k/results/.../Report_03-c10k.md

原始 console output 通常在各 run 目錄的 logs/，機器環境、server output、client output、sar、mpstat、pidstat 也會保留在同一批 artifacts 中。

注意事項

• benchmark target 請使用 Ethernet IP，不要使用 Wi-Fi IP 或 hostname，避免測試流量走錯網路。
• C10K / 20K 測試需要提高 process file descriptor limit。
• 高連線數測試之間需要等待 TIME_WAIT 冷卻，否則 client 可能出現 cannot assign requested address。
• 高 concurrency 不一定代表更高 throughput；當網路或 server/client processing 已進入 plateau，更多 concurrency 主要會增加 tail latency。