現在、外部サイトからデータを取得HttpWebRequest
するために使用していますが、パフォーマンスは良くありませんでした。はるかに良いですかjson
?wcf
これについて専門家のアドバイスが必要です。
現在、外部サイトからデータを取得HttpWebRequest
するために使用していますが、パフォーマンスは良くありませんでした。はるかに良いですかjson
?wcf
これについて専門家のアドバイスが必要です。
簡単な答えは:いいえ。
より長い答えは、WCFは通信方法を指定しないAPIですが、複数の方法をサポートしているということです。ただし、これらのメソッドは通常、JSONよりも耳に聞こえるSOAPを介して行われるため、世界はSOAPから移行することを決定したようです。
どのようなパフォーマンスを求めており、何を得ていますか?ネットワークの場所の物理的な制限に直面しているだけかもしれません。その場合、データが遅い場合でも、インターフェイスの応答性を高めることに目を向ける可能性があります。
待ち時間の大部分がリモートサイトに到達するだけであるかどうかを確認することは価値があります(たとえば、応答時間はping時間に匹敵します)。または、おそらく、問題は、リモートサイトがページを生成して提供するのにかかる時間です。もしそうなら、いくつかの中間キャッシュが最適かもしれません。
おそらくそうではありませんが、それは正しい質問ではありません。
それに答えるには:確かにJSONをサポートするWCFは、最終的にHttpWebRequest
は最下位レベルで使用される予定であり、確かに同じネットワーク遅延があります。さらに重要なことに、JSONを取得するために同じサーバーを使用します。WCFには、Webサービスとクライアントの構築、保守、および構成において多くの利点がありますが、魔法のように高速ではありません。JSONを逆シリアル化する方法は、WCFがデフォルトで使用する方法に比べて非常に遅い可能性がありますが、私はそれを疑っています。
そして、それは本当に重要なポイントをもたらします:パフォーマンスが悪い理由を見つけてください。フレームワークを変更することは、何が遅いかを知っている場合にのみ理解できる最適化オプションであり、ひいては、別のことを行うと速度が遅くなることを意味します。サーバーですか?逆シリアル化ですか?ネットワークですか?それは認証ですか、それとも他のリクエストのオーバーヘッドの詳細ですか?等々。
したがって、本当の答えは次のとおりです。プロファイル!パフォーマンスの問題が実際に何であるかがわかったら、WCFのようなフレームワークが役立つかどうかについて情報に基づいた決定を下すことができます。
Isaacが言ったことに+1しますが、ここでWCFを使用すると、ほとんどの場所で内部的にHttpWebRequestが使用されるため、パフォーマンスがまったく向上しません。意図せずにパフォーマンスを向上させる方法の1つは、WCFがほとんどのトランスポートオブジェクトを内部でリサイクル、再利用、プール、およびキャッシュする方法です。したがって、最終的にはプロファイリングに関するIsaacのアドバイスに戻ります。