ThingWorx Flow > インストールおよび設定 > ThingWorx Flow の設定 > ThingWorx Flow エンジンのチューニングとスケーリング
ThingWorx Flow エンジンのチューニングとスケーリング
ThingWorx Flow エンジンのサービスには多数のコンフィギュレーションオプションが含まれており、これらは ThingWorx Flow のパフォーマンスおよびそのワークフローの実行に多大な影響を与えることがあります。これらのオプションはエンジンモジュールの deploymentConfig.json ファイルにあります。サンプルのエンジン deploymentConfig.json ファイルを以下に示します。
{
"MAX_FLOW_RUN_TIME": 180000, // Only allows a workflow to run for up to 3 minutes.
"EXCHANGE_STATUS_CHECK_INTERVAL": 120000, // Checks if it can communicate with the Exchange service every 2 minutes.
"REFRESH_ON_INTERVAL_MINUTES": 60,
"ENGINE_PORT": 2006, // The port Engine will reserve for health check purposes
"ENGINE_HOST": "localhost", // The hostname Engine will reserve the port against
"SLEEP_BETWEEN_FLOW_EXECUTION": 3000, // Waits 3 seconds before a worker can execute the next workflow
"ENGINE_DATA_PATH": "C:/ThingWorxOrchestration/modules/cache", // Location where files are stored during workflow execution. Files are deleted once the workflow execution is complete.
"EXCHANGE": { // The host and port for the Exchange service that this Engine should communicate with
"HOST": "localhost",
"PORT": "7822"
},
"logLevel":"error", // valid levels are 'trace', 'debug', 'info', 'warn', and 'error'; default is 'error'
"QUEUE": {
"MAX_SOCKET": 100,
"QUEUE_CONSUMPTION_UNIT": {
"256": 1
},
"DEFAULT_FLOW_QUEUE": "256",
"ACTIVE_ADAPTER_DEFAULT": "amqp",
"ACTIVE_ADAPTER_FLOW": "amqp",
"ACTIVE_ADAPTER_STOP": "amqp",
"ACTIVE_ADAPTER_WEBHOOK": "amqp",
"ADAPTERS": {
"AMQP": {
"CONFIG": { // The host and port for the RabbitMQ server
"port": "5672",
"protocol": "amqp",
"host": "localhost",
"vhost": "orchestration",
"CHANNEL_MAX_FETCH": "5" // The maximum number of messages this Engine will fetch from the queue
},
"FLOW_QUEUE": {
"QUEUE_NAMES": {
"256m": "256mb"
},
"QUEUE_NAME": "256mb"
}
}
}
}
}
これらのコンフィギュレーションオプションのいずれかを変更する場合、お使いのオペレーティングシステムのネイティブサービス制御ツール (Windows の場合は Services または sc、Red Hat Enterprise Linux の場合は sysctl) を使用して ThingWorxFlow サービスを再起動する必要があります。
以下の表では、関連する設定について説明し、お使いの環境およびシステムリソースに基づいてこれらを設定する方法に関する推奨事項を示しています。
コンフィギュレーション設定
説明
推奨事項
CHANNEL_MAX_FETCH -
実行スループット
タイプ - 整数
デフォルト - 10
単位 - メッセージ総数
エンジンサービスによって処理されるワークフロー実行メッセージの最大数を制御します。これらのメッセージは、ワークフローサービスが実行された場合に必ず ThingWorx Foundation によって送信され、これには手動で実行されたスタンドアロンワークフローやトリガーを使用するスタンドアロンワークフローも含まれます。この数値を小さくすると、エンジンが同時に実行可能なワークフローの数が制限されます。
開発環境では、システムのコア数に合わせてこの値を設定します。
本番環境では、同じマシンで実行されるその他のサービスの数に応じて、コア数の 50 % から 200 % の範囲でこの値を設定します。
ENGINE_SIZE -
Worker のメモリ割り当て
タイプ - 整数
デフォルト - 1802
単位 - メガバイト (10242 バイト)
エンジン Worker プロセスがオブジェクトに割り当て可能なメモリの最大量をメガバイト単位で表します。この値を設定する際には、以下の要素を考慮してください。
ワークフロー内のアクティビティの数。
インライン定義式または Node.js 操作の複雑度。
各操作で取得または処理されるデータの量。
開発環境では、デフォルト値のままにします。
本番環境では、ENGINE_SIZE の値は、システム RAM の最大量を CHANNEL_MAX_FETCH に使用する値で割った値に設定します。
MAX_FLOW_RUN_TIME -
最大実行時間
タイプ - 整数
デフォルト - 300000
単位 - ミリ秒
1 回の実行でワークフローが実行可能な合計時間をミリ秒単位で制御します。この設定により、エンジン Worker によるワークフローの過度な長時間の実行が防止されます。この値は現在の展開およびネットワーク環境に基づいて変化しますが、Worker が長時間にわたって応答しなくなると、ThingWorx Flow の全体的なパフォーマンスに影響するので、これを防止するためにはこの値を低く維持することをお勧めします。ワークフローが実行を完了するために十分な時間を与えつつ、エンジン Worker がただちに応答できるようにこの値を低く維持するように、適切なバランスをとる必要があります。
開発環境の場合、デフォルト値のままにするか、必要に応じて、デバッグ用に長い時間に変更します。
本番環境では、最も実行時間が長いワークフローの長さプラス 15 % にこの値を設定します。
SLEEP_BETWEEN_FLOW_EXECUTION -
Worker 回復期間
タイプ - 整数
デフォルト - 3000
単位 - ミリ秒
エンジン Worker がワークフローを実行可能になるまでの追加の遅延をミリ秒単位で挿入します。これは主に、オペレーティングシステムに終了したエンジン Worker からメモリを回収させて、ワークフロー実行間でメモリスペースを共有する必要がない環境でセキュリティを向上させるためのものです。
開発環境およびほとんどの本番環境では、この値を 0 に設定します。
混在してはならない機密情報を扱うマルチテナント環境では、この値をデフォルトのままにするか、必要に応じて値を大きくします。
オペレーティングシステムのメモリが適切に再利用されることを保証する値はありません。
KILL_WORKER_AFTER_RUN -
ワークフロー実行後にエンジン Worker を強制終了
タイプ - Boolean
デフォルト - false
ワークフローが実行されると必ず、エンジンサービスはそのワークフローの実際の実行を処理する Worker プロセスを作成します (CHANNEL_MAX_FETCH によって設定されている値まで)。デフォルトでは、Worker プロセスはさらなる実行リクエストを処理するためにアクティブな状態を維持します。この設定によって、ワークフローが完了するとただちに、Worker プロセスが終了するように動作が修正されます。
開発環境およびほとんどの本番環境では、この値をデフォルトのままにします。
混在してはならない機密情報を扱うマルチテナント環境では、これを true に設定することをお勧めします。
AVAILABLE_WORKER_CHECK_TRIES -
Worker 予約再試行数
タイプ - 整数
デフォルト - 10
単位 - 再試行数
すべての Worker プロセスが現在使用されている状態で、保留中のワークフローリクエストがある場合、エンジンサービスは AVAILABLE_WORKER_CHECK_TRIES に設定されている回数まで、引き続き Worker プロセスの予約を試みます。最大数まで再試行を試みると、エンジンは実行リクエストを破棄します。
開発目的の場合、この値はデフォルトのままにします。
本番環境では、この値を AVAILABLE_WORKER_CHECK_INTERVAL の値とともに適切な値に設定します。
合計遅延がリクエストの合計サービス時間の約半分を超えないようにするのが理想的です。
AVAILABLE_WORKER_CHECK_INTERVAL
- Worker 予約再試行遅延
タイプ - 整数
デフォルト - 3000
単位 - ミリ秒
1 回目の試行が失敗したという前提で、ワークフロー実行用の Worker プロセスの予約を試みるまでエンジンサービスが待機する時間を指定します。
開発目的の場合、この値はデフォルトのままにします。
本番環境では、この値を AVAILABLE_WORKER_CHECK_TRIES の値とともに適切な値に設定します。
合計遅延がリクエストの合計サービス時間の約半分を超えないようにするのが理想的です。
WORKER_DISMISS_INTERVAL -
Worker プロセス休止遅延
タイプ - 整数
デフォルト - 1800
単位 - 秒
エンジンサービスが別の作業を待機する時間を指定します。この時間が経過すると Worker プロセスの終了を開始します。KILL_WORKER_AFTER_RUNtrue に設定されている場合、この値は無視されます。
オンプレミス環境では、この値をデフォルトのままにします。
クラウド展開またはメモリに制約がある環境では、ワークフローがたまにしか使用されない場合は特に、この値を小さくすることができます。
これは役に立ちましたか?