Impacto en el rendimiento del uso de aop

Question

Hemos comenzado a usar Spring Aop para aspectos transversales de nuestra aplicación (seguridad y almacenamiento en caché en este momento).

Mi gerente se preocupa por el impacto en el rendimiento de esta tecnología, aunque comprende completamente los beneficios.

Mi pregunta, ¿encontró problemas de rendimiento introducidos por el uso de aop (específicamente spring aop)?

Answer 1

Mientras tenga el control de su AOP, creo que es eficiente. De todos modos, tuvimos problemas de rendimiento, por lo que por razonamiento propio no teníamos el control total;) Esto se debió principalmente a que es importante que cualquiera que escriba aspectos comprenda completo todos los otros aspectos en el sistema y cómo se interrelacionan. Si comienzas a hacer "inteligente" cosas que puedes ser más astuto en un santiamén. Hacer cosas inteligentes en un proyecto grande con muchas personas que solo ven pequeñas partes del sistema puede ser muy peligroso en cuanto al rendimiento. Es probable que este consejo también se aplique sin AOP, pero AOP te permite dispararte en el pie de una manera realmente elegante.

Spring también utiliza proxy para manipulaciones de alcance y eso es un área donde es fácil obtener pérdidas de rendimiento no deseadas.

Pero dado que tiene control, el único punto de dolor real con AOP es el efecto en la depuración.

Answer 2

Si el rendimiento va a ser una preocupación, hemos utilizado AspectJ con gran efecto.

Debido a que utiliza el tejido de código de bytes (el tiempo de compilación frente al tiempo de ejecución marca la diferencia) es uno de los marcos de AOP más rápidos que existen. Consulte: AOP Benchmarks

Answer 3

Cuando lo usé, no lo hice, pero mi aplicación no es tu aplicación.

Si lo usa para llamadas que se usan en un ciclo muy cerrado, existe la oportunidad de un impacto significativo en el rendimiento. Si solo se usa para verificar la seguridad una vez por solicitud y almacenar en caché varias cosas, no puedo ver cómo es probable que sea significativo, pero es por eso que debe perfilar y comparar su aplicación.

Me doy cuenta de que " mide con tu aplicación " probablemente no sea la respuesta que estaba buscando, pero puede ser la que supuso que obtendría :)

Answer 4

Si está utilizando AOP basado en proxy, está hablando de 1 invocación de método Java adicional por aspecto aplicado. El impacto en el rendimiento allí es bastante insignificante. La única preocupación real es la creación de proxies, pero esto generalmente ocurre solo una vez al iniciar la aplicación. El blog SpringSource tiene una excelente publicación sobre esto:

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

Answer 5

En teoría, si usa AOP hacer lo que podría hacer con el acoplamiento duro, no hay problema de rendimiento, ni gastos generales ni llamadas a métodos adicionales, a menos que se entreteje por nada. AOP Framework le ofrece una manera de eliminar el acoplamiento duro y factorizar su preocupación transversal.

En la práctica, AOP Framework puede introducir 3 tipos de gastos generales:

• tiempo de fuego
• mecánico de intercepción
• integración del consumidor (forma de desarrollar un consejo)

Para obtener más detalles, puede consultar when-is-aop-code- ejecutado .

Solo tenga cuidado al implementar un consejo porque el código transversal es una tentación para el boxeo / unboxing y la reflexión (costoso en términos de rendimiento).

Sin un Marco de AOP (uniendo sus inquietudes transversales) puede desarrollar sus presuntos consejos (dedicados a cada tratamiento) más fácilmente sin boxeo / unboxing y reflexión.

Debe saber que la mayoría de los marcos de AOP no ofrecen la forma de evitar totalmente el boxeo / unboxing y la reflexión.

Desarrollé uno para responder a la mayoría de las necesidades faltantes concentradas en 3 cosas:

• fácil de usar (ligero, fácil de aprender)
• transparente (sin código de ruptura para incluir)
• eficiente (sin boxing / unboxing, sin reflejo en el código de usuario nominal y buena mecánica de intercepción)

Puede encontrar mi proyecto de código abierto aquí: Puresharp API .net 4.5.2+ anteriormente < a href = "https://github.com/Virtuoze/NConcern" rel = "nofollow noreferrer"> Marco NCONcern .NET AOP

Answer 6

¿Alguna vez ha pensado en herramientas AOP que agreguen aspectos al objeto en tiempo de ejecución cuando lo necesite? Hay uno para .net " Agregar aspectos al objeto usando Dynamic Decorator " (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Creo que puedes escribir uno similar para Java.

Answer 7

Si está utilizando un marco para algunos aspectos, puede haber algunos problemas de rendimiento. A continuación, si está creando abstracción por encima de un marco y el manejo de aspectos se realiza desde el marco, entonces es muy difícil averiguar la causa del problema relacionado con problemas de desempeño . Si está realmente preocupado por el rendimiento y la pequeña porción de tiempo, le sugiero que escriba sus propios aspectos. Nadie quiere reinventar la rueda, pero en algún momento puede ser mejor. Puede escribir su propia implementación de la abstracción de la alianza AOP.

Answer 8

He usado Spring AOP en un proceso por lotes en mi proyecto actual para gestionar transacciones en una base de datos.

Al principio, se pensó que no habría un problema de rendimiento, pero no figuramos en la ecuación que llamamos a la base de datos miles de veces. una llamada de aspecto en aop no afecta mucho el rendimiento, pero multiplica eso por miles, y resulta que el nuevo sistema era peor que el anterior, debido a estas llamadas a métodos adicionales.

Diría que aop es un gran sistema para usar, pero trate de tomar nota de la cantidad de métodos que se agregan a su aplicación