On Wednesday, May 18, 2011 4:19:32 PM Sven Zethelius wrote:
> Yep, that's actually how we noticed the big difference.  The custom
> DataBinding we have used to just do the marshal(Object, OutputStream)
> form, but then when we moved it to XMLStreamWriter to work with SOAP, we
> saw the huge difference.
> 
> Let me see if I can put together a sample that demonstrates.  It'll
> probably take me a few days to find the free time though.

You can likely just configure a normal GZIP example by adding the  @GZIP 
annotation  and add the property:

"disable.outputstream.optimization" :  "true"

on the endpoint.   That would disable the optimization we do and uses the 
XMLStreamWriter directly.

Dna




> 
> -----Original Message-----
> From: Daniel Kulp [mailto:[email protected]]
> Sent: Wednesday, May 18, 2011 1:10 PM
> To: [email protected]
> Cc: Sven Zethelius
> Subject: Re: JAXB+GZIPFeature - performance
> 
> 
> As Willem suggested, a patch to the GZIP interceptors to wrapper with a
> buffered stream would be more than welcome.
> 
> One note: however, is that it may not provide a huge advantage with
> "native" CXF+JAXB.   Under many circumstances, we don't call
> Marshaller.marshal(Object, XMLStreamWriter)
> 
> and instead call:
> Marshaller.marshal(Object, OutputStream)
> 
> to write directly to the outputstream.   When you do that, JAXB itself does
> a bunch of buffering and optimizations and stuff which may be why we
> haven't seen a need for it.
> 
> That said, the extra Buffered stream likely wouldn't hurt even for that
> case.
> 
> Dan
> 
> On Monday, May 16, 2011 1:42:53 PM Sven Zethelius wrote:
> > We were doing some performance comparisons of the a custom DataBinding
> > using JAXB and noticed a very large jump in response times when combining
> > JAXB marshalling and GZIPFeature.  Without compression, we saw 24 ms
> > response times, of that 3 ms were spent in our custom DataBinding that
> > uses javax.xml.bind.Marshaller.marshal(Object, XMLStreamWriter).  With
> > compression, our sample messages were seeing 400 ms response times, of
> > that most was in the marshal call.  I notice CXF is using the same call
> > for its JAXBDataBinding, so wanted to raise what I've found so anyone
> > else interested can validate the same with stock CXF.
> > 
> > After adding some monitoring, I found a big gain by adding a very simple
> > fix: The GZIPOutInterceptor needs a BufferedOutputStream wrapping the
> > GZIPOutputStream.  I did this with a custom Interceptor that I installed,
> > after(GZIPOutInterceptor.class.getName()).  On just the server Out, this
> > reduced response times from 100 ms, and out serialization to 5 ms.  Need
> > to do some more tweaks to add it to client side as well, which should
> > reduce that 100 ms number even further.
> > 
> > The reason this makes a difference, at least on Windows, is that JAXB
> > makes hundreds of calls to the OutputStream it is passed, in this case
> > GZIPOutputStream.  This means hundreds of JNI calls and a lot of kernel
> > context switching.  With the BuffferedOutputStream, those calls are
> > reduced to a couple dozen, on a much larger data set that makes the
> > Deflater much more efficient.
> > 
> > Environment:
> > JAXB 2.1 (JDK 6)
> > CXF 2.3.2
> > Windows Server 2003
> > 4 request threads

-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com

Reply via email to