Performance

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Performance

Chris Hardin
Is there anything I can do to help increase performance? For example, are
there some strategies for cutting back on the size of the SOap message
generated? Compression? anything would be helpful. I want to squeeze a few
micros off my calls.

thanks in advance
Reply | Threaded
Open this post in threaded view
|

Re: Performance

Chris Hardin
Here is an example of where I thought I might create a performance increase.
My Soap contain a lot of below for an object. I have a really large object
that has a lot of Fields, but the Soap message contains a field even if that
field doesn't contain values.

         <ns2:carpalTunnelJointIssues ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:compensationNotSalary ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:country ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:disabilityNoworNext90days ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:disabledMore60 ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:emailAddress ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:homePhone ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:id>18</ns2:id>
                  <ns2:idnumber ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:idplaceOfIssuance ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressCity ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressState ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressStreet ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressZip ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressCity ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressState ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressStreet ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressZip ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:maritalStatus ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:monthsAtCurrentAddress ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:monthsAtPreviousAddress ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mothersMaidenName ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressCity ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressPhone ns3:nil="true"
xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressState ns3:nil="true"
xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressStreet ns3:nil="true"
xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressZip ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>


On Wed, Mar 31, 2010 at 8:34 AM, Chris Hardin <[hidden email]>wrote:

> Is there anything I can do to help increase performance? For example, are
> there some strategies for cutting back on the size of the SOap message
> generated? Compression? anything would be helpful. I want to squeeze a few
> micros off my calls.
>
> thanks in advance
>
Reply | Threaded
Open this post in threaded view
|

RE: Performance

dvaleri
If you have control of your XML schema, you can set minOccurs=0 for each
child element of carpalTunnelJointIssues instead of setting nillable=true.
This would omit the child element instead of including an empty element with
the nil attribute.

See: http://www.w3.org/TR/2008/WD-xmlschema-patterns-20080328/#optional and
http://www.w3.org/2002/ws/databinding/edcopy/advanced/advanced.html#group-El
ement (2.7.9) for some examples of schema and instance documents using these
two options.

There is a lot of good discussion out there about the semantics of nillable
vs. minOcurrs.  Try Google for more info.  As far as controlling how your
messages get serialized if nillable=true and minOcurrs=0, I will leave that
up to the folks who know far more about databinding tools and XML processing
than I do, but I do know that JAX-B 2.x can handle this ternary state
situation (nil, omitted, and complete) using JAXBElement objects.

-----Original Message-----
From: Chris Hardin [mailto:[hidden email]]
Sent: Wednesday, March 31, 2010 9:38 AM
To: [hidden email]
Subject: Re: Performance

Here is an example of where I thought I might create a performance increase.
My Soap contain a lot of below for an object. I have a really large object
that has a lot of Fields, but the Soap message contains a field even if that
field doesn't contain values.

         <ns2:carpalTunnelJointIssues ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:compensationNotSalary ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:country ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:disabilityNoworNext90days ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:disabledMore60 ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:emailAddress ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:homePhone ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:id>18</ns2:id>
                  <ns2:idnumber ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:idplaceOfIssuance ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressCity ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressState ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressStreet ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:legalAddressZip ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressCity ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressState ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressStreet ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mailingAddressZip ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:maritalStatus ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:monthsAtCurrentAddress ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:monthsAtPreviousAddress ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:mothersMaidenName ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressCity ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressPhone ns3:nil="true"
xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressState ns3:nil="true"
xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressStreet ns3:nil="true"
xmlns:ns3="http://www.w3.org/2001/XMLSchema-instance"/>
                  <ns2:nearestRelativeAddressZip ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>


On Wed, Mar 31, 2010 at 8:34 AM, Chris Hardin <[hidden email]>wrote:

> Is there anything I can do to help increase performance? For example, are
> there some strategies for cutting back on the size of the SOap message
> generated? Compression? anything would be helpful. I want to squeeze a few
> micros off my calls.
>
> thanks in advance
>

Reply | Threaded
Open this post in threaded view
|

Re: Performance

Daniel Kulp
Administrator
In reply to this post by Chris Hardin
On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
> Is there anything I can do to help increase performance? For example, are
> there some strategies for cutting back on the size of the SOap message
> generated? Compression? anything would be helpful. I want to squeeze a few
> micros off my calls.
>
> thanks in advance

Couple suggestions:

1) As mentioned, use minOccurs=0 instead of nillable=true.   For messages with
a lot of "null" values, they are MUCH smaller.

2) Make sure you use the woodstox parser and not the JDK built in parser (for
Java6).  Woodstox is a LOT faster.

3) If you can, use Fastinfoset.   For larger messages, FI can be a huge help
as it makes it much smaller on the wire and much easier to parse.  (although
more expensive to write)

4) If you cannot use FI, but are on a slower connection (aka: not localhost or
gigabit), then enable gzip.  

If you have some large base64 blobs in the message, enabling MTOM would also
be important (unless using FI).   Not sure if that's the case though.


--
Daniel Kulp
[hidden email]
http://dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|

Re: Performance

Mayank Mishra-3
Dan,

Can we shorten the namespace prefix in our engine, specially in cases
for WS-* messages?

With Regards,
Mayank

Daniel Kulp wrote:

> On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
>  
>> Is there anything I can do to help increase performance? For example, are
>> there some strategies for cutting back on the size of the SOap message
>> generated? Compression? anything would be helpful. I want to squeeze a few
>> micros off my calls.
>>
>> thanks in advance
>>    
>
> Couple suggestions:
>
> 1) As mentioned, use minOccurs=0 instead of nillable=true.   For messages with
> a lot of "null" values, they are MUCH smaller.
>
> 2) Make sure you use the woodstox parser and not the JDK built in parser (for
> Java6).  Woodstox is a LOT faster.
>
> 3) If you can, use Fastinfoset.   For larger messages, FI can be a huge help
> as it makes it much smaller on the wire and much easier to parse.  (although
> more expensive to write)
>
> 4) If you cannot use FI, but are on a slower connection (aka: not localhost or
> gigabit), then enable gzip.  
>
> If you have some large base64 blobs in the message, enabling MTOM would also
> be important (unless using FI).   Not sure if that's the case though.
>
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Performance

Daniel Kulp
Administrator
On Wednesday 31 March 2010 4:17:07 pm Mayank Mishra wrote:
> Dan,
>
> Can we shorten the namespace prefix in our engine, specially in cases
> for WS-* messages?

In the JAXB stuff, yea.  There is some config that can specify prefixes to use
and such.

For WS-Security stuff, possibly not.  I think WSS4J has a lot of that burned
in.

Dan


>
> With Regards,
> Mayank
>
> Daniel Kulp wrote:
> > On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
> >> Is there anything I can do to help increase performance? For example,
> >> are there some strategies for cutting back on the size of the SOap
> >> message generated? Compression? anything would be helpful. I want to
> >> squeeze a few micros off my calls.
> >>
> >> thanks in advance
> >
> > Couple suggestions:
> >
> > 1) As mentioned, use minOccurs=0 instead of nillable=true.   For messages
> > with a lot of "null" values, they are MUCH smaller.
> >
> > 2) Make sure you use the woodstox parser and not the JDK built in parser
> > (for Java6).  Woodstox is a LOT faster.
> >
> > 3) If you can, use Fastinfoset.   For larger messages, FI can be a huge
> > help as it makes it much smaller on the wire and much easier to parse.
> > (although more expensive to write)
> >
> > 4) If you cannot use FI, but are on a slower connection (aka: not
> > localhost or gigabit), then enable gzip.
> >
> > If you have some large base64 blobs in the message, enabling MTOM would
> > also be important (unless using FI).   Not sure if that's the case
> > though.

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|

Re: Performance

Chris Hardin
CAn someone give me a quick education what FastInfoSet is? Also, how can I
ensure I am using Woodstox. I have the woodstox.jar in my lib dir.

On Wed, Mar 31, 2010 at 10:05 PM, Daniel Kulp <[hidden email]> wrote:

> On Wednesday 31 March 2010 4:17:07 pm Mayank Mishra wrote:
> > Dan,
> >
> > Can we shorten the namespace prefix in our engine, specially in cases
> > for WS-* messages?
>
> In the JAXB stuff, yea.  There is some config that can specify prefixes to
> use
> and such.
>
> For WS-Security stuff, possibly not.  I think WSS4J has a lot of that
> burned
> in.
>
> Dan
>
>
> >
> > With Regards,
> > Mayank
> >
> > Daniel Kulp wrote:
> > > On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
> > >> Is there anything I can do to help increase performance? For example,
> > >> are there some strategies for cutting back on the size of the SOap
> > >> message generated? Compression? anything would be helpful. I want to
> > >> squeeze a few micros off my calls.
> > >>
> > >> thanks in advance
> > >
> > > Couple suggestions:
> > >
> > > 1) As mentioned, use minOccurs=0 instead of nillable=true.   For
> messages
> > > with a lot of "null" values, they are MUCH smaller.
> > >
> > > 2) Make sure you use the woodstox parser and not the JDK built in
> parser
> > > (for Java6).  Woodstox is a LOT faster.
> > >
> > > 3) If you can, use Fastinfoset.   For larger messages, FI can be a huge
> > > help as it makes it much smaller on the wire and much easier to parse.
> > > (although more expensive to write)
> > >
> > > 4) If you cannot use FI, but are on a slower connection (aka: not
> > > localhost or gigabit), then enable gzip.
> > >
> > > If you have some large base64 blobs in the message, enabling MTOM would
> > > also be important (unless using FI).   Not sure if that's the case
> > > though.
>
> --
> Daniel Kulp
> [hidden email]
> http://dankulp.com/blog
>
Reply | Threaded
Open this post in threaded view
|

Re: Performance

Chris Hardin
I tried this

@XmlElement(required=false, nillable=true)
    @org.apache.cxf.aegis.type.java5.XmlElement(minOccurs="0",
nillable=true)
    @Column(name = "BestContactNumber", length = 10)
    public String getBestContactNumber() {
        return this.bestContactNumber;
    }

    public void setBestContactNumber(String bestContactNumber) {
        this.bestContactNumber = bestContactNumber;
    }

But the Soap message still contains

 <ns2:bestContactNumber ns3:nil="true" xmlns:ns3="
http://www.w3.org/2001/XMLSchema-instance"/>


On Fri, Apr 2, 2010 at 6:17 PM, Chris Hardin <[hidden email]> wrote:

> CAn someone give me a quick education what FastInfoSet is? Also, how can I
> ensure I am using Woodstox. I have the woodstox.jar in my lib dir.
>
>
> On Wed, Mar 31, 2010 at 10:05 PM, Daniel Kulp <[hidden email]> wrote:
>
>> On Wednesday 31 March 2010 4:17:07 pm Mayank Mishra wrote:
>> > Dan,
>> >
>> > Can we shorten the namespace prefix in our engine, specially in cases
>> > for WS-* messages?
>>
>> In the JAXB stuff, yea.  There is some config that can specify prefixes to
>> use
>> and such.
>>
>> For WS-Security stuff, possibly not.  I think WSS4J has a lot of that
>> burned
>> in.
>>
>> Dan
>>
>>
>> >
>> > With Regards,
>> > Mayank
>> >
>> > Daniel Kulp wrote:
>> > > On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
>> > >> Is there anything I can do to help increase performance? For example,
>> > >> are there some strategies for cutting back on the size of the SOap
>> > >> message generated? Compression? anything would be helpful. I want to
>> > >> squeeze a few micros off my calls.
>> > >>
>> > >> thanks in advance
>> > >
>> > > Couple suggestions:
>> > >
>> > > 1) As mentioned, use minOccurs=0 instead of nillable=true.   For
>> messages
>> > > with a lot of "null" values, they are MUCH smaller.
>> > >
>> > > 2) Make sure you use the woodstox parser and not the JDK built in
>> parser
>> > > (for Java6).  Woodstox is a LOT faster.
>> > >
>> > > 3) If you can, use Fastinfoset.   For larger messages, FI can be a
>> huge
>> > > help as it makes it much smaller on the wire and much easier to parse.
>> > > (although more expensive to write)
>> > >
>> > > 4) If you cannot use FI, but are on a slower connection (aka: not
>> > > localhost or gigabit), then enable gzip.
>> > >
>> > > If you have some large base64 blobs in the message, enabling MTOM
>> would
>> > > also be important (unless using FI).   Not sure if that's the case
>> > > though.
>>
>> --
>> Daniel Kulp
>> [hidden email]
>> http://dankulp.com/blog
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Performance

Daniel Kulp
Administrator
In reply to this post by Chris Hardin
On Friday 02 April 2010 7:17:38 pm Chris Hardin wrote:
> CAn someone give me a quick education what FastInfoSet is?

FI is kind of a binary XML with a bunch of optimizations to make it very easy
to parse and generally pretty small.    Things like open and close element
things are replaced with a single byte token, most stings are put into a
string table so repeated strings are only encoded once, byte[] data is not
base64 encoded, etc....     Generally, it's more expensive to write, but it's
a lot more efficient to parse and much smaller on the wire.  There is a little
information at the FI libraries website:
https://fi.dev.java.net/

> Also, how can I
> ensure I am using Woodstox. I have the woodstox.jar in my lib dir.

That SHOULD be enough.

Dan

> On Wed, Mar 31, 2010 at 10:05 PM, Daniel Kulp <[hidden email]> wrote:
> > On Wednesday 31 March 2010 4:17:07 pm Mayank Mishra wrote:
> > > Dan,
> > >
> > > Can we shorten the namespace prefix in our engine, specially in cases
> > > for WS-* messages?
> >
> > In the JAXB stuff, yea.  There is some config that can specify prefixes
> > to use
> > and such.
> >
> > For WS-Security stuff, possibly not.  I think WSS4J has a lot of that
> > burned
> > in.
> >
> > Dan
> >
> > > With Regards,
> > > Mayank
> > >
> > > Daniel Kulp wrote:
> > > > On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
> > > >> Is there anything I can do to help increase performance? For
> > > >> example, are there some strategies for cutting back on the size of
> > > >> the SOap message generated? Compression? anything would be helpful.
> > > >> I want to squeeze a few micros off my calls.
> > > >>
> > > >> thanks in advance
> > > >
> > > > Couple suggestions:
> > > >
> > > > 1) As mentioned, use minOccurs=0 instead of nillable=true.   For
> >
> > messages
> >
> > > > with a lot of "null" values, they are MUCH smaller.
> > > >
> > > > 2) Make sure you use the woodstox parser and not the JDK built in
> >
> > parser
> >
> > > > (for Java6).  Woodstox is a LOT faster.
> > > >
> > > > 3) If you can, use Fastinfoset.   For larger messages, FI can be a
> > > > huge help as it makes it much smaller on the wire and much easier to
> > > > parse. (although more expensive to write)
> > > >
> > > > 4) If you cannot use FI, but are on a slower connection (aka: not
> > > > localhost or gigabit), then enable gzip.
> > > >
> > > > If you have some large base64 blobs in the message, enabling MTOM
> > > > would also be important (unless using FI).   Not sure if that's the
> > > > case though.
> >
> > --
> > Daniel Kulp
> > [hidden email]
> > http://dankulp.com/blog

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|

Re: Performance

Daniel Kulp
Administrator
In reply to this post by Chris Hardin

You don't want the Aegis annotation on there unless you are using aegis.   It
won't really do anything.   What you want is just:

@XmlElement(required=false, nillable=false)

Dan

On Friday 02 April 2010 7:35:10 pm Chris Hardin wrote:

> I tried this
>
> @XmlElement(required=false, nillable=true)
>     @org.apache.cxf.aegis.type.java5.XmlElement(minOccurs="0",
> nillable=true)
>     @Column(name = "BestContactNumber", length = 10)
>     public String getBestContactNumber() {
>         return this.bestContactNumber;
>     }
>
>     public void setBestContactNumber(String bestContactNumber) {
>         this.bestContactNumber = bestContactNumber;
>     }
>
> But the Soap message still contains
>
>  <ns2:bestContactNumber ns3:nil="true" xmlns:ns3="
> http://www.w3.org/2001/XMLSchema-instance"/>
>
> On Fri, Apr 2, 2010 at 6:17 PM, Chris Hardin <[hidden email]> wrote:
> > CAn someone give me a quick education what FastInfoSet is? Also, how can
> > I ensure I am using Woodstox. I have the woodstox.jar in my lib dir.
> >
> > On Wed, Mar 31, 2010 at 10:05 PM, Daniel Kulp <[hidden email]> wrote:
> >> On Wednesday 31 March 2010 4:17:07 pm Mayank Mishra wrote:
> >> > Dan,
> >> >
> >> > Can we shorten the namespace prefix in our engine, specially in cases
> >> > for WS-* messages?
> >>
> >> In the JAXB stuff, yea.  There is some config that can specify prefixes
> >> to use
> >> and such.
> >>
> >> For WS-Security stuff, possibly not.  I think WSS4J has a lot of that
> >> burned
> >> in.
> >>
> >> Dan
> >>
> >> > With Regards,
> >> > Mayank
> >> >
> >> > Daniel Kulp wrote:
> >> > > On Wednesday 31 March 2010 9:34:27 am Chris Hardin wrote:
> >> > >> Is there anything I can do to help increase performance? For
> >> > >> example, are there some strategies for cutting back on the size of
> >> > >> the SOap message generated? Compression? anything would be
> >> > >> helpful. I want to squeeze a few micros off my calls.
> >> > >>
> >> > >> thanks in advance
> >> > >
> >> > > Couple suggestions:
> >> > >
> >> > > 1) As mentioned, use minOccurs=0 instead of nillable=true.   For
> >>
> >> messages
> >>
> >> > > with a lot of "null" values, they are MUCH smaller.
> >> > >
> >> > > 2) Make sure you use the woodstox parser and not the JDK built in
> >>
> >> parser
> >>
> >> > > (for Java6).  Woodstox is a LOT faster.
> >> > >
> >> > > 3) If you can, use Fastinfoset.   For larger messages, FI can be a
> >>
> >> huge
> >>
> >> > > help as it makes it much smaller on the wire and much easier to
> >> > > parse. (although more expensive to write)
> >> > >
> >> > > 4) If you cannot use FI, but are on a slower connection (aka: not
> >> > > localhost or gigabit), then enable gzip.
> >> > >
> >> > > If you have some large base64 blobs in the message, enabling MTOM
> >>
> >> would
> >>
> >> > > also be important (unless using FI).   Not sure if that's the case
> >> > > though.
> >>
> >> --
> >> Daniel Kulp
> >> [hidden email]
> >> http://dankulp.com/blog

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|

FastInfoSet configuration client and server?

Kessel, Christopher
In reply to this post by Daniel Kulp
I'm trying to figure out a few things related to using FastInfoSet:
1) How do I set up our CXF Servlet to use FastInfoSet?
2) How do I set up our SOAP client to use FastInfoSet?
3) Will this work if I also have other SOAP clients that won't be using
FastInfoSet?

In a nutshell, we have server that's exposed to the outside world as
well as used by our internal systems. For example, our batch server will
be calling our main server and could use FastInfoSet since we control
both ends. However, the batch system uses the same interface that's used
by the outside world who probably aren't using FastInfoSet.

Can I use FastInfoSet in this kind of setup? And, if so, can you point
to example configuration/code for server and client?

For the server, I did find the following page, but I'm not sure where
I'd add the Spring <bean> declaration. Would it a sibling to the
<jaxws:endpoint> declaration that exposes the SOAP endpoint?

https://cwiki.apache.org/confluence/display/CXF20DOC/FeaturesList

Thanks,
Chris
Reply | Threaded
Open this post in threaded view
|

Re: FastInfoSet configuration client and server?

Daniel Kulp
Administrator
On Monday 17 May 2010 2:15:02 pm Kessel, Christopher wrote:
> I'm trying to figure out a few things related to using FastInfoSet:
> 1) How do I set up our CXF Servlet to use FastInfoSet?
> 2) How do I set up our SOAP client to use FastInfoSet?

In both cases, if you add something like:
<cxf:bus>
      <cxf:features>
       <bean class="org.apache.cxf.feature.FastInfosetFeature"/>
      </cxf:features>
</cxf:endpoint>

then it should enable the FI stuff.     You can also do it more programmatic
by adding the raw interceptors in the places you want them.  
org.apache.cxf.interceptor.FIStaxInInterceptor
org.apache.cxf.interceptor.FIStaxOutInterceptor


> 3) Will this work if I also have other SOAP clients that won't be using
> FastInfoSet?

By default, yes.    Normally what happens is the first request a client sends
is not FI, but includes a header saying it would like FI if the server
supports it.   If the server does, it responds with FI and future requests
from the client will be in FI.   If not, the client keeps sending normal XML.  
It's kind of a negotiated thing.  

If you want to FORCE the use of FI, you can do:
<bean class="org.apache.cxf.feature.FastInfosetFeature">
    <property  name="force" value="true"/>
</bean>

but I don't normally recommend that.  It's usually better to just allow the
negotiation to occur.

If this is a java first thing, you can add an annotation like:
@Features(features = "org.apache.cxf.feature.FastInfosetFeature")
to the interface instead.  Sometimes a little simpler.

Dan


> In a nutshell, we have server that's exposetd to the outside world as
> well as used by our internal systems. For example, our batch server will
> be calling our main server and could use FastInfoSet since we control
> both ends. However, the batch system uses he same interface that's used
> by the outside world who probably aren't using FastInfoSet.
>
> Can I use FastInfoSet in this kind of setup? And, if so, can you point
> to example configuration/code for server and client?
>
> For the server, I did find the following page, but I'm not sure where
> I'd add the Spring <bean> declaration. Would it a sibling to the
> <jaxws:endpoint> declaration that exposes the SOAP endpoint?
>
> https://cwiki.apache.org/confluence/display/CXF20DOC/FeaturesList
>
> Thanks,
> Chris

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog