cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Startup speed, XML, etc.....
Date Fri, 04 Mar 2011 20:58:42 GMT

I forgot to mention one other huge advantage to all of this...

One of the issues I keep having when deeling with customers and new users and 
such, expecially of some of the advanced things, is the question of "what 
META-INF/cxf/ files do I need to import for my application?"    We've done a 
pretty poor job of documenting exactly what you need and when.     For 
example, I know when Dennis was writing his dev works articles, he sent me a 
couple test cases that were not working, but adding additional imports in (for 
things like ws-a and such) just made them work.     

Now they are all gone.   :-)     Just import cxf.xml and, if in a servlet 
environment, cxf-servlet.xml  (for now, I want to get rid of that next).   
Done.   Everything just works.  :-)

A techical/code solution to a documentation problem.  That's kind of 
backwords.  :-)


Dan



On Friday 04 March 2011 3:47:55 PM Daniel Kulp wrote:
> I just committed the gigantic refactoring of the Spring bus stuff to base
> it on the  ExtensionManagerBus.   I'll describe it in a minute, but first
> the performanc result on my test case:
> 
> Running test - 2.4.0-SNAPSHOT
> Setup: 29105 51/sec
> Invoke: 38174 39/sec
> Setup config: 39026 38/sec
> 
> Compared to the 2.3.3:
> > Running test - 2.3.3
> > Setup: 49732 30/sec
> > Invoke: 62276 24/sec
> > Setup config: 56164 26/sec
> 
> As you can see, it's quite a bit faster across the board now.   That's
> great. The code is also (IMO) a LOT simpler now.   We no longer have to
> modify both bus-extension.xml and cxf-extension-blah.xml files.    The
> extension loading is more unified.  The extension retrieval from the Bus
> is simpler and, for the most part, identical between the Spring and
> Non-Spring cases.    And the performance rocks.  :-)
> 
> For the most part, it's simple to modify existing applications to work.  
> Just remove all the imports for everything except META-INF/cxf/cxf.xml 
> and META- INF/cxf/cxf-servlet.xml if you use a servlet.   However, there
> are a couple of other "gotchas" that I encountered:
> 
> 1) We had several files that did something like:
> 
> <bean id="cxf" class=".... CXFBusImpl>
>      ... conifure some interceptors....
> </bean>
> 
> That no longer works.   The proper way to do that has been to use the
> <cxf:bus> namespaced object.  It's been that way for a while.  Creating
> separate Bus's like that is just asking for having things become confused.
> I converted all the tests to do that properly.   You COULD potentially
> change that to:
> <bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus">
> but using cxf:bus is definitely the better way to go.   Directly
> instantiating and depending on internal "impl" classes and such is
> generally a bad idea.
> 
> 2)  depends-on and injections - since almost none of the CXF internal beans
> are now defined in the Spring context, you cannot really depend on them
> directly.   That's not a normal thing anyway.     The Bus is really the
> only thing that is in the context.
> 
> In anycase, the rest was fairly simple.   If you do define beans in the
> spring config, they will override/replace the auto loaded stuff (just like
> before), the configurations stuff remains the same, etc....    It just
> starts up a ton faster and uses a bit less memory.    :-)
> 
> I definitely have some more testing to do, but I think it's a good start.
> 
> Dan
> 
> On Thursday 03 March 2011 5:01:58 PM Daniel Kulp wrote:
> > 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) {
> >     
> >         BusFactory.setThreadDefaultBus(null);
> >         BusFactory.setDefaultBus(null);
> >         
> >         Service service = Service.create(SERVICE_NAME);
> >         String endpointAddress = "http://localhost:9000/helloWorld";
> >         service.addPort(PORT_NAME,
> >         
> >                    SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
> >         
> >         if (invoke) {
> >         
> >             service.getPort(HelloWorld.class).sayHi("Hello");
> >         
> >         } else {
> >         
> >             service.getPort(HelloWorld.class);
> >         
> >         }
> >     
> >     }
> > 
> > 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 Proxy.
> > 
> > 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 now.
> > 
> > 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 well.
> > 
> > 
> > Dan
> > 
> > 
> > 
> > 
> > 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

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message