cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Startup speed, XML, etc.....
Date Thu, 03 Mar 2011 22:01:58 GMT

I've done quite a bit of work now on trunk to speed up the "normal" use cases.   
With what's on trunk now, a normal JAX-WS client that doesn't include any 
spring config will get the extension bus instead.   With my lastest set of 
changes, a default extension bus now starts up without  ANY XML parsing and 
very few beans and such created.   This is MUCH faster now.    I wrote a 
little benchmark based on the java-first-jaxws example (to avoid any WSDL 
related things) and depending on cxf-bundle to make sure we get EVERYTHING and 
then does:

    public static void doIteration(boolean invoke) {
        Service service = Service.create(SERVICE_NAME);
        String endpointAddress = "http://localhost:9000/helloWorld";
                   SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
        if (invoke) {
        } else {

in a loop under 3 conditions:
1) First is with invoke=false to basically time all the upfront setup costs.   
That includes creating the Bus, creating the Service, and then creating the 

2) Then with invoke=true to include the additional stuff of creating the 
interceptor chains and conduits and doing a real invoke.

3) Again with invoke=false, but this time with specifying a spring config file 
(cxf.xml).   This basically is the same as (1), but involves the spring Bus 

I then ran this with several versions of CXF.      Results are below.  (first 
number is the # of ms for 1500 iterations, then it's iterations/sec)

Basically, the Extension bus stuff is now a TON faster.  For 80% of the use 
cases, it's much faster.   I'm definitely excited about that.    The spring 
case slowed down a bit.  I'm not sure why.   I'll need to profile that a bit 
to figure it out.    In anycase, for standalone applications  and cases where 
config is done through API's, this is quite a bit faster.    As we start 
thinking about Blueprint and such, this can be important.    Right now, the 
server side parts are all very spring based and thus won't benefit from this.  

One thing I'm going to try next is making META-INF/cxf/cxf.xml just have a 
single bean (the ExtensionBus) and removing all the cxf-extension-*.xml files 
(except for the HTTP things, more in a sec on that) and seeing what happens.   

The HTTP stuff on the server side becomes a "challenge".   Right now, we have 
basically 3 implementations of the HTTPDestinationFactory:   jetty, servlet, 
and OSGi.    The user pretty much selects the one they want by importing the 
appropriate cxf-extension file and not the others in their spring config.    
While it works, there is a down side:  you can only have one  implementation 
in  you application.   Normally not a problem, but there IS the use case of a 
Servlet based application that may also want a service or two exposed on a 
specific jetty port  (like maybe for a decoupled client) that isn't under the 
servlet containers control.   

My proposal for that would be to put a single HTTPDestinationFactory in the 
http module that would hold onto a DestinationRegistry.   The OSGi and Servlet 
based things would just grab that DestinationRegistry for their dispatching.   
However, when the HTTPDestinationFactory is asked to create a destination for 
a "full" URL (like "http://localhost:8080/blah") instead of a path (like 
"/blah"), it would call on a delegate that the Jetty stuff would provide to 
it.   I need to think about this a bit more, but I think it would work fairly 


Running test - 2.4.0-SNAPSHOT
Setup: 29086 51/sec
Invoke: 42558 35/sec
Setup config: 69839 21/sec

Running test - 2.3.3
Setup: 49732 30/sec
Invoke: 62276 24/sec
Setup config: 56164 26/sec

Running test - 2.3.0
Setup: 44233 33/sec
Invoke: 56496 26/sec
Setup config: 55305 27/sec

Running test - 2.2.12
Setup: 48193 31/sec
Invoke: 55737 26/sec
Setup config: 50582 29/sec

Running test - 2.1.9
Setup: 43944 34/sec
Invoke: 47652 31/sec
Setup config: 44550 33/sec

Running test - 2.1.1
Setup: 47335 31/sec
Invoke: 48871 30/sec
Setup config: 49255 30/sec

View raw message