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