先把負載與成功定義寫成數字
系統每秒收到一千筆資料，畫面還能開啟，不足以證明可承受一千筆。資料可能在入口排隊、被丟棄或尚未提交。先定義提供多少負載、實際送出多少、接收多少，以及期限內成功保存多少個唯一事件，再討論CPU與網路占用。
本文適用於隔離環境中的採集服務與資料庫負載測試，PostgreSQL十八版統計檢視作觀察範例，其他版本應核對欄位。PLC掃描負擔、串列通訊上限與正式機台行為另行驗證，不把模擬來源的吞吐量當成控制器能力。
示例先以每秒一百、二百、四百筆逐階增加，各階段包含暖機、穩定觀察與停止後清空時間。每筆帶唯一識別，資料大小與欄位分布固定且記錄版本。若升負載同時更換索引或縮短字串，前後差異就無法只歸因於流量。
開始前約定延遲、錯誤率、最大積壓及測試中止條件。示例的數字只是設計方法，現場門檻應由需求決定。測試報告須包含未送出的預定工作；產生器無法達到目標時，不可把不足的負載標成被測系統通過。
沿資料路徑同步觀察四組指標
第一組是工作量：預定筆數、已送筆數、已收筆數、唯一提交筆數與失敗筆數。重試次數另列，不能把同一事件的三次重試當成三筆成功產量。每階段也要保存最大佇列深度與最老待處理事件年齡，避免平均值掩蓋長尾。
第二組是處理器與程序資源。整機CPU百分之二十五可能是一個核心已滿而其他核心空閒，需同看每核心與目標程序。記錄記憶體、執行緒、垃圾回收或程序暫停時間，並確認監測工具沒有把不同時間尺度的數字混在一起。
第三組是網路實際傳送與接收速率、錯誤、重傳及介面容量。每筆有效內容一千bytes、每秒一千筆，內容速率為每秒一百萬bytes，也就是八百萬bits；協定標頭、加密與重試尚未計入，不能直接當成線路總用量。
第四組是資料庫提交速率、查詢延遲、連線與等待。PostgreSQL的pg_stat_activity可協助觀察活動與等待事件，但單一快照只代表那一刻。累積統計須用同一量測區間的增量，注意統計重置與更新時機，不把開機以來總數當本次測試結果。
用證據區分瓶頸所在
若入口每秒四百筆、提交維持二百筆且佇列持續增加，先確認瓶頸在入口之後。資料庫CPU不高仍可能等待鎖、儲存或連線；要對照等待、交易時間與磁碟觀測，再設計只改一項條件的對照測試，不能只看到CPU空閒便要求加更多流量。
若資料庫能處理四百筆，但應用服務只送出二百筆，檢查批次等待、單線程序列化、連線池及同步寫入。增加執行緒之前先確認共享鎖與順序要求；更多平行工作可能造成更長競爭，並不保證吞吐量提高。
若來源產生器CPU已滿、實際只送出目標的一半，這次結果只證明低於目標的工作量。分別保存目標與實際到達曲線，必要時改用獨立產生器主機或降低產生器記錄成本，再重測同一負載，不以設定畫面的數字取代量測。
固定併發且每次等回應才發下一筆的封閉模型，會在系統變慢時降低到達率；固定到達率的開放模型則以另一方式表達需求。Grafana k6官方文件說明兩者差異。選擇時應對照真實來源是否會因下游變慢而減速，不能只挑容易通過的模型。
停止送入後仍要驗證恢復與完整性
假設積壓六千筆，恢復後持續新增每秒一百筆，實際處理每秒一百五十筆，淨清空速度為每秒五十筆，理想清空需一百二十秒。若直接用六千除以一百五十，會忽略仍持續流入的資料。實際時間另受重試、批次與資源競爭影響。
停止負載後觀察佇列是否清空、延遲是否回到基準、連線是否釋放與錯誤是否停止。只看佇列變成零還不夠，可能是服務把待處理資料丟掉；必須用唯一識別集合比對送入與保存結果，並單獨統計拒絕或失敗。
若驗收要求九成五事件在一秒內完成，應直接依各事件起訖時間計算該比例，並交代未完成事件如何計入。只報平均零點二秒可能仍隱藏少數等待數十秒的事件；中途丟棄的事件也不能從分母悄悄移除。
每個階段保存開始與結束時間、設定版本、負載大小分布及原始監控資料。若有重啟、統計歸零或測試中更改參數，在曲線上標示。不要把不同設定的樣本混成一個平均吞吐量，讓讀者誤以為同一版本能穩定達成。
完成後應能指出哪個階段首次超過需求門檻、當時哪段開始積壓，以及支持推論的觀察。若只看到相關性，先標為待驗證原因；透過受控改動使預期指標改善，才有更強證據。
練習與常見問題
練習：預定送入一萬筆，產生器實送九千，服務收到九千，截止時唯一提交八千五百，另有五百待處理。這時不可寫成功率百分之百，也不能寫丟失一千五百筆；應分列一千筆未產生、五百筆尚未完成，以及截止後的最終去向。
先用低負載驗證計數器與識別比對，再增加壓力。計數本身錯誤時，大量曲線只會放大誤判。對每次失敗保留足以追查的摘要，避免把逐筆大量同步日誌加入正式不存在的負擔。
問：CPU越高代表效能越好嗎？答：需同看成功吞吐量與延遲，高占用也可能是重試或無效迴圈。
問：網路沒有滿就排除通訊問題嗎？答：不能，延遲、重傳、連線限制與單一路徑壅塞仍可能影響。
問：增加資料庫連線一定有幫助嗎？答：不一定，應先查等待與交易型態，過多連線可能增加競爭。
問：十分鐘通過代表能連續運作一週嗎？答：不能，長時間累積、資源洩漏與週期作業需要另外的耐久測試。
參考：PostgreSQL 18官方文件：活動與累積統計的觀察範圍。