Details
Description
We return arrays of complex objects - all of the same type for any particular web services call. Axis2 was unusably slow. Upon closer inspection, it was spending much of its time in BeanUtil. The #1 problem is that it is performing introspection repeatedly for each and every object. Introspection is very expensive - calling the methods once you find them is cheap.
The solution is to perform the introspection and cache the results. I added a few lines of code to BeanUtil.java and brought our request from 48 seconds down to 8. This solution may not be exactly how you would implement it, but the idea is sound and the results are very impressive:
import java.util.concurrent.*;
private static final ConcurrentMap<Class<?>,BeanInfo> beanInfoCache = new ConcurrentHashMap<Class<?>,BeanInfo>();
// About line 140, where calls Introspector.getBeanInfo:
BeanInfo beanInfo = beanInfoCache.get(beanClass);
if(beanInfo==null) beanInfoCache.put(beanClass, beanInfo = Introspector.getBeanInfo(beanClass, beanClass.getSuperclass()));
The map would probably need to use weak references to not prevent class unloading. And you may not want to depend on the Java 5 generics and concurrent collections. But the point remains - without this POJO is too slow (rhyme intended).
Please add this to the Axis2 to benefit others.
Thank you,
Dan Armstrong
AO Industries, Inc.
Attachments
Issue Links
- duplicates
-
AXIS2-4524 Caching BeanInfo in adb module's BeanUtil improves performance
- Resolved
- is duplicated by
-
AXIS2-5118 In high load scenarios with many threads, the call to Introspector.getBeanInfo(Class,Class) causes high synchronization resulting in system stall
- Resolved
-
AXIS2-5119 ComplexType array return performance issue
- Resolved
- supercedes
-
AXIS2-4629 Poor performance in 1.5.1 due to threads waiting on monitor for synchronized jre method
- Resolved