ThingWorx Flow エンジンのチューニングとスケーリング
ThingWorx Flow エンジンのサービスには多数のコンフィギュレーションオプションが含まれており、これらは ThingWorx Flow のパフォーマンスおよびそのワークフローの実行に多大な影響を与えることがあります。これらのオプションはエンジンモジュールの deploymentConfig.json ファイルにあります。このいずれかのコンフィギュレーションオプションを変更した場合、お使いのオペレーティングシステムにネイティブなサービスコントロールツール (Windows の場合は「サービス」または sc、Red Hat の場合は sysctl) を使用して、ThingWorxFlow サービスを再起動する必要があります。以降のセクションでは、関連する各設定について説明し、お使いの環境およびシステムリソースに基づいてこれらを設定する方法に関する推奨事項を示しています。
実行スループット (CHANNEL_MAX_FETCH)
• タイプ - 整数
• デフォルト - 10
• 単位 - メッセージ総数
エンジンサービスによって処理されるワークフロー実行メッセージの最大数を制御します。これらのメッセージは、ワークフローサービスが実行された場合に必ず ThingWorx Foundation によって送信され、これには手動で実行されたスタンドアロンワークフローやトリガーを使用するスタンドアロンワークフローも含まれます。この数値を小さくすると、エンジンが同時に実行可能なワークフローの数が制限されます。
開発環境では、システム上のコアの数に合わせてこれを設定する必要があります。生産システムでは、同じマシンで実行されるその他のサービスの数に応じて、コア数の 50 % から 200 % の範囲でこれを設定する必要があります。
Worker のメモリ割り当て (ENGINE_SIZE)
• タイプ - 整数
• デフォルト - 1802
• 単位 - メガバイト (10242 バイト)
これは、エンジン Worker プロセスがオブジェクトに割り当て可能なメモリの最大量をメガバイト単位で表します。この値を設定する際には以下の要素について考慮する必要があります。
• ワークフロー内のアクティビティの数
• インライン定義式または Node.js 操作の複雑度
• 各操作で取得または処理されるデータの量
展開に関する推奨事項 - 開発環境ではデフォルトのままにすることをお勧めします。本番環境では、システム RAM の最大量を CHANNEL_MAX_FETCH に使用されている設定で割ったおおよその値に ENGINE_SIZE を設定する必要があります。
最大実行時間 (MAX_FLOW_RUN_TIME)
• タイプ - 整数
• デフォルト - 300000
• 単位 - ミリ秒
1 回の実行でワークフローが実行可能な合計時間をミリ秒単位で制御します。この設定により、エンジン Worker によるワークフローの過度な長時間の実行が防止されます。この値は現在の展開およびネットワーク環境に基づいて変化しますが、Worker が長時間にわたって応答しなくなると、Flow の全体的なパフォーマンスが低下するので、これを防止するためにはこの値を低く維持することをお勧めします。ワークフローが実行を完了するために十分な時間を与えつつ、エンジン Worker がただちに応答できるようにこの値を低く維持するように、適切なバランスをとる必要があります。
展開に関する推奨事項 - 開発環境ではデフォルトのままにすることをお勧めします。デバッグ用に必要な場合は、この値を大きくします。本番環境では、最も実行時間が長いワークフローの長さプラス 15 % にこの値を設定することをお勧めします。
Worker 回復期間 (SLEEP_BETWEEN_FLOW_EXECUTION)
• タイプ - 整数
• デフォルト - 3000
• 単位 - ミリ秒
エンジン Worker がワークフローを実行可能になるまでの追加の遅延をミリ秒単位で挿入します。これは主に、オペレーティングシステムに終了したエンジン Worker からメモリを回収させて、ワークフロー実行間でメモリスペースを共有する必要がない環境でセキュリティを向上させるためのものです。
展開に関する推奨事項 - 開発環境およびほとんどの本番環境では、この値を 0 に設定することをお勧めします。混在してはならない機密情報を扱うマルチテナント環境では、この値をデフォルトのままにするか、必要に応じて値を大きくすることをお勧めします。オペレーティングシステムのメモリが適切に再利用されることを保証する値はありません。
Flow 実行後のエンジン Worker の終了 (KILL_WORKER_AFTER_RUN)
• では、Worker プロセスは別の実行リクエストを処理するためにアクティブな状態を維タイプ - Boolean
• デフォルト - false
ワークフローが実行されると必ず、エンジンサービスはそのワークフローの実際の実行を処理する Worker プロセスを作成します (CHANNEL_MAX_FETCH によって設定されている値まで)。デフォルトでは、Worker プロセスはさらなる実行リクエストを処理するためにアクティブな状態を維持します。この設定によって、ワークフローが完了するとただちに、Worker プロセスが終了するように動作が修正されます。
展開に関する推奨事項 - 開発環境およびほとんどの本番環境では、この値をデフォルトのままにすることをお勧めします。混在してはならない機密情報を扱うマルチテナント環境では、これを true に設定することをお勧めします。
Worker 予約再試行数 (AVAILABLE_WORKER_CHECK_TRIES)
• タイプ - 整数
• デフォルト - 10
• 単位 - 再試行数
すべての Worker プロセスが現在使用されている状態で、保留中のワークフローリクエストがある場合、エンジンサービスは設定されている最大回数まで、引き続き Worker プロセスの予約を試みます。最大数まで再試行を試みると、エンジンは実行リクエストを破棄します。
展開に関する推奨事項 - 開発目的では、この値をデフォルト値に維持すれば十分です。本番環境では、この値を妥当な値に設定することをお勧めします。設定 AVAILABLE_WORKER_CHECK_INTERVAL を併用して、合計遅延がリクエストの合計サービス時間の約半分を超えないようにする必要があります。
Worker 予約再試行遅延 (AVAILABLE_WORKER_CHECK_INTERVAL)
• タイプ - 整数
• デフォルト - 3000
• 単位 - ミリ秒
1 回目の試行が失敗したという前提で、ワークフロー実行用の Worker プロセスの予約を試みるまでエンジンサービスが待機する時間を指定します。
展開に関する推奨事項 - 開発目的では、この値をデフォルト値に維持すれば十分です。本番環境では、この値を妥当な値に設定することをお勧めします。設定 AVAILABLE_WORKER_CHECK_TRIES を併用して、合計遅延がリクエストの合計サービス時間の約半分を超えないようにする必要があります。
Worker プロセス休止遅延 (WORKER_DISMISS_INTERVAL)
• タイプ - 整数
• デフォルト - 1800
• 単位 - 秒
エンジンサービスが別の作業を待機する時間を指定します。この時間が経過すると Worker プロセスの終了を開始します。KILL_WORKER_AFTER_RUN が true に設定されている場合、この値は意味を持ちません。
展開に関する推奨事項 - オンプレス環境では、この値は通常はデフォルト値のままで十分です。クラウド展開またはメモリに制約がある環境では、ワークフローがたまにしか使用されない場合は特に、この値を小さくすることをお勧めします。
エンジンコンフィギュレーションのサンプル
サンプルのエンジン 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
"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"
}
}
}
}
}