八條連線不代表八筆可以同時完成
看到閘道規格列出可連多個TCP客戶端，先不要把它當成下游更新率。TCP連線數描述可維持多少連線，下游設備數描述可配置多少目標，請求處理率描述每秒完成多少交易，暫存容量描述等待或尚未送達資料能存多少。四個數字各有用途，不能只挑最大的一個作容量結論。
| 容量項目 | 要問的問題 | 對應指標 |
|---|---|---|
| TCP sessions | 限制按整機、模式還是介面計算 | 目前與最大連線數 |
| 下游設備 | 幾個實體埠，各埠如何排程 | 每埠站號與交易耗時 |
| 每秒請求 | 何種功能、數量與回覆時間 | 完成率及回應時間分布 |
| Mapping數 | 一個項目占幾word與轉換成本 | 資料項、資料寬度、CPU |
| Queue容量 | 按筆數還是bytes，滿了怎麼辦 | 等待數、最舊年齡及拒絕數 |
例如Moxa的MGate MB3170與MB3270官方資料分別列出TCP客戶端能力與請求暫存，並說明不同路由模式的連線限制。這提醒我們先固定型號及模式；不能只抄產品首頁的單一數字，就套到系列所有配置。本篇後續八連線與時間數值都是另訂的虛構試算，不代表該產品實測。
建立容量表之前，先列出每個客戶端要讀哪些點、每次幾個word、多久一次、能容忍多舊的資料，以及逾時是否重送。兩台HMI讀同一點可能仍形成兩筆下游請求；只有明示支援集中輪詢與快取的閘道，才能按其機制另外估算。
三種負載先用同一組假設比較
自訂設備最多八條TCP連線，所有請求進同一RS485串列埠，一次只處理一筆。每筆服務時間暫假設固定50 ms，包含發送、設備處理、回覆與必要間隔。先忽略故障與背景工作，理想完成率為一除以0.05，等於每秒20筆；這只是模型上界，不是現場保證吞吐量。
| 負載組合 | 請求到達率 | 理想忙碌比例 | 判斷 |
|---|---|---|---|
| A 八客戶端各每秒一筆 | 8筆/秒 | 8×0.05=40% | 模型有餘裕，仍待實測 |
| B 八客戶端各每秒五筆 | 40筆/秒 | 40×0.05=200% | 持續超出單埠能力 |
| C 四端每秒二筆，四端每五秒一筆 | 8+0.8=8.8筆/秒 | 44% | 平均可排，但要查突發 |
三組都只有八條連線，B卻不能穩定服務。若平均每秒進40筆、最多出去20筆，佇列淨增20筆；教學暫存上限120筆且初始為零，約六秒就用完。達上限後會拒絕、丟棄或阻塞，必須由產品文件決定，不能讓試算表自動假設資料不會少。
C的平均負載看似接近A，但若所有客戶端整點同時送出，仍可能有八筆突發。同一埠依序服務時，最後一筆要等前七筆約350 ms，再加自身50 ms才完成；若客戶端期限只有200 ms，就可能在平均負載低的情況下逾時。因此平均率、突發量與期限必須一起看。
請求內容和重試會改變時間預算
讀一個word與讀五十個word的回覆長度不同，50 ms不能直接套所有請求。先按功能碼列出請求與正常回覆bytes，再加串列鮑率、字元位數、訊框間隔、設備處理時間及閘道排隊。TCP速度再高也不能縮短RTU設備處理或串列傳送時間，調整客戶端連線數前應先確認真正瓶頸。
| 量測欄位 | 起訖點 | 能定位什麼 |
|---|---|---|
| 排隊時間 | 閘道接收至下游開始送 | 需求過多或排程問題 |
| 下游交易時間 | 串列送出至完整回覆 | 格式、設備處理與回覆長度 |
| 應用完成時間 | 客戶端送出至解析完成 | 整條通訊鏈與客戶端處理 |
| 資料age | 最後有效取得至現在 | 控制或畫面是否使用舊值 |
自訂A組每秒八筆正常需求。若其中兩筆逾時後各重試兩次，該秒額外增加四筆，合計十二次嘗試；但逾時嘗試可能各占500 ms，不能仍按正常50 ms計算。單埠被一個離線站長時間占用，就可能拖慢其他正常站，須設定有限重試並記錄每站成本。
再看單位：每秒十筆交易、每筆二十word，是每秒二百word的讀取量，不一定是二百個獨立測點。一個Float32占兩word，若全部都是這種格式，就只有一百個數值；同一批資料被重讀多次也不能當成不同資產。映射表應同時保存word數、資料項數及要求更新頻率。
有快取模式時，上游每秒五次讀取可能只是五次讀同一份暫存；下游每秒更新一次，來源新鮮度仍約由那一秒輪詢及延遲決定。回覆很快不等於量測很新。客戶端若需要來源時間或品質，必須確認閘道提供的欄位及其更新規則。
測試台逐步加載與停止條件
先以一個客戶端、一個站、一個小讀取建立基線，再逐項增加連線、每次數量與頻率。一次只改一個因素，保存設定版本、樣本數、正常及失敗筆數、延遲分布、CPU、記憶體、佇列長度與最舊等待時間。沒有提供CPU診斷的產品，就把該欄列為不可取得，不自行填估計百分比。
| 階段 | 自訂測試內容 | 完成後應看到 |
|---|---|---|
| 基線 | 一端每秒一筆，十分鐘 | 耗時分布與無負載佇列基線 |
| 連線增加 | 保持總每秒八筆，逐增到八端 | 可分辨session成本 |
| 頻率增加 | 固定八端，逐增請求率 | 找出等待持續成長的區間 |
| 單站離線 | 測試替身延遲或無回覆 | 重試有限，其他站age可觀察 |
| 恢復 | 撤回負載並恢復替身 | 佇列下降，品質按新資料恢復 |
先訂停止條件，例如佇列持續成長、某站超過資料age門檻、錯誤率超出測試政策或管理介面失去回應。這些門檻是工程需求，不是協定固定值。達條件即停止增載並保存證據，不靠無限放大buffer把等待藏起來；buffer越大，最舊資料也可能越過可用期限。
若只在平均延遲欄寫50 ms，可能掩蓋少數五秒的尖峰。除了平均值，至少保留最大值與適當百分位及樣本數，並檢查最慢交易是哪個功能、站號和資料長度。測試時鐘需一致，排隊時間與客戶端往返時間的起訖不同，不可直接相減拼成不存在的設備處理時間。
FAQ與型號限制
FAQ1：規格允許八條連線，就能同時每秒五次嗎？不能。本例B組八端每秒五次共40筆，已超過假設單埠20筆的理想處理率；連得上和準時取得資料是兩種驗收。
FAQ2：CPU只有三成，為什麼還逾時？瓶頸可能在單一串列埠、離線站重試或排隊。CPU低只能說整體處理器尚有餘裕，不能證明每個通訊資源都空閒。
FAQ3：把buffer加倍可以永久解決嗎？若長期到達率高於處理率，只是延後滿載。本例淨增20筆每秒，容量由120改240筆，理想填滿時間由六秒延到十二秒，根因沒有消失。
FAQ4：快取回覆很快就代表即時嗎？還要看下游最後有效採樣及品質。上游回覆速度和來源資料年齡應分欄顯示，不能用本次TCP接收時間冒充設備採樣時間。
本篇是容量試算與驗收方法。八連線、50 ms、120筆queue及三組負載均為自訂案例；正式結論須以指定型號、韌體、路由模式、實際功能碼與測試數據確認，不把相鄰產品或行銷上限當現場保證。
參考：Moxa MGate MB3170與MB3270官方產品頁，TCP客戶端、請求暫存及路由模式能力分列。
參考：Modbus Messaging Implementation Guide V1.0b，TCP交易與服務處理背景。