吞吐量指標：RPS、QPS、TPS 完全指南

目錄

1. 什麼是吞吐量指標
2. 核心指標比較
3. 各指標詳解
4. 相關指標
5. 實際應用
6. 計算與監控
7. 常見問題
8. 總結

什麼是吞吐量指標

吞吐量（Throughput）指標用於衡量系統在單位時間內處理的工作量，是評估系統效能的重要依據。

吞吐量 = 單位時間內完成的操作數量

常見單位：每秒（/s 或 per second）

為什麼需要多種指標？

不同層級關注不同維度：

使用者層   → RPS（請求）  → 使用者發了多少請求？
應用層     → QPS（查詢）  → 系統處理了多少查詢？
資料庫層   → TPS（交易）  → 完成了多少筆交易？

核心指標比較

三大指標總覽

關係與差異

數量關係

一般情況：1 RPS ≥ 1 QPS ≥ 1 TPS

範例：一次下單請求
├── 1 個 HTTP 請求（1 RPS）
├── 可能產生多次資料庫查詢（N QPS）
│   ├── 查詢商品庫存
│   ├── 查詢用戶餘額
│   └── 查詢優惠券
└── 最終完成 1 筆訂單交易（1 TPS）

各指標詳解

RPS (Requests Per Second)

定義：每秒接收並處理的 HTTP 請求數量

RPS = 總請求數 / 時間（秒）

應用場景：

特點：

• ✅ 最直觀的前端指標
• ✅ 容易測量和監控
• ❌ 不區分請求複雜度
• ❌ 無法反映後端處理情況

範例：

Nginx 配置參考：
- 單核可處理：~10,000 RPS（靜態內容）
- 單核可處理：~1,000 RPS（反向代理動態請求）

QPS (Queries Per Second)

定義：每秒執行的查詢操作數量

QPS = 總查詢數 / 時間（秒）

應用場景：

特點：

• ✅ 精確反映查詢層效能
• ✅ 適用於讀取密集型應用
• ❌ 不區分讀寫操作
• ❌ 不反映查詢複雜度

各系統 QPS 參考值：

TPS (Transactions Per Second)

定義：每秒完成的完整交易數量

TPS = 成功完成的交易數 / 時間（秒）

什麼是交易（Transaction）？

交易 = 一組必須全部成功或全部失敗的操作

範例：銀行轉帳
├── 1. 扣除 A 帳戶餘額
├── 2. 增加 B 帳戶餘額
└── 3. 記錄交易日誌
     ↓
這三個操作必須同時成功，否則全部回滾

應用場景：

特點：

• ✅ 最能反映業務處理能力
• ✅ 包含完整業務流程
• ✅ 符合 ACID 特性
• ❌ 計算較複雜
• ❌ 不同交易複雜度差異大

業界參考值：

相關指標

延遲指標 (Latency)

吞吐量與延遲的關係：

            高吞吐量
              ↑
    理想區域   │   過載區域
   （低延遲、  │  （高延遲、
    高吞吐）   │   吞吐下降）
              │
 ─────────────┼─────────────→ 高延遲
              │
    閒置區域   │   異常區域
              │

並發指標 (Concurrency)

Little's Law（利特爾法則）：

L = λ × W

L = 系統中的平均請求數（並發數）
λ = 平均到達率（吞吐量，如 RPS）
W = 平均等待時間（回應時間）

範例：
如果 RPS = 100，平均回應時間 = 0.5 秒
則平均並發數 = 100 × 0.5 = 50

其他吞吐量指標

實際應用

場景 1：Web 應用架構

使用者請求流程中的指標對應：

Browser ──→ CDN ──→ Load Balancer ──→ Web Server ──→ App Server ──→ Database
           │           │                  │              │            │
         RPS(CDN)   RPS(LB)            RPS(Nginx)     RPS(API)     QPS/TPS

場景 2：電商下單

一次下單操作的指標分解：

用戶點擊「下單」
    │
    ├── 1 RPS（HTTP 請求）
    │
    └── 後端處理
        ├── 查詢商品資訊（1 QPS）
        ├── 查詢庫存（1 QPS）
        ├── 查詢用戶資訊（1 QPS）
        ├── 查詢優惠券（1 QPS）
        ├── 建立訂單（1 TPS）
        │   ├── INSERT 訂單
        │   ├── UPDATE 庫存
        │   ├── UPDATE 優惠券狀態
        │   └── COMMIT
        └── 返回結果

總計：1 RPS → 4+ QPS → 1 TPS

場景 3：系統容量規劃

計算與監控

計算公式

# RPS 計算
RPS = 總請求數 / 統計時間（秒）

# QPS 計算
QPS = 總查詢數 / 統計時間（秒）

# TPS 計算
TPS = 成功交易數 / 統計時間（秒）

# 系統容量
最大 RPS = 1000ms / 平均回應時間(ms) × 並發執行緒數

監控工具

Nginx 查看 RPS

# 即時查看 RPS（每秒請求數）
tail -f /var/log/nginx/access.log | pv -l -i10 -r > /dev/null

# 統計最近一分鐘的 RPS
awk -v now=$(date +%s) '$4 ~ /\[/ {
    gsub(/\[/, "", $4);
    cmd = "date -d \""$4"\" +%s";
    cmd | getline ts;
    close(cmd);
    if (now - ts < 60) count++
} END { print count/60 " RPS" }' /var/log/nginx/access.log

MySQL 查看 QPS

-- 查看當前 QPS
SHOW GLOBAL STATUS LIKE 'Questions';
-- 間隔 1 秒再查一次，差值即為 QPS

-- 或使用 SHOW STATUS
SHOW GLOBAL STATUS WHERE Variable_name IN (
    'Queries',
    'Questions',
    'Com_select',
    'Com_insert',
    'Com_update',
    'Com_delete'
);

Redis 查看 QPS

# 查看 Redis 即時 QPS
redis-cli INFO stats | grep instantaneous_ops_per_sec

常見問題

問題 1：RPS 和 QPS 有什麼區別？

RPS：衡量 HTTP 請求數量（網路層）
QPS：衡量查詢操作數量（應用層/資料庫層）

一個 HTTP 請求（1 RPS）可能觸發多次資料庫查詢（N QPS）

問題 2：QPS 和 TPS 有什麼區別？

QPS：單次查詢操作（可能只是 SELECT）
TPS：完整交易（包含 BEGIN → 多個操作 → COMMIT）

一個交易（1 TPS）通常包含多次查詢（N QPS）

問題 3：如何提升 TPS？

問題 4：高 QPS 但低 TPS 說明什麼？

可能原因：
1. 交易包含大量查詢 → 優化業務邏輯
2. 交易鎖等待嚴重 → 檢查死鎖、鎖競爭
3. 交易提交慢 → 檢查磁碟 I/O、redo log
4. 大量交易回滾 → 檢查業務邏輯錯誤

總結

核心要點

快速對照表

選擇指標的原則

問自己：我要衡量什麼？

「系統能承受多少流量？」    → RPS
「資料庫查詢效能如何？」    → QPS
「業務處理能力如何？」      → TPS
「使用者體驗如何？」        → RT / P99

建立日期：2025-12-04 最後更新：2025-12-04