基礎設施估算

每秒 100 次時平均同時處理多少？

使用工具

每秒處理 100 請求是否需 100 個槽位？取決於停留時間，0.01 秒與等待兩秒產生的同時在途數不同。工具估算穩定系統平均量，用於關聯觀測值，不自動決定伺服器數量。

含單位的第一次計算

L = λ × W
100 requests/second × 0.2 seconds = 20 requests

選擇平均同時處理，速率 100、平均停留 0.2 秒，得 20。秒相消，單位是請求件數，不是使用者數或 CPU。應先定義一件請求與系統邊界。

200 ms 要填 0.2 秒，填 200 就是二百秒，得 20000，差千倍。每分鐘百件也不是每秒百件。先保留公式單位，避免把換算錯誤當效能問題。

若邊界是接收到回應，停留包括排隊與外部等待。只填 CPU 活躍時間是另一問題。API 全到達率配 DB 局部時間會失去一致含義，應使用同對象、同邊界的率與時間。

0.2 秒中若 0.15 秒等待外部，平均二十件不意味二十顆 CPU 一直忙。非同步與連線處理影響資源使用，應把滯留件數與 CPU、連線池容量分開分析。

只改變停留時間的比較

100/s × 0.2 s = 20
100/s × 0.5 s = 50
100/s × 2.0 s = 200

速率保持 100，時間改 0.5、2 秒，平均變 50、200。無到達尖峰也可因完成變慢而增同時數。公式解釋關係，不診斷變慢原因；時間分解需實測。

相同到達率下平均時間縮短，平均在途數也降。但僅最快請求改善不能替換均值。前後應使用同類請求與相同統計方法。

突發到達與長請求可使瞬時數超平均。平均二十不保證上限二十無排隊。速率乘 p95/p99 延遲也不等於對應同時數分位數，因為公式連結平均而非分位點。

顯示向上取整參考值也不是資源數保證。平均 0.5 含閒置時段，不是半個實體請求。決定容量還需等待目標、尖峰、失敗率與負載測試。

模型前提是平均穩定，不應把積壓不斷增長區間當可持續穩態。初始積壓、失敗取消、跨觀察邊界的長請求都會影響統計。應核對同一可比區間的到達與完成數。

報告應含速率、平均時間、邊界，如每秒百件、接收到回應 0.2 秒、平均駐留二十件。用於解釋等待或發現測量不一致，不替代 CPU 或最大連線數規劃。