SOAP Performance - Really so slow ?

Discussion in 'Java' started by frankgerlach@gmail.com, Nov 28, 2005.

  1. Guest

    >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 ?
    , Nov 28, 2005
    #1
    1. Advertising

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

    --
    Vadym Stetsyak aka Vadmyst
    http://vadmyst.blogspot.com
    <> wrote in message
    news:...
    > >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 ?
    >
    Vadym Stetsyak, Nov 28, 2005
    #2
    1. Advertising

  3. Bruce Wood Guest

    ....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....
    Bruce Wood, Nov 28, 2005
    #3
  4. Guest

    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
    , Nov 28, 2005
    #4
  5. In article <>,
    wrote:

    > >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 ?


    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

    --
    Scott Ellsworth

    Java and database consulting for the life sciences
    Scott Ellsworth, Nov 28, 2005
    #5
  6. Roedy Green Guest

    On 28 Nov 2005 12:06:06 -0800, wrote, quoted or
    indirectly quoted someone who said :

    >>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 ?


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

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

    vs two binary bytes.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Nov 28, 2005
    #6
  7. Guest

    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....
    , Nov 28, 2005
    #7
  8. wrote:
    > 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
    Andrew McDonagh, Nov 29, 2005
    #8
  9. wrote:
    > 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
    Andrew McDonagh, Nov 29, 2005
    #9
  10. Bruce Wood wrote:

    >
    > 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.
    Jon Martin Solaas, Nov 29, 2005
    #10
  11. Roedy Green Guest

    Roedy Green, Nov 29, 2005
    #11
  12. Roedy Green Guest

    On Tue, 29 Nov 2005 01:14:00 +0000, Andrew McDonagh
    <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.
    Roedy Green, Nov 29, 2005
    #12
  13. Mike Gaab Guest

    <> wrote in message
    news:...
    > >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 ?
    >


    Can you quantify your results?

    Thanks, Mike



    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mike Gaab, Nov 29, 2005
    #13
  14. Guest

    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.
    , Nov 29, 2005
    #14
  15. Stefan Simek Guest

    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

    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.
    >
    Stefan Simek, Nov 29, 2005
    #15
  16. Bruce Wood Guest

    Jon Martin Solaas wrote:
    > Bruce Wood wrote:
    >
    > >
    > > 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.


    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. :)
    Bruce Wood, Nov 29, 2005
    #16
  17. Bruce Wood Guest

    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. :)
    Bruce Wood, Nov 29, 2005
    #17
  18. Bruce Wood Guest

    Roedy Green wrote:
    > On Tue, 29 Nov 2005 01:14:00 +0000, Andrew McDonagh
    > <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.

    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.
    Bruce Wood, Nov 29, 2005
    #18
  19. Bruce Wood Guest

    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.
    Bruce Wood, Nov 29, 2005
    #19
  20. Mike Gaab Guest

    "Bruce Wood" <> wrote in message
    news:...
    >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



    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mike Gaab, Nov 29, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Amir
    Replies:
    3
    Views:
    591
  2. Replies:
    3
    Views:
    3,025
  3. nc
    Replies:
    1
    Views:
    491
    nice.guy.nige
    Feb 3, 2005
  4. Prabhu

    .net SOAP toolkit performance for SOAP deserialization

    Prabhu, Nov 12, 2004, in forum: ASP .Net Web Services
    Replies:
    5
    Views:
    283
    Dan Rogers
    Nov 18, 2004
  5. Mat Schaffer

    String#chop slow? REALLY slow?

    Mat Schaffer, Jul 27, 2006, in forum: Ruby
    Replies:
    11
    Views:
    327
    Caio Chassot
    Jul 27, 2006
Loading...

Share This Page