performance - Repercusión en el rendimiento del uso de aop

spring

Question

Hemos comenzado a utilizar 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 entiende completamente los beneficios.

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

Answer 1

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 bucle muy ajustado, existe la posibilidad de un golpe de rendimiento significativo. Si solo se usa para verificar la seguridad una vez por solicitud y guardar varias cosas en la memoria caché, no veo cómo es probable que sea importante, pero esa es la razón por la que debe perfilar y comparar su aplicación.

Me doy cuenta de que "medir con tu aplicación" probablemente no sea la respuesta que estabas buscando, pero bien podría ser la que creías que obtendrías :)

Answer 2

Mientras tenga control de su AOP, creo que es eficiente. De todos modos, teníamos problemas de rendimiento, por lo que, con nuestro propio razonamiento, no teníamos el control total;) Esto se debía principalmente a que es importante que todos los que escriben aspectos comprendan por completo todos los demás aspectos del sistema y cómo se relacionan. Si comienzas a hacer cosas "inteligentes", puedes ser más astuto en un santiamén. Hacer cosas inteligentes en un proyecto grande con mucha gente que solo ve partes pequeñas del sistema puede ser muy peligroso para el rendimiento. Este consejo probablemente se aplique sin AOP también, pero AOP te permite dispararte en el pie de maneras realmente elegantes.

Spring también usa proxys para manipulaciones de alcance y esa es un área donde es fácil obtener pérdidas de rendimiento no deseadas.

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

Answer 3

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

Debido a que usa el bytecode weaving (el tiempo de compilación frente al tiempo de ejecución hace una gran diferencia) es uno de los frameworks de AOP más rápidos que existen. Ver: AOP Benchmarks

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 los proxies, pero esto generalmente ocurre una sola vez en el inicio de la aplicación. El blog de SpringSource tiene una excelente publicación sobre esto:

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

Answer 5

¿Alguna vez has pensado en herramientas de AOP que agreguen aspectos al objeto en tiempo de ejecución cuando lo necesites? 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 6

Si está utilizando algún framework para aspectos, puede haber algunos problemas de rendimiento. A continuación, si está creando una abstracción por encima de un framework y el manejo de aspectos se realiza desde el framework, entonces es muy difícil averiguar la causa del problema relacionado con los problemas de rendimiento. Si realmente te preocupan más el rendimiento y la pequeña fracción de tiempo, te sugiero que escribas aspectos propios. Nadie quiere reinventar la rueda, pero en algún momento, para mejor, puede ser mejor. Puedes escribir la propia implementación de la abstracción de la alianza AOP.

Answer 7

Utilicé el AOP de primavera en un proceso por lotes en mi proyecto actual para gestionar transacciones de 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 al rendimiento, sino que lo multiplica por miles, y resulta que el nuevo sistema era peor que el anterior, debido a estas llamadas a métodos adicionales.

Yo diría que aop es un gran sistema para usar, pero trate de tomar nota de cuántos métodos se agregan llamadas a su aplicación

Answer 8

En teoría, si usa AOP para lo que podría hacer con el acoplamiento rígido, no hay problemas de rendimiento, ni gastos indirectos, ni llamadas a métodos adicionales a menos que no se teje nada. El Marco AOP le ofrece una forma de eliminar el acoplamiento rígido y de factorizar su preocupación transversal.

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

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

Para obtener más información, puede consultar cuándo se ejecuta is-a-aop-code .

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 AOP (uniendo sus preocupaciones transversales) puede desarrollar sus presuntos consejos (dedicados para cada tratamiento) más fácilmente sin boxeo / desembalaje y reflexión.

Debes saber que la mayoría de los frameworks de AOP no ofrecen la manera 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 interrupción para incluir)
• eficiente (sin boxeo / unboxing, sin reflejo en el código de usuario nominal y buena mecánica de interceptación)

Puede encontrar mi proyecto de código abierto aquí: NConcern .NET AOP Framework