2017-05-24 11 views
0

アプリケーションに負荷がかかると、CPUが非常に高くなります(100%で15コア)。プロファイルは、主にServiceActivatingHandlerによって使用されるSpELによって20%+が使用されていることを示しています。アプリケーションはメッセージを処理するためにサービスアクティベータを使用しますが、SpELを使用することはありません。メッセージハンドラでSpELが原因でCPUが高い

次のように定義されている流れの中、約12 ServiceActivatorsあります:

<service-activator ref="myService"/> または <service-activator ref="myService" method="addStuff"/>

次のように多くの署名がある:スクリーンショットをプロファイリング

@ServiceActivator public Message<String> handle(Message<String>, @Header("header1") String header1, @Header("header2") String header2, @Header("header3") String header3)

Profiling screenshot

この式の評価を避けるにはどうすればよいですか?アプリケーションはSprintBootとSpringIntegration 4.3.xで動作します

+0

その呼び出しの「Own time」は '<0.1'です。実際にどこの時間が費やされているかを見るには、そのhandleRequestMessageにドリルダウンする必要があります。 –

+0

真実ですが、別のスクリーンショットがありません。 OpNEとTernaryで時間が費やされますgetInternalValue() –

+0

あなたの設定と 'addStuff'の署名を表示できますか?再現できるかどうかを確認します。近日リリースの5.0では、ほとんどのPOJOメソッド呼び出しでSpELを使用していません。 –

答えて

2

ヘッダーの抽出は少し高価です。メッセージを渡すのは珍しいことですし、フレームワークのヘッダーを抽出することもあります。あなたはメッセージ全体を持っているので、あなたはヘッダーにアクセスできます。

かなり高速なSpELをコンパイルできます。私のテストでは、8000ms(100,000コール)から137msに落ちました。

-Dspring.expression.compiler.mode=MIXED 

しかし、これは5.0でのSpring Frameworkの4.3.7以降(this fix is needed)以降春の統合4.3.8または(which has this workaround

を必要とし、可能であれば我々はSPELを避け、同じテストをして動作します約400ms。

+0

'@ Header'アノテーションを使ってヘッダーにアクセスする方がよりエレガントに見えましたが、パフォーマンスのためにすぐに変更することができます。だから、引数 '-Dspring.expression.compiler.mode = MIXED'は4.3.8+にはまだ必要ですか?デフォルトではアクティブですか? –

+0

コンパイルを有効にするには、システムプロパティが必要です。問題は、SpELコンパイラが三項演算子とElvis演算子を処理しないことにありました。コンパイルは失敗し、SpELは解釈に戻りました。 –

+0

4.3.9にアップグレードし、コンパイラフラグを設定すると、パフォーマンスは予想以上に向上します。ゲイリーラッセル、ありがとう、これは非常に高く評価されています! –

関連する問題