Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > SOAP Performance - Really so slow ?

Reply
Thread Tools

SOAP Performance - Really so slow ?

 
 
Bruce Wood
Guest
Posts: n/a
 
      11-29-2005

Mike Gaab wrote:
> "Bruce Wood" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
> >so do everything you can to make
> > fewer calls and ship more information across the wire on each call. We
> > know that we have to design differently for WS than we would if we were
> > using a binary protocol.

>
> Could you elaborate a tad? Just what can be done?


Well, for example, the gurus recommend that Web Services be stateless.
That, along with the knowledge that each call carries a lot of overhead
makes us prefer to make one call to search for stock items and return
the whole list to the client, rather than writing a "get first / get
next" style interface. We also offer client programs fewer options as
to how much information is returned for each item, because it's better
to return more info than the client wanted than to have a client
calling over and over again to get progressively more information about
a particular item. "Return the entire result, and return enough or more
than enough information about each item on one call" is the philosophy
we're running with for now.

If we were running a binary interface we might have done it
differently: make more calls to finer-grained routines on the server
side.

>
> Also, I'm not sure how to determine when a WS should be used over some
> other techology. If I my business uses a Java server, then just use a Java
> technology to pass the data. Is that how you are determining which to use?
> What would be some other factors?


I think of it this way: If I have a server running Java, and I'm pretty
sure that all of my clients, now and in the future, will either be Java
clients or browser-based clients (which could be served by a Java-based
Web server), then I would go with RMI, knowing that that would, for all
practical purposes, lock me into Java forever. I would get much better
performance and it would be easier to make the whole thing work. The
price I pay is that if my bosses ever come to me and say that they want
me to write a C# client on a Windows handheld then I'm in a bit of
trouble. (At that point I would either talk them out of it or build Web
Services on top of the Java server framework and use those, but I
wouldn't really be leveraging all of that RMI investment.) Lots of
shops are one-language shops, and in that environment there's really no
reason to incur the performance penalties of Web Services.

If, on the other hand, there is a reasonable likelihood that I'll be
dealing with all sorts of clients, and browser-based won't cut it (so I
would need to deploy client apps on various client platforms), then I'd
seriously consider Web Services because of the interoperability, even
though the performance sucks (comparatively) and in some cases it's not
as solid as some of the binary protocols (depending upon whose app
server you're using).

In our case, it's our server side that's the problem. Our choices there
are extremely limited... basically it's Web Services or nothing for us
on the server side.

 
Reply With Quote
 
 
 
 
Andrew McDonagh
Guest
Posts: n/a
 
      11-29-2005
Roedy Green wrote:
> On Tue, 29 Nov 2005 01:16:31 +0000, Andrew McDonagh
> <(E-Mail Removed)2s.com> wrote, quoted or indirectly quoted
> someone who said :
>
>
>>http://www.zeroc.com/performance/index.html

>
>
> is that the right url?


yeah works for me - is not for you?
 
Reply With Quote
 
 
 
 
Andrew McDonagh
Guest
Posts: n/a
 
      11-29-2005
Bruce Wood wrote:
> Roedy Green wrote:
>
>>On Tue, 29 Nov 2005 01:14:00 +0000, Andrew McDonagh
>><(E-Mail Removed)2s.com> wrote, quoted or indirectly quoted
>>someone who said :
>>
>>
>>>What this boils down to, is that there is no 'Right' or 'OneTrue' way.

>>
>>Correct, but there are some ways that deserve to die they are so
>>inept.
>>--
>>Canadian Mind Products, Roedy Green.
>>http://mindprod.com Java custom programming, consulting and coaching.

>
>
> Be that as it may, I beg to differ that SOAP / Web Services is one of
> those "inept" ways that deserves to die.
>


Agreed -

> In our case, for example, SOAP / Web Services is a godsend. We have a
> legacy back-end consisting of millions of lines of code, and no, we're
> not about to rewrite the thing in Java or C# just to make purists
> happy. Web Services is the first thing we've seen that could open up
> our closed mainframe-style architecture and start delivering some
> results. Is it inefficient compared to binary protocols? Yup. However,
> it's also the only practical way to deal with a heterogeneous
> environment.
>
> Binary protocols are efficient and easy to work with until you come up
> against a system that has different parts written in different
> languages. Then they quickly become a nightmare. For all of its
> inefficiencies and problems, SOAP doesn't suffer from that one critical
> flaw.
>
> Sure, there may be a "SOAP backlash" coming from twits who use the
> technology for absolutely everything, including inter-process
> communication. However, the technology does fill a niche (and a huge
> niche it is) that RMI, Remoting, etc. have never been able to
> adequately address. I think that SOAP / Web Services are here to stay.
>


Those twits are usually (though not always) the same people who abuse
all distributed messaging technologies by creating tiny methods that
pull or push singular atomic data values between two points. Early
CORBA days were full of people creating Business Object models that had
the objects residing anywhere and then having set/gets & normal methods
on those objects. And they wondered why it did run very quickly?????

Even with SOAP I see people making this fundamental mistake.

Andrew
 
Reply With Quote
 
Andrew McDonagh
Guest
Posts: n/a
 
      11-29-2005
Stefan Simek wrote:
> Hi,
>
> Well, this is an extremely non-real-word benchmark, that would work
> for cases where the request takes zero time at the server side, which is
> not a common case, or is simply caused by a design flaw.
>
> You say that you get 140 SOAP calls / sec = cca 7 ms per call, and 1600
> RMI calls = cca 0.6 ms. But should the request take 10 ms to complete at
> the server, the difference would be 17 ms vs. 10.6 ms, less than
> two-fold. With a 100 ms request, this would be 107 ms compared to 100.6
> ms, a difference that's completely negligible compared to the benefits
> provided by SOAP.
>
> Just my 2c.
>
> Stefan
>
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
>> A hello-world (with one String as parameter) SOAP application was at
>> about 140 calls/sec when running the client and the server on the same
>> PC (2 GHz Athlon). RMI and SimpleORB would be at about 1600 calls/sec
>> with the same helloworld app, on the same machine.
>> This means that SOAP is an order of a magnitude slower than competing
>> technologies...
>> Regarding interoperability: CORBA and technologies like SimpleORB ARE
>> cross-platform, they might only need an http "converter" so that they
>> can tunnel through firewalls.
>>


Nice!
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-30-2005
On 29 Nov 2005 10:16:54 -0800, "Bruce Wood" <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>
>Binary protocols are efficient and easy to work with until you come up
>against a system that has different parts written in different
>languages. Then they quickly become a nightmare. For all of its
>inefficiencies and problems, SOAP doesn't suffer from that one critical
>flaw.


A soap creator/parser is much more complex that a package to deal with
the wrong endianness of data. Just count lines of code to convert
binary to char to byte to char to binary compared with little endian
to big endian network order.

Soap has an illusion of simplicity because it is easy for humans to
deal with, but it is not humans dealing with it.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
Bruce Wood
Guest
Posts: n/a
 
      11-30-2005

Roedy Green wrote:
> On 29 Nov 2005 10:16:54 -0800, "Bruce Wood" <(E-Mail Removed)>
> wrote, quoted or indirectly quoted someone who said :
>
> >
> >Binary protocols are efficient and easy to work with until you come up
> >against a system that has different parts written in different
> >languages. Then they quickly become a nightmare. For all of its
> >inefficiencies and problems, SOAP doesn't suffer from that one critical
> >flaw.

>
> A soap creator/parser is much more complex that a package to deal with
> the wrong endianness of data. Just count lines of code to convert
> binary to char to byte to char to binary compared with little endian
> to big endian network order.


But it's not about just big-endian versus little-endian and low-level
concerns like that.

My point is that tools and frameworks for producing / consuming SOAP /
Web Services on all sorts of platforms and languages are sprouting up
like mushrooms. I don't have to write the bare-bones code that worries
about serialization, transport, and even (latterly) security and
encryption because it's all being done for me by hundreds of vendors.

The beauty of SOAP / WS isn't that it's easy for any particular vendor
to support it on any particular platform. In fact, as you pointed out,
it's not: it's bloody difficult, and getting more difficult by the
month as higher and higher level standards are created.

Instead, the beauty of SOAP / WS is that I as a consumer can buy an
application server that is designed to run services written in Java
from one vendor and a client platform for .NET clients from another
vendor and the two work together. CORBA never managed to get that much
market penetration. So far as I know the field of players trying to do
that sort of thing with RMI or .NET Remoting is thin indeed. If I can
grab products off the shelf and have them interoperate out of the box,
I don't care how much of a pain it was for the vendor to create them.
I'm happy. I'm even happier when vendor #1's client platform turns out
to be crap and I can just dump it and substitute another platform from
a competing vendor and it still works with my server-side Web Services.
I like the security of knowing that my whole system doesn't live or die
based on one vendor's ability to deliver, or even one language's
ability to deliver.

As well, my business partners can choose their own platforms and
languages and call my Web Services without knowing or caring what
language they're written in. Try doing that with .NET Remoting.

There's nothing wrong with RMI / Remoting / CORBA / whatever. They're
great technologies. However, they just don't have the vast market
penetration that Web Services is shaping up to have. As I said, if
interoperability between heterogeneous platforms is high on my list of
requirements, I probably won't be considering Java RMI as my protocol.
If I'm in a closed, all-Java shop, then that changes everything. Use
the right tool for the right job... and there are many jobs for which
SOAP is the right tool.

 
Reply With Quote
 
frankgerlach@gmail.com
Guest
Posts: n/a
 
      11-30-2005
I got 1600 calls/s with RMI or SimpleORB and about 140 calls/s with
SOAP. Application was hello-world with one String as argument.

 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-30-2005
On 29 Nov 2005 17:46:22 -0800, "Bruce Wood" <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>Instead, the beauty of SOAP / WS is that I as a consumer can buy an
>application server that is designed to run services written in Java
>from one vendor and a client platform for .NET clients from another
>vendor and the two work together.

that is also true of CORBA or messages defined by ASN.1.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
frankgerlach@gmail.com
Guest
Posts: n/a
 
      11-30-2005
Potentially WRONG: Real-world requests will transfer much more data,
which produces a VERY lengthy SOAP message. SOAP is not just a huge
envelope around efficiently encoded data, but a lengthy envelope that
contains lenghty data structures.
Just look at the encoding of an integer:
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.

 
Reply With Quote
 
Aquila Deus
Guest
Posts: n/a
 
      11-30-2005
(E-Mail Removed) wrote:
> Potentially WRONG: Real-world requests will transfer much more data,
> which produces a VERY lengthy SOAP message. SOAP is not just a huge
> envelope around efficiently encoded data, but a lengthy envelope that
> contains lenghty data structures.
> Just look at the encoding of an integer:
> <Integer xmlns="urn:vwservices">1</Integer>
> That is 40 bytes for a single integer - about a factor of ten (actually
> 40 if intelligently encoded) worse than CORBA.
> This means that multi-object messages are ALSO inefficient, because
> each object/value if inefficiently encoded.


hmmm couldn't this be easily solved by compression??

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: slow slow slow! Expert lino fitter Computer Support 5 12-12-2008 04:00 PM
Re: slow slow slow! Expert lino fitter Computer Support 0 12-10-2008 02:33 PM
String#chop slow? REALLY slow? Mat Schaffer Ruby 11 07-27-2006 05:45 PM
Really slow, painfullu slow asp.net web app michael@randallk.com ASP .Net 3 02-15-2006 11:02 PM
.net SOAP toolkit performance for SOAP deserialization Prabhu ASP .Net Web Services 5 11-18-2004 10:42 PM



Advertisments