4

私たちは、サード パーティの Web サービスに対して最大数万回の小さな Web サービス呼び出しを行わなければならない .NET アプリを開発しています。より「分厚い」呼び出しを希望しますが、サードパーティはそれをサポートしていません. クライアントは、構成可能な数のワーカー スレッドを使用するように設計されており、テストを通じて、1 つのマルチコア マシン用にかなり最適化されたコードが用意されています。ただし、速度を向上させたいと考えており、複数のマシンに作業を分散することを検討しています。私たちは典型的なクライアント/サーバー/データベース アプリに精通していますが、複数のマシン向けの設計は初めてです。それで、それに関連するいくつかの質問：

  • マルチスレッド以外に、http 要求/応答の速度を向上させるために検討すべきクライアント側の最適化はありますか? (これは非標準の Web サービスであるため、WCF または SOAP クライアントではなく、WebClient を使用して実装されていることに注意してください)
  • 私たちの現在の考えでは、WCF を使用して作業のチャンクを MSMQ に発行し、クライアントを 1 つまたは複数のマシンで実行してキューから作業を引き出すというものです。私たちは WCF + MSMQ の経験がありますが、より良いオプションを見逃さないようにしたいと考えています。今日これを行うための他のより良い方法はありますか?
  • DigiPede や Microsoft の HPC 製品などのサードパーティ製ツールを見てきましたが、これらはやり過ぎのように思えます。これらの製品の使用経験や、自社製品よりも検討すべき理由はありますか?
4

4 に答える 4

3

あなたの目標は、これらすべてのWebサービス呼び出しをできるだけ早く実行し、結果を表にまとめることであるように思われます。それを考えると、最大の効率制御は、実行できる同時リクエストの数をスケーリングすることによって行われます。

クライアント側の接続制限を必ず確認してください。デフォルトでは、システムのデフォルトは2接続だと思います。私自身はこれを試していませんが、このプロパティを使用して接続数を増やすと、理論的には、単一のマシンからより多くの接続を生成することで、より多くのリクエストを生成するという点で乗数効果が見られるはずです。MSフォーラムに詳細があります。

MSMQオプションはうまく機能します。私はその構成を自分で実行しています。ActiveMQも優れたソリューションですが、MSMQはすでにサーバー上にあります。

あなたには良い出発点があります。それを運用してから、パフォーマンスとスループットに移ります。

于 2009-02-16T18:54:32.920 に答える
1

今年のCodeMashで、WesleyFalerはこの種の問題について興味深いプレゼンテーションを行いました。彼の解決策は、「ジョブ」をDBに保存し、クライアントを使用して作業をプルダウンし、完了時にステータスをマークすることでした。

その後、彼はインフラストラクチャ全体をAmazonのEC2にプッシュしました。

これがプレゼンテーションからの彼のスライドです-彼らはあなたに基本的な考えを与えるはずです：

ローカルで複数のPCを使用して同様のことを行いました。ワークロードの管理の基本は、Falerのアプローチと同様でした。

于 2009-02-16T18:58:12.443 に答える
1

コードを最適化した場合は、ネットワーク側を最適化して、送信されるパケット数を最小限に抑えることを検討できます。

  • HTTPセッションを再利用します（つまり、接続を開いたままにして複数のトランザクションを1つのセッションにまとめ、TCPオーバーヘッドを削減します）
  • 帯域幅を節約するために、リクエストでHTTPヘッダーの数を最小限に減らします
  • サーバーでサポートされている場合は、gzipを使用してリクエストの本文を圧縮します（圧縮を実行するためのCPU使用率と、節約する帯域幅のバランスをとる必要があります）
于 2009-02-16T19:03:07.440 に答える
0

MSMQの代わりにRhinoServiceBusを検討することをお勧めします。ソースはここから入手できます。

于 2009-02-16T18:55:29.813 に答える