ApacheBench (ab) 壓力測試完整指南：參數詳解、結果分析、效能基準與常見誤區

ApacheBench (ab) 核心參數、輸出指標解讀與實戰壓測流程

ab (ApacheBench) 是 Apache 附帶的 HTTP 壓力測試工具，輕量、易用、支援 KeepAlive、並發控制。本文詳細說明所有參數、關鍵輸出指標含義、結果分析方法、實戰壓測流程與常見誤區。

核心參數完整對照表

常用壓測命令範例

# 基礎壓測：100 並發，10000 請求
ab -c 100 -n 10000 https://example.com/

# POST 壓測 (需檔案 post.txt 含 "param1=value1¶m2=value2")
ab -c 50 -n 5000 -p post.txt -T "application/x-www-form-urlencoded" https://example.com/api

# KeepAlive 測試
ab -c 100 -n 10000 -k https://example.com/

# 自訂標頭 (API Token)
ab -c 100 -n 10000 -H "Authorization: Bearer token123" https://example.com/api

# 輸出 CSV 供 Excel 分析
ab -c 100 -n 10000 -e result.csv https://example.com/

# 輸出 gnuplot 繪圖資料
ab -c 100 -n 10000 -g plot.data https://example.com/

關鍵輸出指標深度解讀

Server Software:        Apache/2.4.54
Server Hostname:        example.com
Server Port:            80

Document Path:          /
Document Length:        1234 bytes

Concurrency Level:      100
Time taken for tests:   12.345 seconds
Complete requests:      10000
Failed requests:        0
Non-2xx responses:      0
Total transferred:      14567890 bytes
HTML transferred:       12340000 bytes
Requests per second:    810.12 [#/sec] (mean)     ← 核心吞吐指標
Time per request:       123.45 [ms] (mean)        ← 平均延遲 (含並發)
Time per request:       1.23 [ms] (mean, across all concurrent requests) ← 單請求處理時間
Transfer rate:          1152.34 [Kbytes/sec] received

核心指標定義

連線時間分解

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       2    5   1.2      4       25
Processing:   10   80  15.3     75      350
Waiting:       8   75  14.8     70      340
Total:        12   85  15.5     80      360

• Connect：TCP 連線建立時間 (含 TLS 握手)。
• Processing：伺服器處理 + 傳輸回應時間。
• Waiting (TTFB)：首字節時間，最關鍵的使用者體驗指標。
• Total：Connect + Processing。

百分位分布 (Latency Percentiles)

Percentage of the requests served within a certain time (ms)
 50%    80
 66%    90
 75%    95
 80%   100
 90%   150
 95%   200
 98%   300
 99%   340
100%   360 (longest request)

解讀：50% 請求 (中位數) 在 80ms 內完成，99% 在 340ms 內。關注 P99、P99.9 而非平均值，避免長尾延遲影響體驗。

實戰壓測流程 (標準化)

1. 基準測試：單機單進程，關閉快取，測試靜態檔案、簡單 PHP、資料庫查詢三類場景。
2. 尋找極限：固定 -n 100000，遞增 -c 10, 50, 100, 200, 500, 1000，記錄 RPS、P99、錯誤率。
3. 穩定性測試：在最佳並發下持續跑 30 分鐘 (-t 1800)，觀察記憶體洩漏、RPS 抖動、錯誤率上升。
4. 對比優化：啟用 OPcache、調整 PM 數量、資料庫連線池、Redis 快取、CDN 靜態資源，每次單一變數對比。
5. 生產流量回放：使用 tcpcopy 或 go-replay 將線上流量複製到測試環境。

常見誤區與避坑

1. ab 壓測 ab 自身：高並發下 ab 客戶端 CPU/埠/檔案描述符耗盡，導致結果失真。解決：分散式壓測 (多台 ab)、使用 wrk (Lua 腳本、事件驅動、效能更高) 或 Locust (Python、分散式、Web UI)。
2. 忽略 KeepAlive：生產環境通常啟用 KeepAlive，壓測必須加 -k，否則 TCP 握手開銷佔比過大。
3. 目標 URL 缺少斜線：https://example.com vs https://example.com/ 可能觸發 301 重導向，干擾結果。統一加斜線。
4. 單機壓測單機：網路/CPU 瓶頸在客戶端。客戶端與伺服端分離，且客戶端規格 >= 伺服端。
5. 只看平均值：平均值掩蓋長尾。必看 P95/P99/P99.9。
6. 未預熱：首輪請求觸發 JIT 編譯、快取填充、資料庫連線建立。先跑幾輪預熱 再正式記錄。

進階工具推薦

• wrk：wrk -t4 -c100 -d30s https://example.com/ (多執行緒、事件循環、Lua 腳本)。
• hey：Go 編寫、支援 HTTP/2、輸出直方圖。
• Locust：Python 定義使用者行為、分散式、Web 即時監控。
• k6：JS 腳本、CI/CD 整合、雲端執行。
• JMeter：GUI 複雜場景、多協議、企業級。