1. Homepage
  2. Mule Runtime (4.5)
  3. Mule 3 ユーザー向けの Mule 4 情報
  4. Mule 4

  5. 実行エンジン、スレッド、および同時実行

Mule 4 の概要: 実行エンジンのスレッドと同時実行

Mule 4 では実行エンジンが改良され、Mule アプリケーションを簡単に開発および拡張できるようになりました。根幹的なエンジンは、非ブロック型のリアクティブアーキテクチャに基づきます。このタスク指向の実行モデルでは、非ブロック IO コールを活用して、処理方式の不適切な設定に起因するパフォーマンスの問題を回避できます。

開発面では、いくつかの大きな変更が行われています。

  • エクスチェンジパターンが廃止されました。どのコネクタも応答を受信します。メッセージを非同期処理する場合は、非同期コンポーネントを使用します。

  • どのフローでも常に非ブロック処理方式が使用されるため、今後は処理方式を設定する必要がありません。

  • すべてのフローを対象とする 1 つのグローバルスレッドプールがあります。詳細は、​「実行エンジン」​を参照してください。

同時実行の制御

Mule 4 では、スレッド設定が同時実行管理から切り離されています。フロー上、または同時実行をサポートするコンポーネント上の同時実行を制御するには、​maxConcurrency​ 属性を使用して、そのコンポーネントが任意の時点で受信できる同時呼び出し数を設定します。

<flow maxConcurrency=“1”>
  <http:listener>
  <scatter-gather maxConcurrency=“3”>
    <route/>
    <route/>
  </scatter-gather>
</flow>

スレッドプールとアプリケーションの調整

Mule 4.3 以降では、Mule に UBER プールと呼ばれる一意のスレッドプールが 1 つ含まれています。このスレッドプールは Mule によって管理され、同じ Mule インスタンス内のすべてのアプリケーションで共有されます。Mule は、起動時にシステム内で使用可能なリソース (メモリや CPU コアなど) を調査し、Mule が実行されている環境に合わせて自動的に調整します。このアルゴリズムはパフォーマンステストによって確立されたもので、ほとんどの状況で最適な値になっています。

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

Mule イベントプロセッサーは、CPU Intensive (CPU 負荷大)、CPU Light (CPU 負荷小)、IO Intensive (IO 負荷大) のいずれの操作を行うかを Mule に示します。これらのワークロード種別によって、Mule はさまざまなワークロードを調整することができ、最適なパフォーマンスを実現するためにユーザーがスレッドプールを手動で管理する必要がなくなります。Mule は、システム内で使用可能なリソース (メモリや CPU コアなど) を調査し、スレッドプールを自動的に調整します。

新しいスレッドモデルおよびアップグレード手順についての詳細は、​「実行エンジン」​を参照してください。

Mule 4.2/4.1 からのアップグレード

Mule 4.2.x または 4.1.x から Mule 4.3.x 以降にアップグレードする場合は、次のアクションを実行します。

  • 適用されるカスタムスレッド設定がない場合 (​scheduler-pools.conf​ ファイルを使用、または Mule アプリケーションで直接)、アクションは必要ありません。

  • 適用されるカスタムスレッド設定がある場合、デフォルト設定を使用して Mule アプリケーションをテストします。
    UBER プール戦略をはじめとする Mule 4.3 で実装されたパフォーマンス更新のために、カスタムスレッド設定が不要な場合もあります。

  • テストでカスタム設定がまだ必要であることが確認された場合は、アプリケーションのリソース管理、いずれかのアプリケーション連動関係、または Mule インスタンスに問題があることが考えられます。カスタム設定を使用すると、リソースの使用が不十分になる場合があり、基盤となる問題が見えてこないこともあります。