代理並行飽和測試：找出安全吞吐拐點
看似最快的代理設定，往往已經過載。吞吐量可能仍在上升，但排隊時間、p95 延遲、重試次數與每個有效結果的成本增加得更快。真正適合正式環境的點，是繼續增加並行量卻幾乎無法增加已驗證產出的拐點之前。
本指南適用於住宅、輪換、ISP 與資料中心代理路由的可重複容量測試。測試目標必須由你擁有，或已明確授權進行負載測試。本文不是突破網站限制的方法。
先拆分四種「並行」
- 提交並行量： 排程器嘗試同時執行的工作數。
- 進行中請求： 已離開應用程式但尚未完成的請求數。
- 作用中連線： 已建立或正在建立的傳輸連線；多工可讓一條連線承載多個請求。
- 排隊工作： 等待於應用程式、HTTP 用戶端、代理閘道或下游處理器的工作數。
如果只記錄工作程序數，用戶端連線池可能悄悄把大部分工作排隊，最後卻把請求抵達代理前產生的延遲誤判為代理效能問題。
列出每一層可能的瓶頸
測試前先畫出完整路徑：
排程器 -> 解析器 -> 用戶端連線池 -> 代理帳號/閘道
-> 網路與 TLS -> 已授權目標 -> 解析處理 -> 儲存任何一層達到上限，都可能呈現為「代理飽和」。應分別收集用戶端排隊、取得連線、DNS、代理連線、目標連線、TLS、首位元組、傳輸、驗證與下游處理時間。
準備確定且已授權的測試端點
使用專為測試設計的端點，保持回應大小、摘要與延遲可控制，並與擁有者約定測試時段與上限。固定內容、方法、標頭、預期狀態與驗證規則。
建立兩條對照：
- 直接連線對照： 在允許時，用同一用戶端直接存取同一端點，找出用戶端、目標端與下游上限。
- 代理路徑： 將完全相同的工作負載送往一個有明確記錄的路由類別與帳號策略。
不要在同一條曲線中混合市場、工作階段模式、位址家族或目標端行為。Global、North America、Europe 與 APAC 若對業務重要，應分開測試。
只計算真正有效的工作
每次嘗試記錄去識別化欄位：
run_id, route_class, market, address_family, session_mode
offered_concurrency, active_connections, in_flight, client_queue_ms
dns_ms, proxy_connect_ms, tls_ms, ttfb_ms, total_ms
status_class, retry_after_seen, attempt_number, response_digest_ok
bytes_transferred, useful_result, failure_phase每個並行級距應報告：
- 每秒已驗證有效結果；
- 排隊與總耗時的 p50、p95、p99；
- 首次嘗試成功率與最終成功率；
- 回應完整性通過率；
- 每個有效結果所需的重試與傳輸位元組；
- 依階段拆分的 407、429 與 5xx；
- 每個有效結果的成本，而非每次請求成本。
遭截斷、位置錯誤、未通過驗證或內容無效的回應，不能算入有效吞吐。
執行有上限的並行階梯
依記錄的方法預熱用戶端，再測試 1、2、4、8、16、32 等級距。範例不是建議上限；真正上限必須來自測試授權、供應商方案與目標策略。
每個級距：
- 保持工作定義與路由類別不變。
- 使用相同觀測時間，並涵蓋正常延遲變化。
- 將暖機樣本與正式樣本分開。
- 重複測試，以區分容量變化與短暫路由雜訊。
- 一旦超過約定上限、錯誤預算或延遲護欄，立即停止。
先採用閉迴路模型：每個工作程序只有在前一項工作完成後才開始下一項。開迴路到達率測試能揭示佇列增長，但工作可能以高於系統完成速度的速率累積，因此需要更嚴格的保護。
找拐點，不追峰值
相鄰級距計算：
吞吐增量 = 新級距有效 RPS - 前一級距有效 RPS
每新增工作程序收益 = 吞吐增量 / 新增並行數
單一有效結果成本 = 代理總成本 / 已驗證結果數拐點是邊際吞吐明顯衰退或護欄被突破前的最後一個級距。常見訊號包括：
- 並行量加倍，有效吞吐卻只成長不到 10%–15%；
- p95 總耗時或排隊延遲陡升；
- 首次嘗試成功率或回應完整性下降；
- 每個有效結果的重試與位元組數增加；
- 429、407、連線重設或逾時加速；
- 解析或儲存佇列持續堆積。
正式環境應保守地設定在拐點以下。穩定級距的 70%–85% 可作為評估起點，但安全係數必須反映路由波動與業務容忍度，不能機械套用。
找出真正飽和的層
| 證據 | 可能的限制 | 下一項檢查 |
|---|---|---|
| 用戶端佇列上升，作用中連線不變 | 用戶端池或連線上限 | 檢查單一來源與全域連線限制 |
| 代理連線時間和 407 上升 | 帳號或閘道策略 | 核對供應商並行與驗證限制 |
| 直接與代理路徑的目標首位元組都上升 | 已授權目標容量 | 降低負載並與目標擁有者協調 |
| 出現 429 與重試指引 | 目標策略 | 遵守等待時間並降低到達率，不得輪換規避 |
| 傳輸時間隨位元組增加 | 路由或本地頻寬 | 比較依位元組正規化的吞吐與網路遙測 |
| 網路穩定但完成佇列增長 | 解析或儲存 | 限制輸入並安全擴充下游 |
HTTP/2 或 HTTP/3 多工會讓請求並行量與連線數分離。必須記錄協商協定與串流行為，不能假設一條連線只對應一個請求。
設定正式環境工作池
可用容量受最小授權上限限制：
安全並行量 = 每類路由的實測穩定容量 × 安全係數同時以用戶端資源、供應商合約、目標授權與下游容量為硬上限。依市場和工作負載類型保留獨立預算，避免某條慢速路由占滿全域工作池。
加入自適應背壓：
- 佇列超過時間或深度預算時停止接收新工作；
- 尾端延遲或首次失敗持續惡化時降低並行量；
- 遵守伺服器重試指引，採用有上限且帶隨機抖動的退避；
- 限制重試次數，並將所有嘗試計入成本與負載；
- 經過數個健康觀測窗口後再逐步恢復，而非直接跳回舊峰值。
不得透過輪換 IP 規避速率限制或存取政策。
驗收清單
- [ ] 測試目標、時段與負載上限已明確授權。
- [ ] 直接與代理對照使用同一個確定性工作單元。
- [ ] 市場、位址家族與工作階段模式分別產生曲線。
- [ ] 排隊時間、作用中連線與進行中請求分別測量。
- [ ] 同時報告首次成功、完整性與有效吞吐。
- [ ] 重試、位元組與成本按有效結果正規化。
- [ ] 自動停止條件已設定並經過驗證。
- [ ] 正式環境並行量低於可重複出現的拐點。
- [ ] 背壓與漸進恢復已設定。
常見問題
最高 RPS 級距就是正確設定嗎？
通常不是。它可能隱藏極高尾端延遲、重試、無效回應與不穩定佇列。應選擇在品質、政策與成本護欄內最高且可重複的級距。
為什麼增加工作程序後，作用中連線沒有增加？
HTTP 用戶端可能設定單一來源或全域連線限制，將額外工作排隊；多工協定也可能在一條連線承載多個串流。請檢查連線池指標與協商協定。
所有路由都應使用相同並行量嗎？
不應。容量會隨市場、位址家族、代理產品、工作階段策略與工作負載改變，應為每種實際路由類別保存實測預算。
可以不計重試嗎？
不可以。重試會消耗頻寬、代理用量與目標容量。首次結果應分開報告，但最終成本與負載必須包含所有嘗試。
相關 98IP 指南
合規說明
僅對自己擁有或已明確授權的系統進行負載測試。遵守合約、robots 與存取政策、已聲明的速率限制、隱私要求和重試指引。不得以代理輪換規避封鎖、配額或身分控制。僅儲存去識別化營運遙測，絕不記錄代理憑證或個人資料。
