Performance of SOAP vs. XML-RPC or REST

StackOverflow https://stackoverflow.com/questions/106546

Question

The arguments about the simplicity of solutions using XML-RPC or REST are easy to understand and hard to argue with.

I have often also heard arguments that the increased overhead of SOAP may significantly impact used bandwidth and possibly even latency. I would like to see the results of a test that quantifies the impact. Any one know a good source for such information?

Was it helpful?

Solution

There are a few studies which have been done regarding this which you might find informative. Please see the following:

There is also an (somewhat out of date) interesting performance conversation about the topic at the MSDN Forums.

In short - most of these sources seem to agree that SOAP and REST are roughly the same performance for general-purpose data. Some results, however, seem to indicate that with binary data, REST may actually be less performant. See the links in the forum I linked for more detail on this.

OTHER TIPS

The main impact in speed of SOAP vs. REST has not to do with wire speed, but with cachability. REST suggests using the web's semantics instead of trying to tunnel over it via XML, so RESTful web services are generally designed to correctly use cache headers, so they work well with the web's standard infrastructure like caching proxies and even local browser caches. Also, using the web's semantics means that things like ETags and automatic zip compression are well understood ways to increase efficiency.

..and now you say you want benchmarks. Well, with Google's help, I found one guy whose testing shows REST to be 4-6x faster than SOAP and another paper that also favors REST.

REST as a protocol does not define any form of message envelope, while SOAP does have this standard.

Therefor, its somewhat simplistic to try and compare the two, they are apples to oranges.

That said, a SOAP envelope (minus the data) is only a few k, so there shouldn't be any noticeable difference in speed provided you are retrieving a serialized object via both SOAP and REST.

SOAP and any other protocol which uses XML generally bloats your messages quite a bit - this may or may not be a problem depending on the context.

Something like JSON would be more compact and maybe faster to serialise / deserialise - but don't use it exclusively for that reason. Do whatever you feel makes sense at the time and change it if it's a problem.

Anything which uses HTTP typically (Unless it's reusing a HTTP 1.1 keepalive connection, which many implementations do not) starts up a new TCP connection for each request; this is quite bad, especially over high latency links. HTTPS is much worse. If you have a lot of short requests from one sender to one receiver, think about how you can take this overhead out.

Using HTTP for any kind of RPC (whether SOAP or something else) is always going to incur that overhead. Other RPC protocols generally allow you to keep a connection open.

Expanding on "pjz" 's answer.

If you're getting a lot of INFORMATION(get* type of calls) based SOAP operations, currently there is no way you can cache them. But if you were to implement these same operations using REST, there is a possibility that the data(depends on your business context) can be cached, as mentioned above. Because SOAP uses POST for its operations, it cannot cache the information at the server side.

SOAP is definitely slower. Payloads are significantly larger which are slower to assemble, transport, parse, validate and process.

I don't know of any answer to the benchmarking question, however, what I do know about the SOAP format is yes, it does have overhead, but that overhead does not increase per request: if you have one element sent to the web service, you have overhead + one element construction, and if you have 1000 elements sent to the web service, you have overhead + 1000 element construction. The overhead occurs as the XML request is formatted for the particular operation, but every individual argument element in the request is formatted the same.

If you stick to repeatable, short bursts of data (say, 500 elements), the speed should be acceptible.

I guess the main question here is how compares RPC with SOAP.

they both serve the same approach of communication abstraction by having stub objects you operate with and primitive/complex data types you get back without really knowing how this all is handled underneath.

I would always prefer (JSON-)RPC because

  • it's lightweight
  • there are many great implementations for all programming languages out there
  • it's simple to learn/use/create
  • it's fast (especially with JSON)

although there are reasons you should use SOAP, i.e. if you need naming parameters instead of relying on their correct order

some more details you get from this stackoverflow question

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top