47

XML-RPC または REST を使用したソリューションの単純さに関する議論は、理解するのは簡単ですが、反論するのは困難です。

また、SOAP のオーバーヘッドの増加が、使用される帯域幅に大きな影響を与え、場合によってはレイテンシーにさえ影響を与える可能性があるという議論もよく耳にします。影響を定量化するテストの結果を見てみたい。そのような情報の良い情報源を知っている人はいますか?

4

8 に答える 8

63

SOAP と REST の速度における主な影響は、ワイヤ速度ではなく、キャッシュ可能性に関係しています。REST は、XML 経由でトンネリングしようとするのではなく、Web のセマンティクスを使用することを提案しています。そのため、RESTful Web サービスは通常、キャッシュ ヘッダーを正しく使用するように設計されているため、キャッシング プロキシやローカル ブラウザー キャッシュなどの Web の標準インフラストラクチャとうまく連携します。また、Web のセマンティクスを使用するということは、ETag や自動 zip 圧縮などの機能が効率を高める方法としてよく理解されていることを意味します。

..そして今、あなたはベンチマークが欲しいと言います。Google の助けを借りて、REST が SOAP よりも 4 倍から 6 倍高速であることをテストで示したある人物と、同じく REST を支持する別の論文を見つけました。

于 2008-09-20T01:25:47.293 に答える
19

プロトコルとしての REST はメッセージ エンベロープの形式を定義していませんが、SOAP にはこの標準があります。

したがって、この 2 つを試して比較するのはやや単純ですが、リンゴとオレンジです。

つまり、SOAP エンベロープ (データを除く) は数 k にすぎないため、SOAP と REST の両方を介してシリアル化されたオブジェクトを取得する場合、速度に顕著な違いはありません。

于 2008-09-20T00:31:53.240 に答える
8

XML を使用する SOAP およびその他のプロトコルは、通常、メッセージをかなり肥大化させます。これは、コンテキストに応じて問題になる場合とそうでない場合があります。

JSON のようなものは、よりコンパクトで、シリアル化/逆シリアル化がより高速になる可能性がありますが、その理由だけで使用しないでください。その時点で理にかなっていると思うことは何でも行い、問題がある場合は変更します。

通常、HTTP を使用するものはすべて (多くの実装では行わない HTTP 1.1 キープアライブ接続を再利用しない限り)、要求ごとに新しい TCP 接続を開始します。これは、特に待ち時間の長いリンクでは、非常に悪いことです。HTTPS の方がはるかに悪いです。1 つの送信者から 1 つの受信者への短い要求が多数ある場合は、このオーバーヘッドをどのように取り除くことができるかを考えてください。

あらゆる種類の RPC (SOAP であろうとその他のものであろうと) に HTTP を使用すると、常にそのオーバーヘッドが発生します。他の RPC プロトコルでは、通常、接続を開いたままにすることができます。

于 2008-09-20T07:53:41.680 に答える
6

これに関して行われたいくつかの研究があり、参考になるかもしれません。以下をご覧ください。

また、MSDN フォーラムには、このトピックに関する (やや古い) 興味深いパフォーマンスに関する会話があります。

要するに、これらのソースのほとんどは、SOAP と REST が汎用データに対してほぼ同じパフォーマンスであることに同意しているようです。ただし、一部の結果は、バイナリ データを使用すると、REST のパフォーマンスが実際には低下する可能性があることを示しているようです。詳細については、リンクしたフォーラムのリンクを参照してください。

于 2012-11-30T18:57:32.740 に答える
5

「pjz」の答えを拡張します。

多くのINFORMATION（get *タイプの呼び出し）ベースのSOAP操作を取得している場合、現在、それらをキャッシュする方法はありません。ただし、RESTを使用してこれらの同じ操作を実装する場合は、前述のように、データ（ビジネスコンテキストによって異なります）をキャッシュできる可能性があります。SOAPは操作にPOSTを使用するため、サーバー側で情報をキャッシュすることはできません。

于 2008-09-20T01:39:01.270 に答える
4

SOAPは間違いなく遅いです。ペイロードは非常に大きく、アセンブル、転送、解析、検証、および処理が遅くなります。

于 2009-07-04T07:09:01.010 に答える
2

ベンチマークの質問に対する答えはわかりませんが、SOAP 形式について私が知っていることは、はい、オーバーヘッドがありますが、そのオーバーヘッドはリクエストごとに増加しないということです: Web サービスに送信される要素が 1 つある場合、オーバーヘッド + 1 つの要素の構築があり、1000 個の要素が Web サービスに送信される場合は、オーバーヘッド + 1000 の要素の構築があります。XML 要求が特定の操作用にフォーマットされるため、オーバーヘッドが発生しますが、要求内の個々の引数要素はすべて同じようにフォーマットされます。

反復可能な短いバースト データ (たとえば 500 要素) に固執する場合、速度は許容できるはずです。

于 2008-09-20T00:32:46.873 に答える
0

ここでの主な問題は、RPC と SOAP をどのように比較するかということだと思います。

どちらも、操作するスタブオブジェクトと、これらすべてがどのように処理されるかを実際に知らなくても返されるプリミティブ/複雑なデータ型を持つことにより、通信抽象化の同じアプローチを提供します。

私は常に (JSON-)RPC を好みます。

  • それは軽量です
  • そこにはすべてのプログラミング言語の優れた実装がたくさんあります
  • 学習/使用/作成が簡単です
  • 高速です (特に JSON の場合)

ただし、SOAP を使用する必要がある理由はいくつかあります。つまり、正しい順序に依存するのではなく、パラメーターに名前を付ける必要がある場合などです。

このスタックオーバーフローの質問から得られる詳細

于 2014-04-03T08:04:38.580 に答える