兩個核准專案共用代理工作程序，A持續完成工作，B卻一直等待，甚至尚未送出請求。帳號整體成功率可能掩蓋問題。購買更多容量或更換出口前，先確認B是否卡在自有派送器。
本文以小型自有預備負載驗收專案隔離，不測供應商容量，也不承諾SLA。目標是逐專案看見接納、派送及完成，確認慢專案不能占滿本機承諾保護的執行槽位。
一、分別記錄等待與執行
入列前分配穩定專案ID、邏輯工作ID及唯一嘗試ID。在同一程序使用合適單調時鐘，記錄入列、符合派送資格、開始執行及完成。沒有文件化同步方式，不直接相減不同機器時鐘。
佇列等待與執行時間分開報告。HTTP程式庫若另有取得連線的佇列，也須測量或註明邊界：「工作程序開始」未必表示請求已離開用戶端。沒有派送事件的工作不能歸類為代理回應慢。
二、明訂隔離政策及限制
記錄全域處理中上限、各專案活動上限、有限佇列長度、最長等待年齡及溢位動作。用戶端、供應商及目的端目前核准限制皆是硬性約束，專案預算相加不能突破。
決定閒置保留容量是否可借用，以及新工作抵達後如何恢復資格。不要承諾立即搶占已執行請求。寫清下一空位交給哪個合格專案，及過期、取消的排隊工作如何移除。佇列滿時須有明確拒絕、延後或過期結果，不能無限增加記憶體。
98IP動態住宅IP產品頁可確認授權工作使用的路徑產品，測試前仍須查核實際帳號選項與限制。API設定文件用於檢查已公布連線方式。兩者不證明應用程式自帶專案派送，也不保證分開憑證就獨享供應商容量。
三、建立兩專案確定樣本
- 在自有或獲准以約定負載測試的端點建立兩個合成專案，回應小且已知。
- 透過自有樣本或本機工作介接器刻意讓A變慢，B工作維持短小且內容可查核。
- 使用固定小型到達序列與總預算，逐專案記錄入列、啟動、拒絕、過期及完成。
- 執行前約定派送順序或資格規則，不從事後整體吞吐推論公平。
例如本機合成設定可在全域上限2以內，為兩專案各保留1個執行槽位。A占用自己的槽位時，合格B工作仍應可使用B空位，並遵守其他已聲明門檻。這只是派送器範例，不是建議代理上限或實測效能。
四、查核仍然共用的資源
兩通道若仍等待同一個耗盡HTTP集區、信號量、事件迴圈或結果寫入器，只分開應用程式佇列還不夠。追蹤B從符合資格到真正開始請求，再到產出驗證完成。隱藏全域資源可能在看似公平的派送之後再次造成飢餓。
依執行環境實際支援控制，決定哪些共用資源需要可執行分區或有界存取，並計入額外成本。邏輯隔離不保證獨立頻寬、出口或供應商額度。下游瓶頸阻塞兩專案時應如實定位，不能憑佇列名稱宣稱隔離成功。
五、重試與清理保留原專案歸屬
重試沿用邏輯專案身分並占用該專案核准嘗試預算。延遲重試經相同資格政策重新入列，不假裝新工作插隊。等待重試時間的工作不應占活動槽位，除非是明訂且經驗證的設計。
槽位應在底層操作真實生命週期允許時釋放，不是介面停止等待就算空閒。派送前已過期的工作則應移除，避免稍後突然執行。取消後底層仍運作，就記錄殘留工作，不分配虛構可用容量。
六、演練隔離與恢復
建議四個預備案例：A持續緩慢而B抵達；A佇列達到上限；A一次失敗後安排重試；A排隊工作在空位出現前過期。逐項查核B資格、全域上限、專案結果與槽位清理。這些是建議演練，並非已執行測量。
再讓A恢復，確認過期工作不復活、延後工作依約定順序執行、恢復重試不瞬間突破總預算。若允許借用容量，也要測A占借用槽位時B抵達，報告實際等待，不承諾立即歸還保留位。
紀錄包含到達順序、專案、工作、嘗試、資格、等待年齡、活動數、終態及內容驗證。小樣本可檢查完整序列；平均值可能掩蓋從未啟動的專案，不能只因總完成量增加就通過。
常見問題與驗收清單
更多IP能修復未被派送的工作嗎？單靠IP不能。先證明等待在哪一層，再變更網路資源。
公平就是完成數相同嗎？不是。工作時間與核准權重不同可產生不同數量，應驗證既定資格、保護規則及專案服務目標。
- 佇列等待、HTTP集區等待及執行可以區分。
- 各專案接納有界且溢位行為明確。
- 專案限制不突破共用總上限與目的端授權。
- 重試、過期與清理保留專案歸屬。
- 慢專案及恢復案例維持承諾的派送保護。
- 其餘共用瓶頸與未測情況已揭露。
只使用核准目標與小型合成負載，達約定請求及資源上限即停止，遮蔽機密，不以正式流量洪峰測試。隔離是須驗收的用戶端控制，不是規避目的端節流的許可，也不保證供應商層獨立。