We\'re using Spring (3.0.5) AOP with @AspectJ
style annotations and
. We use it for transactions, auditing, profilin
From what you've posted it looks like your using Load Time Weaving which incurs a startup penalty because the system has to weave all the classes as they are being loaded. If your primary concern is startup time, then I would suggest you switch to Compile Time Weaving. You can find instructions on how to do this in the spring documentation (Chapter 6, Section 8) or in at the AspectJ site (http://www.eclipse.org/aspectj/docs.php)
Switching to Compile time weaving with the AspectJ compiler is relatively stragiht forward:
<aop:aspectj-autoproxy/>
notation
from your context file. For Maven:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.3</version>
<configuration>
<verbose>true</verbose>
<source>1.6</source>
<target>1.6</target>
<complianceLevel>1.6</complianceLevel>
<showWeaveInfo>true</showWeaveInfo>
<aspectLibraries>
<aspectLibrary>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</aspectLibrary>
</aspectLibraries>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
For Ant
<taskdef
resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties">
<classpath>
<pathelement location="${lib.dir}/AspectJ_1.6.8/aspectjtools.jar"/>
</classpath>
</taskdef>
<iajc aspectPath="${file.reference.spring-aspects.jar}; ${build.classes.dir}/path/to/custom/aspects"
classpath="${lib.dir}/AspectJ_1.6.8/aspectjrt.jar; ${javac.classpath}"
inpath="${build.classes.dir}"
destDir="${build.classes.dir}"
showWeaveInfo="true" />
Apparently this is a known issue if you have a lot of non-singleton beans. There seems to be a fix for Spring 3.1: https://jira.springsource.org/browse/SPR-7328
Do you have any circular dependency? That's what's killing my current app.
I know that's not really a solution but I would break up the context to run different services in different vms, SOA-style. That should allow all your apps to have a small startup time and that should also give you some flexibility to change the implementation of these services more easily, small amount of code to test, etc.
I didn't do that in one of my apps and now startup time is at about 3/4 mins which is crazy (we have a couple of thousand beans). That problem doesn't go away, it will only get worse, but if you try to do something about it too late, the app will be too big and too difficult to break up.
Another thing I would look into is hibernate, creating the session factory can be pretty slow.
I had the same problem, before I change jdk1.7 back to jdk1.6. By jdk1.7, my app hang on “Initializing Spring root WebApplicationContext” for more tha 30 seconds. After I change back, it startup in 10sec.
I am not sure that it applies to your situtation, but Spring performance can be improved by empolying a CachingBeanFactory.
This usually applies when wiring beans, but depending on how your aspects are applied and wired, it might bring improvements.
I had the same issue, it turns out Spring AOP auto-proxying spends a LOT of time at startup loading classes with bcel (without caching, so loading again and again same classes like java.lang.Object...) when trying to figure out which advices apply. It can be somewhat improved by writing more fine-grained Point cuts (use within, @within for example) but I've found a solution that worked better if all your pointcuts are written with @annotation.
1) Desactivate auto-proxy with: spring.aop.auto=false
2) Write a custom subclass of AnnotationAwareAspectJAutoProxyCreator to filter beans to be decorated according to your own criteria, for example this one is based on package and annotations :
@Override
protected Object[] getAdvicesAndAdvisorsForBean(Class<?> beanClass, String beanName, TargetSource targetSource) {
if (beanClass != null && isInPackages(beansPackages, beanClass.getName()) && hasAspectAnnotation(beanClass)) {
return super.getAdvicesAndAdvisorsForBean(beanClass, beanName, targetSource);
} else {
return DO_NOT_PROXY;
}
}
In my case startup time down from 60s to 15s.
I hope it will help someone and polar bears