Wow! I was unaware of the coloc feature. Using that makes my service call timings roughly equivalent to making direct Java method calls on my service implementation class. Awesome feature!
-----Original Message----- From: Daniel Kulp [mailto:[email protected]] Sent: Thursday, March 10, 2011 6:59 PM To: [email protected] Subject: Re: Local Transport Benchmarks On Thursday 10 March 2011 11:18:01 AM Joel Turkel wrote: > I finally got around to running some benchmarks on my web service and > found that the local transport was 19% slower than the http transport > using CXF 2.3.2... definitely not what I was expecting! After a warm-up > period, the benchmark made 10,625 calls to my service sending ~21GB of > data in outbound requests and receiving 2MB in inbound responses. The > test was run on a 6-core 2.8GHz Windows 7 machine. I haven't done any > profiling yet to see where the extra time is being spent. Interesting. Definitely a bit unexpected. If both are using the same Bus object, you might want to try enabling the ColocFeature. (org.apache.cxf.binding.coloc.feature.ColocFeature) That woud then bypass much of the writing/reading entirely. Dan > > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Friday, February 25, 2011 3:36 PM > To: [email protected] > Cc: Joel Turkel > Subject: Re: Local Transport Benchmarks > > On Thursday 24 February 2011 10:06:23 AM Joel Turkel wrote: > > I'm exploring the possibility of using the CXF local transport to > > optimize the performance of a SOAP web service for intra-JVM > > communication. Has anyone done any benchmarking of the local vs. http > > transport? I'm sure the performance depends greatly on the web service > > but I'm just trying to get a feel for other people's experiences with > > the local transport. > > Honestly, I'm not sure if the Local transport would be significantly > faster > unless you combine it with the object binding. Pretty much the entire > code > path is the same so all the SOAP serialization, etc... would still > occur > which is normally the expensive part. > > I could be wrong though. :-) -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
