axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Junaid.Bha...@mro.com
Subject RE: Status of RPC performance - does it scale?
Date Fri, 11 Apr 2003 19:52:11 GMT

Sorry for the divergence, but I have question along these lines. I'd like
to implement a doc/literal style webservice, since my application mainly
exchanges XML documents back and forth. Is there a way in Axis to implement
a doc/literal style webservice but **avoid** the extra overhead of
de-serialization to a Java object at the server?

I could do a Message style service, but I really do want to indicate to the
end-user the schema / type of the input XML  in the WSDL, instead of a
generic Document type.

Any pointers on how this could be achieved in Axis?

Thanks.




                                                                                         
                                             
                      "Anne Thomas                                                       
                                             
                      Manes"                   To:       <axis-user@ws.apache.org> 
                                                   
                      <anne@manes.net>         cc:                                 
                                                   
                                               Subject:  RE: Status of RPC performance - does
it scale?                                
                      04/11/2003 03:31                                                   
                                             
                      PM                                                                 
                                             
                      Please respond to                                                  
                                             
                      axis-user                                                          
                                             
                                                                                         
                                             
                                                                                         
                                             




Keep in mind that many SOAP implementations do de/serialization to Java
with
doc/lit.
The difference between rpc/encoding and doc/literal is simply formatting.

Anne

> -----Original Message-----
> From: Benjamin Tomasini [mailto:btomasini@neteverything.com]
> Sent: Friday, April 11, 2003 2:48 PM
> To: axis-user@ws.apache.org
> Subject: Re: Status of RPC performance - does it scale?
>
>
> I read this article.  This is what motivated me to write this message.
> WebLogic also publishes one.  I think the results may be invalid /
> outdated.
>
> Two problems with this article:
>
> 1. Doc lit and RPC cannot be compared side by side because RPC does two
> steps of the process - transport of SOAP, and de/serialization to Java
> objects.  If a doc-lit developer designs bad code to handle the SOAP
> message, it could be just as slow.
>
> 2. The performance curve on RPC doesn't make sense to me, until I read
> about a bug that was fixed in Dec, where the RPC stack was not releasing
> some resources.
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15015>
>
> If the fix above handles the RPC performance curve, then your average
> doc-lit style service *with* full XML handling to the business layer may
> be comparable to RPC style.  In other words, if the performace / byte
> size curve is now linear, then all of these arguments would have to be
> called into question again.
>
> Ben Tomasini
>
> On Fri, 2003-04-11 at 14:31, Frank Cohen wrote:
> > Not that this will make you feel any better but I'm finding that
> > SOAP-RPC performance suffers on most SOAP stacks. See my article at:
> > http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/
> >
> > -Frank
> >
> >
> >
> > On Tuesday, April 8, 2003, at 10:19 AM, Brian Ewins wrote:
> >
> > > Thats this bug report, if its any help:
> > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15015>
> > >
> > > Benjamin Tomasini wrote:
> > >> I agree.
> > >> I think some of the doc versus RPC tests are unfair because
> they don't
> > >> take into account the fact that RPC is doing much more work than
> > >> doc-lit.
> > >> However, I was inquiring about a specific posting that I ran across
> > >> lately.  Here is a snip:
> > >> **** Previous posting:
> > >> List:     axis-user
> > >> Subject:  Re: Performance problems with RPC messages over 20k
> > >> From:     Dennis Sosnoski <dms () sosnoski ! com>
> > >> Date:     2002-12-03 8:27:54
> > >> I investigated this further and found that there definitely is a
> > >> problem
> > >> in 1.0 with large messages using RPC encoding. With my particular
> > >> test data it started showing up at the 320KB message size and got
> > >> exponentially worse with larger sizes. I think I've tracked this
> > >> down, and have entered a bug report and fix against the offending
> > >> code. In my tests the fix keeps performance stable at least into the
> > >> 1.3MB range.
> > >> That done, I figured I should correct my earlier, overly- (or at
> > >> least prematurely-) optimistic, statement about Axis
> performance with
> > >> large messages. :-)
> > >>   - Dennis
> > >> Dennis M. Sosnoski
> > >> Enterprise Java, XML, and Web Services Support
> > >> http://www.sosnoski.com
> > >> Dennis Sosnoski wrote:
> > >>> In my own tests (running client and server on a single system) I
> > >>> found
> > >>> Axis performance went up at first as I increased the message size,
> > >>> then basically leveled off. Here's what my raw results look like:
> > >>>
> > >>> Message size   Roundtrip Time (ms.)
> > >>>   10KB                     107
> > >>>   20KB                     162
> > >>>   40KB                     289
> > >>>   80KB                     491
> > >>>  160KB                    981
> > >>>  320KB                   2000
> > >>>
> > >>> Martin Jericho wrote:
> > >>>
> > >>>
> > >>>> I was doing some benchmarking to test how much it would impact
on
> > >>>> performance to break up a single, large request into several
> > >>>> smaller ones.
> > >>>> I was expecting of course that for a fixed volume of data,
> dividing
> > >>>> it into
> > >>>> more separate messages would increase the overheads and
> make things
> > >>>> slower.
> > >>>>
> > >>>> What I found was quite surprising.  It seems that once a message
> > >>>> gets
> > >>>> bigger
> > >>>> than 20kb, the response time increases at a rate much greater than
> > >> the
> > >>>> linear relationship one would expect.  I did some tests with a
bean
> > >>>> containing an array of other beans.  The size of the message with
> > >>>> no array
> > >>>> elements is 1571 bytes, and each array element is 772 bytes.
> > >>>>
> > >>>> The times recorded are from calling the service method on the
> > >>>> client until
> > >>>> receiving the response back from the server (the response
> is just a
> > >>>> string).
> > >>>>
> > >>>> The results were as follows:
> > >>>>
> > >>>> Number of calls,    Number of Array Items,    Total Response Time
> > >>>> in Seconds
> > >>>> 0001,    1000,    20.7
> > >>>> 0002,    0500,    13.6
> > >>>> 0004,    0250,    9.9
> > >>>> 0005,    0200,    9.7
> > >>>> 0010,    0100,    7.6
> > >>>> 0020,    0050,    7.2
> > >>>> 0040,    0025,    6.8
> > >>>> 0050,    0020,    6.9
> > >>>> 0100,    0010,    7.3
> > >>>> 0200,    0005,    9.4
> > >>>> 0250,    0004,    10.5
> > >>>> 0500,    0002,    15.4
> > >>>> 1000,    0001,    25.6
> > >>>>
> > >>>> So the most efficent way to send my 1000 beans was in 40 separate
> > >>>> messages
> > >>>> each containing 25 beans, each of about 20kb in size.
> > >>>>
> > >>>> Does anyone know an explanation for this?  It seems to me that
> > >>>> there must be
> > >>>> something in axis which has been very poorly implemented to cause
> > >> this
> > >>>> blowout in performace.
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >> On Tue, 2003-04-08 at 12:05, Anne Thomas Manes wrote:
> > >>> Performance is a function of XML processing. You aren't likely to
> > >>> shave off
> > >>> any latency by using Doc rather than RPC. You're just transferring
> > >>> the XML
> > >>> processing to the application. What's needed is a more efficient
XML
> > >>> processor.
> > >>>
> > >>> Anne
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Benjamin Tomasini [mailto:btomasini@neteverything.com]
> > >>>> Sent: Tuesday, April 08, 2003 11:32 AM
> > >>>> To: axis-user@ws.apache.org
> > >>>> Subject: Status of RPC performance - does it scale?
> > >>>>
> > >>>>
> > >>>> Hello,
> > >>>>
> > >>>> I saw some postings regarding the performance of RPC messages over
> > >>>> 20K.
> > >>>> The problem was that performance dropped off rapidly as the file
> > >>>> size
> > >>>> increased, rather than being linear.
> > >>>>
> > >>>> One of the developers said that they problem had been identified,
> > >>>> and
> > >>>> they a fix was in the works.
> > >>>>
> > >>>> Can anyone comment on the issue of getting RPC to scale linearly
> > >>>> instead
> > >>>> of dropping off as the size increases?  Are there open bugs for
> > >>>> this?
> > >>>>
> > >>>> I am a fan of RPC, but the performance concerns make me look to
doc
> > >>>> style instead.
> > >>>>
> > >>>> Thanks much,
> > >>>>
> > >>>> Ben Tomasini
> > >>>>
> > >>>>
> > >>>
> > >
> > >
> > --
> > Frank Cohen, Founder, PushToTest, http://www.PushToTest.com, phone: 408
> > 374 7426
> > Come to PushToTest for free open-source test automation solutions that
> > test and monitor
> > Web-enabled applications, especially Web Services for scalability and
> > reliability.
> >
> >
>
>







Mime
View raw message