2

IIS でホストされている WCF Web サービスがあります。このサービスにはメソッドがあります。それを DoSomething() と呼びましょう。DoSomething() は、クライアント側アプリケーションから呼び出されます。

DoSomething は何らかの処理を実行し、ユーザーに回答を返します。ここで、DoSomething が呼び出される頻度をログに記録する必要があります。これを DoSomething 関数に追加して、呼び出しごとに SQL データベースに書き込み、カウンターを更新することができますが、ユーザーがこの余分なデータベース呼び出しを待つ必要があるため、DoSomething メソッドの速度が低下します。

DoSomething メソッドがデータベース内のカウンターを更新する新しいスレッドを生成し、スレッドが終了するのを待たずに DoSomething メソッドからの応答をユーザーに返すのは良いオプションですか? その後、データベースの更新が失敗したかどうかはわかりませんが、それは重要ではありません。

新しいバックグラウンド スレッドを生成し、それが WCF で終了するのを待たないことに問題はありますか? または、これを解決するためのより良い方法はありますか?

更新：少し異なる方法で質問する。wcf Webサービスメソッド内で新しいスレッドを生成するのは悪い考えですか?

4

2 に答える 2

2

主な問題は信頼性の 1 つです。これはあなたが気にかけている電話ですか？応答を返した後、スレッドが完了する前に IIS プロセスがクラッシュした場合、それは問題になりますか? いいえの場合は、クライアント側の C# ツールを使用できます。それが問題になる場合は、信頼できるキューイング テクノロジを使用する必要があります。

クライアント側を使用する場合、DB 呼び出しでブロックするためだけに新しいスレッドを生成することは、決して正しい答えではありません。必要なのは、呼び出しを非同期にすることです。そのためには、接続で有効になっていることを確認した後にSqlCommand.BeginExecuteを使用します。AsyncronousProcessing

信頼性の高い処理が必要な場合は、永続化されたキューに依存する非同期プロシージャ実行のようなパターンを使用できます。

補足として、ロギングやヒット カウントなどは、HTTP リクエストごとにデータベースに書き込む単純な方法で行うと、パフォーマンスの大きなボトルネックになります。バッチおよびフラッシュする必要があります。

于 2012-06-22T11:09:32.050 に答える
1

In ServiceのようDoSomething()に 1 つのメソッドのみを追跡する場合は、カスタム操作動作を作成してメソッドに適用できます。

操作動作には、情報をデータベースに記録するコードが含まれます。その操作動作では、.NET 4.0 の新しい TPL ライブラリを使用して、データベース ログを処理するタスクを作成できます。TPL を使用する場合、直接スレッドを作成することについて心配する必要はありません。

明日別のメソッドを追跡する必要がある操作動作を使用する利点は、その時点でコードを複製する代わりに、カスタム操作動作でメソッドをマークするだけです。すべてのメソッドを追跡したい場合は、サービスの動作を確認する必要があります。

操作の動作の詳細については、http://msdn.microsoft.com/en-us/library/system.servicemodel.operationbehaviorattribute.aspxを確認してください。

TPL (Task Parallel Library) の詳細については、http://msdn.microsoft.com/en-us/library/dd460717.aspxを確認してください。

于 2012-06-19T09:29:44.070 に答える