4

私は、シミュレーション実稼働環境のテストダブルとして機能することを目的とした WCF サービスを含む ASP.NET アプリケーションに取り組んでいます。Web サービス経由で注文を受け取り、数時間後または数日後に (他のシステムで Web サービスを呼び出して) 通知を送信できる、非常に複雑なバックエンドの代わりになります。

このテスト ダブル アプリケーションの最初のリリースの要件の 1 つは、ステートレスであること、つまりデータベースがないことでした。

プロジェクトに参加していない元の開発者によって配置された設計は次のとおりです。

  1. Webサービスで注文を受けます。
  2. バックグラウンド スレッドを生成する
  3. 返信定型文をクライアントに返す
  4. その後、バックグラウンド スレッドは 5 ～ 30 秒間スリープし、通知を送信し、再びスリープし、通知を送信します。これをおそらく 3 ～ 4 回繰り返し、最後に何もすることがなくなったときに終了します。

スレッドが 5 秒から 30 秒スリープするのは、本番システムの何時間も何日もかかる遅延をシミュレートするためのものです。各バックグラウンド スレッドの存続時間は、約 3 分程度です。

現在、設計はその目的のためにうまく機能しているようです。これまでのところ、このアプローチで発生した唯一の問題は、アプリケーションを再起動させる何かが発生した場合 (web.config の変更、新しい DLL の展開、IIS の再起動など)、バックグラウンド スレッドが強制終了されたように見え、保留中の通知がバックグラウンド スレッドは発生しません。

5 秒から 30 秒の遅延は短すぎるため、通知の間隔を 5 分間遅らせるのがより適切であるとお客様が判断しました。これは、バックグラウンド スレッドの有効期間が 20 分を超える可能性があることを意味します。

私の直感では、遅延を 5 分にすることは、この設計ではおそらく良い考えではありません。これについて人々がどのような考えを持っているかを見ることに興味があります。

遅延が増加した場合、この設計の信頼性はどの程度になるでしょうか? これについてコメントできる ASP.NET でバックグラウンド スレッドを長時間実行した経験のある人はいますか?

4

3 に答える 3

3

このような「睡眠」は、このアプリケーションで行われたため、決して行うべきではありません。なぜそうなのかはすでにお分かりでしょう。この遅延を大きくすると、タスクが完了しない時間が指数関数的に増加します。時間が長くなるほど、アプリ プールのリサイクルの可能性が高くなります。

Web サイト/サービスが接続してこれらの長時間実行タスクを開始できる別の Windows サービスを作成する価値がある場合があります。Windows サービスは、ASP.NET サービスのように自動的にリサイクルされません。WCF を使用して、ASP.NET と Win サービス間の通信を容易にすることができます。

于 2011-06-08T05:43:01.437 に答える
1

とにかく、これに対処するには何らかのサービスが必要になります。Web サイト、特に IIS では、アプリケーション プールのリサイクルが非常に積極的であるため、バックグラウンド処理を行うべきではありません。

基本的に、必要なのはスプーラまたはキューです。これは、多くの場合、個別のサービス、または実行されるスケジュールされたタスクの形で提供されます。Linux の世界では、これらをデーモンまたは cron ジョブと呼びます。

サービスを使用する場合は、ワーク オーダーまたはキュー アイテムを渡すことで、そのサービスと対話できる必要があります。それらの名前は何であれ、組み込みの何らかの通知遅延ルールを使用してそれらを処理します。いいえデータベース ストレージが必要ですが、ときどき選択されるフォルダーにファイルを簡単にダンプできる場合があります。

スケジュールされたタスク（おそらく毎分実行される）を使用する場合、それをsqliteデータベースまたはファイルシステムに保存して、タスクに取得させるのは簡単です。ファイルを取得して処理を実行する単純なコマンド ライン アプリを作成できます。

于 2011-06-08T05:54:11.450 に答える
1

MSMQ を使用して注文を保存し、スレッドを実行してキューを処理できる場合は、良い考えです。これにより、IIS サーバーのアップグレード/再起動の際の信頼性が向上します。

于 2011-06-08T06:07:57.103 に答える