購買更多容量前，如何執行代理並行爬坡測試

增加並行工作者不一定增加有效資料。當代理工作流程逐漸壓滿閘道、目標授權額度、本機連線池、解析器、瀏覽器叢集或下游佇列時，重試會進一步放大負載。原始請求數仍在上升，有效結果卻可能停滯。

並行爬坡測試用於找出授權工作負載可持續、穩定、合規且經濟的最高區間。它是容量規劃，不是突破目標控制的手段。

先以業務結果定義容量

不要從「每秒請求數」開始。先定義真正需要的輸出：每小時驗證後的商品列、每分鐘通過地區檢查的頁面、完成的可用性檢查，或其他可稽核結果。

每個階段至少計算：

• 首次嘗試有效率： 首次嘗試中有效輸出的比例。
• 有效吞吐量： 有效輸出除以經過時間。
• 佇列等待： 工作就緒到工作者啟動的時間。
• 服務延遲： 連線、TLS、首位元組與總耗時。
• 重試放大： 全部嘗試次數除以原始工作數。
• 單位有效結果成本： 代理、運算、瀏覽器與重試成本除以有效輸出。
• 新鮮度落後： 要求觀察時間與合格資料入庫時間的差值。

可持續點必須讓有效吞吐量繼續增加，同時錯誤、延遲、成本與政策風險不超標。

測試前拆開瓶頸

畫出完整路徑：

1. 排程器與佇列。
2. 工作者或瀏覽器容量。
3. 本機 DNS 與連線池。
4. 代理閘道驗證與通道建立。
5. 出口選擇、地區、位址家族與工作階段行為。
6. 已授權目標及其限制。
7. 解析、驗證、儲存及下游消費者。

若只能看見最終狀態碼，七個環節都可能被誤判為「代理故障」。應先在每個邊界加入時間戳與錯誤分類。

建立具代表性的測試集

只使用自有或明確授權目標。選擇接近生產回應體積、渲染需求、地區、工作階段模式與資料驗證的工作負載。

一次爬坡中固定：瀏覽器或 HTTP 用戶端版本、代理產品與閘道、請求地區、輪換或黏性策略、IPv4/IPv6、目標集合和內容斷言、逾時與重試、工作者映像及連線池。

變數有實質變化時應分開爬坡。把瀏覽器與原始 HTTP、輪換與黏性、多個地區混成一個數字會掩蓋限制案例。

選擇安全並行階梯

從目標所有者、代理契約或內部系統給出的最小限制以下開始。可採 1、2、4、8、12、16、24 個工作者，但數值必須符合授權環境。

每個階段：

1. 用短暫低流量預熱。
2. 執行到足以覆蓋正常延遲變化。
3. 固定或清楚限制原始工作數。
4. 任一安全或品質門檻失敗時停止升級。
5. 系統需要恢復時安排冷卻。
6. 重複同一階段，區分趨勢與偶發事件。

不要從一個工作者直接跳到最大值。漸進爬坡才能看見曲線拐點。

驗證內容，而非只驗證傳輸

HTTP 200 可能是登入頁、空表、同意頁、舊快取、地區變體或封鎖提示。為每類目標定義有效結果契約：必要欄位與型別、列數上下限、語言/幣別/地區標記、新鮮度、已知空狀態，以及必須使結果失敗的解析警告。

把傳輸成功和內容有效分成兩個欄位。代理可能成功傳輸位元組，但工作流程沒有業務價值。

讓重試可見且有邊界

第一次測量不能被重試覆蓋。先記錄首次嘗試，再只對符合條件且可安全重複的工作執行有限重試。

至少分類連線與驗證、DNS、TLS、標頭前逾時、HTTP 429/503、內容契約、地區或工作階段偏差、解析與儲存失敗。

回應含 Retry-After 時，把它視為該作用域的最小等待時間。不得為了規避限制而輪換位址。限制可能依帳戶、資源、路由或伺服器執行，合規用戶端應降低需求，而非增加身分。

對符合條件的暫時故障使用帶抖動的指數退避、嚴格次數上限及批次總預算。重試放大超標即停止該階段。

同時觀察佇列

工作者保持忙碌時，有效吞吐量仍可能停滯，因為一個慢目標占滿共享容量。依目標類別記錄佇列深度與年齡。

設定每目標並行上限，避免單一網域使其他工作飢餓。不同地區或產品差異很大時使用隔離佇列或公平排程。只有全域工作者數無法得到可信容量結論。

找到曲線拐點

拐點是新增並行幾乎不增加有效吞吐量，或使品質快速惡化的階段。生產上限應低於拐點，為延遲變化與維護保留餘裕。

以標準化結果比較價格

按 GB、請求或並行工作階段計費不能直接比較。對相同授權工作負載統一換算為：

預估月成本 / 在要求新鮮度內通過驗證的輸出數

納入無效頁面與合規重試耗用的流量；瀏覽器運算、佇列基礎設施和人工維護成本較高時也應納入。最便宜的流量單位可能產生最昂貴的有效結果。

放量與回復門檻

只有重複階段通過全部閾值，才能核准並行等級。記錄測試窗口、精確設定、樣本與授權、首次和最終有效率、吞吐量、佇列年齡、p50/p95、重試放大、單位有效結果成本、依地區/ASN/前綴/工作階段/目標聚類的失敗、生產上限、負責人與複查日期。

生產窗口觸發安全、政策、品質、成本或新鮮度閾值時回復。用戶端、代理產品、目標或工作負載實質變更後重新爬坡。

檢查清單

• 已定義業務輸出與有效結果契約。
• 目標為自有或明確授權。
• 已記錄代理與目標限制。
• 每次爬坡只測一組變數。
• 並行依受控階梯增加。
• 重試前先記錄首次嘗試。
• 遵守 Retry-After。
• 重試可安全重複、有上限、有預算。
• 依目標類別記錄佇列深度與年齡。
• 對 200 回應執行內容驗證。
• IPv4/IPv6、輪換/黏性分開統計。
• 成本換算為單位有效結果。
• 生產上限保留餘裕。
• 已記錄回復觸發與負責人。

常見問題

測試中成功的最大並行就是生產上限嗎？

不是。短時測試可能在沒有餘裕的等級通過；生產應低於拐點並位於重複驗收區間。

遇到 429 是否應立即輪換代理？

不應。先遵守目標政策與 Retry-After。輪換身分規避限制不是容量規劃。

為何必須單列首次嘗試？

最終成功會掩蓋重試成本、額外負載及新鮮度下降；首次表現更能反映基本路由健康度。

多久複測一次？

用戶端、瀏覽器、代理產品、地區、工作階段策略、位址家族、目標契約或工作負載規模有實質變化後都應複測，高價值生產路徑也應定期複查。

來源與合規說明

內部研究參考 IETF HTTP Semantics 規範、Mozilla HTTP 429 與 Retry-After 資料，以及近期關於十倍擴容、佇列飢餓、重試成本和無效資料的海外需求討論。研究網址僅保存在內部營運中台。

代理只能用於自有或已授權系統和資料。遵守契約、適用的 robots 與存取政策、速率限制、隱私要求、安全控制及當地法律。不得使用並行、重試或輪換規避限制或偽裝身分。

相關 98IP 內容：代理試用驗收測試、瀏覽器與代理迴歸測試及住宅代理來源稽核。