4

IISでホストされているC＃WCFWebサービス内からRabbitMQRPCサービスを呼び出す必要があります。これは問題なく動作していますが、私はRabbitMQクライアントのドキュメントを読んでいて、「IModelはスレッド間で共有しないでください」と述べています。

私の理解では、RabbitMQではIModelは実際にはソケット接続です。これは、呼び出しごとに、WCFサービスがIModelを作成し、完了したらそれを破棄する必要があることを意味します。

これは、パフォーマンスとソケットの使用法に関してやや過剰に思えます。私の理解が実際に正しいのか、またはスレッド間でIModelの接続プールを使用するなどの利用可能な他のオプションがあるのか​​疑問に思います。

どんな提案でもありがたく受け取られるでしょう。以下に私が使用しているコードのサンプルを示します。rabbitMQ接続は実際にはGlobal.asaxで初期化されています。ここにあるだけで、使用法を確認できます。

        var connectionFactory = new ConnectionFactory();
        connectionFactory.HostName = "SampleHostName";
        connectionFactory.UserName = "SampleUserName";
        connectionFactory.Password = "SamplePassword";
        IConnection connection = connectionFactory.CreateConnection();
        // Code below is what we actually have in the service method.
        var model = connection.CreateModel();
        using (model)
        {
            model.ExchangeDeclare("SampleExchangeName", ExchangeType.Direct, false);
            model.QueueDeclare("SampleQueueName", false, false, false, null);
            model.QueueBind("SampleQueueName", "SampleExchangeName", "routingKey" , null);
            // Do stuff, like post messages to queues
        }
4

2 に答える 2

3

IModelは実際にはソケット接続です

これは正しくありません。IConnectionは接続を表します:)複数のクライアントが同じtcp接続を使用できるようにするためにモデルが導入されました。したがって、モデルは「物理的」接続に対する「論理的」接続です。

モデルが行うタスクの1つは、大きなメッセージを分割して再アセンブルすることです。メッセージが特定のサイズを超える場合、メッセージはフレームに分割され、フレームにラベルが付けられ、受信者によって組み立てられます。ここで、2つのスレッドが大きなメッセージを送信すると想像してください...フレーム番号が台無しになり、2つのメッセージのランダムな部分で構成されるフランケンシュタインメッセージになってしまいます。

モデルの作成にはいくらかのコストがかかるとあなたは正しく想定しています。クライアントはサーバーにモデルを作成するための要求を送信し、サーバーはこのモデルのメモリ内に構造を作成し、モデルIDをクライアントに送り返します。これは、すでに開いているtcp接続を介して行われるため、接続の確立によるオーバーヘッドはありません。ただし、ネットワークの往復のため、まだいくらかのオーバーヘッドがあります。

WCFバインディングについてはよくわかりませんが、ベースのウサギの.netライブラリはモデルのプーリングを提供していません。それがあなたの場合に問題であるならば、あなたはあなた自身で何かを考え出さなければならないでしょう。

于 2012-07-31T16:49:54.707 に答える
1

セッションごとに1つのIModelオブジェクトが必要です。これは、ネットワークベースのAPIではごく普通のことです。たとえば、AzureTableStorageクライアントはまったく同じです。なぜ、複数の同時通信ストリームが実行されている単一のチャネルを持つことはできません。

後続のIModelインスタンスを作成するオーバーヘッドを削減する特定のレベルのキャッシュ（DNSなど）が発生することを期待します。

Azure Tablesで同じことを行う場合、パフォーマンスは問題ないため、IModelでは完全に問題ないはずです。本当に必要があることを証明できる場合にのみ、これを最適化してみてください。

于 2012-07-30T11:19:04.087 に答える