打爆它，
然後解釋為什麼。

三個核心概念：User（一個虛擬使用者 = 一個 greenlet，跑自己的任務迴圈）、@task(weight)（任務與權重，read_posts(3):read_users(1) = 75%:25%）、wait_time（思考時間，真人不會連發請求）。

1. 全套起來：docker compose up -d --build --wait
   為什麼：demo1 就是 compose 的預設腳本，三容器（db / 靶機 / Locust）一起上、cpuset 與記憶體限制全套生效，不必另外指定 LOCUSTFILE。
2. 開 Web UI http://localhost:8089/?tab=charts，先用 10 users 開打
   為什麼從 10 開始：低負載先確認管線是通的、報表會動，當作後面兩級的基準；一上來就 100 users，「慢」是真瓶頸還是還沒暖機會分不清。
3. 依序 50、100 users 各跑一輪，每輪記錄 p50 / p95 / RPS / error rate
   為什麼一次只加一級：users 是這支唯一動的旋鈕。三級分開跑，才能畫出「users → RPS」的關係，看出它不是線性。

# 全套起來（db + 靶機 + Locust），demo1 是預設腳本
docker compose up -d --build --wait
open http://localhost:8089/?tab=charts   # UI 設 10 → 50 → 100 users 各跑一輪，直接看 Charts

要能回答：100 users + wait_time(1,3) 的理論 RPS 上限是多少？為什麼 users 加倍，RPS 沒跟著加倍？

上面模擬器的真槍實彈版。用同樣 20 users、同樣 constant(0)（連發）打三個只差在「怎麼等那 1 秒」的端點，把 blocking / async / CPU-bound 一次量出來。靶機只有 1 worker、1 條 event loop，這是所有戲劇的前提。

1. 先跑對照組 B：在 class-picker 勾 AsyncSleepUser，20 users / spawn 20，按 Start
   為什麼先跑 B：它是「正確行為」的基準線——RPS≈20、p95≈1s。手上先有「正常長什麼樣」，A 和 C 的異常才有對照。
2. Stop 後改勾實驗組 A：SyncSleepUser（users / spawn 不變）
   為什麼只換 class：users、時長、spawn rate 全固定，唯一變因是端點等待方式，p95 從 1s 暴衝到數十秒就只能歸因到 blocking。
3. 跑 A 的同時，另開 terminal：curl -m 5 http://localhost:8000/healthz
   為什麼這一刀最關鍵：/healthz 根本不碰 DB、理應毫秒回應，此刻卻 timeout——證明 blocking 卡的不是「某個請求」，是整條服務。這正是 K8s liveness probe 會誤殺 Pod 的根因。
4. 最後改勾實驗組 C：CpuUser
   為什麼留到最後：打破「async = 快」的迷思——C 是 async def 卻照樣串行，因為 CPU 計算期間沒有讓出點。async 解決 I/O 等待，救不了 CPU bound。

# 起 Web UI，在 class-picker 選 class 開打（教學預設用 UI 看 Charts）
docker compose up -d --build --wait
LOCUSTFILE=demo2_event_loop.py docker compose up -d locust
open http://localhost:8089/?tab=charts   # 先勾 AsyncSleepUser(B)，20 users / spawn 20，Start
# 看完一輪按 Stop → 改勾 SyncSleepUser(A)、CpuUser(C) 各跑一輪對照

要能回答：為什麼一個 time.sleep(1) 連 /healthz 都殺死？實驗 C 是 async def 為什麼還是卡？哪些常見函式庫（requests、psycopg2…）會像 A 一樣偷偷 block？

做任何靶機實驗前的前置檢查：先證明攻擊機自己不是瓶頸，否則 demo4/5/6 全是在測 Locust，不是測靶機。同樣 300 users、同樣打 /healthz（靶機最快、幾乎零成本的端點），只換攻擊機用的 HTTP client。

1. 另開 terminal 先掛上 docker stats
   為什麼要先開：本 demo 重點不在 RPS 數字，而在攻擊機的 CPU%。沒同時盯攻擊方，看到「RPS 上不去」會誤判成靶機弱。
2. 第一輪對照組：class-picker 勾 SlowAttacker，300 users / spawn 100，Start
   觀察什麼：locust 容器 CPU 鎖死 ~100%（單核），RPS 卡在 5,921。此刻去看靶機 uvicorn——CPU 還很閒。瓶頸在攻擊機，數據是假的。
3. Stop 後改勾實驗組：FastAttacker，users / spawn 不變
   為什麼參數要完全一樣：唯一變因是武器。RPS 從 5,921 跳到 24,762（4.2×），靶機沒任何改動——直接證明剛才壓的是 Locust 的天花板。
4. 第三輪 --processes 4：要停掉預設 locust、改用 --service-ports 起（見指令；前菜：階段三分散式）
   為什麼還要加 process：單 process 受 GIL 限制只吃一核；locust 容器有 4 核（cpuset 4-7），開 4 process 才吃得滿。RPS 再翻——接著瓶頸換人（靶機？網路？）。

docker compose up -d --build --wait
LOCUSTFILE=demo3_attacker_bottleneck.py docker compose up -d locust
open http://localhost:8089/?tab=charts   # 勾 SlowAttacker 跑一輪 → Stop → 改勾 FastAttacker，皆 300 users / spawn 100
docker stats   # 全程盯 locust 容器 CPU% —— SlowAttacker 會先鎖死 100%

# 第三輪要 --processes 4：停掉預設 locust 讓出 8089，改用一次性 run（不加 --headless = Web UI）
docker compose stop locust
docker compose run --rm --service-ports locust -f /mnt/locust/demo3_attacker_bottleneck.py \
  --host http://app:8000 --processes 4 --class-picker
open http://localhost:8089/?tab=charts   # 勾 FastAttacker，Start

要能回答：怎麼從 metrics 判斷「瓶頸在攻擊機」而非靶機？Python GIL 在這裡扮演什麼角色？單機 --processes 和 K8s 分散式 Locust 差在哪？

本訓練的核心對照實驗。前置都做完了（會用工具、懂 event loop、攻擊機不是瓶頸），現在打真 PostgreSQL。?delay_ms=100 讓每個查詢佔住 connection 100ms，模擬慢查詢。

1. export DB_POOL_SIZE=100，再 docker compose up -d --build --wait
   為什麼先把 pool 開大：要讓 sync 的瓶頸確定落在 threadpool（40）而不是 pool。pool 太小兩組都卡 pool、看不出差異（demo5 會證明）。為什麼一定要 export：不 export，下一個 compose 指令會用預設 pool=5 把 app 默默重建回去——真踩過，四輪數據一模一樣。
2. 先跑對照組：class-picker 勾 SyncPostsUser，100 users / spawn 50，Start
   為什麼當對照：sync 是「沒做任何特別處理」的基準。先量它，才知道 async 到底快多少。
3. Stop 後改勾實驗組：AsyncPostsUser，users / spawn 不變
   為什麼只換 class：唯一變因是併發模型。100 併發 > threadpool 40 時，sync 被迫排隊、async 不必，差異此刻才現形。
4. 跑完驗證旋鈕：docker inspect k8s-app-1 … | grep DB_POOL
   為什麼養成這習慣：確認 app 真的吃到 pool=100 而非被默默重建回 5。「改了變因卻沒變化，先驗證旋鈕接上了」是 LESSON 04。

# pool 開大，逼 sync 瓶頸落在 threadpool（40）而非 pool
# 一定要 export，否則下個指令以預設 pool=5 把 app 重建回去（真實踩過）
export DB_POOL_SIZE=100
docker compose up -d --build --wait
# 起 Web UI，對照組 → 實驗組只在 class-picker 換 class，users / spawn 不變
LOCUSTFILE=demo4_sync_vs_async_db.py docker compose up -d locust
open http://localhost:8089/?tab=charts   # 勾 SyncPostsUser → Stop → 改勾 AsyncPostsUser，皆 100 users / spawn 50
# 驗證旋鈕真的生效
docker inspect k8s-app-1 --format '{{.Config.Env}}' | tr ' ' '\n' | grep DB_POOL

要能回答：sync 版的 40 哪來的（AnyIO threadpool 預設）？把它調大是對的解法嗎？瓶頸是 threadpool 還是 pool 連線數，怎麼設計實驗分開驗證？

固定攻擊參數，只掃一個旋鈕 DB_POOL_SIZE，畫出「p95 對 pool 大小」的曲線。這支證明：connection pool 才是 p95 的主宰，async 不是魔法。?delay_ms=50 讓查詢佔住連線、放大 pool 的影響。

1. 每輪開頭先重置：docker compose down
   為什麼每輪都重置（鐵則 03）：不掛 volume，down 即回到同一份 seed（50 users / 200 posts）。每輪從相同起點出發，四條 p95 數據才能放同一張圖比較。
2. 設這一輪 pool：export DB_POOL_SIZE=10，再 up -d --wait
   為什麼從 10 當對照：先量「pool 嚴重不足」長什麼樣，當基準線。為什麼 export：同 demo4——不 export 會被下個 compose run 默默重設回 5，四輪全是假數據（LESSON 04 的由來）。
3. 打固定攻擊：UI 設 200 users / spawn 100，跑 ~60s 記錄 RPS / p95
   為什麼攻擊參數一字不動：四輪唯一變因是 pool。攻擊一變，p95 的變化就無法單純歸因到 pool。
4. 換 export DB_POOL_SIZE=20 / 50 / 100，重複步驟 1–3
   為什麼掃四級而非只比兩點：要看出「報酬遞減」的轉折——pool 50→100 幾乎不再有效益，代表瓶頸已換人。一條曲線比兩個點更有說服力。

# 每輪：重置 DB（鐵則 3）→ 換 pool 重啟 → 同一個攻擊 → 記錄
docker compose down
export DB_POOL_SIZE=10    # 下一輪換 20 / 50 / 100，攻擊參數不動
docker compose up -d --build --wait
LOCUSTFILE=demo5_pool_starvation.py docker compose up -d locust
open http://localhost:8089/?tab=charts   # UI 設 200 users / spawn 100，跑 ~60s 看 Charts 的 p95
docker inspect k8s-app-1 --format '{{.Config.Env}}' | tr ' ' '\n' | grep DB_POOL  # 驗證旋鈕

要能回答：pool 開越大越好嗎？PG 每條 connection 都是一個 process，max_connections 撞到會怎樣？pool_timeout 30s 到了會發生什麼——demo6 看到的某些 error 就是它。

整合戰：用擬真的讀寫混合流量（滑 feed:看用戶:發訊息 = 10:3:1）做階梯式加壓，找出靶機的崩潰點。StepLoadShape 自動控制階梯，不必手動調 users。

1. export DB_POOL_SIZE=100，再 up -d --build --wait
   為什麼用最大 pool：要找的是「系統極限」，不是 pool 瓶頸——pool 先開到最大，崩潰點才反映真正的天花板（CPU / MEM / 連線數）。export 理由同前。
2. 三容器一起掛 docker stats
   為什麼三方都要盯：崩潰時要立刻分辨誰先死——靶機 CPU？靶機 MEM？攻擊機？只看 RPS 看不出崩在哪一層。
3. 用多 process 起 Web UI：--processes 4 --service-ports（不加 --headless；階梯由腳本控制，免設 users）
   為什麼一定要多 process：5000 users 單 process 會先讓攻擊機變瓶頸（demo3 的教訓）；locust 容器有 4 核，開 4 process 才打得出 5000。坑：--processes 下別加 --csv-full-history，worker 繼承 flag 卻拿不到 prefix、啟動即死。
4. 逐階記錄，盯住「哪一階開始噴 error、第一個 error 是什麼」
   為什麼盯第一個 error 類型：它指向崩在哪一層——pool timeout 30s（pool/DB）？connection refused？OOM？這條崩潰曲線就是階段三 HPA 要對抗的敵人。

# 兩側容器 fd 上限 nofile=10240 已在 compose 設好，免調 ulimit
export DB_POOL_SIZE=100
docker compose up -d --build --wait
# 5000 users 要多 process；先停掉預設 locust 讓出 8089，再用 --service-ports 起 Web UI（不加 --headless）
docker compose stop locust
docker compose run --rm --service-ports locust -f /mnt/locust/demo6_step_load_social.py \
  --host http://app:8000 --processes 4
open http://localhost:8089/?tab=charts   # 按 Start，StepLoadShape 自動跑 10→100→1000→5000
docker stats   # 三容器一起盯：誰先死？

要能回答：崩潰時第一個 error 是哪種（pool timeout？connection refused？OOM？），它指向哪一層？wait_time(1,3) 下 5000 users 的理論 RPS 是多少？（≈ 2500，不是 5000）