Blogs

RedMonk

Dork post: RFC vs XML Web Services performance test

A lot of people talk about XML and Web Services overheads, or now similarly JSON vs XML in AJAX, without using specific data to back up their claims. That’s fine. You don’t have to be a measurement genius to see that XML generally, and SOAP specifically, leads to bigger files. But here is some interesting data about RFC calls vs Web Services in an SAP environment so I thought I would point to. The data is even available for download- it would be cool to see it on swivel.

Daniel McWeeney’s conclusion:

“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.”

Or -its not the size of your packet but what you do with it that matters. Where and when you parse is the critical issue concerning performance overhead. It would be great to hear from the datapower folks about this.

4 Comments

  1. Posted January 10, 2007 at 6:34 pm | Permalink

    I actually tried to put it on swivel, but there were lots of data sets and it seems that it only supports one data column at a time which is a bit of a nightmare. If people want though i will throw it up there.

  2. Posted January 11, 2007 at 3:54 pm | Permalink

    Does Size Matter?

  3. Posted January 17, 2007 at 7:49 pm | Permalink

    What would you like to hear? :) Our experiences agree with the comments by you and Daniel. I believe that one factor for this is the relative maturity of the TCP/HTTP/SSL stacks compared to the XML parsers; another is probably trying to do XML/object mapping “gorp”

  4. Posted January 19, 2007 at 7:15 pm | Permalink

    Rich hits the nail on the head here. For example, if you use a profiler to see where the bottlenecks are in Java processing of XML documents, you find that it’s not at the actual parsing level, but at the object-creation level [and anything else concerning objects - marshalling, mapping]. People say it’s a problem of XML being “text-based”, but XML itself isn’t so much to blame here, but rather the blame may go back to the original assumptions of how XML should be mapped to objects. I was programming with ASN.1 parsers and EDI parsers 10 years ago and that kind of object-creation overload would have been unconscionable then.

    I’d love to write more, but I’m afraid I’d be lynched by my colleagues for giving away too much XML acceleration “secret sauce” in a public forum :-) . But, we do have a case study of how we deployed appliances to offload processing from a SAP XI environment here: http://www.vordel.com/customers/manufacturing.html . I’m happy to provide more technical details via email at http://radio.xmlstoragesystem.com/rcsPublic/mailto?usernum=0111797

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*

Additional comments powered by BackType

Bad Behavior has blocked 0 access attempts in the last 7 days.

Close
E-mail It