Re: SOAP performance data and open benchmarks

Steve, you are right as usual :-), IIOP should not be used in this manner.
Just trying make a point, about possible approaches to parsing XML under
different circumstances.
In exchanges it may be very common to ignore a chunk of data as different
parts of it belong to different targets.  Also you may want to check a
signature on a part of the document that is signed.

Leo Golubovsky
[email protected]

-----Original Message-----
From: Discussion of implementing SOAP applications today
[mailto:[email protected]]On Behalf Of Vinoski, Stephen
Sent: Wednesday, October 16, 2002 10:57 AM
To: [email protected]
Subject: Re: [SOAP] SOAP performance data and open benchmarks


This isn't an IIOP issue. If you've sent so much data through IIOP that you
want to ignore the bulk of it, then you have a design flaw in your
application.

--steve

> -----Original Message-----
> From: Leo Golubovsky [mailto:[email protected]]
> Sent: Wednesday, October 16, 2002 10:46 AM
> To: [email protected]
> Subject: Re: [SOAP] SOAP performance data and open benchmarks
>
>
> This is also an excellent point.  However, most of the
> parsers now use SAX
> and it makes things faster.
> But there is one interesting point here to be made about
> parsing.  Unlike
> other systems like IIOP (CORBA and RMI based on), XML parsing
> allows for
> partial and selective parse.  What that means is that in RMI
> or CORBA if
> data structure is huge you still need to parse all of it into
> your language
> structure.  In XML you have a choice of parsing out only
> needed elements.
> So in certain cases, you can take advantage of that and make
> things happen
> pretty fast.
>
> Leo Golubovsky
> [email protected]
>
> -----Original Message-----
> From: Discussion of implementing SOAP applications today
> [mailto:[email protected]]On Behalf Of Anne Thomas Manes
> Sent: Wednesday, October 16, 2002 8:10 AM
> To: [email protected]
> Subject: Re: [SOAP] SOAP performance data and open benchmarks
>
>
> > -----Original Message-----
> > From: Discussion of implementing SOAP applications today
> > [mailto:[email protected]]On Behalf Of Phil Troy
> > Sent: Tuesday, October 15, 2002 2:24 AM
> > To: [email protected]
> > Subject: Re: [SOAP] SOAP performance data and open benchmarks
> >
> >
> > Hi!
> >
> > One fo the responses to the question about performance
> indicated that XML
> > was necessarily (much) slower because of the increased size of the
> > messages.
> >
> > Would the difference be significantly decreased if
> compression were used,
> > particularly with arrays where the same keywords may be used very
> > frequently in the message.  Furthermore, if the compression
> were built
> into
> > the xml text generation, might not the processing time to create the
> > compressed message be very significantly reduced?
>
> From my experience, the performance hit isn't a function of
> message transfer
> speed, it's a function of the XML processing speed. It takes
> time to process
> the XML and convert the XML types into Java or C# types.
> Compression only
> adds to the processing time.
>
> Also, keep in mind that messages may get routed through one or more
> intermediaries that might perform functions such as authentication or
> authorization checks, auditing, version control,
> transformation, or some
> other type of header processing work. If you're compressing
> your messages,
> then you're likely to make performance worse.
>
> They best way to increase performance is to improve the
> efficiency of your
> XML parser.
>
> Anne
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the SOAP archive, unsubscribe from
> SOAP, or subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>

You can read messages from the SOAP archive, unsubscribe from SOAP, or
subscribe to other
DevelopMentor lists at http://discuss.develop.com.

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.