13

netNamedPipeBindingバインディングを使用してコンソールに自己ホスト型のWCFサービスがあります。サービスには空のメソッドが1つだけありますSend(DataTable bulk)

[ServiceContract]
public interface IWcfQueueService
{
    [OperationContract]
    void Send(DataTable bulk);       
}
public class WcfQueueService : IWcfQueueService
{
    public void Send(DataTable bulk)
    {           
       // Here would be something like _bulks.Add(bulk);
       // BUT, for now it is empty method and still it's slower than MSMQ
    }    
}

私のクライアントはDBから200Kの入力を取得し、それをBoundedThreadPoolで処理します（たとえば、20のスレッドのみを作成します）。各入力は異なるスレッドで処理されます。各スレッドが実行され、結果MyMethodの最後ににMyMethod追加されbulkManagerます。

public void MyMethod(string input)
{            
    var res = ProcessInput(input);
    bulkManager.Add(res);
}

N個のアイテム（=バルク）を蓄積するbulkManagerと、バルクを別のスレッドに渡し、次の2つの方法のいずれかでそのバルクをキューに入れます。

  1. wcfが有効になっている場合：wcfQueueService.Send(bulk);
  2. それ以外の場合、MSMQが有効になっている場合：new MessageQueue(@".\private$\q").Send(new Message {Body = bulk});

2つの方法はすべて機能しますが、MSMQははるかに高速に機能します。MSMQを使用すると、クライアントは20秒で約80Kのバルクを処理できますが、wcfを使用すると20K〜30Kのバルクしか処理できません。なぜそれが起こるのか分かりません。私のWCFは、MSMQとは異なるプロセスで実行されます。さらに、私のWCFは何も格納せず、空のメソッドがあります。では、なぜMSMQがWCFに勝つのでしょうか。

更新しました

提案されたようleppieに、私は.NetRemotingを試しました。NetRemotingは確かに速度を改善しました。クライアントは60Kを処理しました。だが、

  1. それでもMSMQより遅い
  2. 私が読んだように、.Net RemotingはWCFによって非推奨になり、これによるとWCFは.Net Remotingよりも高速であるはずですが、なぜwcfが遅くなるのでしょうか。たぶん私のバインディングが間違っていますか？
4

3 に答える 3

4

あなたはlikeとlikeを比較していません。

最も明らかな違いは、WCFの場合、タイミングにはサービス側のチャネルスタック全体の実行と操作の呼び出しが含まれるのに対し、直接のMSMQの場合は、クライアント側でペイロードをエンキューする時間のみを測定することです。WCFでのサービス側の処理には、DataTableオブジェクトの逆シリアル化が含まれることに注意してください。これは、バルキングファクターNが大きい場合、おそらく非常にコストがかかります。

さらに、サービスのインスタンス化とスロットルのノブをどのように構成したかによっては、クライアントからの要求がサービスの構成よりも速く行われる可能性があり、その結果、要求自体がサービス側で実行するためにキューに入れられます。

また、バインディングの構成方法によっては、セキュリティなど、他にも大きな違いがある場合があります。ちなみに、タイトルが示すように、NetMsmqBindingではなくNetNamedPipeBinding（質問が述べているように）を実際に使用しましたか？その場合、デフォルトのバインディング構成を使用すると、各バルクメッセージの暗号化と署名がまったく不要になります。これは、直接のMSMQの場合には発生しません。大きなメッセージに対するこれらの暗号化操作も、比較的コストがかかります。

より良い比較は、OneWayとして定義されたWCF操作との比較です。

于 2012-07-22T12:15:59.530 に答える
1

表示されている動作を示すサンプルコードを提供できますか？

送信するメッセージを20,000個生成して、独自のテストを行いました。直接MSMQを使用して20,000を試し、MSMQエンドポイントを抽象化するWCFを使用して20,000を試しました。

直接MSMQを使用する20,000はCPU時間の64.75％を使用し、20,000メッセージを送信するWCFバージョンはCPU時間の34.16％を使用しました（Visual Studio Ultimateの分析機能を使用して計測）。

私が自分の側でエラーを起こさない限り、WCFバージョンはハードコードされた同等のMSMQのほぼ2倍の速さでした。

于 2012-07-09T01:37:26.527 に答える
0

違いは、WCF操作で何が起こるかとMSMQが要求を受け入れるときに何をするかということだと思います。

MSMQ simpleを使用してメッセージをエンキューするときに実行されるメソッドは、メッセージのみを受け入れ、他には何も受け入れないことを期待しています。一部のバックエンドワーカーは、手間のかかる作業を行います。

オペレーションでは、リクエストをリクエストハンドラのシングルトンインスタンスに渡す必要があります。サービスが「スピンアップ」したときに、リクエストハンドラインスタンスをインスタンス化する必要があります。

また、.NET4のタスク並列ライブラリを使用して要求を並列化することでパフォーマンスが向上する場合があります。

于 2012-07-04T23:48:10.250 に答える