as far as i can see the problem is "on the other side of the fence". applicationcontext has much better metadata about its beans then we do so it should be cached there as it can be done so properly.
if this is urgent we can build a temporary cache into springbeanlocator, but its not the proper thing to do imho. if we follow this logic then we can actually start caching bean references as well and essentially build our own applicationcontext.... -igor On Thu, Dec 11, 2008 at 1:33 PM, leok <[email protected]> wrote: > > Hello, > > Our Wicket app makes use of the @SpringBean annotation thorughout our code, > which is a pretty cool feature. While checking some thread stack traces > during load testing, we found lots of threads bottlenecking in the > SpringBeanLocator class: > > Object blocked: 145.133 ms, Object wait: 0 ms, CPU wait: 2.118 ms, I/O wait: > 9.017 ms, CPU: 73.847 ms > > * > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton > (DefaultSingletonBeanRegistry.java:180, bci=22, server compiler) > o blocked on java.util.concurrent.ConcurrentHashMap > (0x000000cd67f9d170) > * > org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch > (AbstractBeanFactory.java:415, bci=41, server compiler) > * > org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType > (DefaultListableBeanFactory.java:223, bci=142, server compiler) > * > org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType > (DefaultListableBeanFactory.java:202, bci=4, server compiler) > * > org.springframework.context.support.AbstractApplicationContext.getBeanNamesForType > (AbstractApplicationContext.java:933, bci=5, server compiler) > * > org.springframework.beans.factory.BeanFactoryUtils.beanNamesForTypeIncludingAncestors > (BeanFactoryUtils.java:143, bci=8, server compiler) > * org.apache.wicket.spring.SpringBeanLocator.getBeanNameOfClass > (SpringBeanLocator.java:104, bci=2, server compiler) > * org.apache.wicket.spring.SpringBeanLocator.getBeanName > (SpringBeanLocator.java:192, bci=29, server compiler) > * org.apache.wicket.spring.SpringBeanLocator.isSingletonBean > (SpringBeanLocator.java:133, bci=13, server compiler) > * > org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue > (AnnotProxyFieldValueFactory.java:90, bci=46, server compiler) > * org.apache.wicket.injection.Injector.inject (Injector.java:108, > bci=87, server compiler) > * org.apache.wicket.injection.ConfigurableInjector.inject > (ConfigurableInjector.java:39, bci=6, server compiler) > * org.apache.wicket.injection.ComponentInjector.onInstantiation > (ComponentInjector.java:52, bci=5, server compiler) > * org.apache.wicket.Application.notifyComponentInstantiationListeners > (Application.java:974, bci=20, server compiler) > * org.apache.wicket.Component.<init> (Component.java:873, bci=35, server > compiler) > * org.apache.wicket.MarkupContainer.<init> (MarkupContainer.java:105, > bci=2, server compiler) > * org.apache.wicket.markup.html.WebMarkupContainer.<init> > (WebMarkupContainer.java:39, bci=2, server compiler) > * > org.apache.wicket.markup.html.WebMarkupContainerWithAssociatedMarkup.<init> > (WebMarkupContainerWithAssociatedMarkup.java:42, bci=2, server compiler) > * org.apache.wicket.markup.html.panel.Panel.<init> (Panel.java:76, > bci=2, server compiler) > [...snip...] > > I found that if we specified a name in @SpringBean (e.g. @SpringBean(name = > "foo")), then we would avoid this bottlenecking and our requests per second > improved 50-75%. It appears that the SpringBeanLocator.isSingletonBean() > call will do an expensive lookup of the bean name against > BeanFactoryUtils.beanNamesForTypeIncludingAncestors() if the name isn't > specified, even if the bean is already cached. By specifying the @SpringBean > name parameter, you avoid the lookup. > > This feels like a bug, though I don't know who to should address it, Wicket > or Spring. Specifying a name in @SpringBean is optional, and the performance > gain of a cache lookup of already-injected beans is consequently defeated by > the isSingletonBean() call, which is called every single time a SpringBean > is injected. This implies Wicket should be addressing it. OTOH, Spring > BeanFactoryUtils.beanNamesForTypeIncludingAncestors() is clearly a > bottleneck if called too frequently, though when I've found performance > issues in Spring code (e.g. http://jira.springframework.org/browse/SPR-4505) > they've implied that Wicket should have better bean caching (though they've > fixed them anyway). > > So.. how would one go about addressing this problem? It's a big performance > issue for those deploying a Wicket app using @SpringBean on multi-core > systems. I'm able to hack around it in our app, but not knowing much about > how Spring and Wicket should be interacting I'm not sure I can give an > educated guess. > > Thanks, > leo > -- > View this message in context: > http://www.nabble.com/SpringBeanLocator-and-%40SpringBean-performance-issue-tp20964687p20964687.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
