実行エンジン

Mule 実行エンジンは Project Reactor 上に実装され、非ブロックランタイムの基盤を提供します。この実装は、タスク指向の実行モデルで、フロー内の各操作は実行に関するメタデータを提供するタスクで、エンジンはそのメタデータに基づいて調整の決定を行います。

処理種別

Mule イベントプロセッサは、実行する処理の種類をランタイムに示します。これは、次のいずれかです。

  • CPU Light (CPU 負荷小): 短時間の操作または非ブロック IO 用。たとえば、ロガー (logger) や HTTP 要求操作 (http:request) など。

  • Blocking IO (ブロック IO): コール元スレッドをブロックする IO 用。たとえば、Database Select 操作 (db:select) など。

  • CPU Intensive (CPU 負荷大): CPU の負荷が大きい計算用。たとえば、Transform Message コンポーネント (ee:transform) を使用する場合など。

特定のコンポーネントやモジュールがサポートする処理種別については、それらのドキュメントを参照してください。指定しない場合、デフォルトは CPU Light (CPU 負荷小) です。

Mule SDK を使用して作成されたコネクタの場合は、コネクタの実装方法に基づいて SDK によって最適な処理種別が決定されます。そのメカニズムについての詳細は、Mule SDK のドキュメントを参照してください。

スレッド

コンポーネントの処理種別に基づき、ランタイムはそのコンポーネントをその種別の処理専用に調整したスレッドプールで実行します。これらのスレッドプールはランタイムによって管理され、同じランタイム内のすべてのアプリケーションで共有されます。ランタイムは、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、実行中の環境に合わせてスレッドプールを自動的に調整します。デフォルト設定は、パフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。

異なるスレッドプールを使用することでランタイムの効率が向上し、Mule 3 に比べて、同じ量のワークロードを処理するために必要なスレッド数 (およびそれに伴うメモリフットプリント) が大幅に削減されました。

プールの設定は、起動時に使用可能なシステムのリソース (CPU とメモリ) に基づいて計算されます。デフォルト設定は、パフォーマンステストに基づくもので、ほとんどの状況で最適な値になっています。デフォルト設定は、schedulers-conf を使用して変更できます (設定オプションに関するドキュメントは、このファイルのコメント内にあります)。ただし、再設定はお勧めしません。この設定はグローバルであり、Mule Runtime インスタンス全体に影響することに注意してください。実際のシナリオに含まれるすべてのアプリケーションを使用して負荷テストとストレステストを実行することによって、スレッド設定への変更を検証し、Mule 4 でのスレッドプールの動作について理解することを強くお勧めします。

注意: 仕様として、CloudHub ではスレッドプール設定を変更できません。ローカル設定での変更は、CloudHub アプリケーションとの比較では無効です。

次のセクションでは、各スレッドプールの主要な側面について説明します。

CPU Light (CPU 負荷小)

CPU Light (CPU 負荷小) は、比較的小さなスレッドプール用です (デフォルトでは使用可能なコアごとに 2 スレッド)。

CPU_LIGHT プロセッサの実行以外に、このプールはフロー内のプロセッサ (ルータを含む) 間のイベントのハンドオフと、非ブロック IO の応答処理も実行します。

アプリケーションでスループットが落ちたり応答がなくなったりした場合は、一部のコードが CPU Light スレッドプールを誤用している可能性があります。これは、ランタイムのスレッドダンプを取得し、WAITING または BLOCKED を探すか、CPU Light スレッド内で実行時間が長いプロセスを探すことで簡単にチェックできます。

CPU Intensive (CPU 負荷大)

CPU Intensive (CPU 負荷大) も小さなスレッドプール (デフォルトでは使用可能なコアごとに 2 スレッド) ですが、より多くのタスクを受け付けるためのキューがあります。

IO

IO は、必要に応じて大きくなる可変スレッドプールです。

このプールで実行するタスクは、ほとんどの時間、CPU で処理されるのではなく WAITING または BLOCKED の状態でいるため、他のプールと競合しません。

また、トランザクションが有効である場合にも (多くのトランザクションマネージャでは同じトランザクションのすべてのステップを同じスレッドによって処理する必要があるため) IO プールが使用されます。

その他

3 つの主要なスレッドプール以外に、ランタイムまたは一部のコネクタの標準使用によって作成されるプールがいくつかあります。

  • フローリングバッファ: フローのソースとフロー自体の間のハンドオフを実行します。各フローに 1 つのプールがあり、デフォルトでは使用可能なコア数の半分までのスレッドが含まれます。

  • NIO セレクタ: 非ブロック IO を有効にします。各コネクタは、必要に応じて何個でも作成できます。

バックプレッシャー

負荷が大きい場合、ランタイムが特定のイベントを処理するために使用可能なリソースがないことがあります。この問題は、CPU_LIGHT スレッドがすべて使用中で新しく受信したイベントのハンドオフを実行できない場合や、現在のフローの maxConcurrency がすでに超過している場合に発生する可能性があります。

その場合、その状況に関する次のメッセージが記録されます: Flow 'flowName' is unable to accept new events at this time (フロー「flowName」は、現在新しいイベントを受け付けられません)。また、フローのソースには、必要なアクションを実行するように通知されます。

バックプレッシャーのために実行するアクションは、各コネクタのソースに固有です。たとえば、http:listener503 エラーコードを返す可能性があり、メッセージブローカーリスナはリソースが使用可能になるまで待つかメッセージを削除する可能性があります。場合によっては、ソースは処理しきれないデータを取得しないようにリモートシステムから切断し、サーバが正常な状態に戻ったときに再接続することがあります。

コネクタソースによるバックプレッシャーの処理方法についての詳細は、特定のコネクタのドキュメントを参照してください。

Was this article helpful?

💙 Thanks for your feedback!