Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerMule 4 は、Mule Runtime Engine (Mule) をデプロイした環境の動作条件に従って自己チューニングを行い、自身を最適なパフォーマンスに調整します。
自己チューニングにより、Mule の内部処理ではなく自分のアプリケーションに集中できるため、最適化プロセスが容易になります。また、Mule は出荷時に最も一般的なユースケースに合わせて最適なパフォーマンスにチューニングされていますので、パラメーターの変更は、それによる影響を完全に理解している場合にのみ行ってください。
以下に、アプリケーションレベルで適用することで特定のユースケースにおいて有効なチューニングの推奨事項を紹介します。
自分のユースケースで最適なフローパフォーマンスを実現するストリーミング戦略を理解してください。
反復可能ストリーム (ペイロードを複数回読み取る)
反復不可能ストリーム (ペイロードを 1 回だけ読み取る)
詳細は、「反復可能ストリームと反復不可能ストリーム」を参照してください。
バックプレッシャーと maxConcurrency
パラメーターの使い方を理解して、フローに送信される同時メッセージ数をチューニングします。
詳細は、「back-pressure と maxConcurrency」を参照してください。
バックエンドサーバーの平均レイテンシーとスループットによってアプリケーションの拡張性やパフォーマンスが制限されていないかを確認します。
詳細は、「バックエンドサーバーの応答時間」を参照してください。
データの主要な側面に基づいて、キャッシュするタイミングや使用するキャッシュ戦略を決定します。Mule では、Cache スコープや HTTP キャッシュ API ゲートウェイポリシーなど、カスタマイズ可能なメカニズムによってニーズに合わせたキャッシュ処理を実現できます。
詳細は「キャッシュ」を参照してください。
コンポーネントをプールすることで、同時に受信する要求を効率よく処理できます。パフォーマンステストで必要だと判明した場合には、pooling-profile
をコネクタに追加してください。
詳細は、「プーリングプロファイル」を参照してください。
ドメインを使用することで、すべての共有リソースの中央リポジトリが用意され、クラスローディングプロセスが容易になります。同じオンプレミスの Mule Runtime Engine インスタンスに複数のサービスをデプロイする場合には、ドメインによってパフォーマンスが向上します。
詳細は「ドメイン」を参照してください。
非同期ログのほうが同期ログよりパフォーマンスが高い理由を理解してください。
詳細は「ログ記録」を参照してください。
Mule はメッセージをバッチ処理できますが、バッチ処理には、スレッドを並行して処理するのに十分な使用可能メモリが必要です。つまり、レコードを永続的なストレージから RAM に移動します。アプリケーションに合わせたバッチブロックサイズプロパティを設定する方法を理解してください。
詳細は「バッチ処理」を参照してください。
設計フェーズで特定のプラクティスに従うことにより、Mule アプリケーションのパフォーマンスを高めることができます。
詳細は「アプリケーションの設計」を参照してください。