47

アプリケーションの横断的側面(現時点ではセキュリティとキャッシング)にSpringaopを使用し始めました。

私のマネージャーは、このテクノロジーのパフォーマンスへの影響を心配していますが、そのメリットは十分に理解しています。

私の質問ですが、aop(特にSpring aop)の使用によって引き起こされるパフォーマンスの問題に遭遇しましたか?

4

9 に答える 9

36

AOP を制御できる限り、効率的だと思います。とにかくパフォーマンスの問題があったので、独自の理由で完全に制御できませんでした;) これは主に、アスペクトを書く人がシステム内ののすべてのアスペクトとそれらがどのように相互関係しているかを完全に理解していることが重要だからです. 「賢い」ことを始めれば、あっという間に自分の裏をかくことができます。多くの人がシステムの小さな部分しか見ていない大規模なプロジェクトで賢明なことを行うことは、パフォーマンス面で非常に危険です。このアドバイスはおそらく AOP がなくても当てはまりますが、AOP を使用すると、非常にエレガントな方法で自分自身を撃つことができます。

Spring はスコープ操作にもプロキシを使用しますが、これは望ましくないパフォーマンスの低下を招きやすい領域です。

しかし、制御できることを考えると、AOP の唯一の問題点は、デバッグへの影響です。

于 2009-01-11T20:02:12.547 に答える
28

パフォーマンスが問題になる場合は、AspectJを使用して大きな効果を上げています。

バイトコードウィービングを使用しているため(コンパイル時とランタイムでかなりの違いがあります)、最速のAOPフレームワークの1つです。参照:AOPベンチマーク

于 2009-01-11T20:15:38.697 に答える
21

私がそれを使用したときは、そうではありませんでしたが、私のアプリケーションはあなたのアプリケーションではありません。

非常にタイトなループで使用される呼び出しに使用すると、パフォーマンスが大幅に低下する可能性があります。リクエストごとに 1 回セキュリティをチェックし、さまざまなものをキャッシュするために使用されるだけの場合、それがどのように重要であるかはわかりませんが、アプリのプロファイリングとベンチマークを行う必要があるのはそのためです

「アプリで測定する」はおそらくあなたが探していた答えではないことを理解していますが、それはあなたが得ると推測したものかもしれません:)

于 2009-01-11T19:38:14.390 に答える
7

プロキシベースの AOP を使用している場合、適用されるアスペクトごとに 1 つの追加の Java メソッド呼び出しについて話していることになります。パフォーマンスへの影響はごくわずかです。唯一の懸念事項はプロキシの作成ですが、これは通常、アプリケーションの起動時に 1 回だけ発生します。SpringSource ブログには、これに関する素晴らしい投稿があります。

http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/

于 2009-01-11T19:41:47.097 に答える
1

現在のプロジェクトのバッチプロセスでSpringAOPを使用して、データベースをトランザクション管理しました。

最初は、パフォーマンスの問題はないと考えられていましたが、データベースを何千回も呼び出す方程式を理解していませんでした。aopでの1つのアスペクト呼び出しはパフォーマンスにあまり影響しませんが、それを数千倍すると、これらの余分なメソッド呼び出しのために、新しいシステムは古いシステムよりも劣っていたことがわかります。

aopは使用するのに最適なシステムだと思いますが、アプリケーションに追加されるメソッド呼び出しの数に注意してください。

于 2009-01-11T20:21:40.107 に答える
1

理論的には、ハード カップリングでできることに対して AOP do を使用する場合、無駄に織り込まない限り、パフォーマンスの問題、オーバーヘッド、余分なメソッド呼び出しはありません。AOP フレームワークは、ハード カップリングを取り除き、分野横断的な問題を因数分解する方法を提供します。

実際には、AOP フレームワークは 3 種類のオーバーヘッドを導入できます。

  • 発射時間
  • 迎撃メカニック
  • 消費者統合 (アドバイスを作成する方法)

詳細については、when-is-aop-code-executed を参照してください。

トランスバーサル コードはボックス化/ボックス化解除およびリフレクション (パフォーマンスの点で高価) の誘惑になるため、アドバイスの実装方法には注意してください。

AOP フレームワーク (分野横断的な関心事のハード カップリング) がなければ、ボックス化/ボックス化解除や熟考なしで、推定されるアドバイス (各治療に専用) を簡単に作成できます。

ほとんどの AOP フレームワークは、ボックス化/ボックス化解除とリフレクションを完全に回避する方法を提供していないことを知っておく必要があります。

不足しているニーズのほとんどに対応するために、次の 3 つのことに集中して開発しました。

  • ユーザーフレンドリー(軽量、習得しやすい)
  • 透過的 (コードを壊すことはありません)
  • 効率的(ボックス化/ボックス化解除なし、名目上のユーザーコードへの反映なし、優れたインターセプトメカニズム)

ここで私のオープン ソース プロジェクトを見つけることができます: Puresharp API .net 4.5.2+以前はNConcern .NET AOP フレームワーク

于 2016-12-13T06:40:49.687 に答える
0

必要なときに実行時にオブジェクトにアスペクトを追加する AOP ツールについて考えたことはありますか? .net「動的デコレータを使用してオブジェクトにアスペクトを追加する」(http://www.codeproject.com/KB/architecture/aspectddecorator.aspx) 用のものがあります。Java 用に同様のものを作成できると思います。

于 2011-01-14T17:38:32.063 に答える