we just move our definition of cron jobs from xml based definitions to annotation driven with
<task:annotation-driven />
we did not configured it further as the defaults are just fine. We have a few @Scheduled annotations. Everything worked fine. When we deployed it we saw a massive drop in response time from around 20-30 ms average response time to 40-60 average response time.
After just commenting out the one-liner above our response time average dropped again to usual values.
We checked to see what is happening. We are using @Configurable, too. we found that
AsyncAnnotationBeanPostProcessor.postProcessAfterInitialization(...)
is called each time an @Configurable bean is instantiated and it took 15% of execution time.
Additionally ScheduledAnnotati开发者_开发百科onBeanPostProcessor is called each time but it took nearly 0% of our execution time, because this method is only doing
AnnotationUtils.getAnnotation(method, Scheduled.class);
The additional runtime overhead together with @Configurable makes it unsusable for us.
Why is AsyncAnnotationBeanPostProcessor doing so much more than ScheduledAnnotationBeanPostProcessor?
As we don't us @Async at the moment, is there a way to disable it?
I just tested it with
<task:annotation-driven mode="aspectj" executor="myExecutor" scheduler="myScheduler" />
<task:executor id="myExecutor" pool-size="1" />
<task:scheduler id="myScheduler" />
now it runs faster because of Aspectj mode. Eclipse shows me an error for mode attribute. I don't know why. But it works. It seems that AOPUtils.canApply() is too slow which is used with mode="proxy".
Update: Still have 80% of my configurable runtime in finding @Scheduled annotations, see picture:
So if you use @configurable, be aware that there is extra overhead. for every new instance it is checked if this class has methods annotated with @Scheduled. As it is rather strange to have @Configurable and @scheduled on the same class I think searching for @Scheduled annotations should only be done on application context startup.
精彩评论