服務定位

k6 是 Grafana Labs 旗下的 scriptable load testing 工具、2021 年被 Grafana 收購。產品線分兩層：k6 OSS（Go 寫的 engine + JS API 描述 scenario、CLI 為主、output 可丟 Prometheus / InfluxDB / JSON / CSV）跟 Grafana Cloud k6（前 k6 Cloud、SaaS 多 region runner + 結果保存 + 跟 Grafana Cloud dashboard / Loki / Tempo 同 plane）。底層 engine 是 Go、不是 JS — JS 只是 scenario 描述層、runtime 由 Go 跑、所以單機 VU 容量比 Python-based 工具高出一個量級。

跟 JMeter 比、k6 走 code-first + CI-friendly、JMeter 走 XML / GUI + plugin ecosystem；JMeter 在 protocol 廣度（JDBC / LDAP / JMS / FTP）跟非工程團隊操作勝出、k6 在版控、PR review、artifact pipeline 勝出。跟 Locust 比、k6 用 JS、Locust 用 Python；Locust 對 Python team 自然、但 Python GIL 讓單機 VU 容量受限、需多 worker、k6 單機可跑數千 VU。跟 Gatling 比、Gatling 走 JVM + Scala/Java/Kotlin DSL、適合 JVM-heavy 團隊；k6 的 threshold + Grafana ecosystem 整合在 release gate 場景更直接。

定位

k6 適合把壓測納入工程流程。當團隊已經能描述 traffic shape、endpoint mix、arrival rate、think time 與 stop condition，k6 可以把這些模型寫成腳本，讓每次 release、capacity review 或 peak-event readiness 都能重跑同一組驗證。

這個定位讓 k6 接到三個主章。它從 9.2 Workload Modeling 接收流量模型，從 9.4 Saturation Discovery 接收 ramp-up 與 knee point 判讀，從 9.10 Production-Side 驗證 接收 canary、dark launch 或 production-like load test 的安全邊界。

適用場景

API 壓測是 k6 最穩定的入口。Checkout、login、search、order query、payment callback mock 與 internal API 都可以用 scenario 表達，並用 threshold 把 latency、error rate 與 throughput 轉成 pass / fail 訊號。

CI performance gate 是 k6 的常見價值。團隊可以在 merge、nightly、pre-release 或 game day 前跑固定 baseline，觀察 p95 / p99、error rate、throughput 與 regression trend，再把結果交給 6.13 Performance Regression Gate。

Peak readiness rehearsal 適合用 k6 表達階段式負載。活動前可以用 ramping arrival rate 模擬 T-90、T-30、T-7、T-1 與 T-0 的負載階段，並把結果回寫到 9.11 高峰事件準備。

最短判讀路徑

判斷 k6 deployment 是否健康、最少看四件事：

• Scenario design：用 executor: ramping-arrival-rate 而非 constant-vus、把 RPS / arrival rate 設成 first-class、VU 由 engine 自動算；scenario 描述跟 9.2 Workload Modeling 的 endpoint mix、think time、cohort 對得起來
• Threshold gate：thresholds 區塊明確寫 p95 / p99 / error rate / throughput、CI fail 條件清楚、不靠人眼看 summary 判斷 pass / fail
• Output 進 observability stack：--out experimental-prometheus-rw 把 metric remote-write 到 Prometheus、Grafana dashboard 接 k6 同 datasource、結果跟 target service 的 saturation metric 在同一張圖上看
• k6 Cloud vs CLI 邊界：本地 CLI 跑 baseline + CI、Grafana Cloud k6 跑跨 region / 大規模 / 結果 retention；不要把 CI gate 放 Cloud（成本 + 時間不對）、也不要本地單機硬跑 100k VU（runner 自身瓶頸假象）

四件事任一缺失、就是 scenario 已經寫得不完整、threshold gate 失效、或 runner 觀測缺失。

選型判準

腳本化價值來自可重跑。一次性的壓測只能回答當天配置能撐多少；可版本化 scenario 可以回答 release 後容量曲線有沒有漂移，並讓退化調查回到同一份 workload model。

CI 友善價值來自交接成本低。壓測結果要能轉成 artifact、threshold、trend 與 gate decision，才會從「工程師手動跑工具」變成 release 流程的一部分。

API 導向價值來自後端路徑明確。k6 很適合 checkout API、search API、internal API 與 webhook receiver；如果主要問題是完整 browser UX、第三方真實支付或多裝置同步，文章要把資料準備、side effect 與環境隔離另外寫清楚。

跟其他工具的取捨

k6 和 JMeter 的主要差異是工作方式。k6 偏程式化腳本、CLI、CI artifact 與工程流程；JMeter 偏 GUI、protocol plugin、既有企業測試流程與非工程團隊協作。

k6 和 Gatling 的主要差異是生態與語言。k6 使用 JavaScript-style 腳本，Gatling 偏 JVM / Scala / Java / Kotlin 生態；團隊語言能力與既有 pipeline 會影響維護成本。

k6 和 Locust 的主要差異是團隊技能與模型表達。Locust 使用 Python，對 Python 團隊與 custom user behavior 很自然；k6 的 threshold、CLI 與雲端 / Grafana 生態讓 release gate 整合更直接。

k6 和 Vegeta 的主要差異是場景複雜度。Vegeta 適合簡單 HTTP load、CLI workflow 與快速 saturation 探測；k6 適合較完整的 multi-step scenario、threshold 與長期 baseline。

核心取捨表

選 k6 的核心訴求：API-first scenario + CI gate + Grafana / Prometheus ecosystem 已用、且團隊接受 JS DSL。Protocol 廣度需求大、走 JMeter；Python team、走 Locust；JVM-heavy、走 Gatling。

進階主題

k6 Browser：基於 Chromium + Playwright API、跑在 k6 同 scenario 內、可混 protocol-level 跟 browser-level load（前段 API call、後段真實 browser flow）。意義是「pure API load 跟 real user UX 在同一份 scenario」、不用維護兩套工具。但 browser VU 比 protocol VU 重幾十倍、runner cost 要重新算。

xk6 extensions：用 Go 寫 k6 extension、補 protocol（Kafka / Redis / SQL / AMQP）或 output（custom backend）。xk6 build 生出客製 binary、organization 可維護自家 extension。意義是 k6 不只跑 HTTP — Kafka producer load / Redis hot-key probe 都能用同一個 scenario harness。

Grafana Cloud k6（前 k6 Cloud）：SaaS 跑 multi-region runner、結果保存、跟 Grafana Cloud dashboard / Loki / Tempo / Prometheus 同 plane。適合 跨 region 真實延遲驗證、大規模 distributed run、結果 retention + team share。跟 Grafana Cloud 已用的團隊 ecosystem 一致；只用 OSS 的團隊走 k6 Operator on k8s。

Distributed execution：自管 distributed 走 k6 Operator on Kubernetes、scenario 拆 instance、結果 aggregate 到 output。意義是不需要 k6 Cloud 也能跑跨機器 load、但 runner pool 自管成本 + 結果 aggregation 自己處理。

Output integration：--out experimental-prometheus-rw 直接 remote-write 到 Prometheus、Grafana dashboard 一張圖看 k6 client metric + target service saturation；--out cloud 上 Grafana Cloud k6；--out json=... 落地檔案給 CI artifact；--out influxdb 接 InfluxDB（legacy）。Loki 用來接 k6 console log、Tempo 用來接 k6 trace（若 scenario 帶 W3C trace context）。

排錯與失敗快速判讀

• VU 跑不上去 / runner CPU 滿：scenario 寫了重 JS 邏輯（big JSON parse、複雜 regex、crypto）— 把 setup-once 邏輯搬 setup()、不要每 VU iteration 重算
• Resource throttling 假象：runner 機器 CPU / network bandwidth / file descriptor 自身瓶頸、target service 還沒到 saturation — 換大機 / 多 runner / 看 runner 自身 saturation metric 排除
• Threshold 設過嚴 / CI 一直 red：threshold 抄 production SLO 不留 budget — staging tenant 跑 5-10 次抓 baseline distribution、threshold 設 baseline + buffer、不是 SLO 直接搬
• p95 看起來好但 user 抱怨慢：scenario endpoint mix 跟 production traffic shape 不符 — 補 production endpoint distribution、按 weight 配 scenario、跟 9.2 Workload Modeling 對齊
• Script logic 太重 / VU iteration 不穩：在 scenario 內做 token refresh / large payload 處理、iteration 時間漂移 — 用 executor: ramping-arrival-rate 鎖 RPS 而非 VU count、iteration 時間漂移由 engine 吸收
• 結果無法回放 / 找不到 baseline：output 沒落 artifact、Grafana dashboard 沒存 time range — 每次 run 強制 --out json + tag scenario version + push 到 evidence package

操作成本

k6 的主要成本是 workload model 維護。腳本本身容易寫，真正的成本在 production endpoint mix、資料分布、tenant / region / user cohort、think time 與 peak shape 的持續校正。

Runner 成本會隨負載規模上升。單機 runner 適合小型 API baseline；跨 region、數十萬 RPS 或長時間 soak test 需要分散式 runner、網路成本、目標服務隔離與觀測儲存。

測試資料治理是高風險成本。Checkout、payment、order、email、notification 與 webhook 路徑都可能產生 side effect，因此 scenario 要明確定義 test tenant、idempotency key、mock boundary、cleanup 與 stop condition。

Evidence Package

k6 結果應回寫到 evidence package。最小欄位包括 scenario version、target environment、time range、VUs / arrival rate、threshold、p95 / p99、error rate、throughput、target service saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓 release gate 能判斷。k6 的 threshold pass 只是其中一個訊號；gate 還要看 target service 的 CPU、connection、DB latency、cache hit rate、queue lag 與 cloud cost。

案例回寫

k6 目前在 09 案例庫中主要作為工具類承接點，案例主角仍是負載形狀與驗證節奏。它可回寫到 9.C15 Tixcraft 售票壓測 的 pre-event load test 判讀、9.C1 Prime Day readiness 的 staged validation、9.C28 FanDuel 雙峰 workload 的多模型壓測需求、9.C2 GR8 Tech FIFA World Cup readiness 的 54000 TPS @ 25ms p95 驗證、以及 9.C7 Lyft 8x peak 跨 100+ 微服務的獨立 threshold 設計。

這些案例提供的是負載形狀與工程節奏。k6 頁引用案例時，要把 case 轉成 workload model、ramp-up、threshold、runner 規模與 stop condition，並讓工具回到可替換的承載選項 — 例如 GR8 Tech 25ms p95 是 threshold pass / fail 的硬目標、Lyft 的「8x 是特定服務、不是全部 8x」要拆成 per-service scenario。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.4 Saturation Discovery
• 跨模組：6.13 Performance Regression Gate
• 官方：Grafana k6 documentation

壓測理論的角色是讓「加機器能不能解決」這個問題從直覺變成可推導。沒有理論基礎時、容量決策容易陷入「跑壓測 → 看數字 → 加機器」的盲試循環；有理論之後、可以從「現在的延遲 / 吞吐 / 並發量」反推「瓶頸在哪個資源、加什麼有效」。

本章是 9.2-9.12 的共同基礎。後續章節的 workload modeling、saturation discovery、capacity planning、SLO 都會回引本章的數學工具。讀者可以把這章當作「容量規劃的最小詞彙表」、其他章節是這些詞彙的應用情境。

本章不深入推導公式、聚焦在 工程意義。讀完之後讀者能回答：為什麼系統在 80% utilization 就該擴、為什麼加機器會邊際效益遞減、為什麼 sub-ms 延遲需求會反推架構選擇。

Little’s Law：穩態系統的最小數學工具

Little’s Law 用一條等式 L = λW 把三個變數綁在一起：L 是系統內平均並發數、λ 是請求到達率、W 是請求平均逗留時間。這個關係在 穩態（流量已穩定、不在 warmup 階段）必然成立、不需要假設特定分布或服務模式。

工程上最有價值的用法是「反推」。給定預期 RPS λ = 1000 跟 SLO latency 上限 W = 200ms、能算出系統最大穩態並發 L = 1000 × 0.2 = 200。這個 200 直接對應「connection pool size」「thread pool size」「async worker count」這類容量參數 — 訂得比 200 小、系統撐不住預期流量；訂得比 200 大太多、資源浪費。

反向也成立。當 connection pool 卡死在某個 size L、latency budget W 已訂、能算出可支撐的 RPS。這個算法在 capacity planning 階段比 ramp-up 壓測更快、可以先用 Little’s Law 篩掉明顯撐不住的配置、再用壓測驗證剩下的候選。

對應案例：Coinbase sub-ms 把 W 訂在 sub-millisecond、所有架構選擇都從這個 W 反推；Tubi ML p99 < 10ms 從 W 反推 feature lookup 必須 cache hit 路徑、不能回到持久 store。

詳見 Little’s Law 卡片。

Queueing Theory：為什麼 80% 利用率就是 knee

排隊論（M/M/c 模型）解釋了一個常見直覺：「系統在 50% utilization 看似還很閒、80% 就該擴、90% 已經太晚」。這個直覺不是經驗法則、是 數學必然。

M/M/c 系統的平均 queue length 跟 utilization 之間是非線性關係。當 utilization 從 50% 漲到 70%、queue length 約增加 2-3 倍；從 70% 漲到 90%、queue length 增加 10 倍以上。latency 跟 queue length 成正比（Little’s Law 又出現）、所以 latency 也呈現同樣的指數成長。

工程意義：健康系統運轉在 50-70% utilization、超過 80% 就接近 knee、超過 90% 進入不可預測區。「為什麼明明還沒滿就 saturate」的答案就在這條曲線。autoscaler 的 target metric 通常訂在 60-70%、是 queueing theory 推導出的安全邊界、不是工程師憑感覺。

多 server 模型（M/M/c）比單 server（M/M/1）有顯著容量優勢：c 個 server 的有效容量遠超 1 個 server 容量 × c。這也解釋了為什麼水平擴容（多開幾個 instance）通常比垂直擴容（單機加 CPU）划算 — 不只是規模、是 queue 行為的本質差異。

對應案例：GR8 Tech 25ms p95 把 p95 維持在 25ms 同時撐 54K TPS、靠的是 永遠不讓系統進入 knee、AI 預測讓擴容窗口縮短到 reaction time 內。

Universal Scalability Law：擴容會邊際失效

USL（Neil Gunther 提出）的公式 throughput(N) = N / (1 + α(N-1) + βN(N-1)) 解釋了「為什麼加機器到某個點之後 throughput 反而下降」。兩個常數 α 跟 β 描述系統的擴展限制：

• α 是必須序列化的部分（Amdahl’s Law 的對應）。distributed lock、coordinator、單一 leader DB 都是 α 來源。α 越大、線性擴容越早 plateau。
• β 是節點間互相通訊的成本（crosstalk）。cache invalidation broadcast、consensus quorum、cross-region replication 都是 β。β 比 α 更危險、會讓 throughput 在 N 大到某點後 反向下降。

工程上 α 比較好處理 — 把序列化部分拆細、用 partition 切分、用 sharded coordinator。β 比較難 — 通訊本質就需要協調、降低 β 通常要重新設計分散式協議（例如 Spanner 用 TrueTime 把跨節點交易的協調成本降低）。

對應案例：Spanner 線性擴展到 10 億 req/sec — TrueTime API 讓跨地區交易的 β 降到可接受、達成傳統 OLTP 做不到的線性；Coinbase RAFT consensus — RAFT 的 quorum 通訊讓 β 不可降、所以 選擇不橫向擴、改用 z1d + Cluster Placement Group 榨單機。

詳見 USL 卡片。

Saturation Curve：linear → knee → cliff

實際系統的 latency vs throughput 曲線分三段。第一段是 linear region — utilization 低、latency 平穩、加流量幾乎不影響 latency。第二段是 knee — utilization 接近 80%、latency 開始指數成長、再加流量會明顯變慢。第三段是 cliff — 系統進入不穩定區、latency 不可預測、可能 timeout、可能 cascade failure。

容量規劃的關鍵概念是 knee point = 設計容量上限。健康系統運轉在 knee 以下 50-70%、留出 headroom 應付 burst 跟 forecast 誤差。沒有量過 knee 的系統等於「不知道距離崩潰多遠」 — 平日看起來穩、實際隨時可能因為一個小 spike 進入 cliff。

不同 system 的 knee 位置差異很大。stateless service 通常 knee 在 80% CPU；DB 因為 lock contention、knee 可能在 60% utilization；broker / queue 因為 disk I/O bottleneck、knee 可能在 50%。容量規劃時不能一概而論、必須個別量測。

每次重大改動後必須 re-test knee。新增功能、改 ORM、升級 library、調 GC tuning、改 cache 策略 — 任何一個都可能讓 knee 往不好的方向移。

對應案例：Tixcraft DynamoDB IOPS 20 → 135K — partition 設計均勻時 saturation point 可以推到極遠（6750x 擴展）；Amazon Ads 9000 萬 RPS — 線性擴展靠 partition key 均勻、不靠 vendor 神話。

詳見 Saturation Point 卡片。

反推：從業務 KPI 到系統參數

理論工具的真正價值在「反推」 — 不是先設計系統再量測 saturate 多少、是 先訂業務目標再反推系統參數。這層思維把容量規劃從 reactive（撐到撐不住才擴）變成 proactive（按業務需求預先配置）。

反推流程通常從 latency budget 開始（詳見 9.12 SLO 與 Performance Budget）：

1. 從 user-perceived end-to-end latency（例如 p99 500ms）開始
2. 拆到每個 stage（網路、CDN、application、cache、DB、第三方）的 latency 配額
3. 配額決定每個 stage 的設計選擇 — DB 配 50ms → 不能跨 region、application 配 100ms → 不能多層 microservice hop
4. 配額 + 預期 RPS → Little’s Law 算每個 stage 的並發
5. 並發 → 每個 stage 的容量需求 → 實例數 / connection pool size / cache size

反推失敗的常見徵兆：算出來的某個 stage 容量超過 vendor 提供的上限（例如「需要 50 萬 DynamoDB RCU」可能超過單一 table partition 上限）、或某個 stage latency 配額過短（例如 cross-AZ 網路至少 1-2ms、配 0.5ms 不可能達成）。這時要回頭調整 SLO 或重新設計架構。

詳見 Latency Budget 卡片。

案例對照

下一步路由

• 下游：9.2 Workload Modeling（把模型量化成 production traffic）
• 下游：9.4 Saturation Discovery（實測 knee point）
• 跨章節：9.12 SLO 與 Performance Budget（latency budget 拆解）

既建知識卡片

• Little’s Law
• Universal Scalability Law
• Saturation Point
• Latency Budget
• Tail Latency

觀察

2025 年 Prime Day 期間 AWS 主要服務的峰值數字（引自 AWS News Blog）：

基礎設施層面：AWS Graviton 處理器承擔超過 40% 的 EC2 compute、部署超過 87,000 顆 Inferentia / Trainium AI 晶片、AWS Outposts 對機器人下達 5.24 億條指令（年增 160%）。

判讀

Prime Day 是「可預期極端峰值」的標竿。它的容量問題不是「會不會撐住」、而是「準備到什麼程度才划算」。對應主章問題節點：

1. Capacity Planning（9.6）：年度活動的容量計算可以用歷史 baseline × 預期成長 × headroom 三項相乘、但 Prime Day 規模下、每一項的不確定性放大都會變成數百萬美金成本差異。Amazon 公開的年增率（API Gateway +30%、CloudFront +43%、ECS on Fargate +77%）顯示連 Amazon 自己每年的成長預測都不能直線外推。
2. Performance Observability（9.8）：DynamoDB 「1.51 億 RPS、毫秒級回應」這種敘述同時包含吞吐與延遲、是 production-grade 容量地圖的最小單位。只說吞吐不說延伸分布、容量資訊不完整。
3. Improvement Loop（9.9）：FIS 混沌實驗 8 倍於 2024 顯示 Amazon 把「在 Prime Day 之前主動製造失敗」當成必修課、不是事後檢討。這層投資跟容量規劃同等重要。

策略

這個案例可以抽出三個跨平台可重用的工程做法。

1. 把可預期峰值寫進服務級 SLO：Prime Day 在 SQS / Lambda / DynamoDB / Aurora 都建立了內部 SLO baseline、平日跑在 baseline 之下、峰值是擴張到「設計容量」而不是「實驗容量」。這跟 9.12 SLO 與 Performance Budget 直接對齊。
2. pre-scaling + scheduled capacity：CloudFront 43%、API Gateway 30% 的年增率都是 提前算進 容量計畫、不是當天 reactive 擴容。對應 EC2 Auto Scaling 的 predictive / scheduled scaling 模式。
3. 事前主動製造失敗、不靠當天 reactive：FIS 8x 成長代表「在 Prime Day 之前 6800 次 chaos test」、把驗證成本前置到容量規劃階段。這條跟 06.4 Chaos Testing 形成閉環 — 06 講失敗模式驗證、09 講容量地圖、兩者在 Prime Day 級別的事件上必須一起做。

跨平台等效：GCP 的 Compute Engine MIG + Predictive Autoscaler、Azure 的 VM Scale Sets + Predictive Autoscale、Kubernetes 生態的 KEDA + Karpenter 都可以實作同樣的 pre-scaling 策略。差異是 vendor 整合度、不是工程概念。

下一步路由

• 想規劃年度活動容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想設計可預期峰值的 SLO → 9.12 SLO 與 Performance Budget + 06.6 SLO 與 Error Budget 政策
• 想做事前混沌驗證 → 06.4 Chaos Testing + 06.22 Steady State Definition
• 對照不同形狀的峰值 → 9.C2 GR8 Tech（事件型不可預期峰值）/ 9.C3 Coinbase（無峰值低延遲）

引用源

• AWS services scale to new heights for Prime Day 2025: key metrics and milestones
• Conquering Peak Retail Events with AWS
• Predictive scaling for Amazon EC2 Auto Scaling

概念位置

模型命名中的 active parameter 線索：

模型在不同維度的影響：

事實查核註：active parameter 跟模型能力的關係是社群常見回報、不是嚴格定理；具體模型在 coding / reasoning / 對話等任務的表現依訓練資料、RLHF、prompt 風格變化、需以 SWE-bench 等公開 benchmark 跟自己工作流校準。

設計責任

理解 active parameter 後可以解釋兩個現象：為什麼 30B MoE 跟 30B Dense 在同硬體下生字速度差很多（前者每 token 只走 3B active）、為什麼 MoE 模型能力對應的「等價 Dense 大小」不是簡單線性（社群常見回報接近總參數的 60% ~ 80% 等價 Dense 能力、但 case-by-case）。

選 MoE 模型時、active parameter 是速度判讀軸、總參數是記憶體判讀軸、能力判讀靠自己工作流的 benchmark；不要直接拿「30B」跟 Dense 30B 作能力對等。

概念位置

Flash Attention 在推論架構中的角色：

1推論時的 attention 計算：
2  ├── 原始實作：Q · K^T 整個算完、寫進 memory、再讀出來做 softmax、再算 · V
3  │     └── 多次 memory 讀寫、長 context 下 IO 成為瓶頸
4  └── Flash Attention：用 tiling 把計算切塊、中間結果留在 SRAM / register
5        └── 減少 memory 讀寫、長 context 加速明顯

跟 attention 變體的關係：

• Flash Attention 是實作層的優化、跟 MHA / GQA / MLA 等架構層變體是兩個獨立維度。
• 不同變體都能搭配 Flash Attention 的實作技巧。

在 llama.cpp 中的旗標：

1llama-server -fa  # 啟用 flash attention
2# 或
3llama-server --flash-attn

事實查核註：Flash Attention 的版本演進快（Flash Attention 1 / 2 / 3）、不同推論引擎的支援度依版本變化。具體限制（如「V cache Q4 量化要 -fa 才能啟用」）依 llama.cpp 版本變動、引用前以 llama-server --help 跟 release notes 為準。

設計責任

理解 Flash Attention 後可以解釋兩個現象：為什麼啟用 -fa 後長 context 推論速度提升明顯（IO bound 變 compute bound）、為什麼部分 KV cache 量化組合（如 V=Q4_0）在 llama.cpp 上需要 flash attention 才能跑（實作層面的耦合）。

工程實務上、啟用 flash attention 通常沒副作用（數學上等價、品質不變）、是 PC 場景長 context 推論的預設啟用旗標。詳見 5.2 KV cache 量化策略 的 flash attention 段落。

理解這個機制不只是為了知識本身。後續所有加速技巧（speculative decoding、MTP、KV cache、量化）都是在攻擊這兩個瓶頸的不同部分；不懂瓶頸在哪，看到「2x 加速」「3x 加速」這種廣告詞就無從判讀。

本章目標

讀完本章後，你應該能回答：

1. 為什麼 LLM 採用「一個 token 接一個 token」的生成方式、而非整段一次生出？
2. 為什麼 Apple Silicon 的「統一記憶體」對 LLM 推論是優勢？
3. 為什麼模型量化能加速、而非只是省記憶體？
4. 為什麼長 prompt 的首字延遲特別有感？

自回歸架構：一次只能吐一個 token

自回歸的核心概念是「下一個 token 的生成需要前面所有 token 的結果」。模型每生成一個 token，都要把目前已有的 token 序列（你的 prompt + 它已經生成的部分）重新丟進神經網路算一次，得到下一個 token 的機率分佈，挑一個輸出，然後重複。

舉個具體例子。當你輸入 寫一個 Python function 計算費氏數列，模型生成回答的過程大致是：

1. 把 prompt 丟進模型，產出第一個 token，例如 def。
2. 把 prompt + def 丟進模型，產出 fib。
3. 把 prompt + def fib 丟進模型，產出 (。
4. 一直重複到模型決定產出結束 token。

每一步都要跑一次完整的神經網路 forward pass（神經網路把輸入資料從第一層算到最後一層、產出輸出的單次計算）。這就是為什麼回答長度直接影響等待時間、跟雲端旗艦模型一樣；差別只是雲端每個 forward pass 跑得更快。

陷阱是把自回歸跟 streaming 混淆。Streaming 只是把已產出的 token 即時顯示在畫面上，看起來「邊想邊說」；模型內部該跑幾次 forward pass 就是幾次，streaming 不會加速生成本身。

記憶體頻寬：Apple Silicon 真正的瓶頸

LLM 推論的瓶頸幾乎一定落在記憶體頻寬、而不是算力。原因是每生成一個 token 都要把整個模型的權重從記憶體讀到處理器一次；模型有多大、每秒能讀多少 GB、就決定了每秒能吐幾個 token。每生一個 token 都要把整份權重讀過一次、所以「每秒能讀完幾份權重」就是「每秒能吐幾個 token」。

模型大小的換算規則很簡單：bf16 每個權重佔 2 bytes、Q4 量化後每個權重約 0.5 byte。所以：

• Gemma 4 31B 的 bf16 權重約 62GB（31B × 2 bytes）、Q4 量化後約 18GB。
• M4 Max 的記憶體頻寬約 546 GB/s、M2 Pro 約 200 GB/s。
• 理論上限 = 頻寬 / 模型大小。M4 Max 跑 Q4 量化 31B 模型、理論上限約 546 / 18 ≈ 30 tok/s。

實際數字會比理論上限低 30 ~ 50%（attention 機制的 KV cache 也要讀寫、有些運算需要中間結果），所以 M4 Max 跑 Q4 31B 大約落在 20 ~ 25 tok/s。這個推導讓你看到任何「在 Mac 上跑 70B 模型很快」的說法時，可以直接用頻寬算一下合不合理。

Apple Silicon 的**統一記憶體**（Unified Memory Architecture, UMA）讓 CPU、GPU、Neural Engine 共用同一塊記憶體、省下跨 PCIe 搬資料的成本。傳統 PC + NVIDIA GPU 的記憶體分成系統記憶體跟 VRAM；模型權重要放進 VRAM 才能用 GPU 跑、跨 PCIe 搬資料的速度成本很高。Mac 的 64GB 統一記憶體可以幾乎全部給模型用（扣掉系統保留部分）、同等價位的 PC 通常只有 12GB ~ 24GB VRAM。

這就是為什麼 Mac 在「跑得動多大的模型」上佔優勢，但在「跑多快」上輸給 H100。H100 的 HBM 頻寬約 3,300 GB/s，是 M4 Max 的 6 倍。能跑得動 vs 跑得快，是兩件事。

量化：用精度換頻寬

量化的核心是把模型權重從 16-bit float 壓成 4-bit、5-bit、8-bit integer。權重數量不變，但每個權重佔的 bytes 變少；模型總大小變小，每秒能讀過的權重變多，生字速度直接變快。

常見量化等級：

接近真實的選擇：

• 32GB Mac 跑 31B 模型：選 Q4_K，記憶體佔用 ~ 18GB，留 14GB 給系統與 IDE。
• 24GB Mac 跑 14B 模型：選 Q5_K 或 Q4_K，看任務品質要求。
• 16GB Mac 跑 7B 模型：選 Q4_K，是現實上界。

陷阱是把量化等級拉到極限以塞下更大模型。Coding 任務上 Q3 的 31B 模型常輸給 Q5 的 14B 模型；模型「夠大」跟「夠好」是兩件事、選 model size 時先看任務通過率、再用量化等級調記憶體。後續 模型選型章節 會展開這個取捨。

KV cache 與長 prompt 痛點

KV cache（key-value cache）把 attention 機制每個 token 產生的中間結果暫存、後續 token 生成時直接讀 cache 跳過重算、讓「已經算過的 prompt」省下重複跑 forward pass。

但 KV cache 有兩個性質會放大長 prompt 的痛點：

1. 首次處理 prompt 時要完整算過一次、這個階段稱為 prefill。10K token 的 prompt 在本地可能需要 30 ~ 90 秒才 prefill 完、這 30 ~ 90 秒就是 TTFT 的主要來源。
2. KV cache 本身佔記憶體：長 context 跑下來、KV cache 可能比模型權重還大、會擠壓可用記憶體。

這就是為什麼 coding agent 場景（塞整個 repo 進 prompt）在本地特別痛：每次都要重新 prefill，每次都等 30 ~ 90 秒。oMLX 這類特化伺服器就是針對這個痛點，用 paged SSD KV cache 把已 prefill 過的 context 存到 SSD，下次同樣的 prompt 前綴可以直接讀 cache，把 TTFT 從 30 ~ 90 秒降到 1 ~ 3 秒。詳見 0.4 MLX / MTP / oMLX。

Speculative decoding 與 MTP

既然瓶頸是「每生一個 token 都要讀一次完整模型權重」、那能否一次生多個 token？speculative decoding（推測解碼）就是這個想法的具體實作。

機制大致是：

1. 用一個小模型（drafter、例如 1B 參數）快速猜未來 N 個 token。
2. 把這 N 個 token 一次餵給大模型（target、例如 31B 參數）、讓大模型並行驗證每個位置的機率分佈。
3. 大模型保留認同的前綴、從第一個拒絕點之後重新生成。

這個機制能加速的關鍵是「大模型的驗證可以並行」。一次 forward pass 驗證 N 個 token 的時間，跟驗證 1 個 token 的時間差不多（因為瓶頸是讀權重，不是算力）。如果接受率高，等於一次 forward pass 產出多個 token。

寫 code 場景特別適合 speculative decoding、因為 code 有大量可預測 pattern（縮排、括號、常見變數名、import 語句）、小模型猜對的接受率高。Google 為 Gemma 4 釋出官方 drafter、官方數據在 coding 任務有 2 ~ 3 倍加速；接受率低的任務（純創意寫作、隨機字串生成）加速幅度可能降到 1.5 倍左右、加速倍數跟任務 pattern 強相關。

Multi-Token Prediction（MTP）是這個概念的具體實作、本質是 speculative decoding 的工程化版本。下一章 0.4 MLX / MTP / oMLX 會把 MTP 跟其他容易混淆的術語放在一起對照。

何時這套推導失準

「頻寬決定生字速度」是 dense 模型 + 單請求情境下的乾淨推導。實務上有三類情境會讓這個公式失準、解讀效能數字時要對應調整：

1. MoE 模型（Mixture of Experts）：每個 token 只啟用部分專家層、實際讀的權重遠小於總權重。例如 Mixtral 8x7B 名義 46B 參數、但每個 token 只啟用約 12B、速度上限要用「啟用權重」算、不是總權重。判讀 MoE 模型在 PC 獨立 GPU 上的部署細節見 MoE CPU 卸載。
2. 多請求 batching：資料中心級推論伺服器把多請求 batch 一起跑、權重讀一次處理 N 個 token、攤平頻寬成本。本章開頭舉的「H100 跑 200 tok/s」是 batch=1 的單 user 數字、production 場景 batch=32 時單 user 看到的速度更接近 50 tok/s、但 total throughput 翻 N 倍。詳見 batching 卡片。
3. Speculative decoding 接受率變動：MTP / drafter 的加速幅度跟任務 pattern 強相關、coding 任務的 2 ~ 3 倍無法直接 carryover 到創意寫作、看 benchmark 數字時要追問「跑的是哪類任務」。

判讀效能數字時的反射動作：先問「dense 還是 MoE」「batch 多少」「任務 pattern 強弱」、再決定能不能套頻寬公式。

下一章

下一章：0.2 三層架構，把任何本地 LLM 工具放回正確的層級。

跟 Backend 04 的分工：本文從 client-side 使用角度說明 Sentry 的 error tracking、performance monitoring 與 session replay — SDK 怎麼埋、error 怎麼分群、release 怎麼追蹤。Server-side 平台治理（告警路由整合、SLI 指標設計、self-hosted vs SaaS 成本治理、跟 OTel 的整合）見 Backend 04 Sentry vendor page。

Sentry 的核心是 error tracking — 自動捕獲未處理的例外、提供 stack trace、自動分群（grouping）相同 root cause 的 error。在 error tracking 的基礎上，Sentry 擴展了 performance monitoring（transaction / span）和 session replay（重播使用者操作）。

Error tracking

Sentry 的 error tracking 架構有三個層次：SDK 端的自動捕獲、server 端的 issue grouping 和 UI 端的 issue management。

自動捕獲

Sentry SDK 在各平台註冊全域錯誤處理器（和模組三 自動攔截的機制相同）。捕獲到例外後，SDK 收集 stack trace、breadcrumbs（最近的使用者操作）、device context（OS / browser / device model）和自訂 tags，打包成 event 送到 Sentry server。

Issue grouping

Sentry server 收到 error event 後，用 fingerprinting 演算法判斷這個 error 是否和已有的 issue 相同。預設的 fingerprinting 基於 stack trace 的 frame — 如果兩個 error 的 stack trace 指向同一個位置，歸入同一個 issue。

自訂 fingerprint 讓開發者控制 grouping 邏輯。例如：不同使用者觸發的同一個 API error 可能有不同的 stack trace（因為 call site 不同），但 root cause 相同 — 自訂 fingerprint 把它們歸入同一個 issue。

Issue management

每個 issue 有狀態（unresolved / resolved / ignored）、指派（誰負責修復）、趨勢（這個 issue 的發生頻率是上升還是下降）。Sentry 的 UI 提供 issue 列表、趨勢圖、影響範圍（影響多少使用者）。

Performance monitoring

Sentry 的 performance monitoring 用 transaction 和 span 模型（和 OpenTelemetry 的 trace / span 概念相同）。

Transaction 代表一個完整的操作（頁面載入、API 請求處理）。Span 是 transaction 內的子操作（database query、外部 API 呼叫）。Transaction 和 span 的 duration 構成操作的時間分佈。

Performance monitoring 的價值是發現「慢」的問題 — P95 回應時間超過閾值、特定 span 佔了 transaction 80% 的時間。和 error tracking 互補：error 告訴你「什麼壞了」，performance 告訴你「什麼慢了」。

Session replay

Session replay 錄製使用者的操作過程 — DOM 變化、滑鼠移動、點擊事件 — 在 Sentry UI 中重播。開發者可以看到「使用者在觸發 error 之前做了什麼操作」。

Session replay 的實作是 DOM snapshot + mutation recording。記錄的是 DOM 結構的變化（非螢幕錄影），在重播時重建 DOM。資料量比錄影小很多，但仍然是所有 Sentry 功能中資料量最大的。

隱私考量：session replay 會看到使用者輸入的內容（除非做 masking）。Sentry 提供 privacy configuration 控制哪些元素被 mask（輸入框、敏感資料區域）。

自架方案和 Sentry 的差距

Sentry 的核心價值在 issue grouping 和趨勢分析 — 把大量 error event 歸類成可管理的 issue 列表，自動追蹤每個 issue 的趨勢。自架方案用 grep 做不到自動 grouping。

下一步路由

• Firebase 的整合方案 → Firebase 套件
• Datadog 的全棧 APM → Datadog RUM
• 自架 vs 商業的判斷 → 自架 vs 商業的判斷決策表
• 自架方案的 error fingerprint 實作 → Error Fingerprint 與去重分群

服務定位

JMeter 是 Apache Software Foundation 的 OSS load testing tool、Java 寫、用 XML 描述 thread group / sampler / listener 組成的 test plan（.jmx 檔）、支援 GUI 與 CLI（non-GUI / headless）雙模式。它是業界最老牌、protocol 覆蓋最廣的壓測工具 — sampler 直接覆蓋 HTTP、JDBC、JMS、SOAP、FTP、SMTP、IMAP、TCP、JUnit、OS process 等。

跟 k6 比、JMeter 走 GUI-driven + protocol 廣、k6 走 code-first（JavaScript）+ HTTP 為主；JMeter 適合 QA 團隊維護、k6 適合 dev / SRE 寫進 CI。跟 Locust 比、JMeter 用 XML + plugin、Locust 用純 Python class、custom client 彈性 Locust 強但 protocol 內建支援 JMeter 廣。跟 Gatling 比、JMeter 偏 GUI / 多 protocol、Gatling 偏 JVM DSL（Scala / Java / Kotlin）+ async runtime、單機 throughput Gatling 較高但 protocol 廣度與既有資產承接 JMeter 勝。

關鍵張力：GUI / protocol 廣度 ↔ 單機 throughput / CI 友善度 是選 JMeter 的根本取捨。GUI 適合 QA 團隊與跨角色協作、.jmx 又有 plugin 生態與十多年累積；代價是 XML diff 難 review、GUI listener 吃記憶體、CI 整合相比 k6 / Gatling 多一層 packaging。

JMeter 適合測試資產已經存在的組織。當團隊有大量 .jmx 測試計畫、QA 團隊用 GUI 維護 scenario、或壓測需要跨 HTTP、JDBC、JMS 與其他 plugin protocol，JMeter 的價值在於承接組織流程，而不只是產生 HTTP 負載。這個定位讓 JMeter 接到 9.3 壓測工具選型 與 9.10 Production-Side 驗證。它能支援 production-like test 的多系統 dependency，但 evidence package 要補上測試計畫版本、plugin 版本、runner 配置與結果保存方式。

適用場景

多 protocol 壓測是 JMeter 的主要入口。企業服務常同時需要測 HTTP API、JDBC query、JMS queue、FTP 或 mail flow，JMeter 的 sampler 與 plugin 生態能讓同一份測試計畫覆蓋多種 dependency。

GUI 協作適合非純工程團隊。QA、測試中心或受監管環境常需要可視化測試設計、審核與交接，JMeter 的 GUI 能降低跨角色溝通成本。

Legacy 測試資產適合保留 JMeter。既有 .jmx 檔案、listener、plugin 與報表流程如果已經運作多年，重寫到 k6、Gatling 或 Locust 的機會成本要用維護收益抵銷。

最短判讀路徑

判斷 JMeter deployment 是否健康、最少看四件事：

• Thread group 設計：thread count / ramp-up / loop count / duration 是否反映真實流量模型、有沒有用 Stepping Thread Group（plugin）或 Concurrency Thread Group 控制 arrival rate、不是把 thread 當「user」直接綁
• Listener 配置：GUI listener（View Results Tree / Aggregate Report / Graph）只在 design / debug 階段開、正式跑必須改 Simple Data Writer 輸出 JTL、結果分析交給離線 HTML report 或外部 Grafana
• Distributed mode 設定：單機 thread 上限約 3000-5000（受 JVM heap 與 thread context switch 限制）、超過要走 master + slave（remote engine）；slave 機器 plugin / JMeter version / JVM 參數要跟 master 一致、否則結果不可信
• GUI vs CLI 模式區分：GUI 是 design / debug only、production load 一律走 jmeter -n -t plan.jmx -l result.jtl；GUI 跑大規模測試會把 listener 拉爆記憶體、結果反而失真

四件事任一缺、就是 9.3 壓測工具選型 邊界的待補項目。

選型判準

多 protocol 價值來自 dependency coverage。當 workload model 包含 database、queue、file transfer 或 legacy endpoint，JMeter 可以把不同 dependency 的壓力放在同一個測試計畫中觀察。

GUI 協作價值來自跨角色可見性。這個優點會帶來版本控制成本，因為 XML diff 不容易 review；團隊要補上 naming、folder structure、parameterization 與 review checklist。

跟其他工具的取捨

JMeter 和 k6 的主要差異是 workflow。JMeter 偏 GUI、plugin 與既有企業流程；k6 偏 code-first、CLI、threshold 與 CI artifact。

JMeter 和 Gatling 的主要差異是 scenario 表達。JMeter 用 test plan、thread group、sampler 與 listener 組裝；Gatling 用 JVM DSL 描述 simulation，較適合工程團隊維護複雜 flow。

JMeter 和 Locust 的主要差異是自訂能力。JMeter 依賴 plugin 與 sampler，Locust 可以直接用 Python library 實作 custom client；如果 protocol 特別特殊，Python 團隊可能更適合 Locust。

JMeter 和 Vegeta 的主要差異是複雜度。Vegeta 適合快速 HTTP saturation probe；JMeter 適合多步驟、多 dependency 與可交接測試計畫。

操作成本

JMeter 的主要成本是測試計畫治理。.jmx 檔案可以累積大量 listener、debug sampler、hard-coded variable 與過期 assertion，長期不整理會讓壓測結果失去可追溯性。

Runner 成本來自 JVM 與 listener。GUI listener 適合開發階段觀察，不適合大規模壓測；正式測試要使用 non-GUI mode，把結果輸出成 JTL、HTML report 或外部 metrics。

Plugin 成本來自版本漂移。不同 runner、不同工程師機器或 CI image 的 plugin 版本如果不一致，同一份測試計畫可能產生不同結果，因此要把 plugin 清單、JMeter 版本與 container image 固定下來。

Evidence Package

JMeter 結果應回寫到 evidence package。最小欄位包括 test plan version、JMeter version、plugin list、runner topology、thread group 設定、ramp-up、duration、p95 / p99、error rate、throughput、target saturation metric 與 known gap。

Evidence package 的核心用途是讓結果可審查。JMeter 測試計畫常由多人維護，gate decision 要能追到哪一版 .jmx、哪一組 runner、哪一批測試資料與哪一個目標環境。

進階主題

JMeter Plugins 生態：jmeter-plugins.org 社群維護的 plugin 集合補齊原版 JMeter 的不足 — Custom Thread Groups（Stepping / Ultimate / Concurrency / Arrivals）讓 thread schedule 反映真實 arrival rate、PerfMon 抓 remote server CPU / memory、Throughput Shaping Timer 直接以 RPS 為目標而非 thread count、Dummy Sampler 拿來 mock dependency。Plugin Manager 統一安裝、CI image 要把 plugin 清單固定（PluginsManagerCMD.sh install <plugins>）避免漂移。

BlazeMeter Cloud / Distributed execution：自建 distributed mode（master + slave 跨多 VM）成本高 — slave 機器要同 JMeter 版本、同 plugin、同 JVM 參數、RMI port 開通、結果回傳網路足夠。BlazeMeter（Perforce / 前 CA）是 JMeter SaaS、直接吃 .jmx 跑 cloud-scale 壓測、附 geo-distributed runner、適合短期 spike 測試不想自建 distributed cluster 的團隊。trade-off 是 vendor lock-in 跟 per-test 計費 — 長期高頻測試自建較划算。

Distributed mode 細節：master 機器發 control plane（thread group 配置、test plan 分發）、slave 跑 thread 並回傳 sample 結果。瓶頸常出在 master 收結果（RMI / 自訂 protocol），不是 slave 跑不動 — 大規模測試應該關掉 GUI listener、用 Backend Listener 把 metric 即時推到外部時序資料庫、master 只收彙整指標而非每個 sample。同步要點：所有 slave 用同一份 .jmx 與 test data CSV，CSV 不能依賴 master local path。

Backend Listener + Grafana 整合：JMeter 原生 Backend Listener 支援 InfluxDB / Graphite / Elasticsearch、把 active thread / response time / hit / error 即時推出去、Grafana 配 official JMeter dashboard 即時看 throughput / latency curve。這個組合取代 GUI listener、是 distributed mode 的標準觀測方式 — listener overhead 從 master 移到外部時序系統、master 不再被 GUI 拉爆。配合 4 observability 的時序資料庫已有時、JMeter metric 進同一個 Grafana、跟 application 端的 latency / error 並列、加速 6.13 Performance Regression Gate 的對照判讀。

排錯與失敗快速判讀

• GUI 模式吃記憶體爆 / OOM：GUI listener（View Results Tree / Graph）會把所有 sample 留在 heap、跑大規模就 OutOfMemoryError — 設計階段才開 GUI、正式跑切 jmeter -n non-GUI、listener 用 Simple Data Writer 寫 JTL 而非 in-memory aggregate
• Listener 拖累 throughput / 結果失真：太多 listener 同時開、每個 sample 都被多個 listener 處理、JMeter 自身成為瓶頸 — 正式測試只留 Simple Data Writer + Backend Listener、結果分析離線跑 jmeter -g result.jtl -o report/ 產 HTML
• Thread group 計算錯 / 真實流量對不上：把 thread 當「user」直接設、忽略 think time + ramp-up、結果壓出來的是 thread 全速跑而非業務流量 — 改用 Concurrency Thread Group 或 Throughput Shaping Timer 直接以 RPS 為目標、配 Constant Timer 模擬 think time
• Distributed mode 結果跟單機對不上：slave 機器 plugin / JMeter version / JVM heap 不一致、或 CSV 路徑只存在 master — 把 slave 環境 container 化（同 Docker image）、CSV 隨 .jmx 一起分發、--remote-start 統一啟動
• .jmx XML diff 不可 review / merge conflict 多：多人同時改測試計畫、GUI 改完 XML 結構大變 — 拆 fragment（Test Fragment + Module Controller）、scenario 分檔、parameterization 走外部 CSV / properties、PR review 看截圖 + 跑結果而非 raw XML diff
• Plugin 版本漂移 / CI 結果不可重現：dev 機器 plugin 跟 CI image 不同版 — 固定 plugin manifest、CI image 用 PluginsManagerCMD.sh install-for-jmx plan.jmx 從 plan 自動安裝、版本鎖到 image tag
• HTTPS / TLS 連線數爆炸：JMeter 預設每 thread 一個 TLS handshake、large thread count 把 server TLS 拖垮、結果反而測到 TLS 不是 app — 開 HTTP Cache Manager 跟 KeepAlive、必要時調 httpclient4.idletimeout

案例回寫

JMeter 在 09 案例庫中適合作為 enterprise load test 承接點。它可回寫到 9.C15 Tixcraft 售票壓測 的 pre-event validation、9.C17 BookMyShow ticketing 的售票流量模型、9.C1 Prime Day readiness 的 staged validation、9.C13 Hotstar IPL 1860 萬同時觀看 的全球直播 pre-event rehearsal、以及 9.C14 Standard Chartered 跨 7 個受監管市場的 Aurora 4000 TPS 容量驗證。

這些案例提供的是複雜業務流程與活動前驗證節奏。JMeter 頁引用案例時，要把 case 轉成 thread group、ramp-up、data set、dependency sampler 與 result artifact，並讓負載數字回到業務流程判讀 — 例如 Hotstar 的「集中地理區 CDN 壓力」要在 JMeter 用 per-region thread group 模擬、不是把全球流量塞進單一 runner。

下一步路由

• 上游：9.3 壓測工具選型
• 上游：9.10 Production-Side 驗證
• 平行：k6、Gatling、Locust
• 跨模組：6.13 Performance Regression Gate
• 官方：Apache JMeter documentation

Workload modeling 的角色是讓壓測結果有意義。如果壓測模型跟 production traffic shape 不一致、壓測通過不代表 production 撐得住。這一層的工作不是「製造大量請求」、而是「製造跟 production 一樣形狀的請求」。

跟 9.1 壓測理論 的關係：9.1 提供推導工具、9.2 把工具的輸入（流量參數）量化。沒有 workload model、Little’s Law 的 λ 跟 W 都是猜。

本章的核心問題：production traffic 不是「N RPS」這麼簡單。它有時間分布、地理分布、操作分布、cohort 分布、burst pattern。每個維度都會影響系統行為。一個只測「總 RPS」的壓測通過了、production 還是可能因為某個 cohort 集中或某個 burst pattern 出事。

Traffic shape 的五個維度

Production traffic shape 至少要量五個維度才算 model 完整。

平均吞吐 vs 峰值：peak/avg ratio 是工程意義最大的單一指標。1.5x 的 peak/avg 代表流量相對平緩、容量規劃可以接近 average peak；3-5x 的 peak/avg 代表 bursty 流量、必須按 peak 規劃、平日大幅 over-provision。對應案例：ASOS Black Friday 24h 1.67 億 / 峰值 3500 RPS 峰均比約 1.81x 屬於相對溫和；Tixcraft 5 分鐘賣完 是另一極端。

時間分布：日內（早晚通勤）、週內（週末活躍）、月內（月初發薪）、季內（節慶）、年內（活動）。不同尺度的週期都要記錄、用於 forecast 跟 pre-scaling 決策。

用戶分布：geographic（哪個 region 多）、device（mobile vs desktop）、tier（free / paid / VIP）。同樣 RPS、不同分布可能造成完全不同系統行為 — VIP 用戶可能跑更複雜 query、mobile 用戶可能更多 retry、跨 region 用戶可能更多 cross-zone latency。

操作分布：read vs write 比、不同 endpoint 的 mix。一個系統 90% read 跟 50% read 的容量設計完全不同 — read-heavy 可以 cache、write-heavy 必須關注 storage IOPS。

Cohort 與 burst pattern：同一秒的請求不一定均勻 — bursty arrival 比 Poisson arrival 對系統更殘酷。突發 burst 來源：promo 推播、KOL 推廣、新片發布、新聞事件。

對應案例：GR8 Tech 賽事高潮 burst — 賽事「進球瞬間」 burst 比平均流量高 10-50 倍；Disney+ 新片發布 — 同片瞬間集中、cohort 高度集中。

從 production log 抽 workload model

實務上 workload model 不能憑空寫、要從 production data 抽。流程通常分四步：

第一步：data 蒐集。從 access log、APM trace、metric 系統取得 production traffic 樣本。要 sampling（不是全量）、避免影響 production；要包含 至少一個完整 weekly cycle（含週末、含峰谷）；要按 endpoint / per-tenant 分組。

第二步：分組統計。對每組（per endpoint、per tier、per region）計算 percentile（p50 / p95 / p99）、arrival pattern（Poisson、bursty、scheduled）、payload size 分布。輸出是「workload profile」 — 比單一數字更接近 reality。

第三步：序列重播。複製一段 production traffic 的時間序列、保留 inter-arrival timing（不只是 RPS 平均、是 每秒幾個）。這層讓 burst 在壓測重現、不只是「平均壓力均勻分布」。

第四步：脫敏處理。PII（user_id、phone、address）必須匿名化或替換 — 否則壓測環境變成 PII 洩漏點。常見做法：hash + salt + 確保結果 cardinality 跟 production 一致。

production log 通常缺寫入 payload（log 只記 metadata、不記 request body）、要從 application metric 或 schema sample 補。schema sample 用「distinct value 抽樣」、不是「random」 — 確保壓測涵蓋常見 value pattern。

Synthetic load vs production replay

兩種主要壓測方式各有取捨。

Synthetic load：手寫腳本、明確控制每個請求的 shape。優點是好複現、可以針對特定情境設計（例如「測登入失敗 retry」）；缺點是容易脫離 production reality、寫腳本的人會無意識套用自己的偏見。

Production traffic replay：用 GoReplay、Istio mirror、AWS VPC Traffic Mirroring 等工具把 production traffic 複製到測試環境。優點是 最貼近真實、自動帶上 burst 跟 cohort；缺點是消耗 production 下游資源（要算進容量規劃）、PII / 合規處理複雜、replay 環境的下游 mock 不容易做。

混合模式：常態壓測用 synthetic（cheap、可控）、release candidate 驗證用 production replay（真實）、debug 特定 incident 用 特定時段 的 replay。三種工具在不同階段用、不是二選一。

對應案例：FanDuel 雙峰需要兩個 workload model 並行 — 直播 model（CDN heavy、長 session）跟投注 model（低延遲、burst at goal）必須分開壓測、不能合成一個。

詳見 Workload Model 卡片 跟 Shadow Traffic 卡片。

模型驗證：怎麼知道模型像 production

寫了 workload model 之後、怎麼驗證它真的「像 production」？方法是 跑壓測 同時 對比 production metrics。

驗證指標包含：throughput pattern（總 RPS、各 endpoint mix）、latency 分布（p50 / p95 / p99 對比）、resource utilization（CPU / memory / network 行為）、error rate 與 retry pattern。

兩個可能的偏差結果：

• 模型撐不住但 production 撐得住 → 模型太苛刻、可能高估了流量或操作複雜度。usually fine、調整模型參數即可。
• 模型撐得住但 production 撐不住 → 模型不足、漏了某個維度。dangerous、需要回到 data 蒐集階段找漏掉的 pattern。

對應案例：Zoom 30x COVID surge — 之前的 workload model 完全不能用、必須 reset baseline 重新從 post-COVID 流量抽 model；Tixcraft 10K t2.micro 壓測 — 用實際售票場景重播驗證、不是 synthetic 數字。

模型維護：定期 review

Workload model 不是一次抽完就永久有效。業務變化會讓模型過時、過時的模型導出的容量規劃會失準。

需要 re-抽 model 的訊號：

• 新功能上線改變 user journey（例如新增 video upload、user 行為變寫多）
• 新市場進入改變 cohort 分布（例如進入印度市場、mobile share 大幅增加）
• 行銷活動改變 burst pattern（例如新增 push notification、burst 集中度上升）
• 用戶習慣轉變（例如 work-from-home 讓週末跟平日流量比變化）

維護節奏建議每季 review 一次、重大產品改動立即 re-抽。每次 re-抽要 跟前一版對比、量化變化幅度、決定哪些容量計畫要重新評估。

案例對照

下一步路由

• 上游：9.1 壓測理論
• 下游：9.3 壓測工具選型（用什麼工具實作 model）
• 下游：9.4 Saturation Discovery（用 model 跑 ramp-up）
• 跨模組：04 可觀測性模組（production log 來源）

既建知識卡片

• Workload Model
• Shadow Traffic
• Growth Curve
• Peak Forecast

觀察

GR8 Tech 從本地基礎設施遷移到 AWS、重建為微服務架構後的關鍵數字（引自 GR8 Tech case study）：

服務組合：Amazon EKS（Kubernetes 容器編排、跨雲端與本地）、Amazon EC2（compute）、Amazon S3 與 Amazon EBS（儲存）、AWS Auto Scaling 結合 GR8 Tech 自家 AI 預測模型、AWS Infrastructure Event Management（重大賽事支援）。

擴展範圍：「Scaled to 15 markets using AWS」。事件覆蓋：2022 FIFA World Cup 期間零停機。

判讀

GR8 Tech 的工程做法揭露三個事件型峰值的判讀重點。

1. 不可預期 ≠ 不可預測：賽事「何時開打」是已知的（schedule 提前公告）、「賽事內何時爆量」是未知的（進球、加時、最後一分鐘）。AI 預測模型不是預測「會不會有峰值」、而是預測「峰值在 60 秒內可能多大」、把擴容窗口縮短到反應時間之內。對應 9.11 高峰事件準備 跟 9.6 容量規劃模型 的「預測時間尺度」軸。
2. 延遲是業務指標、不是技術指標：「2-3 秒額外延遲」直接造成「投注失敗、客戶流失」。25ms p95 是收入 KPI 而不是 SLO 漂亮數字。對應 9.8 效能可觀測性 把 latency 翻成業務 metric 的責任。
3. 微服務 + 容器編排是擴容粒度的前置：遷移前的單體系統「擴容」只能複製整套系統、成本曲線陡峭。EKS 拆解後可以針對熱點服務（投注引擎、結算引擎）獨立擴容、跟 9.5 瓶頸定位流程 的逐層定位直接對齊。

需要警惕的判讀盲點：54000 TPS @ 25ms 是 公開的成功數字、不是「永遠都這樣」的承諾。AI 預測模型必然有預測誤差、AWS Infrastructure Event Management 也是事件型服務、不是平台預設。這類案例適合作為「目標可達性」的存在證明、不適合直接套用為自家服務的容量假設。

策略

可重用的工程做法：

1. 把賽事 schedule 灌進 capacity forecast：在事件已知的條件下、預先把 baseline 拉高、避免 AI 模型在零起跑時擴容。對應 EC2 Auto Scaling 的 scheduled scaling + predictive scaling 雙模。
2. AI 模型輸入要包含領域訊號：通用 ML autoscaler 用 CPU / latency 預測、領域 autoscaler 還會用 賽事重要性、投注量歷史曲線、下注玩家集中度 等業務訊號。這層讓擴容時機從反應式變成預測式。
3. 熱點服務獨立擴容、不是整體擴容：投注引擎跟結算引擎的峰值時間不一致（投注集中在賽前 + 比賽中、結算集中在賽後）、單獨擴容比整體擴容省 25%+ 成本。
4. AWS Infrastructure Event Management 等廠商支援服務：在年度重大事件可以申請（World Cup、Olympic、Black Friday 等）、提供 pre-scaling 與專屬監控通道。這在 GCP / Azure 也有對等服務（GCP Customer Care Premium、Azure Event Management Support）。

跨平台等效：GCP GKE + Vertical Pod Autoscaler + 自家 ML 預測、Azure AKS + KEDA + Azure ML 預測、自建 Kubernetes + Karpenter + Prometheus 推導模型都可以實作同樣的「預測 + 擴容」模式。

下一步路由

• 想做事件型峰值的容量預測 → 9.11 高峰事件準備 + 9.6 容量規劃模型
• 想用 AI / ML 做預測式擴容 → 9.9 Performance Improvement Loop + 9.8 效能可觀測性
• 想拆解微服務以便獨立擴容 → 9.5 瓶頸定位流程 + 9.7 成本邊界與 efficiency
• 對照不同形狀的峰值 → 9.C1 AWS Prime Day（可預期極端峰值）/ 9.C3 Coinbase（無峰值低延遲）

引用源

• GR8 Tech Achieves High Performance and Scalability with Data Center Migration to AWS
• Predictive scaling for Amazon EC2 Auto Scaling
• Scheduled scaling for Amazon EC2 Auto Scaling

服務定位

Gatling 是 Scala-origin / 現以 Java DSL 為主流 的 load testing 工具、跑在 JVM、async / non-blocking engine（基於 Akka / Netty）讓單一 injector node 就能驅動高 RPS。它跟 k6 / JMeter / Locust 的核心差異在 語言生態 + engine efficiency + scenario 表達力、壓出負載的能力都具備：

• vs k6 — k6 走 Go runtime + JavaScript scripting、CLI / Grafana 生態友善；Gatling 走 JVM + Java/Scala/Kotlin DSL、適合既有 JVM 工具鏈與強型別 review
• vs JMeter — JMeter 走 GUI / XML test plan、適合非工程角色協作；Gatling 走 code-first、適合 PR / build pipeline / refactor 工作流
• vs Locust — Locust 走 Python coroutine、scripting 自由度高；Gatling 走 DSL + injection profile、scenario 結構化程度更高
• engine efficiency — async / non-blocking model 讓 Gatling 在單機可推到數萬 RPS、JMeter thread-per-user 在同等資源下 throughput 較低

產品線分兩層：Gatling OSS（開源 simulation runner + HTML report）與 Gatling Enterprise（前身 FrontLine、加上 distributed injector、cluster orchestration、live monitoring、long-term result storage、role-based access）。OSS 適合單機 baseline / CI smoke、Enterprise 適合 cross-region distributed / 大型活動前壓測 / 結果長期治理。

最短判讀路徑

判斷 Gatling 在壓測流程裡是否健康、最少看四件事：

• Scala DSL vs Java DSL 版本：Gatling 3.7+（2022）正式加 Java DSL、2024 後新專案多走 Java DSL；舊 Scala simulation 仍可跑、但團隊要決定 維持 Scala 還是漸進改寫 Java、避免雙語言治理
• Injection profile 設計：simulation 是否明確區分 open model（rampUsersPerSec / constantUsersPerSec、模擬真實 arrival）vs closed model（atOnceUsers / rampUsers、模擬 fixed user pool），對應 9.2 Workload Modeling 的 traffic shape
• Assertion gate：simulation 是否有 assertions { global.responseTime.percentile3.lt(500) } 這類 hard gate、CI 跑完直接 fail build；沒 assertion 的 simulation 只是壓測、不是 release gate
• Enterprise vs OSS 邊界：是否清楚知道哪些能力只 Enterprise 有（distributed injector / multi-region / long-term result storage / live dashboard）、避免用 OSS 拼湊 Enterprise 級需求

定位

Gatling 適合 code-first 且 JVM 能力強的團隊。當 workload model 需要多步驟 flow、資料 feeder、條件分支、session state 與明確 injection profile，Gatling 能用 simulation 把這些行為寫成工程 artifact。

這個定位讓 Gatling 接到 9.2 Workload Modeling 與 9.4 Saturation Discovery。它的價值在於把 traffic shape 寫進 injection profile，讓 ramp-up、constant users、stress peak 與 soak test 都能被版本化。

適用場景

JVM 團隊適合用 Gatling 承接壓測。Java、Scala 或 Kotlin 團隊能把 simulation 當成一般程式碼 review，並用既有 build、dependency、CI 與 artifact 流程維護。

複雜 scenario 適合用 Gatling 表達。登入、搜尋、加入購物車、checkout、payment mock、order query 這類 multi-step flow 可以用 session 與 feeder 管理資料。

高品質 report 適合 release review。Gatling 的 report 能幫 reviewer 看到 response time distribution、request group、error 與 injection profile，適合在 release gate 中保留可讀證據。

選型判準

JVM DSL 價值來自可維護性。壓測 scenario 如果需要被長期 review、重構、抽 helper 或接 build pipeline，Gatling 的 code-first workflow 會比 GUI test plan 更適合工程團隊。

Injection profile 價值來自負載形狀精準。團隊可以把 steady load、spike、ramp、open model 與 closed model 放到 simulation 中，讓 9.4 Saturation Discovery 的 knee point 判讀更可重現。

跟其他工具的取捨

Gatling 和 k6 的主要差異是語言與生態。Gatling 適合 JVM 團隊與強型別 simulation；k6 適合 JavaScript-style scripting、CLI workflow 與 Grafana 生態。

Gatling 和 JMeter 的主要差異是維護模式。Gatling 偏 code review、build pipeline 與 simulation abstraction；JMeter 偏 GUI、plugin 與跨角色測試資產。

Gatling 和 Locust 的主要差異是自訂語言。Locust 適合 Python 團隊與任意 Python client；Gatling 適合 JVM 團隊與 report / injection profile 的結構化壓測。

Gatling 和 Vegeta 的主要差異是 scenario 深度。Vegeta 適合快速 HTTP pressure test；Gatling 適合需要 session、feeder、assertion 與多 request group 的長期測試。

操作成本

Gatling 的主要成本是 JVM 團隊能力。非 JVM 團隊要承擔語言、build tool、dependency 與 simulation pattern 的學習成本；這個成本只有在 scenario 複雜度夠高時才划算。

測試資料成本來自 feeder 與 session。多步驟 flow 需要 account、cart、order、token、region 與 tenant 資料，資料過期或分布偏差會讓壓測結果失真。

Enterprise / distributed 成本要提前評估。單機 Gatling 適合中小型 baseline；跨 region、大型活動前驗證或長時間 soak test 需要 runner topology、結果集中與雲端成本治理。

Evidence Package

Gatling 結果應回寫到 evidence package。最小欄位包括 simulation version、injection profile、feeder source、target environment、assertion、response time distribution、error rate、throughput、target service saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓 simulation 可回放。Reviewer 要能從 report 回到 injection profile、scenario code、feeder 與目標環境，才有辦法判斷一次壓測是容量訊號還是測試設計偏差。

核心取捨表

選 Gatling 的核心訴求：JVM 團隊 + 複雜 scenario（session / feeder / 多 group）+ 高 RPS 單機效率 + HTML report 作為 release gate 證據。Java DSL 在 2024 後降低了 Scala 學習門檻、讓 Java/Kotlin 後端團隊不必再為了壓測導入 Scala。

進階主題

Gatling Enterprise（前 FrontLine）：商業版加 distributed injector cluster（跨 region / 跨 cloud 推大型負載）、live monitoring dashboard（real-time RPS / response time 趨勢、不用等 simulation 結束看 HTML）、long-term result storage（cross-run comparison、retention policy）、role-based access（QA / dev / SRE 不同權限）。對只跑單機 baseline 的團隊 OSS 已夠；要跑黑五 / 春晚級活動前壓測或多 region 同時施壓、需要 Enterprise 或自建 distributed topology。

Java DSL 取代 Scala 成主流（2022-2024）：Gatling 3.7（2022）正式釋出 Java DSL、3.9+ 文件 Java / Kotlin / Scala 三語並列、2024 後新教學多以 Java 為主。對 Java 後端團隊降低 onboarding 成本、但要注意 Gatling 2.x → 3.x 的 Scala syntax 不向後相容（scenario builder、http config、feed 用法都改寫）— 舊 simulation 升級時等於改寫一遍。

Distributed execution（OSS）：OSS 沒有內建 cluster orchestration、要靠 multiple injector + result aggregation：每台 injector 跑同一份 simulation（按 user count 切割）、結束後把 simulation.log 蒐集到一處用 gatling.sh 重跑 report stage。常見補位是用 Kubernetes Job + 共享 PVC、或直接走 Gatling Enterprise。

HTML report 與 release gate：simulation 跑完自動產 HTML report、含 response time percentile distribution（mean / p50 / p95 / p99 / max）、per-request-group breakdown、active users over time、error log。release gate 的標準做法是：CI job 跑 simulation → assertion gate fail 直接 break build → HTML report 存成 build artifact 供 reviewer 翻查、配合 Evidence Package 治理。

CI integration 模式：Jenkins / GitLab CI / GitHub Actions 都靠 mvn gatling:test / gradle gatlingRun / sbt gatling:test 入口、CI 設定 baseline simulation（每 PR 跑、catch regression）+ release simulation（release branch / nightly 跑、長時間 soak）。staging environment 跑壓測時要隔離噪音來源（其他 QA 流量 / cron job）、否則 RPS 數字會被污染。

排錯與失敗快速判讀

• Scala learning curve 拖累進度：團隊沒人會 Scala、被 implicit / case class / pattern match 卡住 — 改用 Java DSL（3.7+）或 Kotlin DSL、保留 Gatling 表達力但去除 Scala 學習成本
• Gatling 2.x → 3.x 升級 simulation 全紅：bootstrap import path / scenario builder API / feed 語法都變了 — 走 新專案直接 3.x、舊專案維持 2.x 雙軌、或安排專門 sprint 改寫、避免邊跑邊踩雷
• JVM heap OOM / GC pause 拖慢 RPS：高 RPS 下 default heap 不夠、Young Gen GC 頻繁 — 調 -Xmx4G -Xms4G、用 G1GC / ZGC、監控 injector 的 GC log 跟 CPU、不是只看 target service
• Injection profile 設計錯導致誤判 saturation：用 atOnceUsers(1000) 壓 closed model 但實際 traffic 是 open arrival、結果 knee point 找錯 — 看 production traffic shape、open model 用 constantUsersPerSec / rampUsersPerSec、closed model 才用 atOnceUsers
• Single injector node 撞 client-side bottleneck：injector CPU / network / file descriptor / source port 用滿、看起來 target saturate 其實是 injector saturate — 監控 injector resource、scale out 成 distributed 或走 Enterprise
• Feeder data 過期 / 分布偏差：用同一份 users.csv 反覆壓、cache hit rate 失真、production 看不到的 cache miss 路徑沒被測 — feeder 走 random / shuffle、定期 regenerate、覆蓋 long-tail key
• HTML report 看起來綠但 production 出事：assertion gate 只設 average response time、p99 / error rate 沒設、release 後尖峰時段才爆 — assertion 要明確設 p95 / p99 + error rate threshold、不只看 mean

案例回寫

Gatling 適合回寫多步驟與多負載模型案例。它可接 9.C28 FanDuel 雙峰 workload 的直播與投注雙模型、9.C16 SeatGeek waiting room 的 token / admission flow、9.C17 BookMyShow ticketing 的售票流程壓力、9.C4 DraftKings Aurora 金融帳本 的「比賽期讀爆量 + payout 時寫爆量」雙峰錯位，以及 9.C2 GR8 Tech 的「投注 / 結算 / 賠率更新」三類請求 group 的 injection profile。

這些案例的重點是 scenario 與 injection profile。Gatling 頁引用案例時，要把業務流程拆成 request group、session state、feeder、assertion 與 stop condition — 例如 DraftKings 雙峰錯位要寫成兩個 scenario 平行注入、各自有獨立 assertion budget。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.4 Saturation Discovery
• 平行：k6、JMeter、Locust
• 官方：Gatling documentation

壓測工具選型的核心不是「哪個工具最強」、是「哪個工具最貼合本團隊的 workload model 表達能力跟 CI 整合需求」。沒有絕對最好的工具、只有最匹配當前場景的工具。

跟 9.2 Workload Modeling 的關係：9.2 定義 workload 長什麼樣、9.3 找能複製這個樣子的工具。工具選對、壓測結果可信；工具選錯、壓測結果誤導。

本章不是工具教學、是 選型維度 + 主流工具的 適用情境。讀者讀完後能回答「我現在這個 workload 該用哪個工具」、而不是「哪個工具最快」。

六個選型維度

選工具時要按六個維度評估、不能只看「能不能跑 HTTP GET」。

腳本表達能力：能不能寫複雜 user journey（登入 → 瀏覽 → 加購物車 → 結帳）、不只是單一 HTTP request。複雜系統的壓測通常是 user journey 級別、單一 endpoint 壓測只能找絕對極限、找不到 cross-endpoint contention。

協議支援：HTTP / WebSocket / gRPC / TCP / 自家二進位協議。WebSocket 跟 gRPC 是現代後端常見、傳統工具（JMeter、wrk）可能要 plugin 補。

規模能力：單機可以發多少 RPS、能不能分散式擴容。本機 wrk 可發 10K-50K RPS；分散式 Locust 可發 1M+ RPS。決定因素：CPU 效率、async I/O 模型、是否單機 bound。

CI 整合：能不能在 PR 上跑 lightweight perf check、結果能不能機器可讀（JSON / Prometheus exposition）、能不能跟 baseline diff。沒有 CI 整合的工具只能做「事件型壓測」、無法做 continuous perf governance。

結果分析：原生 dashboard（k6 Cloud、Gatling Enterprise）/ Prometheus + Grafana 整合 / 純文字輸出。要看結果分發、團隊成員能不能輕鬆查詢歷史。

學習曲線：腳本語言（JavaScript / Scala / Python / Go）、團隊熟悉度。工具好但團隊不會用、會變成 1-2 個工程師的孤島技能、流失時整套廢掉。

主流開源工具對照

k6 是過去 5 年崛起的綜合首選。JavaScript 腳本（前端工程師也能寫）、原生 dashboard、Prometheus exposition、CI 友善。Grafana 收購後生態加速。缺點：複雜 stateful 場景（DB connection pool 共享）需要繞 workaround。

JMeter 是企業常見的 incumbent。協議支援廣（含 LDAP、JDBC、JMS）、有 GUI 編輯器。缺點：腳本是 XML、版本控制困難；GUI 主要用來生成腳本、實際跑壓測還是要 headless。已經在用的團隊建議繼續、新團隊不必特意選它。

Gatling 高 throughput 純 async、性能優秀、報表精美。缺點：Scala / Kotlin DSL 學習曲線陡、新版本（11+）改了 DSL 不向後相容。

Locust 是 Python 生態的選擇、特別適合複雜業務邏輯（用 Python 寫 user journey 自然）。分散式部署原生支援。缺點：Python 單線程 throughput 受限、要靠分散式擴容。

Vegeta 跟 wrk 是「quick check」工具、用於單一 endpoint 的極限測試。不適合複雜場景、適合 saturation discovery 第一輪「找這個服務的天花板」。

Production traffic replay 工具

當需要複製 真實 production traffic 的壓測場景時、需要另一類工具。

GoReplay 是最常用的開源 traffic replay 工具。在 production server 上 tcpdump-based 捕獲 HTTP traffic、可以 store 到 file 或 stream 到 staging 環境。優點：開源、無 vendor lock-in；缺點：HTTP only、加密流量要拿到 key 才能用。

Service mesh shadow（Istio / Linkerd mirror）：mesh 層 mirror traffic 到 staging service。優點：mesh 已部署的話 zero infra cost、加密 traffic 也能 mirror。缺點：需要 service mesh 已落地。

AWS VPC Traffic Mirroring：底層網路層 mirror、application 完全無感。優點：最低 invasion；缺點：AWS only、加密 traffic 要另外處理。

Diffy（Twitter / X 開源、已 deprecated 但概念仍有效）：dual-write 同時打到舊 / 新版本、比對結果。適合驗證「新版本是否邏輯正確」、不是純壓測。

對應案例：Tixcraft 10K t2.micro 壓測 — 用分散式 EC2 跑 synthetic load 模擬 100K 同時搶票；SeatGeek Virtual Waiting Room — token 配發邏輯通常用 dual-write 驗證新舊版本一致。

雲端 managed 壓測服務

當不想養 load test infrastructure、想 ad-hoc 跑大規模壓測時、用 managed service。

AWS Distributed Load Testing：CloudFormation 起 Fargate cluster 跑 JMeter 或 Taurus、報表寫到 S3。優點：一鍵部署、Fargate 計費；缺點：JMeter-based、不是現代 k6 風格。

Grafana k6 Cloud：託管 k6、跨地理 distributed 壓測（從多個 region 同時發流量）。優點：地理分散原生、跟 Grafana 整合無縫；缺點：vendor cost。

Azure Load Testing：Azure 原生、整合 Application Insights。優點：Azure 用戶無縫；缺點：相對較新、生態還在補。

GCP 沒有 first-party managed load testing：要靠 Marketplace 方案或自管 Locust on GKE。

工具選型決策樹

落地時的快速決策：

• 想快速驗證單一 API 極限 → wrk / Vegeta
• 想寫複雜 user journey + CI 整合 + JavaScript 團隊 → k6（新項目首選）
• 企業已有 JMeter 流程、不想換 → JMeter（接受 XML / GUI 複雜度）
• 大規模分散式 + Python 生態 → Locust
• 報表給管理層看、Scala 團隊 → Gatling
• 想複製真實 production traffic → GoReplay 或 service mesh shadow
• 想 ad-hoc 雲端大規模壓測 → 對應雲商的 managed load test

常見反模式

• 只測單一 API、不測 user journey：找不到 cross-endpoint contention、找不到 session state 累積
• 壓測機跟被測機在同一網段：網路延遲被低估、p99 比 production 樂觀
• 壓測時 throttle 自己的工具：結果不是被測系統的極限、是工具自己的極限
• 結果報表只看平均：tail latency 看不到、p99 退化被掩蓋
• 壓測環境跟 production hardware 不一致：CPU 型號、network、disk IOPS 差很大、結果不可外推
• 沒驗證 model：跑了壓測但沒對比 production metrics、不知道 model 是否貼近 reality

案例對照

下一步路由

• 上游：9.2 Workload Modeling
• 下游：9.4 Saturation Discovery（用工具找 knee）
• 下游：9.9 Improvement Loop（CI 整合）
• 跨模組：06.1 CI Pipeline（壓測在 CI 的位置）

既建知識卡片

• Load Test
• Workload Model
• Shadow Traffic
• Saturation Point

觀察

Coinbase 在 2023-05 推出國際交易所、上線後關鍵數字（引自 Coinbase Case Study）：

服務組合：

• Amazon EC2 z1d 實例：高頻 CPU + NVMe 本地儲存、針對單執行緒效能最佳化
• EC2 Cluster Placement Groups：強制把節點集中到單一機架附近、最小化 node-to-node 網路延遲
• Amazon Aurora：高速 transaction lookup 的關聯式資料庫
• 「Built from the ground up, using Cloud Native principles」（沒有複用既有交易所程式碼）
• 內部使用 RAFT consensus 維持交易順序

判讀

這個案例最值得讀的地方、是它「沒有做」的事比「做了」的事更有教學價值。

1. 沒有用 Auto Scaling：交易撮合引擎用 RAFT consensus 維持嚴格順序、節點數量是 consensus 一部分、不能臨時增加。容量規劃完全是 pre-provision、不是 reactive。對應 9.6 容量規劃模型 必須區分「可水平擴容服務」跟「不可水平擴容服務」、後者的容量公式只有 headroom × peak、沒有 elastic 補救。
2. 沒有用通用 EC2 實例：z1d 是 AWS 針對「高頻 CPU + NVMe」設計的特化實例、犧牲了通用性換取單核效能。這層選擇隱含一個容量規劃決策：單機效能上限 直接決定 系統理論吞吐上限、橫向擴容不能超過 RAFT 節點數限制、那麼縱向就必須榨乾。對應 9.5 瓶頸定位流程 必須先判斷瓶頸屬「可分散」還是「不可分散」。
3. 沒有用多區域分散：Cluster Placement Group 把節點壓到同一可用區內、犧牲了 region failover 速度、換取 node-to-node 網路延遲。這跟「高可用性」的常見直覺相反、是「延遲敏感型負載的容量設計優先於可靠性設計」的一個範例。
4. 延遲是設計輸入、不是設計結果：sub-millisecond 是先訂目標、再反推所有架構選擇的結果、壓測只是驗證手段。對應 9.1 壓測理論與系統行為 中 Little’s Law 的反向應用 — 給定延遲目標 + 吞吐目標、反推 concurrency 上限 + 每個 stage 的 latency budget。

需要警惕的判讀盲點：「sub-millisecond latency 達成」這類陳述通常指 p50 或 p90、不一定是 p99 或 p999。長尾延遲在 RAFT 系統下可能比平均高一個數量級（leader election、replication lag）。讀案例時要注意延遲分布 vs 平均值的差別。

策略

可重用的工程做法：

1. 延遲敏感型服務先做 latency budget 反推：給每個 stage（網路、CPU、磁碟、序列化、共識）一個 latency 配額、總和等於 SLO 上限。對應 9.12 SLO 與 Performance Budget。
2. 單機效能榨乾優先於橫向擴容：當 consensus / ordered processing 限制了水平擴容時、單機選型（CPU 頻率、NUMA locality、NVMe）變成主要槓桿。對應 9.4 Saturation Discovery 把 saturation 點推得越遠。
3. 拓樸感知的部署策略：Cluster Placement Group 是 AWS 名稱、概念是「網路拓樸感知的工作負載放置」。GCP 有 Compact Placement Policy、Azure 有 Proximity Placement Groups、自建 Kubernetes 有 Pod Topology Spread Constraints + Node Affinity。
4. 接受「不可彈性」是有意識決策、不是失敗：很多服務不該全部都自動擴容。設計時要區分「需要 elastic 的 stateless 邊緣」跟「必須 pre-provision 的有狀態核心」、容量規劃也要兩條腿。

跨平台等效：所有主流雲端都有對應的高頻 CPU 實例（GCP C2 / Azure HBv 系列）、placement policy 與本地 NVMe 儲存。自建環境可以用 SR-IOV + RDMA + NUMA pinning 達成更極致的版本。

下一步路由

• 想設計延遲敏感型服務的容量地圖 → 9.1 壓測理論與系統行為 + 9.6 容量規劃模型
• 想搞清楚哪些服務該水平擴容、哪些不該 → 9.5 瓶頸定位流程 + 9.4 Saturation Discovery
• 想做 latency budget 反推 → 9.12 SLO 與 Performance Budget + 04.16 SLI / SLO 訊號
• 對照不同形狀的負載 → 9.C1 AWS Prime Day（可預期極端峰值）/ 9.C2 GR8 Tech（事件型不可預期峰值）

引用源

• Coinbase Launches an Ultra-Low-Latency Cryptocurrency Exchange on AWS
• Coinbase Scales 50% Faster, Cuts Costs 62% with AWS
• Ultra-Low-Latency Crypto Exchange on AWS（video）

你應該看什麼

• Dropbox - Open sourcing our Go libraries

這個案例告訴我們什麼

1. Go 很常被選在 Python 已經不夠用的後端邊界。
2. 併發支援通常是遷移的重要原因之一。
3. 遷移通常先把性能最敏感的部分換成 Go，逐步擴展。

可對照的公開原始碼

• dropbox/godropbox
• dropbox/dropbox-api-spec

Dropbox 的公開 Go libraries 與 API spec 很適合對照閱讀。你會看到一個大公司如何把 Go 用在可重用工具與服務邊界上。

服務定位

Locust 適合把壓測寫成一般 Python 程式。當 workload model 需要呼叫 internal SDK、特殊 protocol、複雜資料準備、狀態機、隨機行為或自訂 client、Locust 可以直接使用 Python 生態來表達。底層架構是 master + worker 分散式 swarm、worker 之間用 Gevent green-thread（非 OS thread）模擬大量並發 user、master 負責 spawn rate、aggregation 跟 Web UI。

這個定位讓 Locust 接到 9.2 Workload Modeling 與 9.5 瓶頸定位流程。它能把特殊 client 與下游 dependency 放進同一個 user behavior、但也要求團隊處理 runner、資料與可重現性。

跟 k6（JS / Go runtime）比、Locust 用 Python 換到 自訂能力與生態相容、但代價是單 worker capacity 低、CPU bound 容易先打到自己。跟 JMeter（GUI / XML）比、Locust 偏 code-first 工程團隊、scenario 直接走 Git review、不靠 GUI plugin 拼裝。跟 Gatling（Scala DSL）比、Locust 換到 Python team 友善 + 既有 domain library 重用、但失去 JVM injection profile 的精細度與報表內建。

關鍵張力：Python 表達力 ↔ runner 效能上限。Python team 想 reuse domain library、staging fixture、API client 寫壓測腳本時 Locust 是首選；但要心裡有數 單 worker RPS 上限不高、超過幾千 RPS 就要靠 worker scale-out、不是調 Locust 本身。

適用場景

Python 團隊適合用 Locust 長期維護壓測。既有 domain library、API client、fixture、資料產生器與驗證 helper 都可以被壓測腳本重用。

自訂 protocol 適合用 Locust。HTTP 之外、如果服務需要 gRPC、WebSocket、binary protocol、message broker client 或自家 SDK、Locust 可以直接接 Python library。

Distributed load 適合用 Locust worker 擴展。當單機 Python runner 遇到 CPU 或 connection bottleneck、可以用 master / worker 拆開負載產生能力。

本章目標

讀完本頁、讀者能判斷：

1. Locust 在壓測 stack 中承擔哪一段（user behavior modeling / load generation / distributed swarm）、哪些要外接（Prometheus / Grafana 觀測 worker 自身、APM 看目標 saturation）
2. User class / task weight / on_start lifecycle 的 ownership 設計（誰寫 locustfile、誰 review、誰調 spawn rate）
3. Distributed master-worker 部署的容量規劃（單 worker user 上限、worker 數量計算、target RPS 對應 worker count）
4. 何時用 Locust、何時走 k6 / JMeter / Gatling 的取捨

最短判讀路徑

判斷 Locust 壓測是否健康、最少看四件事：

• User class 設計：每個 HttpUser / User subclass 是不是一個明確的 persona（mobile user / API client / admin user）、wait_time 是否反映真實使用者間隔（不是 0 拼最大 RPS、是 between(1, 5) 模擬 think time）、user state 是否在 instance 內封閉
• Task 比例：@task(weight) 數字是否對應 production traffic mix（80% read / 15% write / 5% admin、不是每個 endpoint 等比例）、weight 是否走版控 review
• on_start lifecycle：login / token fetch / session bootstrap 是否寫在 on_start（每個 user 一次）、不是寫在 @task 裡（每個 request 都重做）— 寫錯位置會讓 auth endpoint 變成主要 traffic
• Distributed master-worker：worker 數量是否夠（單 worker 跑幾千 user 後 CPU 會先打死、不是目標服務先死）、master 是否獨立機器（master 也跑 user 時 aggregation 跟 Web UI 會卡）、--expect-workers 是否設、worker sync drift 是否觀察

四件事任一缺失、就是壓測證據可信度的待補項目。

日常操作與決策形狀

locustfile 結構：locustfile.py 是 Python module、定義 User / HttpUser subclass、每個 user 有 wait_time、若干 @task(weight) method、on_start / on_stop lifecycle hook。執行用 locust -f locustfile.py --host=https://target 起 Web UI、或 locust --headless -u 1000 -r 100 -t 10m 在 CI 跑無 UI 模式。locustfile 應該走 Git review、不是 GUI 改完就跑。

Task weight / wait_time 設計：weight 是 相對權重、不是百分比 —@task(8) + @task(2) 等於 80% / 20%。wait_time = between(1, 5) 在每個 task 之間等 1-5 秒、模擬 think time；若要拚最大 RPS 用 constant(0)、但同時要意識到這就不是 user behavior 模型、是 throughput probe。

on_start vs @task 的邊界：on_start(self) 每個 user instance 啟動時跑一次、適合做 login、token fetch、cache warm、fixture lookup；@task 是 user 行為主迴圈、每次選一個 task 跑。把 login 寫在 @task 是常見錯誤、會讓 IdP 變成主壓力來源、不是目標 API。

Gevent-based concurrency：Locust 用 gevent 的 green-thread 模擬大量 concurrent user、不是 OS thread。意義是單 worker 可以跑幾千個 user、但 CPU bound 工作（JSON serialization、加密、本地計算）會 blocking 整個 worker 的 event loop。gevent.monkey.patch_all() 要在 import 第一行、否則 socket / time / ssl 不會被 patch、blocking call 會卡死 swarm。

Distributed master-worker：單機到極限時開 distributed — locust --master 起 master、locust --worker --master-host=master.example.com 起 worker。Master 負責 Web UI、spawn rate 控制、result aggregation、stat 收集；worker 負責跑 user。Master 不該跑 user（會跟 aggregation 搶 CPU、stat 失真）。worker 數量計算：先單 worker 拉到 CPU 80% 看能撐多少 user、目標 user 數除這個值 + 20% buffer。

Custom load shape：除了固定 -u 1000、Locust 支援 LoadTestShape subclass 寫 時間軸負載曲線 — spike test（瞬間 0 → 5000 user）、ramp test（線性爬升）、wave test（週期性高低交替）、step test（階梯式增加）。tick() method 每秒回傳 (user_count, spawn_rate)。用 custom shape 才能模擬 9.C16 SeatGeek waiting room 那種 ticket drop 瞬間衝擊。

Prometheus exporter / 觀測：Locust 內建 stat 只是 in-memory 的 p50 / p95 / p99 / RPS、結束就消失。長期觀測接 locust-prometheus-exporter（或 --csv result.csv 自己抓）、把 metric 推到 Prometheus + Grafana。worker 自身的 CPU / memory / network 一定要同時觀測、不然分不出是目標 saturation 還是 worker 已死。

Locust Cloud（managed SaaS）：2024 後 Locust 推官方 Locust Cloud、託管 master + worker + result storage、付費換 ops 成本。自管 master-worker 對 CI / staging 是合理的；production 等級的 scale test（10k+ concurrent user）跑一次要拉幾十台 worker、用 Cloud 省 infra ops 是合理 trade-off。

核心取捨表

選 Locust 的核心訴求：Python team + custom user behavior + 既有 domain library 重用、且能投入 worker scale-out 預算（單 worker capacity 低、要靠分散式補）+ scenario 走 Git review 不靠 GUI。標準 HTTP 高 RPS 單機壓測直接走 k6 更快、非工程角色協作壓測走 JMeter、JVM team 精細模擬走 Gatling。

進階主題

Distributed Locust 的 master-worker swarm：production scale test 通常需要 10-100 個 worker。實作要點：worker 之間 不要 共享 state、shared resource 由 master 統一發（用 zeromq message bus）；worker 加入 / 離開時 user 會 redistribute、避免 user index 當 unique key；worker 跨 region 跑時 latency 來自 worker → target 不只是 target 內部、要在 worker 本身的 region 對齊。

Custom load shape（spike / wave / step）：LoadTestShape.tick(self) return (user_count, spawn_rate) tuple 每秒被叫一次。Spike test：前 60 秒 0 user、第 61 秒瞬間衝 5000、模擬 9.C16 SeatGeek waiting room 的 admission storm。Wave test：sine wave 在 1000-3000 user 之間振盪、測 autoscaling 反應速度。Step test：每 5 分鐘加 1000 user、觀察哪一階開始降級。custom shape 是 Locust 比 k6 強的點之一。

跟 Prometheus exporter 整合：locust-prometheus-exporter 把 Locust stat 推到 Prometheus / Grafana、做長期 baseline、跨 test 比較、p99 退化偵測。實務上要在 dashboard 同時放 Locust 內部 stat + worker host metric + 目標服務 APM、三層 stack 起來才能判讀是 runner 還是目標 saturation。

Locust Cloud（managed SaaS）：2024+ 官方 SaaS、託管 master + worker + result + dashboard。trade-off：自管適合 CI / staging / 內網壓測（target 跑在內網時 Cloud 連不到）；Cloud 適合大規模一次性 scale test（拉 50 worker 跑 2 小時、跑完即停、不想自己 infra ops）。

操作成本

Locust 的主要成本是 runner overhead 與分散式治理。Python runner 的效能上限要用 worker scale-out 解決；壓測結論要同時檢查目標服務 saturation 與 worker 本身 CPU、connection、network 是否已成瓶頸。

腳本工程成本來自自由度。Python 可以很快寫出複雜行為、也容易把測試資料、randomness、side effect、sleep 與 exception handling 寫散；團隊要維持 scenario structure、fixture、logging 與 artifact 標準。

自訂 client 成本來自校正。使用 SDK 或 custom protocol client 時、要確認 client retry、timeout、connection pool 與 serialization 行為是否接近 production、避免 runner 模擬出不存在的壓力形狀。

排錯與失敗快速判讀

• Worker CPU 100% 但目標服務閒：Python runner 先死、不是 target saturation — 加 worker 數量、或檢查 task 裡有沒有 CPU bound 的本地計算（大 JSON parse、加密、本地 fixture 生成）擠掉 event loop
• Gevent monkey-patch gotcha：requests / psycopg2 / 自家 SDK 在第三方 library 內部 blocking call、整個 worker 卡住 — gevent.monkey.patch_all() 一定要寫在 import 第一行；無法 patch 的 C extension（如 native MySQL driver）改用 gevent-friendly client
• RPS 達不到目標 / 看起來像 target 慢：實際是 worker connection pool 耗盡、或 worker 本身網卡飽和 — 觀測 worker 本身的 TCP socket 數、netstat ESTABLISHED、network throughput；不要直接 blame target
• Distributed sync drift：worker 之間 user count 不平均、aggregation 顯示 RPS 抖動 — --expect-workers=N 確認 master 等所有 worker join 才開測；worker 跨 region 時 message bus latency 也會影響 sync
• on_start 在 @task 裡跑：壓測啟動瞬間打爆 auth endpoint、看到 IdP latency 飆高以為是 target — 把 login / token fetch 移到 on_start、每個 user 只做一次
• wait_time = 0 拼最大 RPS 結果結論奇怪：這已經不是 user behavior 是 throughput probe、p99 跟 production 對不上 — 改成 between(1, 5) 模擬 think time 或寫 custom shape
• Web UI 卡 / master CPU 100%：master 同時在跑 user + aggregation — locust --master 跟 worker 拆機器、master 不跑 user

何時改走其他服務

不在本頁內的主題

• locustfile 完整語法 reference、User 跟 HttpUser 的 attribute 細節
• Locust Cloud 計費跟 quota 細節（看官方 docs）
• gevent 跟 asyncio 的取捨（Locust 選了 gevent、不在本頁討論替代）
• 壓測證據怎麼歸檔（看 9.7 evidence package 通則）

Evidence Package

Locust 結果應回寫到 evidence package。最小欄位包括 locustfile version、user class、task weight、spawn rate、worker count、client library version、target environment、p95 / p99、error rate、throughput、target saturation metric、known gap 與 owner。

Evidence package 的核心用途是區分目標瓶頸與 runner 瓶頸。Locust 分散式測試要同時保存 worker 數量、worker 資源、spawn rate 與 client behavior、讓 reviewer 知道壓力是否真的打到目標服務。

案例回寫

Locust 適合回寫需要高度自訂 user behavior 的案例。它可接 9.C28 FanDuel 雙峰 workload 的投注行為模型、9.C16 SeatGeek waiting room 的 admission / token flow、9.C26 PayPay mobile payment messaging 的外部推送與下游 quota 模擬、9.C8 Niantic Pokémon GO 50x surge 的玩家移動 + 互動混合行為、以及 9.C18 Zoom COVID 30x surge 的會議建立 / 加入 / 離開行為混合。

這些案例的重點是 domain behavior。Locust 頁引用案例時、要把 case 轉成 user class、task weight、custom client、downstream mock 與 worker capacity、再把總 RPS 放回這些行為條件下判讀 — 例如 Pokémon GO 玩家行為跟一般 web user 完全不同（持續 GPS 上報 + 偶發互動）、不能直接用 HTTP RPS 衡量；SeatGeek waiting room 要寫 LoadTestShape 模擬 ticket drop 瞬間衝擊、不是穩態 RPS。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.5 瓶頸定位流程
• 平行：k6、JMeter、Gatling、Vegeta
• 跨類：GoReplay（production traffic replay 替代 synthetic load）
• 跨模組：4 Observability（worker 自身 + 目標 APM 雙觀測）
• 官方：Locust documentation

Saturation discovery 的責任是把「系統能撐多少」這個問題變成可量化答案。沒有 saturation 量測時、容量規劃只能猜；有 saturation 量測之後、能說「在當前配置下、p99 < 100ms 的條件下、能撐 X RPS、headroom Y%」。

跟 9.1 壓測理論 的關係：9.1 預測 saturation curve 的形狀（linear → knee → cliff）、9.4 用實測找出 本服務 的曲線具體位置。理論告訴我們 knee 存在、實測告訴我們它在哪裡。

本章不深入工具操作（9.3 處理工具）、聚焦在 方法論 — 怎麼設計 ramp-up、怎麼判斷 knee、怎麼把結果文件化讓後續決策可用。

Saturation 的精確定義

容量規劃裡 saturation 不是「系統當機」、是「系統 進入 latency 指數成長區」。這個區分很重要 — 系統 看起來 還在跑、其實已經不可預測。

技術上 saturation 對應 queueing theory 的 knee point：utilization 超過某個臨界（M/M/c 通常 70-80%）、平均 queue length 從線性轉成指數成長。latency 是 queue length 的線性函數、所以也跟著指數成長。

實務上把 saturation 分三段：

• linear region（utilization < 50%）：latency 平穩、加流量幾乎不影響
• knee region（utilization 50-80%）：latency 開始上升、但還可接受
• cliff region（utilization > 80%）：latency 不可預測、可能 timeout / cascade failure

健康系統運轉在 linear 後半段或 knee 前段（utilization 50-70%）、留出 headroom 應付 burst。autoscaler 的 target metric 通常訂在 60-70%、是這條曲線推導出的安全位置。

Ramp-up 測試方法

要找出 saturation 點、必須跑 ramp-up 測試 — 不能固定一個壓力值。

單點壓測的問題：跑「2000 RPS 連續 10 分鐘」、看 latency 100ms、結論「能撐 2000 RPS」 — 但不知道 1500 跟 2500 RPS 是什麼樣。可能 1500 也是 100ms（離 knee 還很遠）、可能 2500 直接崩（已經在 cliff）。

Ramp-up 流程：從基線開始、按倍數加壓（1x / 2x / 4x / 8x …）。每個壓力 level 維持 5-10 分鐘、觀察 latency / throughput / resource utilization 的穩態（不是 transient）。紀錄每個 level 的 percentile 分布。

Knee 出現的訊號：

• throughput 從線性成長轉成 sub-linear（加壓但 throughput 不再等比成長）
• latency p50 還算穩、但 p99 / p999 開始飆
• resource saturation queue 開始堆積（不只 utilization 上升）
• error rate 仍接近 0（cliff 才會 error 飆）

Cliff 出現的訊號：throughput 開始下降（加壓反而越來越慢）、latency p99 變成 timeout、error rate 飆升、retry storm 出現。

對應案例：Tixcraft 用 10K t2.micro 壓測 找 DynamoDB 從 20 IOPS 到 135K 的擴展曲線、知道 knee 在哪。

Resource saturation 的六個維度

每次 ramp-up 都要同時觀察六個維度的 resource saturation、找出哪個 先 saturate。

CPU：utilization 100% 不一定 等於 saturation。要看 load average 跟 run queue。utilization 80% 但 run queue 不斷增長 → 已 saturate；utilization 100% 但 run queue 空 → 還能撐（單純 CPU bound）。

Memory：not OOM 即可？不夠。GC pause（Java、Go）、swap（Linux）、cache eviction 都是隱性 saturation。記憶體不直接 OOM 但 GC 飆 → 已影響 tail latency。

Disk I/O：要看三個維度：throughput（MB/s）、IOPS（operations/sec）、queue depth。雲端 SSD 通常先 IOPS bound、不是 throughput；本機 NVMe 可能先 throughput bound。

Network：bandwidth（Gbps）、packets per second、connection count。雲端 instance 通常有 PPS limit、超過會 silent drop、不是顯式錯誤。

Connection pool：DB / cache / external API 的連線數。這是 最常見的隱性 bottleneck。pool size 訂 100、實際在用 95 → utilization 看似還好、其實已經 saturate（剩下的 request 在等 connection）。

External API quota：第三方 rate limit（Stripe、Twilio、Slack API）。這個維度的 saturation 看不到 本系統 的訊號、要看 對方 API 的 429 error rate。

對應案例：Lemino RDB connection limit — connection 是 RDB 的 saturation 點、CPU 跟 RAM 都還沒到。

詳見 USE Method 卡片。

Hot partition 的隱性 saturation

對分散式 KV / OLTP（DynamoDB、Cosmos DB、Bigtable、Cassandra）、saturation 還有另一個維度：hot partition。

名義容量 = 每 partition 上限 × partition 數量。partition key 分布不均 → 名義容量達不到。整體 utilization 看起來 20% → 系統還能撐？不一定。最熱 partition 已經 100%、其他 partition 0%、整體平均才 20%、但加流量會打在最熱 partition、立即 throttle。

識別 hot partition 的訊號：

• throughput 上不去、但 average resource utilization 低
• 某些 key 的 request latency 飆、其他 key 正常
• DynamoDB throttling event 出現（即使 capacity 還沒滿）

處理方法：

• composite key（event_id + user_id_hash）
• write sharding（event_id + random_suffix）
• time-bucket（event_id + minute）
• 用 cache 吸收 hot key（DAX、ElastiCache）

對應案例：Amazon Ads 9000 萬 RPS — partition 設計均勻時可以撐 sustained 高吞吐；Tixcraft 售票 — 同一場演唱會（event_id）天然容易 hot、必須用 composite key 分散。

Long-tail latency 的 saturation

p50 / p95 / p99 / p999 在 saturate 時表現可能完全不同。

p50（中位數）對 GC pause、retry storm、tail latency 不敏感 — 大部分 request 沒事、p50 看不到。 p99（百分之 1）對 connection contention 開始敏感、能早期看到 saturation。 p999（千分之 1）對 GC stop-the-world、leader election、retry storm 敏感、是長尾的最強訊號。

純看 average / p50 會誤判 saturation 還沒到。SLO 通常訂 p99（讓 99% 用戶體驗良好）、internal critical 系統可訂 p99.9（5 個 9 的可用性對應 5 個 9 的 latency 期待）。

對應案例：Tubi p99 < 10ms — ML 系統的 user-perceived latency 是 最後完成的 inference、p50 快沒用；Coinbase sub-ms — RAFT 系統的 p999 通常比 p99 高一個量級。

詳見 Tail Latency 卡片。

Saturation 文件化：容量地圖

Saturation discovery 跑完之後、產出 容量地圖 — 不是一個數字、是一張表。

容量地圖至少要回答：

• 在 X 配置下（instance count、type、network）
• SLO 條件 Y 下（p99 < N ms、error rate < M%）
• 能撐 Z RPS（含分解到不同 endpoint）
• knee 在哪（什麼條件下進入 cliff）
• 第一個 saturate 的 resource 是什麼

紀錄 測試時間 跟 軟硬體版本：硬體 / 軟體版本變動後、saturation 點可能位移、舊地圖不能套用。

加入 release gate：每次重大改動後 re-test、確認 knee 沒往不好的方向移。這層自動化跟 9.9 Improvement Loop 對接。

案例對照

下一步路由

• 上游：9.1 壓測理論 / 9.3 壓測工具選型
• 下游：9.5 瓶頸定位流程（找到 knee 之後、定位是哪個 resource）
• 下游：9.6 容量規劃模型（用 knee 算 headroom）
• 跨模組：04 可觀測性模組（量測訊號）

既建知識卡片

• Saturation Point
• USE Method
• Tail Latency
• Hot Partition

觀察

DraftKings 帳本系統的關鍵數字（引自 DraftKings case study）：

服務組合：Amazon Aurora MySQL-Compatible、Aurora Replicas（讀寫分流）、Aurora I/O-Optimized（2023-05 推出）、Aurora Database Cloning（測試環境）、跨三個 AZ 儲存複製。

關鍵負載形狀：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量、payout event 時是寫爆量、雙峰錯位。

判讀

DraftKings 的工程選擇揭露三個 OLTP 容量設計重點。

1. 200 個獨立資料庫 = sharding 預先做好：按業務切 200 個 cluster、用巨型 cluster 撐全部在這個規模行不通。對應 9.5 瓶頸定位流程 把「單機極限」改成「shard 極限」、每個 shard 的容量規劃變成獨立問題。
2. Replication lag 30 秒 → 10-30 ms：這個改善不只是「快」、而是讓 read-after-write 變得可預測。Aurora 的 storage layer 多 AZ 複製是這個 lag 改善的主因。對應 01 資料庫模組 的 replication lag 影響 transaction boundary 設計。
3. Super Bowl +50% 「no sweat」：這句話的工程意義是 提前做好容量規劃、不是「Aurora 神奇」。寫 workload 預期可能 + 50%、整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成「不流汗」。對應 9.6 容量規劃模型 的 headroom budget 與 event-driven scheduled scaling。

需要警惕：100 萬 ops / 分鐘 = ~17K ops / 秒、跨 200 個 databases 平均下來每個 DB 約 80 ops / 秒。這不是「單一 DB 撐 100 萬 ops」、而是「200 shard 加總 100 萬」。讀案例時要看「峰值是分散到多少 shard」、不只看總數。

策略

可重用的工程做法：

1. 按業務切 OLTP cluster、不要一個 DB 撐全部：DraftKings 200 個 databases 顯示「業務切片」是 OLTP 擴容的前置。對應 01 資料庫模組 的 schema design 與 partition 決策。
2. 讀寫分流是 OLTP 容量規劃的基線：6ms 寫 vs <1ms 讀的差距、加上 read replica、是 OLTP 擴容最基本的兩個槓桿。
3. 事件型峰值預測寫進 baseline：Super Bowl 是已知事件、+50% 是歷史經驗、所以可以提前 pre-scale。事件未知（突發新聞、KOL 推廣）的情況才需要 AI 預測（對照 9.C2 GR8 Tech）。

跨平台等效：GCP Cloud SQL + read replica / Spanner、Azure Database for PostgreSQL + read replica、自建 PostgreSQL + Patroni + pgbouncer 都可以實作對等架構。Aurora 的差異是 storage layer 對 replica 的 lag 改善。

下一步路由

• 想規劃 OLTP 高峰容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備 + 01 資料庫模組
• 想搞清楚事件型 vs 突發型峰值 → 9.C2 GR8 Tech 對照
• 想做 read replica 容量設計 → 01.6 高併發資料存取 + 9.5 瓶頸定位流程
• 想理解 replication lag 對 transaction boundary 的影響 → 01.5 transaction boundary
• 想理解 6 寫 / 4 讀 quorum 跟 200 cluster fleet 治理 → Aurora 儲存層架構
• 想規劃 read replica scaling 與 reader endpoint 路由 → Aurora read replica scaling

引用源

• DraftKings Scales Its Financial Ledger with Amazon Aurora
• Aurora I/O-Optimized announcement

本章目標

學完本章後，你將能夠：

1. 理解 data race 的風險
2. 區分 Mutex 與 RWMutex
3. 用 RLock / RUnlock 保護讀取
4. 用 Lock / Unlock 保護寫入
5. 避免回傳內部 map 或 slice 破壞鎖邊界

【觀察】共享 map 不能被多個 goroutine 無保護地讀寫

共享狀態的核心規則是：只要多個 goroutine 可能同時讀寫同一份資料，就必須用同步機制保護。以下程式同時讀寫 map，存在 data race：

 1type UserRepository struct {
 2    users map[string]User
 3}
 4
 5func (r *UserRepository) Set(id string, user User) {
 6    r.users[id] = user
 7}
 8
 9func (r *UserRepository) Get(id string) (User, bool) {
10    user, ok := r.users[id]
11    return user, ok
12}

如果 Set 和 Get 從不同 goroutine 同時執行，map 可能被同時讀寫。Go 的 map 不保證這種情境安全。

【判讀】RWMutex 區分讀取與寫入

RWMutex 的核心規則是：讀取使用 RLock，寫入使用 Lock；多個讀取可並行，寫入會排他。

 1type UserRepository struct {
 2    users map[string]User
 3    mu    sync.RWMutex
 4}
 5
 6func (r *UserRepository) Set(id string, user User) {
 7    r.mu.Lock()
 8    defer r.mu.Unlock()
 9    r.users[id] = user
10}
11
12func (r *UserRepository) Get(id string) (User, bool) {
13    r.mu.RLock()
14    defer r.mu.RUnlock()
15    user, ok := r.users[id]
16    return user, ok
17}

Set 修改 map，所以用 Lock。Get 只讀 map，所以用 RLock。

【策略】鎖保護的是資料不變式

鎖範圍的核心規則是：鎖要包住所有需要一致觀察或一致修改的資料。鎖的邊界應涵蓋完整不變式，慢速 I/O、網路呼叫與和共享資料無關的計算則應放在鎖外。

例如，這個更新同時修改兩個欄位，兩個欄位要在同一把鎖內更新：

1func (r *UserRepository) Add(user User) {
2    r.mu.Lock()
3    defer r.mu.Unlock()
4
5    r.users[user.ID] = user
6    r.count++
7}

如果 users 和 count 分開鎖，讀者可能看到 map 已更新但 count 還沒更新的中間狀態。

【執行】回傳資料時要保留 copy boundary

鎖邊界的核心規則是：鎖只能保護鎖內操作；回傳內部 map 會讓呼叫者在鎖外修改資料，破壞 repository 對狀態的控制權。

不安全做法：

1func (r *UserRepository) Users() map[string]User {
2    r.mu.RLock()
3    defer r.mu.RUnlock()
4    return r.users
5}

安全做法是回傳複製：

 1func (r *UserRepository) Users() map[string]User {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    result := make(map[string]User, len(r.users))
 6    for id, user := range r.users {
 7        result[id] = user
 8    }
 9    return result
10}

呼叫者拿到的是複本，不能繞過 UserRepository 修改內部狀態。

Mutex 還是 RWMutex？

選擇鎖的核心規則是：讀多寫少且讀操作可並行時用 RWMutex；不確定時先用 Mutex，設計更簡單。

sync.Mutex 的核心優勢是簡單。若狀態很小、讀寫都很快，或讀寫比例尚未明確，先使用 Mutex 通常更容易維護。它讓每次存取都走同一條鎖路徑，讀者也比較容易確認資料何時被保護。

sync.RWMutex 的核心優勢是讀多寫少時可以讓多個讀取並行。它適合像 in-memory cache、狀態查詢 repository 或連線註冊表這類讀取頻繁的資料結構。使用它時，寫入仍然要用 Lock，因為 RLock 只適合保護純讀取。

鎖選擇的判斷重點是資料不變式與讀寫比例。若讀取本身會組裝複雜資料、需要複製大型 map，或很快就會呼叫外部 I/O，RWMutex 帶來的並行讀取收益可能被複雜度抵消。

替代方案：什麼時候不用 RWMutex

RWMutex 不是共享狀態保護的唯一選擇。三類替代方案各有適用條件：

判別準則：

• 保護多欄位不變式（如 users + count 同步）→ RWMutex 或 Mutex
• 保護單一純量且操作可表達為 atomic op（CAS、increment）→ sync/atomic
• 保護大量獨立 key 且無跨 key 不變式 → sync.Map
• 狀態可由單一 owner 持有、外部用訊息驅動 → channel-based、見 4.2 / 4.5 backpressure

選錯方案的代價：用 sync/atomic 保護需要不變式的多欄位 → silent atomicity violation；用 sync.Map 期待 range 一致性 → 拿到 inconsistent snapshot；用 channel 處理需要嚴格 ordering 的 fan-in → 順序錯亂。

RWMutex 不解的問題

RWMutex 解的是 data race（多 goroutine 同時讀寫同一份資料的 visible race）。下列問題不在 RWMutex 防護範圍、必須由其他機制處理：

判讀訊號：

• go test -race pass、production 仍偶發資料異常 → 可能 atomicity violation 或 ordering bug、不是 data race
• 多核 CPU 加倍但 throughput 不增 → lock contention dominate、考慮 shard
• p99 latency 在高 concurrency 下爆炸 → reader 排隊或 starvation、查 lock 等待 metric
• shutdown 時 goroutine 不退 → reader hold RLock + 未 check ctx、補 context 檢查

Context dependence：scale 改變策略

RWMutex 的有效性會隨 deployment 條件變化：

• Map 大小：copy 成本隨 entries 線性增長、1k entries 廉價、1M entries 每次 copy 都是 GC pressure 來源；大 map 改 sync.Map 或 sharded
• 讀寫比例：90% 讀以下、RWMutex 收益不顯著、Mutex 簡單；讀寫接近時 RWMutex 的內部 atomic 操作成本可能反而比 Mutex 慢
• Goroutine 數量：少（< 10）時 contention 微、多（> 1000）時 RWMutex 不適合、要 shard 或換 lock-free 結構
• 持鎖時間：鎖內 microsecond 級 OK、毫秒級會堆隊；鎖內絕不做 I/O / 網路呼叫

選擇 RWMutex 前先問四件事

RWMutex 只解 data race subset——不解 deadlock / starvation / atomicity violation / context cancellation / 多核 contention scaling。狀態可表達為 atomic op、單 owner channel、或大量獨立 key 時、sync/atomic / channel-based / sync.Map 通常更合適。選擇前先問：「不變式跨幾個欄位？讀寫比例？goroutine 數量？持鎖時間？」

模組級快取

Python 模組是天然的單例——模組只會被載入一次。利用這個特性，可以實作簡單的快取。

實際範例：配置快取

來自 .claude/lib/config_loader.py：

 1from typing import Optional
 2
 3# 模組級快取變數
 4_agents_config_cache: Optional[dict] = None
 5_quality_rules_cache: Optional[dict] = None
 6
 7def load_agents_config() -> dict:
 8    """
 9    載入代理人配置
10
11    使用模組級快取，避免重複讀取檔案。
12    """
13    global _agents_config_cache
14
15    # 檢查快取
16    if _agents_config_cache is None:
17        try:
18            _agents_config_cache = load_config("agents")
19        except FileNotFoundError:
20            _agents_config_cache = _get_default_agents_config()
21
22    return _agents_config_cache
23
24def load_quality_rules() -> dict:
25    """載入品質規則配置"""
26    global _quality_rules_cache
27
28    if _quality_rules_cache is None:
29        try:
30            _quality_rules_cache = load_config("quality_rules")
31        except FileNotFoundError:
32            _quality_rules_cache = _get_default_quality_rules()
33
34    return _quality_rules_cache
35
36def clear_config_cache() -> None:
37    """
38    清除配置快取
39
40    用於測試或配置熱更新。
41    """
42    global _agents_config_cache, _quality_rules_cache
43    _agents_config_cache = None
44    _quality_rules_cache = None

使用方式

 1# 第一次呼叫：從檔案載入
 2config1 = load_agents_config()
 3
 4# 第二次呼叫：直接返回快取
 5config2 = load_agents_config()
 6
 7# config1 is config2  # True
 8
 9# 需要重新載入時
10clear_config_cache()
11config3 = load_agents_config()  # 重新從檔案載入

為什麼使用這個模式？

效能考量

 1# 沒有快取：每次都讀取檔案
 2def load_config_slow() -> dict:
 3    with open("config.yaml") as f:
 4        return yaml.safe_load(f)  # I/O 操作
 5
 6# 有快取：只讀取一次
 7def load_config_fast() -> dict:
 8    global _cache
 9    if _cache is None:
10        with open("config.yaml") as f:
11            _cache = yaml.safe_load(f)
12    return _cache

一致性

1# 確保所有地方使用相同的配置
2config_a = load_agents_config()
3config_b = load_agents_config()
4
5# 修改 config_a 會影響 config_b（因為是同一個物件）
6# 這可能是優點也可能是缺點，取決於使用場景

函式裝飾器快取

@functools.lru_cache

Python 標準庫提供的快取裝飾器：

 1from functools import lru_cache
 2
 3@lru_cache(maxsize=128)
 4def expensive_computation(n: int) -> int:
 5    """計算結果會被快取"""
 6    print(f"Computing for {n}...")
 7    return sum(range(n))
 8
 9# 第一次呼叫：執行計算
10result1 = expensive_computation(1000)  # 印出 "Computing for 1000..."
11
12# 第二次呼叫：直接返回快取
13result2 = expensive_computation(1000)  # 不印出任何東西
14
15# 清除快取
16expensive_computation.cache_clear()

@functools.cache (Python 3.9+)

無大小限制的快取：

 1from functools import cache
 2
 3@cache
 4def fibonacci(n: int) -> int:
 5    if n < 2:
 6        return n
 7    return fibonacci(n - 1) + fibonacci(n - 2)
 8
 9# 快取讓遞迴變得高效
10fibonacci(100)  # 瞬間完成

手動實作快取

字典快取

 1_cache: dict = {}
 2
 3def get_user(user_id: int) -> dict:
 4    """取得使用者資料，使用快取"""
 5    if user_id not in _cache:
 6        _cache[user_id] = fetch_from_database(user_id)
 7    return _cache[user_id]
 8
 9def invalidate_user(user_id: int) -> None:
10    """使特定使用者的快取失效"""
11    _cache.pop(user_id, None)
12
13def clear_all_cache() -> None:
14    """清除所有快取"""
15    _cache.clear()

帶過期時間的快取

 1from time import time
 2from typing import Optional, Any
 3
 4_cache: dict = {}
 5_cache_time: dict = {}
 6CACHE_TTL = 300  # 5 分鐘
 7
 8def get_with_ttl(key: str) -> Optional[Any]:
 9    """取得快取，檢查是否過期"""
10    if key in _cache:
11        if time() - _cache_time[key] < CACHE_TTL:
12            return _cache[key]
13        else:
14            # 快取過期
15            del _cache[key]
16            del _cache_time[key]
17    return None
18
19def set_with_ttl(key: str, value: Any) -> None:
20    """設定快取"""
21    _cache[key] = value
22    _cache_time[key] = time()

單例模式

當確實需要單例時的實作方式：

使用模組（最簡單）

 1# singleton.py
 2class _Singleton:
 3    def __init__(self):
 4        self.value = 0
 5
 6instance = _Singleton()
 7
 8# 使用
 9from singleton import instance
10instance.value = 42

使用類別裝飾器

 1def singleton(cls):
 2    instances = {}
 3
 4    def get_instance(*args, **kwargs):
 5        if cls not in instances:
 6            instances[cls] = cls(*args, **kwargs)
 7        return instances[cls]
 8
 9    return get_instance
10
11@singleton
12class Database:
13    def __init__(self):
14        print("Connecting to database...")
15
16# 使用
17db1 = Database()  # 印出 "Connecting..."
18db2 = Database()  # 不印出（返回同一個實例）
19db1 is db2  # True

使用 new

 1class Singleton:
 2    _instance = None
 3
 4    def __new__(cls):
 5        if cls._instance is None:
 6            cls._instance = super().__new__(cls)
 7        return cls._instance
 8
 9# 使用
10s1 = Singleton()
11s2 = Singleton()
12s1 is s2  # True

Hook 系統的實際應用

配置載入器的設計

 1# config_loader.py
 2
 3from typing import Optional
 4
 5# 私有快取
 6_agents_config_cache: Optional[dict] = None
 7
 8def load_agents_config() -> dict:
 9    """
10    載入代理人配置
11
12    特點：
13    1. 使用模組級快取
14    2. 支援預設配置
15    3. 提供清除快取的方法
16    """
17    global _agents_config_cache
18
19    if _agents_config_cache is None:
20        try:
21            _agents_config_cache = load_config("agents")
22        except FileNotFoundError:
23            # 返回預設配置
24            _agents_config_cache = _get_default_agents_config()
25
26    return _agents_config_cache
27
28def _get_default_agents_config() -> dict:
29    """預設配置"""
30    return {
31        "known_agents": [
32            "basil-hook-architect",
33            "thyme-documentation-integrator",
34            # ...
35        ],
36        "agent_dispatch_rules": {
37            "Hook 開發": "basil-hook-architect",
38            # ...
39        }
40    }

測試快取程式碼

 1import unittest
 2
 3class TestConfigLoader(unittest.TestCase):
 4
 5    def setUp(self):
 6        # 每個測試前清除快取
 7        clear_config_cache()
 8
 9    def tearDown(self):
10        # 每個測試後清除快取
11        clear_config_cache()
12
13    def test_config_is_cached(self):
14        """測試配置被快取"""
15        config1 = load_agents_config()
16        config2 = load_agents_config()
17
18        # 應該是同一個物件
19        self.assertIs(config1, config2)
20
21    def test_clear_cache_works(self):
22        """測試清除快取"""
23        config1 = load_agents_config()
24        clear_config_cache()
25        config2 = load_agents_config()
26
27        # 應該是不同的物件
28        self.assertIsNot(config1, config2)

最佳實踐

1. 提供清除快取的方法

1# 好：可以清除快取
2def clear_config_cache():
3    global _cache
4    _cache = None
5
6# 不好：無法重新載入

2. 考慮執行緒安全

 1import threading
 2
 3_lock = threading.Lock()
 4_cache = None
 5
 6def get_cached_value():
 7    global _cache
 8    if _cache is None:
 9        with _lock:
10            # 雙重檢查
11            if _cache is None:
12                _cache = expensive_computation()
13    return _cache

3. 文件化快取行為

1def load_config() -> dict:
2    """
3    載入配置
4
5    Note:
6        結果會被快取，後續呼叫返回同一個物件。
7        使用 clear_config_cache() 可重新載入。
8    """

思考題

1. 模組級快取和 @lru_cache 有什麼區別？
2. 為什麼 clear_config_cache() 很重要？
3. 在多執行緒環境下，模組級快取可能有什麼問題？

實作練習

1. 使用 @lru_cache 實作一個帶快取的 API 呼叫函式
2. 實作一個帶 TTL（存活時間）的快取
3. 為現有的快取添加執行緒安全保護

延伸閱讀（進階系列）

• 進階設計模式 - 更多設計模式的深入探討
• 快取生命週期管理 - 進階快取策略
• 實戰效能優化：LRU 快取 - lru_cache 的實際應用

上一章：工廠模式 下一模組：錯誤處理與測試

服務定位

Vegeta 是 Go 寫的 HTTP load testing CLI，核心模型是 constant rate attack：指定「每秒 N 個 request」就持續打 N rps、不會因 server 變慢就降速，跟「fire-and-wait」型工具（hey / wrk 預設 closed-loop）行為差異很大。constant rate 是 open-loop 模型 — 模擬真實流量「不會因服務慢而減少」的行為、所以 saturation 點才會明確浮現。

Vegeta 是 Unix philosophy CLI：targets 從 stdin 讀（可以 pipe 進複雜 generator）、binary report 從 stdout 出（可以 pipe 進 vegeta report / vegeta plot / vegeta encode）。這個設計讓 Vegeta 容易跟 shell pipeline / CI script 接合、但同時也決定它不適合表達多步驟 session。

跟 k6 比、Vegeta 走 CLI-first + open-loop constant rate、k6 走 JS scenario + threshold + CI artifact。Vegeta 適合「我要對這個 URL 打 200 rps 60 秒」的一次性壓測、k6 適合「我有 3 種 user journey、各占 40/30/30%、跑 ramp-up profile」的可維護 scenario。跟 hey 比、Vegeta 的 constant rate 是真的 open-loop、hey 的 -q 是 per-worker rate（worker 變慢整體就降速）— 探測 saturation 時 Vegeta 比較誠實。跟 wrk / wrk2 比、Vegeta 沒有 LuaJIT 那麼極致的單機壓測效能、但 binary report + vegeta plot + targets pipe 對日常工程師工作流更友善。

本章目標

讀完本頁、讀者能判斷：

1. 何時用 Vegeta、何時走 k6 / hey / wrk / Gatling / Locust 的取捨
2. constant rate attack 的設計意涵（open-loop vs closed-loop、為什麼這對 saturation discovery 重要）
3. target file / rate / duration / report 四件套的 baseline workflow 跟 evidence package 對應
4. 排錯時的常見陷阱：runner 端 TCP socket exhaust、open file limit、constant rate 跟 target server 限速 disconnect

定位

Vegeta 適合快速回答「這個 endpoint 在某個 rate 下表現如何」。當團隊需要先找出大概 knee point、驗證一個修補是否降低 latency、或在 CI 裡跑小型 performance smoke test，Vegeta 的 CLI workflow 很直接。

這個定位讓 Vegeta 接到 9.4 Saturation Discovery 與 9.5 瓶頸定位流程。它提供的是快速壓力探針，後續若要表達複雜 workload model，通常要轉向 k6、Gatling、Locust 或 JMeter。

最短判讀路徑

判斷一次 Vegeta 壓測是否有效、最少看四件事：

• Target 描述完整性：targets file 是否包含 method / URL / headers / body、是否反映真實 request shape（含 auth header、content-type、representative payload size），缺一就會讓壓測結果偏離正式環境
• Rate model 設計：選的是 constant rate（-rate=200/s）還是 ramp（用多段 attack pipe），constant rate 適合 saturation probe、ramp-up 要 wrap script 自己 stage、Vegeta 沒有原生 ramp profile
• Report 解讀：vegeta report 給 mean / p50 / p95 / p99 / max latency + success rate + throughput，重點看 p99 跟 max 的距離 與 requested rate vs actual throughput 是否 disconnect — disconnect 表示 server / runner 端有人在限速
• Duration vs warm-up：短 duration（< 30s）容易吃到 JIT / cache / connection pool warm-up 噪音，baseline 壓測 duration 至少 60s、且第一段 result 要 discard，否則 p99 會被前 5s 拉高

適用場景

單 endpoint saturation probe 是 Vegeta 的主要入口。工程師可以對 login、search、read API、feature flag endpoint 或 internal health-like endpoint 施加固定 rate，觀察 p95 / p99 與 error rate 何時開始上升。

Regression smoke test 適合用 Vegeta。CI 或 pre-release 可以用短時間固定 rate 測試，確認 hot path 沒有明顯退化，再把更完整的 scenario 交給 k6、Gatling 或 Locust。

Incident 後修補驗證適合用 Vegeta。當事故根因是某個 endpoint 的 query、cache miss、lock contention 或 timeout，修補後可以用相同 request set 重跑，快速比較 latency distribution。

選型判準

CLI 簡潔價值來自低摩擦。當問題還在定位階段，工程師可以很快產生可重跑 command 與 target file，先取得 baseline，再決定是否需要完整壓測平台。

固定 rate 價值來自可比較。用相同 request set、rate、duration 與 target environment 重跑，可以讓修補前後的 latency distribution 有清楚對照。

跟其他工具的取捨

Vegeta 和 k6 的主要差異是 scenario 深度。Vegeta 適合固定 rate HTTP probe；k6 適合多步驟 scenario、threshold、CI artifact 與 browser-style flow。

Vegeta 和 JMeter 的主要差異是工具重量。Vegeta 適合快速 CLI；JMeter 適合 GUI、多 protocol、plugin 與企業測試資產。

Vegeta 和 Gatling 的主要差異是長期維護模式。Vegeta 用 command / target file 保持簡單；Gatling 用 simulation 維護複雜 flow 與 injection profile。

Vegeta 和 Locust 的主要差異是自訂能力。Locust 適合 Python user behavior 與 custom client；Vegeta 適合 HTTP endpoint 的直接壓力測量。

操作成本

Vegeta 的主要成本是 workload coverage 有限。它能快速測 endpoint，但多步驟 session、資料依賴、payment mock、queue side effect 與 realistic user journey 需要額外工具或腳本補上。

Artifact 成本來自命令可追溯性。每次測試要保存 rate、duration、targets、headers、body、環境、版本與結果檔；否則快速 probe 很容易變成不可比較的一次性觀察。

Runner 成本通常較低，但仍要檢查本機瓶頸。高 rate 測試時，產生負載的機器也可能先被 CPU、network、file descriptor 或 connection limit 卡住。

Evidence Package

Vegeta 結果應回寫到 evidence package。最小欄位包括 command、target file hash、rate、duration、workers、target environment、p95 / p99、max latency、error rate、throughput、target saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓快速測試可以比較。Vegeta 的結果通常很短，反而更需要保存 command 與 target set，讓下一次修補驗證能跑同一組條件。

核心取捨表

選 Vegeta 的核心訴求：工程師本機 / CI smoke / 修補驗證 / saturation probe 都要快速可重跑、且結果要可以保存比較；不需要完整 scenario 模型也不需要 GUI 報表。若團隊需要完整 user journey、threshold / SLO gate、長期 trend dashboard，直接走 k6 或 Gatling。

進階主題

Reporting 多輸出 format：vegeta report 預設 text summary、加 -type=hist[0,10ms,50ms,100ms,500ms] 給 latency bucket histogram、-type=json 給機器可讀 result、vegeta plot 出 HTML latency chart、vegeta encode -to=csv 轉成可進 spreadsheet / dashboard 的 CSV。binary result 檔可重複 decode 成不同 format，不用重跑壓測。修補驗證的標準作法是保留 results.bin、之後可隨時 re-render report。

Pipe attack workflow：Vegeta 的 stdin/stdout 都是 stream — 可以用 shell pipe 串接 jq 動態產 targets（jq -r '.urls[] | "GET " + .'）、用 vegeta attack | tee results.bin | vegeta report 同時寫檔跟即時看 summary、用 cat results-old.bin results-new.bin | vegeta report 比較兩次結果。這個設計讓 Vegeta 跟 incident drill / chaos test script 容易接合 — 修補 deploy 完跑一次 attack、result 直接 commit 進 git 當 evidence。

CI integration pattern：CI 裡 Vegeta 沒有 k6 那種內建 threshold，要自寫 gate — vegeta report -type=json results.bin | jq '.latencies.p99' 出 p99、bash 比較 budget、超標 exit 非零。把 targets.txt + attack.sh + expected-budget.json commit 進 repo、CI artifact 上傳 results.bin + plot.html，下次 regression 時可以 diff。

排錯與失敗快速判讀

• Requested rate 跟 actual throughput disconnect（要 200rps 實際只跑 80rps）：runner 端先飽和、不是 server 飽和 — 看 vegeta attack stderr 是否報 socket: too many open files、檢查 ulimit -n（生產壓測 runner 至少設 65535）；或 server 端有限速 / rate limit / connection cap 把 request reject 在 TCP 層、Vegeta 看不到完整 response 就被卡
• TCP socket exhaust（runner 端）：constant rate 模型下、若 server 回應慢、connection 會堆積、TIME_WAIT socket 爆 ephemeral port range — 用 -keepalive=true（預設）並調 net.ipv4.tcp_tw_reuse=1、或加 -connections=N 限制 connection pool 上限避免無限堆 socket
• p99 / max latency 異常高、但 server-side metrics 看不到：runner 端 GC pause / CPU steal / network jitter 把 latency 量測污染 — 把 runner 移到跟 target 同 placement group / same AZ、確認 runner CPU 沒被其他 process 搶、duration 拉長到 5min 讓 outlier 變稀釋
• Success rate 100% 但 server 已經爆：targets 沒帶 auth header / 打到 LB 而非 backend、所有 request 在前面就 200 / cache hit、server 根本沒收到壓力 — 檢查 target server access log 的 request count 跟 Vegeta requested rate 是否對得上
• 短時間壓測結果不穩定（同 command 跑兩次差很多）：duration 太短（< 30s）、warm-up 噪音占比太高 — 至少 60s、第一段 5-10s discard、若 endpoint 有 lazy initialization（cache / connection pool / JIT compile）先跑一段 warm-up attack 再正式量

案例回寫

Vegeta 適合回寫單 endpoint hot path 與修補驗證案例。它可接 9.C3 Coinbase ultra-low latency 的 sub-millisecond latency distribution 判讀、9.C25 Tubi feature store 的 p99 < 10ms lookup 驗證、9.C29 Lemino connection limit 的 RDB bottleneck 探測、9.C6 Tinder ElastiCache 的次毫秒 cache lookup 驗證，以及 9.C5 Amazon Ads DynamoDB 的 hot partition 探測。

這些案例的重點是快速定位與比較。Vegeta 頁引用案例時，要把 case 轉成 endpoint、rate、duration、latency budget、target saturation metric 與 runner limit — 例如 Coinbase 的 sub-ms 目標要求 Vegeta runner 必須跟 target 同 placement group、否則 runner 自身的網路 jitter 會吃掉觀測精度。

下一步路由

• 上游：9.4 Saturation Discovery
• 上游：9.5 瓶頸定位流程
• 平行：k6、Gatling、Locust
• 跨模組：6.13 Performance Regression Gate
• 官方：Vegeta documentation

瓶頸定位的責任是回答「為什麼擴 app 沒用」這類問題。當 9.4 Saturation Discovery 找到 knee point 之後、下一步是知道 哪個 resource 先 saturate。沒有定位、容量規劃只能 全部翻倍；有定位、可以 精準加在瓶頸層。

跟其他章節的關係：跟 9.4 是姊妹章（9.4 找出 knee、9.5 定位 knee 的成因）、跟 9.8 效能可觀測性 互補（9.8 訊號治理、9.5 用訊號做定位）。

本章不深入工具操作、聚焦在 方法論 — 怎麼按層次定位、怎麼避免常見誤判、怎麼區分可分散 vs 不可分散瓶頸。

USE method：resource-oriented 觀察

Brendan Gregg 的 USE method 提供逐層定位的最小框架：對每個資源、量三個維度。

Utilization：資源使用率 0-100%。CPU 70%、memory 60%、disk 40% 這類數字。 Saturation：資源排隊量（queue depth）。CPU run queue length、memory swap rate、disk I/O wait queue、connection pool wait count。 Errors：資源層錯誤。CPU page fault、memory OOM、disk I/O error、network packet drop、connection refused。

對每個資源（CPU / RAM / disk / network / DB connection / cache connection / file descriptor）逐一檢查。第一個出現 saturation 上升的資源是 bottleneck、不是 utilization 最高的那個。

USE 跟 RED method（rate / errors / duration）互補：USE 看「哪個資源頂不住」、RED 看「哪個 endpoint 表現變差」。容量規劃通常先用 USE 找瓶頸、再用 RED 看影響面。

詳見 USE Method 卡片。

逐層定位流程

從 application 層往下查、按依賴鏈逐層檢查。多數 bottleneck 在 application 跟 DB 兩層、但不能跳過其他層 — 偶爾真的在意外位置。

1. 應用層（application）：

• thread / coroutine pool 使用率：是否已飽和
• event loop lag（Node.js、async runtime）：> 50ms 是警訊
• GC pause 頻率與時長：影響 p99 / p999
• request queue（accept queue、application internal queue）

2. DB 層：

• connection pool 使用率（最常見隱性 bottleneck）
• slow query frequency
• replication lag
• lock contention（row lock、table lock）
• transaction queue depth

定位到 DB 層瓶頸時、優先檢查 1.13 應用層查詢反模式 清單 — 多數 DB 層瓶頸的根因是「應用程式發給 DB 的 query 寫法」、不是 DB 規格不夠。N+1 query 放大 connection 占用、long-running transaction 放大 lock contention、缺索引讓 slow query frequency 升高、SELECT * 放大 transaction queue。這層判讀走完、再考慮 DB 規格升級或加 replica。

3. Cache 層：

• hit rate（突然下降是訊號）
• eviction rate
• connection 飽和（cache pool 也會耗盡）
• memory utilization

4. Broker / queue 層：

• consumer lag（最重要的單一指標）
• queue depth
• dead-letter rate
• broker connection count

5. 外部 API / 第三方 quota：

• rate limit 觸發頻率
• retry storm（自家 retry 把對方 quota 打爆）
• circuit breaker trip
• timeout rate

6. 網路層：

• bandwidth utilization
• packets per second（PPS limit）
• socket count（file descriptor limit）
• 跨 region / 跨 AZ latency

7. DNS / load balancer：

• DNS resolution latency
• LB connection establishment time
• TLS handshake duration
• backend health check failure

對應案例：Lemino RDB connection limit 是隱性 bottleneck、CPU / RAM 都還行；Tixcraft 付款層獨立 — 把高頻搶票流量跟低頻付款流量分離、避免一層拖累另一層。

Profile 工具鏈

USE 找出哪一層 saturate 之後、profile 工具找出 該層的哪段 code 拖累。

Continuous profiling：Datadog Continuous Profiler、Pyroscope（開源 + Grafana 整合）、Parca（CNCF）、GCP Cloud Profiler、Azure Application Insights Profiler、AWS CodeGuru Profiler。production 持續取樣 CPU / heap / lock、overhead 通常 < 1%。

Distributed tracing：OpenTelemetry、Jaeger、Tempo、AWS X-Ray、GCP Cloud Trace、Azure Application Insights。記錄 request 在每個 service / 每個 stage 花了多少時間、找跨服務的 latency 累積。

Flame graph：profile 結果視覺化的標準。從寬度可以看到「哪段 code 佔 CPU 最多」。學會看 flame graph 是 SRE 的基本功。

Profile diff：壓測 baseline 跟 release candidate 比 stack 差異。看 相對變化 而非絕對值。詳見 Profile Diff 卡片。

對應案例：Netflix Aurora storage / compute 分離 — DB 統一後 application profile 變單純、退化來源更容易識別。

詳見 Continuous Profiling 卡片。

跨層依賴鏈

瓶頸不一定在 本服務、可能在 下游服務。這層判斷常被忽略。

第三方 API quota 是常見隱性瓶頸。Twilio SMS、Stripe API、Slack webhook、Sendgrid email、Google Maps API 都有 rate limit。自家服務看起來健康、實際是 對方 throttle、自家 retry 再讓對方更慢。

跨 region / 跨 zone 網路延遲 是累積的。一個 user request 經過 5 個 service、每個 service 跨 AZ 一次、累積 10-20ms cross-AZ latency。看起來每個 service 都很快、但 end-to-end 慢。

Downstream cache 也是依賴。app 看起來健康、但其實是 cache 在擋；cache 突然 cold start（restart、eviction storm）、application 直接被打爆。

對應案例：PayPay 行動支付 — DynamoDB 寫入可以撐 3K msg/sec、但 APNs / FCM 一天的 quota 有限、推送下游才是瓶頸。

可分散 vs 不可分散瓶頸

定位完瓶頸後、要判斷它 可不可以橫向擴。這個判斷決定能不能用「加機器」解決。

可分散瓶頸：

• stateless app server → 加機器有用
• partitioned KV / OLTP（partition key 均勻時）→ 加 partition 有用
• read replica（read-heavy workload）→ 加 replica 有用
• worker pool → 加 worker 有用

不可分散瓶頸：

• consensus DB（RAFT / Paxos）→ 加節點不一定快（quorum overhead）
• single leader DB（master 寫）→ 必須垂直擴
• 中央 coordinator → 必須拆解或垂直擴
• 共享 cache（hot key）→ 必須改 partition key 或加 local cache

判斷不可分散的關鍵是「協調成本」。一個操作必須 跟所有 / 多數節點協調 才能完成、就不可水平擴。

對應案例：Coinbase RAFT consensus — consensus 不可水平擴、所以 選擇不擴、改用單機極致；Spanner TrueTime — TrueTime 把協調成本 amortize 到 hardware（GPS + 原子鐘）、讓 OLTP 可水平擴。

常見定位陷阱

看單一指標就下結論：CPU 100% 不一定是 bottleneck（可能 saturation queue 空）；CPU 50% 不一定健康（可能 saturation queue 已滿）。always 看 USE 三個維度。

平均看 OK、p99 看不出來：average latency 50ms 看起來健康、p99 500ms 已經出事。用 percentile、不用 average。

Observer effect：profile / tracing 本身有 overhead、量測會輕微影響系統。critical path 上的 instrumentation 要 sampled 不要 100%。

跨 release 比較 baseline 沒對齊：上週的 baseline 對應 v1.2、這週的 candidate 對應 v1.3、但 v1.2 跟 v1.3 之間還有 schema migration / hardware 變化、baseline 已經漂移。重新建 baseline 再 diff。

案例對照

下一步路由

• 上游：9.4 Saturation Discovery
• 下游：9.6 容量規劃模型（針對 bottleneck 規劃）
• 下游：9.9 Improvement Loop（用 profile diff 改進）
• 下游：1.13 應用層查詢反模式與 Query 預算（DB 層 bottleneck 多半在 query 寫法）
• 跨模組：04 可觀測性模組 / 05 部署平台模組

既建知識卡片

• USE Method
• RED Method
• Continuous Profiling
• Profile Diff
• Universal Scalability Law

觀察

Amazon Ads 在 DynamoDB 的關鍵數字（引自 DynamoDB customers）：

讀寫比約 18:1。這個比例反映「曝光發生 1 次、後續查詢可能發生 18 次」的廣告計費邏輯。

判讀

這個案例最重要的不是「DynamoDB 能撐多少」、而是「為什麼可以這樣設計」。

1. 單表分散到上千個 partition：DynamoDB 把每個 table 拆成多個 partition、每個 partition 內部還可以再分散。9000 萬 reads / 秒 是上千個 partition 加總的結果、單一節點達不到這個量級。對應 9.5 瓶頸定位流程 的 sharding 邊界、跟 01 資料庫模組 的 partition 設計。
2. partition key 選擇直接決定容量上限：DynamoDB 的容量是「每 partition 上限 × partition 數量」。partition key 不均勻會出現 hot partition、實際容量遠低於名義容量。對應 9.4 Saturation Discovery 的 saturation 不一定是整體 saturation、而是 最熱的 partition saturation。
3. 99.999% availability ≈ 5 分鐘 / 年的容錯：廣告計費 1 分鐘斷線可能損失幾百萬美金廣告收入。這個 SLO 不是行銷數字、是真實的營收邊界。對應 04.16 SLI / SLO 訊號 與 9.12 SLO 與 Performance Budget。

需要警惕：「9000 萬 reads / 秒」這種敘述通常是 年度峰值的最高一秒、不是平均值。容量規劃要區分「最大瞬時」、「99 百分位平均」、「常態流量」三個不同口徑。

策略

可重用的工程做法：

1. partition key 設計是 KV 容量的第一決策：均勻分散、避免 hot partition、必要時加 random suffix 強制分散。對應 01 資料庫模組 的 schema design 章節。
2. read-heavy 跟 write-heavy 比例變化是容量警訊：當業務邏輯改變（例如新增即時報表）、讀寫比可能跳一個量級、原本的容量規劃會失效。對應 9.8 效能可觀測性 持續監控比例變化。
3. on-demand vs provisioned 是成本 vs 反應速度的取捨：on-demand 自動擴容但成本高、provisioned 便宜但需要預測。Amazon Ads 這種 sustained workload 通常用 provisioned + auto scaling、不用 on-demand。對應 9.7 成本邊界與 efficiency。

跨平台等效：GCP Cloud Bigtable + 良好 row key 設計、Azure Cosmos DB partition key 設計都是對等概念。差異是 DynamoDB 的 partition 透明度（你看不到 partition 數量）vs Bigtable 的明確 tablet 模型。

下一步路由

• 想規劃 KV 高吞吐架構 → 9.5 瓶頸定位流程 + 01 資料庫模組
• 想避免 hot partition → 01.6 高併發資料存取 + 9.4 Saturation Discovery
• 想對照其他 KV 案例 → 9.C11 Minecraft Earth Cosmos DB（Azure 全球分散）
• 想深入 DynamoDB hot partition 反模式 → DynamoDB partition key 反模式
• 想拆 access pattern 對應的 single-table design → DynamoDB single-table design
• 想評估 on-demand vs provisioned 切換時機 → DynamoDB on-demand vs provisioned

引用源

• Amazon DynamoDB Customers
• Handle traffic spikes with Amazon DynamoDB provisioned capacity
• Demystifying Amazon DynamoDB on-demand capacity mode

本章目標

學完本章後，你將能夠：

1. 理解 bounded concurrency 的用途
2. 用 semaphore 或 worker pool 限制同時工作數
3. 看懂 backpressure 為什麼能保護下游
4. 在併發流程中保留 cancellation 與 timeout
5. 辨認什麼時候該拒絕新工作

【觀察】高併發需要容量邊界

goroutine 很便宜，但每個工作仍會消耗下游連線、記憶體、排隊時間與錯誤處理能力。當所有工作都直接丟進 go func()，被放大的通常是：

• 連線數
• 記憶體
• 排隊延遲
• 下游壓力
• 故障面積

高併發設計的第一原則是「可控」。系統需要知道同時有多少工作在跑、多少工作在排隊、滿載時如何回應。

【判讀】bounded concurrency 是基本保護

bounded concurrency 的核心規則是：同一時間只允許有限數量的工作進行。這可以用 worker pool、semaphore 或排隊系統達成。

 1sem := make(chan struct{}, 16)
 2
 3for _, job := range jobs {
 4    sem <- struct{}{}
 5
 6    go func(job Job) {
 7        defer func() { <-sem }()
 8        process(job)
 9    }(job)
10}

這段程式限制同時只有 16 個工作在執行。當工作量暴增時，新的工作會自然排隊，而不是把整台機器一次推爆。

【策略】backpressure 保護的是下游

backpressure 的核心規則是：當系統處理不過來時，不要無限累積工作。這可以表現成：

• channel 滿了就阻塞
• queue 有上限
• goroutine pool 有上限
• 佇列滿時直接拒絕請求

例如 WebSocket、event consumer 或 background worker 如果沒有 backpressure ，輸入端一快，下游就會被放大成連鎖問題。

1select {
2case jobs <- job:
3    // accepted
4default:
5    return ErrQueueFull
6}

這種寫法的重點是明確表達滿載策略：系統在某些壓力下會拒絕新工作，因為保護整體健康比接住所有請求更重要。

【執行】cancellation 與 timeout 不能少

bounded concurrency 只控制數量，不能解決卡死工作。每個工作都應該保留取消訊號與 timeout，否則即使數量受限，資源也會被慢工作一直占著。

1ctx, cancel := context.WithTimeout(parent, 3*time.Second)
2defer cancel()
3
4if err := doWork(ctx, job); err != nil {
5    return err
6}

這樣可以讓每一筆工作都有自己的時間邊界，避免整體系統因單一慢點而拖垮。

【判讀】拒絕工作也是容量策略

拒絕新工作是保護容量邊界的一種策略。當以下條件成立時，拒絕通常比勉強接受更合理：

• queue 已滿
• 下游連線池耗盡
• timeout 已明顯增加
• 系統已進入明顯積壓

這時候回傳 429、503 或 domain-level rejection，往往比讓請求默默堆積更健康。

容量規劃的責任是把「未來 N 個月可能多大」翻成「現在該訂多少 capacity」。這層工作不純靠歷史外推、要結合業務 forecast、事件型成長、頂部風險 buffer。

跟 9.4 Saturation Discovery 的關係：9.4 提供「當前配置能撐多少」、9.6 用這個數字加上 forecast 推「該規劃多少」。沒有 9.4 的 baseline、9.6 只是猜；沒有 9.6 的 forecast、9.4 的 baseline 只是 snapshot。

跟 9.13 擴展軸 的關係：9.13 先決定「沿哪條軸擴」（垂直 / 水平 / Y 軸拆服務 / Z 軸 partition），9.6 才能算出「該擴多少」。同樣是「處理 10 倍流量」、選垂直擴展要算單機規格上限、選水平擴展要算協調成本跟連線池放大、選 Y 軸拆服務要算跨服務 latency budget — 三條軸的容量公式參數完全不同。沒先做 9.13、9.6 的數字會落到錯誤的擴展軸上。

本章是「規劃決策」的章節、不是執行手冊。讀完後讀者能回答：peak 怎麼預測、headroom 訂多少、autoscaler 怎麼配、不可水平擴的服務怎麼處理。

容量公式三項

容量規劃的核心公式可以濃縮成三項相乘：容量 = 預期峰值 × (1 + headroom) / 可擴容速度。每一項都需要獨立分析：

預期峰值（peak forecast）：歷史 baseline × 預期成長 × 事件因子。三項中最影響整體準度。詳見 Peak Forecast 卡片。

Headroom budget：通常 30-50%、為了應付異常 burst + AZ 故障 + forecast 誤差。不同工作負載 headroom 不同。詳見 Headroom Budget 卡片。

可擴容速度（reactive vs predictive）：autoscaler 反應時間 vs 流量上升速度。如果流量上升比 autoscaler 快、必須 提前 pre-scale、不能等 reactive 反應。

這個公式的另一個寫法是「容量 = peak × 安全係數」、安全係數 = (1 + headroom) / 可擴容速度。預測準 + 擴容快 → 安全係數小、容量緊湊；預測差 + 擴容慢 → 安全係數大、成本高。

Peak forecast 方法

Forecast 方法分三層、按業務型態選用。

歷史線性外推：拿過去 N 個月的趨勢、按斜率外推到下 N 個月。適合 sustained growth（B2B SaaS 月增 X%）；不適合 event peak（年度活動）跟 surge（產品爆紅）。

季節性分解（STL：Seasonal-Trend decomposition using Loess）：把長期趨勢、週期成分、殘差分開預測。適合電商（雙 11 / Black Friday）、串流（IPL / Super Bowl）、零售（聖誕節）。需要 至少兩個完整 cycle 的歷史資料。

業務 ML 模型：結合 marketing pipeline（廣告投入）、新用戶獲取（acquisition rate）、留存率、產品變化等多 feature。最精準但成本高、需要 ML team。

最常見錯誤是「拿去年同期 × (1 + 預期成長 %)」：忽略產品改動 + 行銷投入變化 + 外部事件。Prime Day 2025 vs 2024 不只是 +30% — 是 AI shopping assistant 上線、是 ad spend 變化、是新國家上線。

對應案例：Prime Day 年增率 +30% ~ +77% — 連 Amazon 自家每年成長都不能線性外推；Disney+ 新片發布 — 事件型 forecast、按過去新片 metric 預估。

Forecast 必須有 誤差範圍、不能單一數字。給上下界（最壞 / 預期 / 最好）、容量規劃才能用 worst-case 訂 baseline。

Headroom budget 設計

Headroom 不是 over-provisioning 浪費、是容量規劃的安全邊界。常見比例 30-50%、按 saturation 行為跟工作負載敏感度調整。

為什麼是 30-50% 而不是 10%：

• forecast 誤差：預測準度通常 ±20-30%
• burst pattern：瞬間 spike 超過 average peak、需要短時間吸收
• AZ / region failover：一個 AZ 掛、剩下兩個要承擔全部（多 33% 容量）
• 系統老化 / drift：軟硬體升級後 saturation 點可能位移

不同工作負載不同 headroom：

• stateless service：30%（autoscaler 反應快、headroom 可以薄）
• DB：50%（不易擴容、要備援足夠空間）
• broker / queue：60%（consumer 落後恢復時要瞬間吃下積壓）
• consensus DB：80%+（完全不能 reactive 擴）

headroom 太低 → 出事：peak 期間進 cliff、用戶體驗變差。 headroom 太高 → 浪費錢：平日成本拉高、CFO 質疑。

對應案例：GR8 Tech AI 預測 — 預測準了可以降 headroom 比例；預測不準必須拉高 headroom 補回安全邊界。

Growth curve 形狀分類

不同 growth curve 形狀對應不同 forecast 方法跟 review 節奏。

Linear growth：用戶月增 X%。B2B SaaS 最常見。forecast 線性外推、每季 review、headroom 可以薄（成長可預測）。

Step growth：每次行銷 / 活動跳一階、之間 plateau。需要 event tier 規劃、每個事件單獨 forecast、headroom 跟 event 強度連動。

Exponential growth：早期初創、病毒擴散。forecast 容易低估、傳統線性外推會大幅低估；headroom 必須拉到 100%+、不能省。

S-curve growth：成熟產品、會 saturate。Forecast 初期像 exponential、中期 plateau、晚期 mature。需要識別 inflection point、過了就調 forecast 方法。

Cyclical：電商季節性。每年 Black Friday / Cyber Monday / Christmas / Chinese New Year 都重複、forecast 用 STL 季節性分解。

對應案例：Zoom 30x COVID — step growth、外部衝擊讓 baseline 永久上移；Pokemon GO 50x surge — exponential（早期）+ 之後 S-curve；ASOS Black Friday — cyclical。

詳見 Growth Curve 卡片。

Autoscaling sizing

訂好 capacity 之後、要設計 autoscaler 把這個容量 動態使用。

min / max / target metric 三個參數：

• min 太低 → cold start 風險（流量上來時還在 boot）
• min 太高 → 平日浪費
• max 太低 → 限流（peak 時 autoscaler 不能再擴）
• max 太高 → 月底炸帳單（autoscaler 不受控、過 peak 不會主動降）
• target 太高 → autoscale 啟動太晚、進 knee 才反應
• target 太低 → autoscale 太敏感、頻繁 scale up / down 浪費

Predictive vs reactive：

• predictive scaling：根據歷史 pattern 或 ML 模型提前擴
• reactive scaling：根據當下指標擴
• 兩者組合最穩：predictive 處理已知 pattern、reactive 處理 unexpected burst

Scheduled vs metric-based：

• scheduled scaling：時段觸發（年度活動、daily peak）
• metric-based：根據 utilization / queue depth 觸發
• 三層組合（scheduled + predictive + reactive）最穩

不同層的 autoscaler 各自設計：

• EC2 Auto Scaling Group：infrastructure 層
• Kubernetes HPA / VPA：pod 層
• Karpenter：node 層
• DynamoDB auto-scaling：DB capacity 層
• CloudFront：CDN 層

對應案例：Tixcraft 30 分鐘擴 130 倍 — 6 台 → 800 台靠 ASG + AMI prebuild + ELB warmup；Prime Day predictive — pre-scaling 30-77% 年增率提前算進容量。

不可水平擴容服務的容量規劃

部分服務不能用「加機器」解決容量問題。這類服務的容量規劃有獨立邏輯。

典型不可水平擴：

• consensus DB（RAFT / Paxos）：節點數量是 consensus 一部分、不能臨時增減
• single leader DB（PostgreSQL primary、MySQL master）：寫只有一個 leader
• 中央 coordinator：必須拆解才可擴

容量公式變成：單機極限 × headroom、沒有 elastic 救援。 設計重點：

• 預先 provision 到能撐 peak、不依賴 reactive 擴
• 垂直擴容（更大 instance）為主、不是橫向
• 留更高 headroom（80%+）、出事沒有第二招

對應案例：Coinbase pre-provision — RAFT 限制下完全 pre-provision、不 autoscale；Spanner 節點即容量單位 — 雖然全球可擴、但每個 region 內節點數要預先規劃。

跨地理 / 跨 region 容量規劃

跨 region 服務不能用 全球總量 平攤、每個 region 獨立規劃。

為什麼不能聚合：

• 用戶在哪、流量就在哪、不會自動 spread
• 跨 region 切流量有延遲（DNS TTL、用戶習慣）、不能即時 rebalance
• 資料駐留合規可能強制各 region 獨立

規劃方法：

• 每個 region 抽各自的 workload model
• 各自跑 saturation discovery
• 各自訂 headroom（區域峰值 + 區域 AZ failover）
• 跨 region failover plan：哪個 region 掛了、流量去哪、目標 region 要留多少 headroom 接

對應案例：Standard Chartered 7 個受監管市場 — 跨市場獨立容量規劃；Genesys 15 region — 15 主 region + 5 衛星 region 各自規劃；Mercado Libre 18 國 — 每國獨立 cycle。

案例對照

下一步路由

• 上游：9.2 Workload Modeling / 9.4 Saturation Discovery
• 上游：9.13 擴展軸與 Stateless 前提（先選軸再算數量、不可水平擴容服務的判讀基底）
• 下游：9.7 成本邊界與 efficiency（容量翻成成本）
• 下游：9.11 高峰事件準備
• 跨模組：05 部署平台模組 autoscaler 實作

既建知識卡片

• Peak Forecast
• Headroom Budget
• Growth Curve
• Predictive Scaling
• Scheduled Scaling

觀察

Tinder 在 ElastiCache for Valkey 的關鍵數字（引自 ElastiCache customers）：

ElastiCache for Redis 7.1 在 r7g.4xlarge 上可達單節點 100 萬 RPS、單 cluster 5 億 RPS（引自 AWS Database Blog）。

判讀

Tinder 案例值得讀的是「快取在 long-running 服務的角色變化」。

1. 快取不是 DB 的補救、是主要服務面：配對引擎每次互動讀 cache 不讀 DB、cache miss 是 邊緣案例。對應 02 快取模組 的 cache-as-source-of-truth 與 02.4 cache copy freshness boundary 設計。
2. 次毫秒延遲是業務 KPI、不只是技術指標：手指滑動之後 250ms 內必須給結果、否則「卡頓」。中間整個 chain（網路、cache、序列化）的 latency budget 必須緊。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。
3. 長期 sustained growth 的容量曲線是成本曲線：47M MAU 沒有明顯峰谷、容量規劃變成「每月線性擴容 X%」的長期決策、不是峰值規劃。對應 9.7 成本邊界與 efficiency 的長期成本工程。

需要警惕：Tinder 的「configurable matching」業務邏輯複雜、快取資料的 schema 變化頻繁。一個 schema 變更可能讓既有 cache 全部 invalid、引發 cache stampede。對應 02.6 cache migration stampede rollback。

策略

可重用的工程做法：

1. cache layer 容量規劃跟 DB 容量規劃要分開：cache 容量受 working set size 影響、DB 容量受 total dataset 影響、兩者擴容邏輯不一樣。對應 02 快取模組 的 cache sizing。
2. cache 命中率變化是業務變化的訊號：突然命中率掉、可能是新功能影響 access pattern、不一定是 cache 容量問題。對應 9.8 效能可觀測性 的訊號治理。
3. Valkey vs Redis OSS vs MemoryDB 是不同 trade-off：Valkey（社群分支、AWS 主推）、Redis OSS（受授權變化影響）、MemoryDB（持久化）三者選擇影響長期 vendor lock-in。

跨平台等效：GCP Memorystore for Redis / Valkey、Azure Cache for Redis、自建 Redis Cluster + Sentinel 都可以實作對等架構。差異是 vendor 的 patch cadence 與容量擴張流程。

下一步路由

• 想設計 cache layer 容量 → 02 快取模組 + 9.5 瓶頸定位流程
• 想做 latency budget 反推 → 9.12 SLO 與 Performance Budget + 9.1 壓測理論與系統行為
• 想理解 cache stampede 風險 → 02.6 cache migration stampede rollback
• 對照其他 cache 案例 → 9.C5 Amazon Ads DynamoDB（KV 高吞吐）

引用源

• Amazon ElastiCache Customers
• Achieve over 500 million requests per second per cluster with ElastiCache for Redis 7.1
• Optimize Redis Client Performance for ElastiCache and MemoryDB

成本工程的責任是讓容量決策有經濟邊界。沒有成本意識時、容量規劃會「保險起見全部擴」、最終帳單炸裂；有成本意識之後、能 在每一個容量決策點 把「多保險」跟「多省錢」一起評估。

跟 9.6 容量規劃模型 的關係：9.6 算「該訂多少容量」、9.7 算「這樣訂值不值得」。兩者必須一起做、不能先決定容量再算成本。

本章從 cost per request 這個 unit economics 開始、推到 cost curve、TCO、降級成本、人力成本工程化、FinOps 整合。讀完後讀者能回答「容量設計的成本邊界在哪、什麼時候該降級而非擴容」。

Cost per request 模型

雲端帳單從月度視角看是黑箱、從 cost per request 視角看可拆解。

基本公式：月帳單總額 / 月總 RPS = cost per request。但這只是平均、不同 endpoint 成本差很大。 分 stage 拆解：app compute + DB read + DB write + cache + network egress + 第三方 API。每個 stage 自己有 unit cost。 分 endpoint 拆解：登入請求可能 $0.0001、結帳請求可能 $0.001（10x 差距）。原因：結帳走更多 stage、可能跨 region、可能呼叫第三方支付。

對齊業務 metric：

• cost per active user：總成本 / MAU
• cost per transaction：總成本 / 完成的訂單數
• cost per ML inference：總成本 / inference 次數

業務 metric 級別的 cost 才能跟收入對比、才能算 unit economics。

對應案例：Zomato 50% 成本下降 — 算出每筆計費事件的 cost per request 後、發現 TiDB over-provision 拖累、遷移 DynamoDB 後減半；Netflix Aurora 28% 成本降 — DB consolidation 把多套 DB 的 cost 統一到 Aurora、Aurora 自己的 cost per request 更便宜。

詳見 Cost Per Request 卡片。

Cost curve 形狀

不同 pricing 模式的 cost curve 形狀不同、組合起來才能最佳化。

On-demand（pay-per-use）：流量上升、成本同步上升。線性 cost curve。優點：彈性、不用承諾；缺點：單位成本最貴。 Reserved instances（RI）/ Savings Plans：承諾 1-3 年用量、單位成本降 30-60%。階梯 cost curve。優點：便宜；缺點：承諾期內如果用量低、浪費。 Spot instances：用 cloud 閒置 capacity、單位成本降 70-90%。可被中斷。優點：最便宜；缺點：可能突然被收回。

最佳組合通常是「Reserved baseline + On-demand spike + Spot batch」：

• Reserved 覆蓋 baseline 容量（永遠用得到）
• On-demand 處理 peak 跟 unpredicted burst
• Spot 跑 batch 工作（不在 critical path、可被中斷）

對應案例：Riot Games 年省 1000 萬 — 從自管 Mesos 遷到 EKS、降的不只是 instance cost、是 cluster 管理人力 + ops 簡化；Capcom 30% 成本下降 — DynamoDB + EKS 取代自管、釋放 DBA 人力。

Over-provisioning vs under-provisioning 取捨

容量決策的核心經濟學問題：訂多大容量才是最划算？

Over-provisioning 成本：每月多付 $X 雲端費。這個數字直接看帳單。 Under-provisioning 成本：sigma 機率 × downtime × revenue per minute。這個數字更難算 — 需要 historical incident rate + downtime impact analysis。

兩個成本平衡點 = 經濟最佳 headroom。但實務上 under-provisioning 成本不容易量化、保守做法是把 sigma 機率拉高（用 worst-case 估）、headroom 訂寬一點。

Critical workload（金融、醫療、付款）：under-provisioning 成本極高（合約違約 + 客戶流失 + 法規）、寧可 over-provisioning 30-50%。 Non-critical workload（內部工具、分析、batch）：under-provisioning 成本低、可以更貼近 minimum capacity。

對應案例：Zomato TiDB 必須 over-provision — 為了應付 spike、TiDB 必須長期 over-provision；DynamoDB on-demand 不必、pay-per-use 自然處理。

降級的成本邊界

「降級 vs 擴容」是常見容量決策、但常被當成「技術問題」而非「成本問題」。

降級不是免費：

• 流失轉換：UI 顯示「系統忙碌」、用戶可能放棄
• 客訴成本：客服處理客訴的 OpEx
• 品牌損失：社群媒體負面評論、口碑下降
• 合約違約：B2B 客戶可能基於 SLA 求償

算「降級 vs 擴容」哪個成本低：

• 擴容成本：peak 時段多付的 cloud 費用
• 降級成本：上述四項合計
• 哪邊低就選哪邊

降級觸發條件通常按負載門檻 / 成本門檻 / SLA 觸發：

• 負載門檻：utilization > 85% → 啟動降級
• 成本門檻：本月雲端費已超預算 X% → 啟動降級
• SLA 觸發：error budget 快用完 → 啟動降級保 SLA

對應案例：Pokemon GO 50x surge — surge 期間無法等比擴容、必須降級保住核心遊戲機制、犧牲附加功能。

人力成本工程化

雲端帳單是顯性成本、但 人力成本 是常被忽略的隱性容量成本。

自建 vs managed 的人力成本對比：

• 自建 Kafka / PostgreSQL / Redis：需要 DBA / SRE 持續維護 + 升級 + 故障處理
• Managed 服務（MSK、Aurora、ElastiCache）：vendor 負責 patch、backup、failover
• 差距通常 3-10 倍 人力成本

DBA / SRE / network engineer 都是隱性容量成本：

• 一個資深 DBA 在美國年薪 $200K+、台灣 NTD 200-400 萬
• 工程師時間是有上限的、自管系統佔的時間就是 無法投入產品開發 的機會成本

「90% 工程工時下降」是管理 ROI 的關鍵：重點是把工程資源從 維持 轉移到 建構、不是拿來吹噓技術。這條自建 vs managed 的人力成本對比、是 0.22 能力級買 vs 建 裡「計費隨規模成長、自建 TCO 出現交叉點」那條 tripwire 的算法側 — 選型方向在 0.22 判、成本量化在這裡做。

對應案例：Spotify Kafka → Pub/Sub — 不是因為 Pub/Sub 便宜、是因為 Spotify 規模下自管 Kafka 的人力成本不划算；Lemino 90% 工程工時降 — managed 路線讓電信商級新串流服務只用 5-10 個工程師 launch；Capcom DBA 釋放 — 把 DBA 時間從 patching 轉到遊戲品質。

FinOps 跟容量規劃的整合

FinOps 是 財務跟工程的協作框架、把成本決策從事後對帳變成事前規劃。

Showback / chargeback：把雲端成本攤到團隊 / 服務 / feature。每個團隊看得到自己的成本、自然開始 optimize。chargeback（實際扣預算）比 showback（純展示）更有效但組織複雜度高。

每月 cost review 變成容量 review 的一部分：

• 對比預算 vs 實際
• 找出 top 5 cost driver
• 對比上月趨勢、看是否有 anomaly
• 跟 capacity team 一起討論 right-sizing

Spot diversification：spot 中斷風險可以靠 多 instance type 跟多 AZ 分散。例如：spot pool 同時包含 m5.large + m5a.large + m5n.large、各 AZ 都有、單一 type pool 撤回時其他 type 還在。

Right-sizing：定期 review instance type 是否最適。常見浪費：訂太大 instance（CPU / RAM 用 30%）、過時 instance generation（用 c5 沒升到 c7）、reserved 過剩。

反模式

容量成本的常見錯誤模式：

Autoscaling max 設無限大：流量爆衝時 autoscaler 跟著爆衝、月底帳單炸裂。max 必須訂、是 financial circuit breaker。

全部用 on-demand、沒談 reserved / savings plan：cloud spending > $10K/月 已經值得跟雲商 talk discount、savings plan 通常 30-60% off。

沒成本 monitoring、直到帳單來才知道：要建 daily cost dashboard、anomaly 即時 alert、不要等月帳單。

降級用人工觸發、出事時來不及：降級邏輯要 自動化、按 metric 觸發、不是 oncall 工程師看到 dashboard 才下指令。

忘了人力成本：算 build vs buy 只算 cloud 費、忘了 SRE / DBA 時間、結果發現「省的 cloud 費 < 多花的人力」。

案例對照

下一步路由

• 上游：9.6 容量規劃模型
• 下游：9.8 效能可觀測性（cost attribution）
• 跨模組：04.14 cost attribution

既建知識卡片

• Cost Per Request
• Headroom Budget

觀察

Lyft 在 AWS 的關鍵數字（引自 Lyft case study）：

服務組合：Amazon DynamoDB（搭乘追蹤、GPS 座標）、Amazon Redshift（客戶洞察）、Amazon Kinesis（即時事件串流）、AWS Auto Scaling、Amazon EC2 Container Registry。

判讀

Lyft 的工程做法揭露三個微服務容量治理重點。

1. 微服務不是「全部 8x」、是「特定服務 8x」：8x 是 某些核心服務 在週末爆量時刻的擴容比、不是 100 個服務全部 8x。對應 9.5 瓶頸定位流程 必須先做「哪個服務是熱點」的層次定位。
2. 微服務粒度 = 擴容粒度：把 ride matching、payment、driver tracking、notification 切成獨立服務、每個服務的 autoscaling policy 可以獨立設計。對應 03 訊息佇列模組 跟 05 部署平台模組 的服務邊界。
3. GPS 座標寫入 DynamoDB 是高頻 sustained workload：每個 driver 每秒寫 1-2 次位置、200+ 城市 × 每個城市數萬司機 = 巨量持續寫入、跟峰值無關。對應 9.C5 Amazon Ads 的 KV 高吞吐設計同類。

需要警惕：「8x 峰值」是 峰值倍數、不是 尖峰持續時間。週末晚間的尖峰可能持續 3-4 小時、機場特殊事件可能持續 30 分鐘、演唱會結束可能只有 10 分鐘瞬間。容量策略要按持續時間區分。

策略

可重用的工程做法：

1. 微服務粒度切到「同性質擴容單位」：同步 vs async、stateful vs stateless、CPU-bound vs I/O-bound 不該混在同一服務、否則擴容邏輯互相衝突。對應 05 部署平台模組 的 service decomposition。
2. 預測式 + 反應式擴容混用：可預測（早晚通勤）用 scheduled scaling、不可預測（演唱會散場）用 reactive autoscaling、兩者組合。
3. GPS 類持續寫入適合 KV / time-series store：不適合放 OLTP DB、會佔用 transaction 資源。對應 01 資料庫模組 的 storage choice。

跨平台等效：GCP GKE + HPA / VPA / Karpenter、Azure AKS + KEDA、自建 Kubernetes + Cluster Autoscaler 都可以實作對等架構。

下一步路由

• 想做微服務容量治理 → 05 部署平台模組 + 9.6 容量規劃模型
• 想規劃事件型峰值 → 9.11 高峰事件準備 + 9.C2 GR8 Tech
• 想設計高頻 sustained workload → 01 資料庫模組 + 9.C5 Amazon Ads

引用源

• Lyft Case Study
• DynamoDB Customers

本章目標

學完本章後，你將能夠：

1. 把錯誤處理看成可靠性的一部分
2. 區分可恢復錯誤與不可恢復錯誤
3. 用測試保護失敗路徑與並發路徑
4. 讓 timeout、取消與 race condition 能被提早發現
5. 理解為什麼高併發服務更需要明確的測試邊界

【觀察】錯誤是服務常態

在高併發服務裡，錯誤是日常情況的一部分。網路會失敗、下游會超時、資料會不完整、狀態會競爭；這些情境都應進入系統設計，而不是只留給事故發生後人工排查。

Go 把錯誤放在回傳值中，就是要讓這些常態能被直接看見。

【判讀】測試要先保護脆弱邊界

高併發服務最容易出問題的地方，通常是：

• HTTP handler 與外部輸入邊界
• goroutine 之間的共享狀態
• timeout 與 cancellation
• event / queue 的重複或漏處理

這些邊界都應該有測試。人工驗證可以輔助檢查流程，但它無法穩定重現 timeout、取消、race condition 與高併發失敗路徑。

【策略】錯誤路徑也要被測

服務測試需要同時覆蓋成功路徑與失敗路徑。只驗證成功路徑會讓 timeout、下游錯誤、取消與狀態競爭在壓力下才暴露，修復成本會更高。

你至少應該測：

• 參數不合法時是否回傳穩定錯誤
• 下游失敗時是否有正確的包裝錯誤
• timeout 是否真的會停止工作
• 取消 context 後 goroutine 是否退出

【執行】並發測試要看資源是否被正確回收

高併發測試的核心目標是確認資源會被正確回收。跑很多 goroutine 只是製造壓力；真正需要驗證的是：

• goroutine 會不會 leak
• channel 會不會卡住
• 鎖的範圍是否合理
• 資源關閉後流程是否停止

可靠性測試至少要證明流程能正確結束。只證明「看起來可以跑」會漏掉 goroutine leak、channel 卡住、鎖範圍過大與資源未釋放等問題。

為什麼需要並行處理？

在實際開發中，我們常遇到需要同時處理多個任務的情況：

1# 情境 1：批次下載多個檔案（I/O 密集）
2urls = ["https://example.com/file1", "https://example.com/file2", ...]
3# 一個一個下載太慢了！
4
5# 情境 2：處理大量資料（CPU 密集）
6data_chunks = [chunk1, chunk2, chunk3, ...]
7# 能不能同時處理多個資料區塊？

並行處理可以顯著提升這類任務的效率。

I/O 密集 vs CPU 密集

在選擇並行方案之前，首先要判斷你的任務類型：

I/O 密集任務

程式大部分時間在「等待」外部資源：

• 網路請求（HTTP、API 呼叫）
• 檔案讀寫
• 資料庫查詢

1# I/O 密集的特徵：大部分時間在等待
2def fetch_data():
3    response = requests.get(url)  # 等待網路回應
4    return response.json()

CPU 密集任務

程式大部分時間在「計算」：

• 數學運算
• 資料處理與轉換
• 圖像處理

1# CPU 密集的特徵：大部分時間在計算
2def compute_heavy(n):
3    return sum(i * i for i in range(n))  # 純計算

GIL（全域直譯器鎖）

在深入各模組之前，需要先了解 Python 的一個重要機制。

什麼是 GIL？

GIL（Global Interpreter Lock）是 CPython 直譯器的一個機制，它確保同一時間只有一個執行緒能執行 Python bytecode。

 1┌─────────────────────────────────────────┐
 2│              Python 直譯器                │
 3│  ┌─────┐  ┌─────┐  ┌─────┐              │
 4│  │執行緒1│  │執行緒2│  │執行緒3│              │
 5│  └──┬──┘  └──┬──┘  └──┬──┘              │
 6│     │        │        │                 │
 7│     └────────┼────────┘                 │
 8│              ▼                          │
 9│         ┌───────┐                       │
10│         │  GIL  │ ← 同時只有一個能執行      │
11│         └───────┘                       │
12└─────────────────────────────────────────┘

GIL 的影響

這就是為什麼：

• I/O 密集：使用 threading 即可
• CPU 密集：需要使用 multiprocessing 繞過 GIL

注意：Python 3.13+ 推出了 Free-threading（無 GIL）版本，詳見 3.8 Free-Threading

threading 模組

threading 模組提供執行緒級別的並行，適合 I/O 密集任務。

基本用法

 1import threading
 2import time
 3
 4def worker(name, delay):
 5    print(f"{name} 開始工作")
 6    time.sleep(delay)  # 模擬 I/O 等待
 7    print(f"{name} 完成工作")
 8
 9# 建立執行緒
10t1 = threading.Thread(target=worker, args=("Worker-1", 2))
11t2 = threading.Thread(target=worker, args=("Worker-2", 1))
12
13# 啟動執行緒
14t1.start()
15t2.start()
16
17# 等待執行緒完成
18t1.join()
19t2.join()
20
21print("所有工作完成")

執行緒安全與 Lock

當多個執行緒存取共享資源時，需要使用鎖來避免競爭條件：

 1import threading
 2
 3counter = 0
 4lock = threading.Lock()
 5
 6def increment():
 7    global counter
 8    for _ in range(100000):
 9        with lock:  # 使用 context manager 自動獲取和釋放鎖
10            counter += 1
11
12# 建立多個執行緒
13threads = [threading.Thread(target=increment) for _ in range(5)]
14
15for t in threads:
16    t.start()
17for t in threads:
18    t.join()
19
20print(f"Counter: {counter}")  # 應該是 500000

何時使用 threading

• 網路請求（HTTP、API）
• 檔案讀寫
• 資料庫操作
• 任何需要等待外部資源的任務

multiprocessing 模組

multiprocessing 模組使用多個進程來實現真正的並行，繞過 GIL 限制。

基本用法

 1from multiprocessing import Process
 2
 3def cpu_intensive(n):
 4    """CPU 密集計算"""
 5    result = sum(i * i for i in range(n))
 6    print(f"計算完成: {result}")
 7
 8if __name__ == "__main__":  # 在 Windows 上必須使用這個保護
 9    processes = []
10    for i in range(4):
11        p = Process(target=cpu_intensive, args=(10_000_000,))
12        processes.append(p)
13        p.start()
14
15    for p in processes:
16        p.join()
17
18    print("所有計算完成")

進程間通訊

進程之間不共享記憶體，需要使用 Queue 或 Pipe 來通訊：

 1from multiprocessing import Process, Queue
 2
 3def worker(queue, n):
 4    result = sum(i * i for i in range(n))
 5    queue.put(result)  # 將結果放入佇列
 6
 7if __name__ == "__main__":
 8    queue = Queue()
 9    processes = []
10
11    for i in range(4):
12        p = Process(target=worker, args=(queue, 5_000_000))
13        processes.append(p)
14        p.start()
15
16    for p in processes:
17        p.join()
18
19    # 收集結果
20    results = [queue.get() for _ in range(4)]
21    print(f"結果: {results}")

何時使用 multiprocessing

• CPU 密集計算
• 資料處理與轉換
• 需要真正並行執行的任務

concurrent.futures（推薦入門）

concurrent.futures 提供了更高階、更簡潔的 API，統一了執行緒和進程的使用方式。

ThreadPoolExecutor

適合 I/O 密集任務：

 1from concurrent.futures import ThreadPoolExecutor
 2import urllib.request
 3
 4def fetch_url(url):
 5    """下載網頁並返回大小"""
 6    try:
 7        with urllib.request.urlopen(url, timeout=10) as response:
 8            return url, len(response.read())
 9    except Exception as e:
10        return url, f"Error: {e}"
11
12urls = [
13    "https://www.python.org",
14    "https://docs.python.org",
15    "https://pypi.org",
16]
17
18# 使用執行緒池並行下載
19with ThreadPoolExecutor(max_workers=3) as executor:
20    results = list(executor.map(fetch_url, urls))
21
22for url, size in results:
23    print(f"{url}: {size}")

ProcessPoolExecutor

適合 CPU 密集任務：

 1from concurrent.futures import ProcessPoolExecutor, as_completed
 2
 3def compute_heavy(n):
 4    """CPU 密集計算"""
 5    return n, sum(i * i for i in range(n))
 6
 7if __name__ == "__main__":
 8    numbers = [10_000_000, 20_000_000, 15_000_000, 5_000_000]
 9
10    with ProcessPoolExecutor() as executor:
11        # 方法 1：使用 map（保持順序）
12        results = list(executor.map(compute_heavy, numbers))
13
14        # 方法 2：使用 submit + as_completed（先完成先處理）
15        futures = {executor.submit(compute_heavy, n): n for n in numbers}
16        for future in as_completed(futures):
17            n, result = future.result()
18            print(f"n={n}: {result}")

處理異常

 1from concurrent.futures import ThreadPoolExecutor, as_completed
 2
 3def risky_task(n):
 4    if n == 3:
 5        raise ValueError("不喜歡 3！")
 6    return n * 2
 7
 8with ThreadPoolExecutor(max_workers=4) as executor:
 9    futures = {executor.submit(risky_task, i): i for i in range(5)}
10
11    for future in as_completed(futures):
12        n = futures[future]
13        try:
14            result = future.result()
15            print(f"任務 {n} 完成: {result}")
16        except Exception as e:
17            print(f"任務 {n} 失敗: {e}")

選擇指南

決策流程

 1任務類型是什麼？
 2    │
 3    ├─→ I/O 密集（網路、檔案、DB）
 4    │       │
 5    │       └─→ 使用 ThreadPoolExecutor
 6    │
 7    └─→ CPU 密集（計算、處理）
 8            │
 9            ├─→ Python 3.14+ Free-threaded
10            │       │
11            │       └─→ 可以使用 threading
12            │
13            └─→ 傳統 Python
14                    │
15                    └─→ 使用 ProcessPoolExecutor

常見陷阱與最佳實踐

1. 設定合理的 worker 數量

1import os
2
3# I/O 密集：可以設定較多的 worker
4io_workers = min(32, os.cpu_count() + 4)
5
6# CPU 密集：不要超過 CPU 核心數
7cpu_workers = os.cpu_count()

2. 避免共享可變狀態

 1# 不好：共享可變狀態
 2results = []
 3
 4def bad_worker(n):
 5    results.append(n * 2)  # 危險！多執行緒存取
 6
 7# 好：返回結果，由主執行緒收集
 8def good_worker(n):
 9    return n * 2
10
11with ThreadPoolExecutor() as executor:
12    results = list(executor.map(good_worker, range(10)))

3. 使用 context manager

1# 好：使用 with 語句自動管理資源
2with ThreadPoolExecutor(max_workers=4) as executor:
3    results = executor.map(task, items)
4
5# 不好：手動管理
6executor = ThreadPoolExecutor(max_workers=4)
7results = executor.map(task, items)
8executor.shutdown(wait=True)  # 容易忘記

4. multiprocessing 的 if __name__ == "__main__" 保護

 1from multiprocessing import Process
 2
 3def worker():
 4    print("Working...")
 5
 6# Windows 上必須使用這個保護，否則會無限遞迴
 7if __name__ == "__main__":
 8    p = Process(target=worker)
 9    p.start()
10    p.join()

思考題

1. 為什麼 I/O 密集任務使用 threading 就夠了，而 CPU 密集任務需要 multiprocessing？
2. ThreadPoolExecutor 和手動建立 Thread 有什麼優缺點？
3. 在什麼情況下，並行處理反而會比序列處理更慢？

實作練習

1. 寫一個函式，使用 ThreadPoolExecutor 同時檢查多個網址是否可以連線
2. 使用 ProcessPoolExecutor 計算一組大數字的質因數分解
3. 實作一個進度顯示器，顯示多個任務的完成進度

延伸閱讀（進階系列）

• 實戰效能優化：並行處理 - 真實案例的並行化改造
• asyncio 非同步程式設計 - 學習協程與事件迴圈
• GIL 與執行緒模型 - 深入理解 GIL 的設計與實現
• Free-Threading - Python 3.13+ 無 GIL 多執行緒

上一章：argparse - CLI 介面 下一章：效能迷思與優化策略

效能可觀測性的責任是讓容量決策有訊號基礎。沒有適當訊號時、就算有壓測結果跟容量計畫、也看不到「現在實際距離 saturation 多遠」、無法做即時調整。

跟 9.4 Saturation Discovery 的關係：9.4 找到 saturation 點、9.8 定義持續監控這個點的訊號跟 dashboard。跟 04 可觀測性模組 是 sibling — 04 處理通用觀測、9.8 處理 容量規劃用 的觀測。

本章不重複 04 的訊號治理基礎、聚焦在 容量 / 效能 / 成本三條觀測線怎麼整合。讀完後讀者能設計一個「容量 dashboard」、回答「現在距離 saturation 還有多遠、什麼時候該擴」。

USE method 在 production 持續監控

USE method 不只是壓測時用、production 也要持續監控。

對每個資源（CPU / RAM / disk / network / DB connection / cache pool / file descriptor）量三個維度：

• Utilization（使用率 0-100%）：直觀但會誤判
• Saturation（queue depth）：早期警訊
• Errors（資源層錯誤）：已經出事的訊號

為什麼不能只看 utilization：

• CPU 100% 但 run queue 空 → 還能撐（單純 CPU bound）
• CPU 80% 但 run queue 不斷增長 → 已 saturate（saturation 比 utilization 領先）

Saturation metric 是 capacity warning 的最早訊號：

• queue depth（每個 queue / pool）
• connection pool 使用率（最常見隱性 bottleneck）
• thread pool / coroutine count
• event loop lag（Node.js、async runtime）
• GC pause time / frequency
• cache hit rate / eviction rate
• replication lag

Dashboard 設計：每個關鍵資源獨立 panel、同時顯示 utilization 跟 saturation。alert 在 saturation 起飛 時觸發、不是 utilization 滿。

對應案例：Lemino connection limit — connection saturation 是 RDB 的真正 bottleneck、不是 CPU；Zomato latency 降 90% — 從 TiDB 換到 DynamoDB、saturation 行為完全不同、observability 也要跟著改。

RED method：請求層的容量訊號

RED method 跟 USE 互補、從請求層看容量。

• Rate：requests per second（每個 service / endpoint）
• Errors：error rate
• Duration：latency distribution（histogram、不是單一 percentile）

Duration 比 Errors 早：duration p99 飆通常先於 error rate 上升、是 saturation 的早期警訊。

每個 endpoint 都要有 RED：不能只看全站 average、要分 endpoint。登入 endpoint 跟結帳 endpoint 的 saturation 行為不同、混在一起看不到 issue。

Histogram 是必須、不是 nice-to-have：

• 只記 p99 → 看不到 p999、看不到 distribution shape
• 記 histogram → 可以隨時算任何 percentile、可以做 long-tail 分析
• Prometheus histogram、OpenMetrics histogram 是現代標準

對應案例：GR8 Tech 25ms p95 — p95 是業務 KPI、不是技術指標、每個 endpoint 都有獨立 SLO。

p50 / p95 / p99 / p999 的取捨

不同 percentile 反映不同問題、選錯 percentile 會錯失 issue。

• p50（中位數）：整體狀況、感覺正常的指標、對長尾不敏感
• p95：日常 user-perceived experience、大多數用戶感受到的延遲
• p99：minority but critical 用戶體驗、SLO 常訂在這
• p999：極端長尾、受 GC pause / leader election / retry storm 影響、internal critical 系統訂在這

業務 SLO 通常訂 p99：「99% 用戶 request < 500ms」是常見承諾、合約 SLA 也通常基於 p99。 Internal critical 系統訂 p99.9：金融交易、即時配對、客服 SaaS（5 個 9 可用性對應 5 個 9 latency 期待）。

紀錄分布、不只紀錄 percentile：

• gauge p99 → 看不到 distribution shape、看不到 multimodal 分布
• histogram → 可以重新計算任何 percentile、可以對比 distribution、可以找 anomaly

對應案例：Tubi p99 < 10ms — ML inference 在 p99 才能控制用戶體驗、p50 沒意義；Coinbase sub-ms — 必須關注 p999、RAFT 系統長尾顯著。

詳見 Tail Latency 卡片。

Cost dashboard

成本訊號跟容量訊號要 並列顯示、不要分開看。

Per-service / per-endpoint cost attribution：

• 每個 service 自己的雲端成本
• 拆到每個 endpoint
• 跟 RPS / latency 並列、看「成本上升是因為流量還是低效」

Cost per request 的時序變化：

• 突然上升通常是 退化 訊號（新版本沒效率）
• 緩慢上升通常是 規模 訊號（用戶增加但 efficiency 沒變）