Impact sur les performances de l'utilisation de aop

Question

Nous avons commencé à utiliser Spring aop pour les aspects transversaux de notre application (sécurité et mise en cache pour le moment).

Mon responsable s'inquiète de l'impact de cette technologie sur la performance, même s'il en comprend parfaitement les avantages.

Ma question, avez-vous rencontré des problèmes de performances liés à l'utilisation de aop (en particulier Spring aop)?

Answer 1

Tant que vous avez le contrôle de votre AOP, je pense que c'est efficace. Nous avions quand même des problèmes de performances, donc nous n’avons pas le contrôle total;) C’est principalement parce qu’il est important que quiconque écrit des aspects possède la pleine compréhension de tous les autres aspects du système et leurs corrélations. Si vous commencez à faire "intelligemment" choses que vous pouvez vous surpasser en un tournemain. Faire des choses intelligentes dans un grand projet avec beaucoup de personnes qui ne voient que de petites parties du système peut être très dangereux en termes de performances. Ce conseil s'applique probablement aussi sans AOP, mais AOP vous permet de vous tirer une balle dans le pied de manière très élégante.

Spring utilise également les serveurs proxy pour les oscilloscopes et c’est un domaine dans lequel il est facile d’obtenir des pertes de performances indésirables.

Mais étant donné que vous avez le contrôle, le seul véritable problème avec AOP est l'effet sur le débogage.

Answer 2

Si les performances risquent de poser problème, nous avons largement utilisé AspectJ .

Parce qu’il utilise le tissage bytecode (le temps de compilation par rapport à l’exécution fait toute la différence), c’est l’un des frameworks AOP les plus rapides du marché. Voir: Tests de performance AOP

Answer 3

Quand je l'ai utilisé, je ne l'ai pas fait - mais mon application n'est pas votre application.

Si vous l'utilisez pour des appels utilisés dans une boucle très serrée, l'occasion offre un impact significatif sur les performances. Si cela sert uniquement à vérifier la sécurité une fois par demande et à mettre en cache différentes choses, je ne vois pas en quoi elle pourrait être importante, mais c’est pourquoi vous devriez profiler et évaluer votre application

.

Je me rends compte que " mesurez avec votre application " Ce n’est probablement pas la réponse que vous cherchiez, mais c’est peut-être celle que vous pensiez obtenir:)

Answer 4

Si vous utilisez une AOP basée sur un proxy, vous parlez d'une invocation de méthode Java supplémentaire par aspect appliqué. L'impact sur les performances est assez négligeable. La seule préoccupation réelle concerne la création des serveurs proxy, mais cela ne se produit généralement qu'une seule fois au démarrage de l'application. Le blog de SpringSource contient un excellent article:

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

Answer 5

En théorie, si vous utilisez AOP pour faire ce que vous pourriez faire avec un couplage dur, il n’ya pas de problème de performances, pas de surcharge, ni d’appel de méthode supplémentaire, à moins que vous ne travailliez pour rien. Le cadre AOP vous offre un moyen de supprimer le couplage dur et de factoriser votre problème transversal.

En pratique, le cadre AOP peut introduire 3 types de temps système:

• temps d'incendie
• mécanicien d'interception
• intégration du consommateur (moyen d'élaborer un conseil)

Pour plus de détails, vous pouvez vous référer à when-is-aop-code- exécuté .

Faites attention à la manière dont vous mettez en œuvre un conseil car le code transversal est une tentation pour la boxe / déballage et la réflexion (coûteuse en terme de performance).

Sans un cadre AOP (couplage dur de vos préoccupations transversales), vous pouvez développer vos conseils présumés (dédiés à chaque traitement) plus facilement sans boxing / unboxing ni réflexion.

Vous devez savoir que la plupart des frameworks AOP n'offrent pas le moyen d'éviter totalement la boxe / déballage et la réflexion.

J’en ai développé un pour répondre à la plupart des besoins manquants, concentré sur 3 points:

• convivial (léger, facile à apprendre)
• transparent (pas de code de rupture à inclure)
• efficace (pas de boxing / unboxing, pas de reflet dans le code d'utilisateur nominal et bon mécanisme d'interception)

Vous trouverez mon projet open source ici: Puresharp API .net 4.5.2+ précédemment < a href = "https://github.com/Virtuoze/NConcern" rel = "nofollow noreferrer"> Cadre AON de NConcern .NET

Answer 6

Avez-vous déjà pensé à un outil AOP permettant d’ajouter des aspects à un objet lors de l’exécution lorsque vous en avez besoin? Il y en a un pour .net "Ajouter des aspects à un objet à l'aide de Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Je crois que vous pouvez en écrire un similaire pour Java.

Answer 7

Si vous utilisez un framework pour des aspects, il peut y avoir des problèmes de performances. Suivant si vous créez une abstraction au-dessus d’un framework et que la gestion des aspects est effectuée à partir du framework, il est très difficile de trouver la cause du problème lié à les problèmes de performance . Si vous êtes vraiment préoccupé par les performances et que vous vous souciez davantage de la tranche de temps, je suggère d’écrire ses propres aspects. Personne ne veut réinventer la roue, mais pour le meilleur il peut être préférable. Vous pouvez écrire sa propre mise en œuvre de l’abstraction de l’alliance AOP.

Answer 8

J'ai utilisé Spring AOP dans un traitement par lots de mon projet actuel pour gérer les transactions d'une base de données.

Au début, on pensait qu'il n'y aurait pas de problème de performances, mais nous n'avons pas intégré l'équation que nous avons appelée des milliers de fois. un appel d’aspect dans aop n’affecte pas beaucoup les performances, mais multipliez-le par milliers, et il s'avère que le nouveau système était pire que l’ancien, en raison de ces appels de méthodes supplémentaires.

Je dirais que aop est un excellent système à utiliser, mais essayez de noter le nombre d'appels de méthodes ajoutés à votre application