Skip to Content

Web Services Overhead

Have you ever wondered what the overhead of calling a web service in ABAP was vs. just calling a RFC? Well, I did so myself and Ed Gora, a co-op student here at Colgate, collected some data and hopefully came to some reasonable conclusions. To begin none of these systems are isolated so each test was run a considerable number of times to get a feel for the actual value.

Simple Echo Test Setup

“Server System” — This is a Netweaver 2004 system running on AIX. It has a Function module on it that is Remote enabled that takes in one string as input concatenates some information onto it and sends it out as an output parameter. “Caller System” – This is a Netweaver 2004s system running also on AIX. It has a program on it that calls the RFC 50 times in a row recording their run times. The collection mechanism for the timing is the get run time field function which according to the documentation should be accurate to the microsecond. The times below are converted into seconds to make it easier to compare. Just RFC - Web Service Proxy Setup “Server System” – We created a web service on this system that points to the RFC we used in the Simple Echo Test. The virtual interface was created with both parameters in it, nothing was hidden or set to default. “Caller System” – From the WSDL for the new WS on the “Server System” a generated a proxy class was created to allow us to call the WS on the “Server System.” Then a logic port was configured to point to the “Server System,” which is configured as an HTTP destination with SSO Tickets turned on. The program from the Simple Echo Test was modified to call the proxy right after the RFC so we get another 50 rows with a time for the RFC and the proxy call. The same mechanism was used to collect run times as in the prior test.

Table Type Test Setup

“Server System” – Same as in all prior tests. A FM was created that takes in a number of rows as input and produces a table of that many rows with one column filled with the string “foo”. “Caller System” – Just as before a program was created to call the RFC and the proxy back to back using the same time collection mechanism as before. Additionally, we vary the number of rows we get the RFC and Proxy to create. Varying Table Rows -

Same System Test

The above two tests were then conducted on the using only one system, meaning “Server System” = “Caller System”. In this case the “Server System” described above was used for the same system testing. The proxy class points back to the system the service is defined on and the RFC destination was removed. Again all times are in seconds and collection mechanism remains constant.

Simple Echo Test

Same System Simple Echo -

Table Type Test

Varying Table Rows Same System - Here is the raw data also just in case you want to see it.


The first and most obvious conclusion is that Web Services are much slower across the board, if you are calling a really simple function that has a simple interface or a more complex interface with tables, etc. I think everyone kind of knew this but, I’m not sure anyone is talking about it. What gets to be more interesting then that is when you start to compare calling a proxy class on the same system you are on or calling it from another system, which allows you to isolate network time. The amount of data transmitting with a SOAP request and response is probably larger ( does anyone have data on this ) then the comparable RFC request and response but, this amount is negligible when compared to the parsing time of the XML. If we look at the averages of the Same System Table Test vs. the Different Systems Table Test we see that the averages are pretty much in line with sometimes the Different systems outpacing the same systems! So this means that the transmission of increasingly large XML documents doesn’t have much impact on overall time. What does have impact is the parsing of those documents. This is one of those little discussed draw backs of Web Services, they take more time. If you are in a heterogeneous environment it will slow your application down considerably to use web services to do things. What other conclusions can be drawn from these data? Has anyone else compared these things for themselves? Is there a better way to do web services without all the SOAP, REST maybe? Subscribe to my blogs!image

You must be Logged on to comment or reply to a post.
  • Hi Dan:

    Interesting thoughts…I specially like the graphics, they worth more that a thousand words -:)

    I have never worked with WebServices (Die Hard RFC Fan)…So I can argue on your tests…

    Maybe John or Anton had something to say -;)



        • I gotta wait longer? Let’s see if you post yours before I finally post my ZOHO demo from TechEd and Office 2.0 – BTW remind people in your description that you are linking to external photos or something so they understand the popup they get in IE 😉
          • Sorry, few more days need to clean up some code.  I’ll wager a beer at the next TechEd that I get mine up before you.

            People shouldn’t use IE.  🙂

  • Hi Dan –

    From your picture, it doesn’t look like you’re old enough to remember how the simplest join on anything but trivial tables was a veritable pig until Oracle decided to recode its internals to permit parallelism.

    IOW, people didn’t discard a bad paradigm – they just waited around for the techies to make it more palatable.

    Same thing will happen here.  

    Only difference is that Enterprise SOA is actually a good paradigm, whereas the relational model was a bad model.

    So it will be worth the wait for the techies to find ways to make Enterprise SOA tolerable.

    In the mean time, I think there are probably business areas in which Enterpise SOA can do well.

    I say this because in a lot of cases, the limiting factor is how quickly end-users want to do their part of the work.  In my experience, end-users work sufficiently slowly that overlapping of retrieval and presentation can hide a lot of overhead, since the retrievals are being done while the customers are chewing on their penciles looking at the presentations.

    Of course, overlapping of retrieval and presentation is a lost art, but maybe it can be resuscitated in cases where look-aheads are possible.

    Always glad to see blogs about real IT posted at SDN and yours was “really real”.


  • Daniel,

    “What other conclusions can be drawn from these data? Has anyone else compared these things for themselves? Is there a better way to do web services without all the SOAP, REST maybe?”

    Thanks for the blog. Since the advent of Web services (SOAP), there has been a lot of research done of web services being slow and possible optimizations (search of “soap optimization”).

    Well, if you look at SOAP, you’ll see its conceived to solve the problem of tight coupling and platform incompatibility issues. And with it comes the bulkiness, serialization and marshalling associated with XML.

    You just can’t avoid it and still have its advantages. I wonder if (I’m sure they must be) SAP is working on any kind of optimization techniques to speed up things in systems like NetWeaver XI.


    • A highly optimized XML parser would certainly help.  Although, I think most XML parsing is already handled by the kernel.  I have done some other testing on parsing XML documents with the IF_IXML* objects on the ABAP stack instead of CALL Transformation command ( which i assume they are using in the generated proxy class ) and Call transform blows the doors off the IF_IXML* objects.  I’d love to know what some of the SAP kernel hackers think of the push to XML.
  • just as rfc is slower than rpc…

    i don’t think that’s the point right?

    If I may ask, what is the point of your blog, Daniel? I understand the sluggishness part of web services (topic in discussion since its inception few years back) but i don’t understand why you relate it to rfc response time.

    are you suggesting that if speed matters and we have to make a technical choice between those 2 communication protocols, we should stick with rfc?

    or should we try something else that web service?

    if xml parsing is the main problem how can REST solve it? How can REST speed can compensate with its lack of features compared to SOAP has?

    I understand your interest in the topic of application performance but i’d question the initial comparison (rfc vs. ws performance is like orange vs. apple as far as i’m concerned)and the suggestion to investigate alternatives like REST is a little… how should i say… interesting.

    are you onto something secret? can you share?

    • Hi,
      I like the comparison.
      The point is that you have to be aware of what SOAP calls cost in terms of performance. Otherwise you may use SOAP in situations where it’s not appropriate.

      One does not always need the late binding that Web services claim to offer, and you may consider alternatives in that case.

      Looking at the numbers it’s interesting to note that good old Corba is still an order of magnitude faster. A good Corba implementation can do a simple echo easily in less than 1 ms.

      Markus (/people/markus.kohler/blog)

  • i got through some problems.
    in t-code wsconfig when i checked goto–>check results i got message “ORIGINAL INTERFACE DOESNT MATCH WEBSERVICE DEFINTION”.


  • i am getting this error when i click button to generate wsdl code in browser.

    Your request could not be processed
    SRT: ASSERT failed: object reference not bound

    What has happened?
    A Soap Core Exception was raised in Method  CL_SOAP_REGISTRY::generate_wsdl(6)

    Technical Details of Soap Core Exception
    Message Text: SRT: ASSERT failed: object reference not bound
    Method: generate_wsdl
    LocationID: 6
    Program: CL_SOAP_REGISTRY==============CP
    Include: CL_SOAP_REGISTRY==============CM00J
    Line: 59 

    What can I do?
    Contact your system administrator and show him the technical details above.

    Your SAP SOAP Framework Team