cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bimargul...@gmail.com>
Subject Performance measurements (try 2)
Date Tue, 11 Mar 2008 20:58:27 GMT
I ran some tests with JProfiler. I hit send too soon the first time.

Result 1. Spring initialization is very slow. I had to initialize a simple
JAXWS+JAXB entrypoint hundreds of times to stop seeing the cost of
configuring the default bus via spring as the predominant cost. The
big-ticket items here are XML parsing and classloading. If we get complaints
about 'why does it take so long to set up even a simple service', I fear
that we need to consider our options here. We might still want to use
Spring, but we might want to see if there's anything we can do to grease the
wheels.

Result 2: I ran the loop 1000 times. (note: of course, if you initialize
your endpoint via spring, you will see spring as the dominant cost no matter
what).

Now, classloading is the big cost, in getRequestWrapper and
getResponseWrapper. It sure would be easy to make the looping application
faster by caching this, but that's not going to help in the real world
unless we have a real world case of someone complaining about the
performance of recreating the same endpoint over and over. If that was a use
case, then a simple cache here would give things a shave and a haircut.

After the time spent in the classloader (and particularly in the URL
constructor, more on that later), the next culprit was JAXB.

I was bemused to see that the big pile of time in the classloader was spent
constructing URL objects, and then messing with File objects to look for
files. Now, on the one hand, running in eclipse, we have a big classpath of
directories, and if i was running the app with the classes all jarred up, it
would get smaller. But how much smaller, I wonder? Does the JRE cache JAR
files?

What didn't even come close to showing up in the percentages was any of the
meat of the ReflectionServiceFactoryBean.

Ideas?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message