Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-users] Spring AOP & AspectJ: Help reducing startup time

[Crossposted to Spring AOP forum and AspectJ Users list]

We have a Tomcat 6 web application that uses Spring 3.0.3 and AspectJ 1.6.10. Depending upon the hardware, startup times range from 80 seconds on our best build systems, to 2 minutes in production, to close to 4 minutes in some situations on older build systems.

We have determined by disabling the wiring of aspects, i.e. removing <aop:aspectj-autoproxy/>, that Spring AOP is responsible for approximately 60% of the startup cost.

Profiling with YourKit showed the vast majority of the time is beneath org.aspectj.apache.bcel.util.NonCachingClassLoaderRepository. The name of the class makes me fear that we are loading and processing the same class files over and over again. However, even if a caching Repository were used, the use pattern of Repository in org.aspectj.weaver.reflect.Java15AnnotationFinder indicates that such caching would be wasted:

bcelRepository.loadClass()
bcelRepository.clear()

Putting aside the non-caching nature of the Repository, we had a thought that our Pointcuts were not "good", according to Section 7.2.3.5 "Writing Good Pointcuts" of the Spring documentation [1]. Many only had @within(<Java 1.5 Annotation>). So we added execution constraints to only look at our own classes. But this did not significantly nor sufficiently help.

Before I ask a few questions about possible solutions, here are few more details about our application:

- We are using Spring AOP with AspectJ annotations, i.e. @Aspect with @Component
- We essentially have one big ApplicationContext that loads beans (450+) and Aspects (25)
- Most beans are discovered through component-scan'ing the classpath separately for a list of 35+ packages

Here are my questions:

- Does the Spring AOP processing analyze beans in the context, or classes on the classpath? If it processes the beans in the context, does that include beans in parent contexts?

- Are we simply analyzing too many beans against too many aspects? Would creating separate contexts that contain the beans for that layer, and only the aspects that apply to them improve performance sufficiently?

- Should we attempt to convert to compile time weaving? We currently make use of Spring's @Order on several of our @Aspects, so this may not be easy, or even possible. Would this just move the cost from runtime to compile, or does it actually reduce the cost?

- Should we try to modify AspectJ itself to have a CachingClassLoaderRepository, and fix the pattern to only clear the Repository at the end of AOP processing? Although it appears to be getting to the NonCachingClassLoaderRepository via org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreate.postProcessAfterInitialization via org.springframework.beans.factory.support.AbstractBenFactory.getBean. So it would appear to be going a bean at a time, and there might not be a good place to clear the BCEL Repository.

Thanks in advance for reading this far, and any time you choose to spend thinking about my problem!

      -- Josh

[1] http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html


Back to the top