SOAP Performance - Really so slow ?

F

frankgerlach

From my simple performance tests of SOAP it seems that it is about ten
times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?
 
V

Vadym Stetsyak

I think, that everybody will have the same experience, because using SOAP
means that you will get more data then in binary mode. And if data size is
larger then network transfer of this data will be slow...

However, the flavor of SOAP is interoperability with different systems (
e.g. you can have web service written in Java and clients on .NET or vice
versa ).
If interoprability is not your goal then it is better to use binary
protocols...
 
B

Bruce Wood

....not to mention that serialization / deserialization will be slower,
and the routing of the request on the server side will be much slower.

As Vadym says, what SOAP (Web Services) give you is interoperability:
the option to use various technologies for your clients, now or in the
future.

Binary protocols are definitely faster, but they lock you into having a
..NET server and .NET clients forever....
 
J

j-integra_support

If you want the advantages of interoperability AND the performance of a
binary protocol, then J-Integra is the solution. J-Integra offers
interoperability between .NET, Java, COM, and Corba applications
without the overhead of Web Services. The following whitepaper
summarizes a performance analysis of using J-Integra versus Web
Services for Java .NET interop...

http://j-integra.intrinsyc.com/pdfs/whitepaper_performance_summary.pdf

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net
 
S

Scott Ellsworth

From my simple performance tests of SOAP it seems that it is about ten
times slower than binary object request protocols such as RMI, IIOP or
SimpleORB. Is this also YOUR experience ?[/QUOTE]

We had such problems at one point, then realized that we were doing a
SOAP call for simple data accessors. Once we bundled up the calls to be
somewhat higher level - returning whole collections of local objects,
for example, the overhead dropped to where we were willing to use SOAP.

If you are doing something very simple, RMI is going to just scream by
comparison to SOAP.

Scott
 
R

Roedy Green

times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?

Just consider what goes down the wire for a
SOAP int.

<sometag>12345</sometag> = 24 chars.

vs two binary bytes.
 
F

frankgerlach

It's always the same: "Industry Standards" are propagated, regardless
of actual performance or suitability. Just because SOAP is the hype,
all major vendors seem to promote it, without even thinking about
alternatives....
Publishing a "custom" client class library (for all major programming
languages) instead of WSDL would provide a tenfold better performance.
I wonder when the anti-SOAP backlash will happen....
 
A

Andrew McDonagh

It's always the same: "Industry Standards" are propagated, regardless
of actual performance or suitability. Just because SOAP is the hype,
all major vendors seem to promote it, without even thinking about
alternatives....
Publishing a "custom" client class library (for all major programming
languages) instead of WSDL would provide a tenfold better performance.
I wonder when the anti-SOAP backlash will happen....

sure a custom or lightweight standard would give much higher
performance, but then we run into all kinds of problem areas:

technology - .net apps talking to mainframes...
Platform mapping - endianness
Language mapping - Java int is signed 32 bits, C++ has un/signed 1/2/4
bits depending upon complier.
etc...


All of these areas have been addressed in various ways by the various
comms standards: DCOM, CORBA, RMI, SOAP, etc..

Hell, most of the custom lightweight standards I've seen go over TCP/IP,
yet there are times when its preferable for sending data over raw UPD
sockets (as I've had to do in real time Telecoms apps).

What this boils down to, is that there is no 'Right' or 'OneTrue' way.

Each application needs to chose the right distributed technology for its
own characteristics.

Soap allows multiple different technologies, languages, platforms and
environments to communicate via a neutral 'self describing' means - but
this comes with a price - as you say slow performance.

but keep in mind, this slow performance may not actually be the bottle
neck within the system, so 'curing' it would be a false victory.


Andrew
 
A

Andrew McDonagh

If you want the advantages of interoperability AND the performance of a
binary protocol, then J-Integra is the solution. J-Integra offers
interoperability between .NET, Java, COM, and Corba applications
without the overhead of Web Services. The following whitepaper
summarizes a performance analysis of using J-Integra versus Web
Services for Java .NET interop...

http://j-integra.intrinsyc.com/pdfs/whitepaper_performance_summary.pdf

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

or there's ICE - http://www.zeroc.com/performance/index.html

which has the benefits of Corba without the rubbish and is highly
efficient too.

Andrew
 
J

Jon Martin Solaas

Bruce said:
Binary protocols are definitely faster, but they lock you into having a
.NET server and .NET clients forever....

Really? Actually I think binary protocols were used a long time before
..Net was invented.
 
M

Mike Gaab

times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?

Can you quantify your results?

Thanks, Mike
 
F

frankgerlach

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.
 
S

Stefan Simek

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
 
B

Bruce Wood

Jon said:
Really? Actually I think binary protocols were used a long time before
.Net was invented.

Yes, of course, but binary protocols tend to be technology-specific. If
you use RMI in Java then you are pretty-much stuck with having a Java
client and a Java server (or at least a server that speaks RMI). If you
use .NET Remoting then you are pretty-much stuck with writing all of
your clients in .NET.

Since the post was in a C# newgroup, I assumed that the OP would write
at least one part of the system in C#, and therefore if the OP were to
use a binary protocol it is a practical necessity that all other
parties in the communication also be .NET.

Of course, in theory this isn't really true. One could try to write a
Java client for .NET Remoting, for example, but I shudder at the
thought... you'd have to be a masochist to take that one on.

So, yes, I know that binary protocols were used a long time before .NET
was invented. Binary protocols came first... before any other kind of
protocol. However, I didn't really consider that pertienent to the
discussion. :)
 
B

Bruce Wood

Ah. I see now that the OP cross-posted into a Java newsgroup. I hadn't
noticed that at first (the sins of using Google Groups). My apologies
to the Java folk for implying that "binary protocol = .NET"... it was a
problem of context. :)
 
B

Bruce Wood

Roedy said:
Correct, but there are some ways that deserve to die they are so
inept.

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

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.
 
B

Bruce Wood

Everything I've ever heard about SOAP / Web Services says the same
thing: the protocol is heavyweight, 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.

Your "Hello World" app benchmark doesn't surprise me. In fact, it just
re-enforces what I had already heard. This doesn't mean that the
protocol is crap. All it means is that you have to keep in mind its
strengths and weaknesses when evaluating it and if you decide to start
writing code and using it.

So, yes, SOAP / WS has the weakness that each call carries with it a
lot of overhead. Tons of overhead. Its strength is that it's highly
interoperable. For highly interactive applications where the server and
all clients use the same language, SOAP / WS is probably not a smart
way to go. For applications that send few messages, each containing
potentially large amounts of data, high chance of flux in the data
contents, and widely varying technologies on the client side, SOAP / WS
is probably your best choice. It all depends upon what you're trying to
do and in what context.
 
M

Mike Gaab

Bruce Wood said:
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?

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?

Thanks, Mike
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top