- Jelina 概要
- EMS Builder
- 性能テスト
EMS Builder 性能試験マニュアル
マニュアルバージョン: v1.1
現在の集計規則: 回数指定のサンプリングでは先頭・末尾に各 1 回、計 2 回追加取得し、正式結果は中間サンプルのみを集計します。
試験について:実際の計器、PLC、シリアルゲートウェイは接続せず、すべて Modbus TCP の模擬デバイスを使用します。結果は理想的な通信条件での Edge-EMS Builder の処理能力であり、実際の現場におけるエンドツーエンド性能ではありません。
1. 試験内容
Section titled “1. 試験内容”| 試験内容 | 確認事項 |
|---|---|
| データ収集 | EMS Builder が毎秒、安定処理できるポイント数 |
| Trigger | Lua タスクが計画どおりに実行され、所要時間が安定しているか |
| MQTT/協調タスク | 目標タスク数を達成し、遅延や失敗がないか |
| データ保存 | リアルタイム保存と変化時保存が性能へ与える影響 |
| システムリソース | CPU、メモリー、ディスクが上限に近づいていないか |
| 安定性 | 長時間稼働でクラッシュ、再起動、継続的な滞留がないか |
2. 試験負荷
Section titled “2. 試験負荷”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 件生成 |
2.3 毎秒の実負荷
Section titled “2.3 毎秒の実負荷”| 指標 | 計算 | 毎秒 |
|---|---|---|
| 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 回 |
3. 標準シナリオ
Section titled “3. 標準シナリオ”計算方法:
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 時間実行する必要があります。
4. サンプリングと集計規則
Section titled “4. サンプリングと集計規則”4.1 回数指定のサンプリング
Section titled “4.1 回数指定のサンプリング”短時間の性能再試験では、固定回数のサンプリングを使用し、回数は該当する試験報告書に従います。以下は各シナリオで 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 回の短時間データで代替することはできません。
4.2 EMS Builder 全体のリソース
Section titled “4.2 EMS Builder 全体のリソース”次の 5 サービスを同じ sample_no ごとに合計してから、統計指標を計算します。
cb_corecb_nginxcb_backendems_backendems_postgresqlAEMS_CPU_raw(n) = 同じ sample_no の 5 サービスの CPU 合計4コア装置全体CPU(n) = AEMS_CPU_raw(n) ÷ 4Edge-EMS Builderメモリー(n) = 同じ sample_no の 5 サービスのメモリー合計報告には少なくとも平均、P95、P99、ピークを記載します。異なる時刻に発生した各サービスの独立したピークを、単純に合計してはいけません。
4.3 Trigger と MQTT
Section titled “4.3 Trigger と MQTT”trigger_per_sec と mqtt_per_sec は時刻の昇順に並べ、先頭・末尾の秒バケットを除外します。データベース照会範囲の端で 1 秒未満となる区間を避けるためです。
タスクの秒バケットとリソースサンプル数は、必ずしも 1 対 1 に対応しません。記録のない秒や、滞留したタスクが次の秒に集中完了する場合があります。報告には有効な秒バケット数と、次の指標を記載します。
- 毎秒の処理量の平均と、目標に対する達成率。
- 毎秒平均
SpendTimeの平均、P50、P95、P99。 - 全秒バケットにおける単一実行の最大
SpendTime。 - 毎秒平均
SpendTimeが 200 ms を超えた秒数と割合。
完全な 1 秒の区間にタスク記録がない場合、スループットは 0 として集計します。その秒には計算可能な遅延がないため、0 ms として作り出してはいけません。今後の監視スクリプトでは統計区間の開始・終了時刻を明示し、空の秒を補完できるようにしてください。
5. 観測指標
Section titled “5. 観測指標”| 分類 | 集計内容 |
|---|---|
| データ収集 | 設定ポイント数、成功ポイント数、失敗、破棄 |
| Trigger | 目標回数、実回数、平均所要時間、P50、P95、P99、最大値 |
| MQTT/協調 | 目標回数、実回数、所要時間、エラー |
| CPU | EMS Builder 全体の平均、P95、ピーク |
| メモリー | EMS Builder 全体の平均、ピーク、推移 |
| ディスク | 読み書き速度、I/O 待ち、データベース書き込み状態 |
| Modbus | 各 Slave の読み書き数、失敗、タイムアウト、再試行 |
| 安定性 | クラッシュ、OOM、異常再起動、継続的な滞留 |
主要な計算:
正確率 = 成功数 ÷(成功数 + 失敗数 + タイムアウト数 + 破棄数)
達成率 = 実際の毎秒平均処理量 ÷ シナリオ目標SpendTime はタスクの実際の実行時間です。平均だけでなく、P95、P99、最大値も示し、まれに発生する長い遅延を把握する必要があります。
6. 結果判定
Section titled “6. 結果判定”プロジェクト契約または受入仕様を優先します。個別の取り決めがない場合は、次の参考値を使用します。
| 項目 | 推奨基準 |
|---|---|
| 処理量 | 平均達成率 ≥ 99% |
| Trigger / MQTT 所要時間 | P95 < 200 ms |
| CPU | 4 コアデバイスの平均使用率 < 80%、継続的な最大負荷なし |
| メモリー | 装置全体の平均使用率 < 70%、継続的な増加なし |
| 正確率 | ≥ 99.99%、説明のつかない破棄なし |
| 安定性 | 連続 72 時間、クラッシュ・OOM・異常再起動なし |
| 復旧能力 | 負荷低下後 5 分以内に安定状態へ復帰 |
6.1 試験が無効となる条件
Section titled “6.1 試験が無効となる条件”| 状況 | 対応 |
|---|---|
| 試験時間が不足 | 「未完了」と表示 |
| 20 台の Slave がすべて参加していない | 再試験 |
| 書き込みが少数の Slave に集中 | 配分を調整して再試験 |
| 負荷生成元またはネットワークがボトルネック | 原因を解消して再試験 |
| 成功・失敗・タイムアウトのデータが不足 | 「データ不完全」と表示 |
| S6 を 72 時間実行していない | 「安定性合格」と記載不可 |
S4、S5 は負荷試験です。システム限界に達した場合は「負荷限界に到達」または「継続稼働を非推奨」と記載し、通常容量として合格と記載してはいけません。
モデル別報告:
関連情報: