量測自架 Umami（umami.holmesmind.com）在 synforce 網站上 real／cold 兩種情境的承受能力，並驗證兩次升級（機器規格 + 橫向擴展）實際帶來多少改善。
先把機器規格從 2 vCPU 升到 4 vCPU（t4g.medium → c7g.xlarge），大幅改善 real 模式表現；接著把 umami app 橫向擴展成 2 個副本（共用同一個 postgres、Caddy 負載平衡），連 cold 模式也一併解決。兩次升級各自解決不同情境的瓶頸，疊加起來 real／cold 現在都表現健康，全程 checks 100% 通過。
2 vCPU / 3.7GB → 4 vCPU / 8GB
t4g.medium → c7g.xlarge
1 個 app 副本 → 2 個 app 副本
共用同一個 postgres，Caddy 負載平衡
10→50→100→150→200→250→300 req/s
每階持穩 45–75 秒，real／cold 各一輪
| 指標（real 模式） | 原始基準 | 升級一後 | 升級二後 |
|---|---|---|---|
| med 延遲 | 4.52s | 7.51ms | 6.54ms |
| p95 延遲 | 9.75s | 1.79s | 12.83ms |
| max 延遲 | 30.37s | 8.99s | 223.11ms |
| dropped_iterations | 18,762 | 201 | 0 |
| http_reqs | 58,087 | 76,648 | 76,849 |
| 指標（cold 模式） | 原始基準 | 升級一後 | 升級二後 |
|---|---|---|---|
| med 延遲 | 7.34s | 13.96ms | 9.37ms |
| p95 延遲 | 9.37s | 5.32s | 19.72ms |
| max 延遲 | 10.01s | 5.49s | 280.94ms |
| dropped_iterations | 27,694 | 6,840 | 0 |
| http_reqs | 49,155 | 70,009 | 76,849 |
| PG 連線峰值 | 16 | 16 | 26 |
升級一（機器規格）讓 real 模式大幅進步；cold 模式要到升級二（橫向擴展）才真正突破——兩次升級分別針對不同瓶頸，疊加後兩種情境都達到穩定健康的狀態。
每輪測完立即查 /stats，確認 pageviews 對 http_reqs 量級相符，再 reset。
| 輪次 | pageviews | http_reqs | 比例 | visitors |
|---|---|---|---|---|
| 升級二後・real | 53,748 | 76,849 | 69.9% | 600 |
| 升級二後・cold | 53,836 | 76,849 | 70.1% | 600 |
比例對上腳本 7:3 的 pageview／自訂事件設計，visitors 對上 VU 池使用量，確認資料真的完整落地，不是被吞掉的假成功。
10→300 req/s 全程 checks 100% 通過、dropped_iterations 歸零，real 與 cold 的延遲都壓在毫秒級，跟升級前的秒級延遲相比是量級上的改善。
機器規格解決了 real 模式的算力需求；橫向擴展解決了 cold 模式需要更多資料庫併發處理能力的需求。兩個方向互補，疊加後才把兩種情境都補齊。
加開的第二個 app 副本沿用官方 ghcr.io/umami-software/umami:latest，共用同一個 postgres，之後升級 umami 版本直接換 image 即可，不用維護客製化程式碼。
兩個 app 副本由 Caddy 負載平衡分流，其中一個容器異常時另一個仍能繼續服務，不再是單點故障。