代理容量不等於供應商允許的最大並行數字。系統可能仍能建立連線，但延遲已經升高、重試快速增加、有效吞吐反而下降。容量規劃要找出的是：在成功率、延遲、成本與合規要求內能長期維持的最高可持續並行量。
先建立工作負載模型
測試前記錄真實業務特徵：
- 正常與尖峰時段每分鐘請求數；
- 目標國家與目標類型；
- 常見與最大回應大小；
- 工作階段時間，以及是否需要連續性；
- 可接受的中位數與第 95 百分位延遲；
- 逾時與重試額度；
- 「驗證成功結果」的明確標準。
輕量 API、大型頁面與多步驟工作階段的資源消耗不同，不應共用一個並行上限。
區分四種上限
1. 用戶端上限
應用程式可能先耗盡檔案描述元、通訊端、CPU、記憶體或事件迴圈容量。測試時要記錄用戶端資源，避免把本機瓶頸誤判為代理效能問題。
2. 代理路由上限
不同地區、閘道集區與工作階段模式可能有不同容量。每次測試都要標記閘道、地區、工作階段策略與驗證方式。
3. 目標網站上限
目標端可能有速率限制，並在請求壓力上升時降低服務。應遵守公開限制、robots 指示、存取控制與使用條款。容量測試不代表可以繞過限制。
4. 業務品質上限
即使連線仍能完成，只要驗證成功率、延遲、資料時效或成本超出服務目標，就已到達真正的容量上限。
採用階梯式負載測試
從保守基準開始，以固定階段提高並行量，例如 5、10、20、40、80 個工作單元。每個階段要持續足夠時間，讓連線重用、IP 輪換、DNS 行為與正常回應波動充分出現。不要直接跳到標示的最大值。
每個階段至少記錄：
- 嘗試與驗證請求的每秒吞吐；
- 首次成功率與有限重試後的最終成功率；
- 中位數、p95 與 p99 延遲；
- 逾時、連線、驗證與內容檢查錯誤；
- 每筆有效結果的位元組數；
- 活躍工作階段、佇列深度與重試量；
- 每次成功請求的代理、運算與人工成本。
當錯誤明顯加速、延遲超標、佇列持續增長，或有效吞吐不再上升時，就應停止提高壓力。
找出飽和轉折點
繪製並行量與有效吞吐、p95 延遲的關係。飽和轉折點之後，增加工作單元只帶來少量有效吞吐，卻明顯增加延遲、失敗或成本。
例如，40 個工作單元可在合格延遲內提供每秒 34 筆有效結果；增加到 80 後，吞吐只升到 37，但 p95 延遲加倍、重試變成三倍。後者的數字較大，實際營運品質卻更差。
建立安全運行區間
正式環境不應長期處於測試邊緣。要為目標變動、區域事件與流量突增保留餘量。可先把正式上限設為實測可持續上限的 60%–80%，再用真實資料調整。
建議分別設定以下維度的上限：
- 國家或地區；
- 目標網域或端點群組；
- 請求與回應大小；
- 固定、黏著或輪換工作階段；
- 一般與尖峰時段。
控制重試與佇列
重試會產生隱藏並行。100 個主要請求若同時觸發 30 次重試，真實壓力就是 130。應設定小型重試額度，使用帶隨機抖動的指數退避，並依錯誤類型決定是否重試。永久驗證錯誤、無效請求與明確拒絕不應重試。
佇列必須有限制。無限佇列會把過載隱藏到請求已失去業務價值。等待時間超標後，應拒絕、延後或減少新工作。
避免常見測試錯誤
- **只測一個容易的網域：**應使用真實目標組合。
- **只看 HTTP 狀態：**也要驗證內容與時效。
- **忽略預熱：**區分建立連線與穩定狀態。
- **意外重用同一 IP：**確認工作階段行為符合設計。
- **同時改變多個變數：**把並行調整與逾時、重試調整分開。
- **只測短暫突發：**也要測試持續負載與恢復。
- **保留敏感記錄：**移除憑證與不必要的個人資料。
正式環境監控
並行量必須與驗證吞吐、p95 延遲、重試率、佇列等待時間和單位成功成本一起觀察。不要只在完全失敗時警示；佇列上升但吞吐不變，就是早期飽和訊號。
目標組合、回應大小、地區分布、代理方案、用戶端環境或驗證規則改變後，都應重新測試。
容量規劃檢查清單
- 定義驗證成功與延遲目標。
- 測試前拆分工作負載。
- 建立低負載基準。
- 分階段提高並行量。
- 每個階段維持到穩定狀態。
- 分開記錄首次與重試後結果。
- 找出吞吐與延遲的飽和轉折點。
- 為正式環境保留安全餘量。
- 限制佇列與重試額度。
- 跨地區、尖峰時段重複測試。
常見問題
最大並行連線數就是容量嗎？
不是。它通常只是技術允許值。可持續容量還必須符合有效成功率、延遲與成本目標。
所有地區應使用同一上限嗎？
不應該。資源集區、距離、目標與回應大小各不相同，重要地區要分別建立安全區間。
多久需要重新測試？
工作負載或基礎設施明顯改變後要重新測試；高流量路由也應定期複查，並在完整評估之間執行小規模金絲雀測試。
團隊可以查看 98IP 住宅代理容量方案，並在擴大量級前套用這套受控測試方法。只測試已授權目標、遵守目標規則，並盡量減少資料保留。
