先說清楚池裡裝的是什麼
連了三十台設備，就要三十個工作執行緒嗎？先分清開啟中的連線數、同時進行的請求數和工作執行緒數。三十條閒置的長連線不代表三十筆請求同時處理；一個非同步工作流程也可能管理多條連線。把這三個數分開，才有辦法估算容量。
本篇假設三十台設備，各自每秒查詢一次，每次請求占用一個處理名額直到完整回覆，平均占用0.2秒。每台先限制同時一筆未完成請求，整體再限制總併發。這是離線規劃案例，不代表設備手冊允許的連線上限。
若每台維持一條專屬TCP連線，總開啟socket可能是三十，但同時使用中的名額可以少於三十。不能把已連向設備A的socket直接借給設備B；連線池通常依端點及認證等條件分組，設備身份也是池的鍵。
先盤點每個設備可接受的連線數、未完成請求數、查詢週期、回覆長度與最大耗時。再盤點上層程式的socket、記憶體、執行緒及檔案描述元限制。這些上限可能由不同元件決定，不以電腦CPU核心數直接推算。
適用於上位採集程式或有明確併發管理的通訊服務。Q系列CPU和模組的連線資源須另查該型號及通訊方式；Python或伺服器端的信號量概念不能當成PLC已有同名指令。本文不提供未核實的模組連線數。
用到達率乘占用時間建立下限估算
三十台每秒一次，到達率為每秒三十筆。平均每筆占用0.2秒，在穩定且同一統計範圍下，平均忙碌名額約為30乘0.2等於6。這是平均工作需求，不是設定池大小為6就一定沒有等待或逾時。
若六個名額每個都需0.2秒完成一筆，理想總能力是每秒三十筆，剛好追上需求，幾乎沒有餘裕。回覆抖動、解析耗時或重試一增加，工作就可能排隊。因此把六作為理論基線，另以測試驗證可接受的等候時間和尾端延遲。
假設專案先選最大利用率七成作規劃目標，估算名額為6除以0.7約8.57，向上取整為9。七成是本例假設，不是標準或設備保證；實際可否用九還要受每台設備和共享閘道的限制。
九個名額在每筆恆定0.2秒的理想模型，能力為每秒四十五筆。但若這九筆都落到只允許單筆的同一設備，仍不能同時派九筆。總名額只是上限，每設備限制與公平排程同樣需要生效。
計算時間要使用名額實際被占用的期間。若先取名額再做DNS、連線和TLS，這些時間都算占用；若在已建立的連線上查詢，則另統計重建時間。不要用單純網路往返時間代替完整名額占用時間。
把突發與長尾加進驗收
三十台若都在同一秒邊界發起工作，即使平均每秒三十筆，也會形成瞬間三十筆的突發。九個名額、每筆0.2秒且無其他工作時，可分九、九、九、三筆四輪，最後一輪約0.8秒完成；這是理想排程，不含其他開銷。
如果要求每筆自排入到完成不能超過0.5秒，上述最後幾筆就不合格，即使平均容量四十五筆每秒大於需求。可以分散各設備輪詢相位、調整查詢頻率或在設備允許下增加併發，不能只引用平均公式宣布合格。
再加入一台回覆變成兩秒的慢設備。它會占住一個名額更久；若同一設備每秒再排一筆，單設備佇列可能一直長大。應設定每台只保留有限未完成工作，以及新輪詢是否合併、跳過或等待的明確規則。
慢設備不能永久壟斷整體池。分設備排程、適當的公平性和每請求截止時間可以限制影響。若請求已送出但結果未知，取消本地等待不代表設備停止處理；重建連線與下一筆讀寫仍須遵循協定配對規則。
驗收記錄平均、P95、P99和最大占用時間，另記等待名額時間。P99不是所有請求的硬上限，也不能直接以P99乘到達率就當平均需求；可用它建立壓力情境，再以完整時間分布及期限通過率判斷。
觀察借用 歸還 與資源洩漏
池應公開總連線數、空閒連線數、使用中名額、等候筆數、最老等候時間、借用失敗和關閉數。若使用中名額只升不降，先查成功、錯誤、取消及逾時分支是否都有釋放；不要先把池再加大。
名額歸還與連線可否重用是兩件事。回覆格式損壞、封包殘留或連線狀態不明時，可以釋放處理名額，但該socket應隔離或關閉，不回到健康空閒池。否則下一個請求會讀到上一筆的尾端。
借用也要有期限。若總工作期限一秒，排隊已等0.8秒，剩下只有0.2秒可用；不能借到名額後重新給一整秒，讓整體工作無限延長。查詢過期則回報ExpiredBeforeSend，不為了清空佇列發送已無意義的工作。
測試至少比較六、九及設備許可的其他上限，使用相同設備數、回覆分布與請求時間線。記錄期限通過率、錯誤率、記憶體和實際送出速率，找出是否真的改善；併發提高卻讓設備更慢，代表瓶頸已轉移。
恢復測試要包含服務重啟、慢設備回復與大量連線同時重建。重建使用退避和總量限制，不因空閒池為零就瞬間建立所有連線。池的初始化速度也會影響設備負載，應與正常輪詢容量分開驗收。
完成後應交出的容量表與常見問題
完成表應列三十個端點、各自連線上限、每秒請求數、平均占用、尾端延遲、總名額與單設備名額。附上正常、突發和慢設備三種結果，才能說明為何選九而非六或三十。本文核算容量模型。
問：三十台設備需要三十個同時請求名額嗎？答：不必然。開啟連線與同時請求不同；本例平均需求六個，但最後配置仍需驗收突發與期限。
問：平均需求六，設六一定夠嗎？答：不保證。理想能力剛好等於需求，回覆抖動及額外工作可能造成等待，需要餘裕與實測。
問：把池加大可以解決所有逾時嗎？答：不能。單設備併發上限、共享閘道、慢回覆或資源洩漏都可能是原因，先看等待與占用分段。
問：歸還名額後socket一定可重用嗎？答：不是。先確認協定狀態乾淨且連線健康；殘留回覆或狀態不明的連線應隔離，不能送回空閒池。
參考：Python asyncio同步原語：Semaphore與名額取得釋放概念；非PLC API。
參考：AWS Builders Library：過載下的容量與負載處理背景；本例數字是自訂假設。