ASP.NetアプリケーションとベストプラクティスでWCFを使用する

Question

私はWCFを完全に新しくしています。私はそれが通常のWebサービスのように動作すると確信していました。また、私も間違っているとはかなり確信していますが、今私は正しいことをしたいと思っています。

私たちのASP.Netアプリケーションは、インターネット上のWCFサービスに接続します。私は基本的なセキュリティとSSLを実装しています。それは動作していますが、通常のWebサービスを行っていたときよりも遅くなります。返されるデータは基本的に通常のWebサービスと同じです。

通常のWebサービスを使用していたときはいつでもデータを取得する必要がありました。新しいサービスオブジェクトを作成し、必要なデータの関数を呼び出しました。これは正常に動作するように見えましたが、私が想像するように、特に何千人ものユーザーが同時に接続している場合は、これを行う最善の方法ではありません。だから私はWCFに変換したときに、クライアントを開いたままにして、サイトに接続しているすべての人にそれを使用することに決めました。私はキャッシュに入れて、キャッシュがオブジェクトをダンプするときに、私はそれを処分するコールバック関数を持っていた。

私はこれをすべて変更してから、複数の人が接続するときに問題になるかもしれないと思っていた。人物Aがデータを要求した場合、人物Bは、データがそのサービスを介して取り出される前に、その人物が終了するのを待たなければならない。

私はそれをセッションベースに変更しました。私はこれを間違って実装したか、まったくうまくいかなかったので逆効果になった。クライアントはタイムアウトしたり、フォルトを引き起こしたり、まったく動作しません。私はそれを今のところキャッシュに戻した。それはうまく動いているようだ（遅いを除いて）。

このシナリオでは「ベストプラクティス」とは何ですか？必要になったときにクライアントを作成したり、セッションをベースにして（何が間違っているのか把握して）、そのまま使用して1つのクライアントキャッシュメソッドを使用しますか？

Answer 1

この種の問題は、通常、プールを維持することによって解決されます。 1つの極端に1つのサービスオブジェクトを持ち、もう1つの極端にユーザーを1つだけ持つのではなく、そのプールは現在のサービス要求をサポートするために必要なサービスオブジェクトの集合を保持します。したがって、プールは最大限の需要の点までしか成長しません。

サービスオブジェクト内から他のタイムアウトが発生する前にオブジェクトがプールから脱落していないことを確認し、例外があればドロップアウトするようにします。

このようにして、単一のオブジェクトへのアクセスを待っているクライアント要求が複数あることはなく、アイドル状態のオブジェクトがサービスにぶら下がっている可能性があります。

Answer 2

私は通常、言及したようにオンザフライでクライアントを作成しますが、要求が完了した後にこれを廃棄するようにしてください。私はこの問題を多く解決しましたが、正直言って私は1000人以上のユーザーが全く同じサービスを同時に受けることはありません。

興味がある場合は、thisブログの投稿に正確な実装の詳細があります。

質問で言及したことを明確にするために、「通常のWebサービス」と言えば、ASMXについて話していますか？

Answer 3

WCFサービスにとって最も実用的なのは、可能な限り、呼び出しごとの単一インスタンスモデルを持つことです。これにより、最高のスループット、サービスインスタンスでの最も簡単で簡単な動作が得られます。可能であれば、本当に魅力的な理由がない限り、このモデルを使用してください。

あなたのケースでは、サービスインスタンスの作成はかなり高価な操作であるようです。おそらく、これをどうにかする必要があるかもしれません - 実際のサービスインスタンスを非常に軽くて軽量にして、目のまばたきで作成して処理できるようにしてから、バックグラウンドワーカープロセス（またはおそらくプール） Anthonyによって提案されているように）、実際のサービスインスタンスから呼び出すことができます。

マーク