コンテンツにスキップ
JelinaJelina Documentation技術ドキュメント
公式サイトに戻る

EMS Builder 性能試験マニュアル

マニュアルバージョン: v1.1
現在の集計規則: 回数指定のサンプリングでは先頭・末尾に各 1 回、計 2 回追加取得し、正式結果は中間サンプルのみを集計します。

試験について:実際の計器、PLC、シリアルゲートウェイは接続せず、すべて Modbus TCP の模擬デバイスを使用します。結果は理想的な通信条件での Edge-EMS Builder の処理能力であり、実際の現場におけるエンドツーエンド性能ではありません。

試験内容 確認事項
データ収集 EMS Builder が毎秒、安定処理できるポイント数
Trigger Lua タスクが計画どおりに実行され、所要時間が安定しているか
MQTT/協調タスク 目標タスク数を達成し、遅延や失敗がないか
データ保存 リアルタイム保存と変化時保存が性能へ与える影響
システムリソース CPU、メモリー、ディスクが上限に近づいていないか
安定性 長時間稼働でクラッシュ、再起動、継続的な滞留がないか

2.1 EMS Builder が同時実行する処理

Section titled “2.1 EMS Builder が同時実行する処理”
負荷 試験内容
データ収集 20 台の模擬 Slave からポイントを読み取り
集約演算 Lua で収集データを計算
Trigger Lua スクリプトを定期実行し、書き込み・アラーム・MQTT アクションを生成
MQTT タスク MQTT メッセージを定期生成・配信
協調タスク デバイス間の共有と協調処理を実行
データ保存 収集データ、計算結果、タスク記録を保存

2.2 Trigger の Lua スクリプト 1 回あたりの処理

Section titled “2.2 Trigger の Lua スクリプト 1 回あたりの処理”
内容 1 回あたりの実行量 役割
基本計算ループ 100 回 数学計算、条件判定、ループ、文字列・テーブル操作
生データポイント書き込み 2 回 テストポイント 小数据0 と 小数据1 へ各 1 回書き込み
集約ポイント書き込み 1 回 テスト集約ポイント Agg へ書き込み
ローカルアラーム 2 回 レベル 1 アラームを 2 件生成
MQTT アラーム 1 回 レベル 2 MQTT アラームを 1 件生成
指標 計算 毎秒
Lua スクリプト実行 Trigger タスク:1s が 50 個 + 100ms が 5 個 = 100/s、Mqtt タスク:50/s、集約演算:50/s、共有タスク:10/s 210 回
Trigger 基本計算ループ 100 × 100 10,000 回
Trigger 生データポイント書き込み 100 × 2 200 回
Trigger 集約ポイント書き込み 100 × 1 100 回
Trigger ローカルアラーム 100 × 2 200 回
Trigger MQTT アラーム 100 × 1 100 回
Trigger 全書き込みアクション 100 × 6 600 回
MQTT メッセージ配信 50 × 1 50 回
データ変化による集約演算 50 × 1 50 回
データ共有タスク 10 × 1 10 回

計算方法:

Trigger 回数/秒 = 1s Trigger 数 + 100ms Trigger 数 × 10
シナリオ 収集ポイント/秒 集約 1s Trigger 100ms Trigger Trigger/秒 MQTT/秒 協調/秒 保存 時間
S1 500 10 10 0 10 5 0 リアルタイム 30 分
S2 2,000 20 20 2 40 10 2 リアルタイム 30 分
S2.5 2,000 20 20 2 40 10 2 変化時 30 分
S3 5,000 30 50 4 90 20 10 リアルタイム 30 分
S3.5 5,000 30 50 4 90 20 10 変化時 30 分
S4 10,000 30 100 10 200 40 20 変化時 30 分
S5 20,000 40 200 10 300 60 40 変化時 30 分
S6 5,000 20 50 10 150 30 15 リアルタイム 72 時間
保存方式 説明
リアルタイム保存 設定に従い、毎回の収集結果を保存
変化時保存 値が変化したら即時保存。変化しない場合も 10 秒ごとに少なくとも 1 回保存

S5 は性能限界の確認に使用します。S6 は実際に 72 時間実行する必要があります。

短時間の性能再試験では、固定回数のサンプリングを使用し、回数は該当する試験報告書に従います。以下は各シナリオで 1 秒間隔、1,002 回収集する例です。AFE-E630 報告書 v1.3 では 2,002 回収集し、有効サンプルは 2,000 件です。

1 回目:境界サンプル、集計対象外
2~1001 回目:正式サンプル、計 1,000 回
1002 回目:境界サンプル、集計対象外

正式報告では raw_data を sample_no で選別する必要があります。ワークブックの summary シートにある、最初と最後のサンプルを含む全体の集計値を直接使用してはいけません。

30 分間の試験を 1 秒間隔で完全に実施する場合、1,802 回取得し、中間の 1,800 回を集計します。S6 の 72 時間安定性試験を、1,002 回の短時間データで代替することはできません。

次の 5 サービスを同じ sample_no ごとに合計してから、統計指標を計算します。

cb_core
cb_nginx
cb_backend
ems_backend
ems_postgresql
AEMS_CPU_raw(n) = 同じ sample_no の 5 サービスの CPU 合計
4コア装置全体CPU(n) = AEMS_CPU_raw(n) ÷ 4
Edge-EMS Builderメモリー(n) = 同じ sample_no の 5 サービスのメモリー合計

報告には少なくとも平均、P95、P99、ピークを記載します。異なる時刻に発生した各サービスの独立したピークを、単純に合計してはいけません。

trigger_per_sec と mqtt_per_sec は時刻の昇順に並べ、先頭・末尾の秒バケットを除外します。データベース照会範囲の端で 1 秒未満となる区間を避けるためです。

タスクの秒バケットとリソースサンプル数は、必ずしも 1 対 1 に対応しません。記録のない秒や、滞留したタスクが次の秒に集中完了する場合があります。報告には有効な秒バケット数と、次の指標を記載します。

  • 毎秒の処理量の平均と、目標に対する達成率。
  • 毎秒平均 SpendTime の平均、P50、P95、P99。
  • 全秒バケットにおける単一実行の最大 SpendTime。
  • 毎秒平均 SpendTime が 200 ms を超えた秒数と割合。

完全な 1 秒の区間にタスク記録がない場合、スループットは 0 として集計します。その秒には計算可能な遅延がないため、0 ms として作り出してはいけません。今後の監視スクリプトでは統計区間の開始・終了時刻を明示し、空の秒を補完できるようにしてください。

分類 集計内容
データ収集 設定ポイント数、成功ポイント数、失敗、破棄
Trigger 目標回数、実回数、平均所要時間、P50、P95、P99、最大値
MQTT/協調 目標回数、実回数、所要時間、エラー
CPU EMS Builder 全体の平均、P95、ピーク
メモリー EMS Builder 全体の平均、ピーク、推移
ディスク 読み書き速度、I/O 待ち、データベース書き込み状態
Modbus 各 Slave の読み書き数、失敗、タイムアウト、再試行
安定性 クラッシュ、OOM、異常再起動、継続的な滞留

主要な計算:

正確率 = 成功数 ÷(成功数 + 失敗数 + タイムアウト数 + 破棄数)
達成率 = 実際の毎秒平均処理量 ÷ シナリオ目標

SpendTime はタスクの実際の実行時間です。平均だけでなく、P95、P99、最大値も示し、まれに発生する長い遅延を把握する必要があります。

プロジェクト契約または受入仕様を優先します。個別の取り決めがない場合は、次の参考値を使用します。

項目 推奨基準
処理量 平均達成率 ≥ 99%
Trigger / MQTT 所要時間 P95 < 200 ms
CPU 4 コアデバイスの平均使用率 < 80%、継続的な最大負荷なし
メモリー 装置全体の平均使用率 < 70%、継続的な増加なし
正確率 ≥ 99.99%、説明のつかない破棄なし
安定性 連続 72 時間、クラッシュ・OOM・異常再起動なし
復旧能力 負荷低下後 5 分以内に安定状態へ復帰
状況 対応
試験時間が不足 「未完了」と表示
20 台の Slave がすべて参加していない 再試験
書き込みが少数の Slave に集中 配分を調整して再試験
負荷生成元またはネットワークがボトルネック 原因を解消して再試験
成功・失敗・タイムアウトのデータが不足 「データ不完全」と表示
S6 を 72 時間実行していない 「安定性合格」と記載不可

S4、S5 は負荷試験です。システム限界に達した場合は「負荷限界に到達」または「継続稼働を非推奨」と記載し、通常容量として合格と記載してはいけません。

モデル別報告:

関連情報: