SOAP与XML-RPC或REST的性能

Question

有关使用XML-RPC或REST的解决方案简单性的争论很容易理解，很难与之争辩。

我也经常听到有关SOAP增加的开销可能会显着影响已用带宽甚至可能延迟的争论。我希望看到量化影响的测试结果。任何人都知道这些信息的好来源？

Answer 1

有几项研究已经完成，您可能会发现这方面的信息。请参阅以下内容：

• SO: Rest vs Soap Performance
• Q&A: SOAP and REST 101
• Updated SQL Server Data Services: Northwind REST and SOAP Uploads

也有关于在MSDN Forums话题的（有点过时）有趣的表现谈话。

总之 - 大多数这些来源似乎都认为SOAP和REST对于通用数据的性能大致相同。然而，一些结果似乎表明，对于二进制数据，REST可能实际上性能较差。请参阅我链接的论坛中的链接，以获取更多详细信息。

Answer 2

作为协议的REST没有定义任何形式的消息信封，而SOAP确实有这个标准。

因此，它尝试和比较两者，它们有点简单，它们是橙子的苹果。也就是说，SOAP信封（减去数据）只有几个k，所以如果您通过SOAP和REST检索序列化对象，则速度不应该有任何明显的差异。

Answer 3

我不知道任何基准问题的答案，但是，我对SOAP格式知道的是肯定的，它确实有开销，但是这个开销并不会增加每个请求：如果您有一个元素发送到Web服务，你有开销+一个元素的构造，如果你有1000个元素发送到Web服务，你有+ 1000元素构造的开销。当XML请求被格式化为特定操作时，会发生开销，但请求中的每个单独参数元素的格式都是相同的。

如果你坚持可重复的，短的突发数据（比如500个元素），速度应该是可接受的。

Answer 4

SOAP与REST速度的主要影响与线速无关，但与可玩性有关。 REST建议使用Web的语义，而不是试图通过XML对其进行挖掘，因此REST风格的Web服务通常设计为正确使用缓存头，因此它们可以与Web的标准基础结构（如缓存代理甚至本地浏览器缓存）一起使用。而且，使用Web的语义意味着像ETags和自动压缩压缩这样的东西是提高效率的理解方式。

..现在你说你想要基准。好吧，在Google的帮助下，我发现one guy，其测试显示REST比SOAP快4-6倍，另一个paper也支持REST。

Answer 5

扩大“pjz”的答案。

如果您获得了大量基于SOAP操作的信息（获得*类型的调用），那么目前您无法缓存它们。但是，如果您要使用REST实现这些相同的操作，则可能会缓存数据（取决于您的业务上下文），如上所述。由于SOAP使用POST进行操作，因此无法在服务器端缓存信息。

Answer 6

SOAP和任何其他使用XML的协议通常会使您的消息膨胀很多 - 这可能会或可能不会成为问题，具体取决于上下文。

类似于JSON的东西会更紧凑，可能会更快地进行序列化/反序列化 - 但不要仅仅因为这个原因才使用它。做那些你觉得有意义的事情，如果有问题就改变它。通常使用HTTP的任何东西（除非它重复使用HTTP 1.1保持连接，许多实现不会）为每个请求启动一个新的TCP连接;这非常糟糕，特别是在高延迟链接上。 HTTPS更糟糕。如果你有很多从一个发件人到一个收件人的短时间请求，那么请考虑一下你如何把这个开销拿出来。

对任何类型的RPC（无论是SOAP还是其他）使用HTTP总是会产生这种开销。其他RPC协议通常允许您保持连接打开。

Answer 7

SOAP肯定比较慢。有效负载明显较大，组装，传输，解析，验证和处理速度较慢。

Answer 8

我想这里的主要问题是如何比较RPC与SOAP。

它们都服务于相同的通信抽象方法，方法是将存根对象与您操作的基本数据类型和复杂数据类型进行比较，但不知道如何处理这些数据。

我总是喜欢（JSON-）RPC因为

• 它是轻量级的
• 有许多伟大的实现为所有的编程语言在那里
• 它简单易学/使用/创建
• 它很快（尤其是使用JSON）

虽然有理由您应该使用SOAP，即如果您需要命名参数而不是依靠他们的正确顺序

一些更多的细节，你从这个计算器获得question