私はページが要求されるたびにデータベースへの書き込みを実行するアプリケーションを持っています。このdb書き込みは時間的に重要ではないため、パフォーマンス上の理由から、MSMQを使用してオブジェクトをキューに入れるページがあります。 「私は本当にドン、このウェブサイトは自然界ではかなり小さいので、今ASP.NETスレッド+デザインに関する質問
public class QueueProcessor {
public void Start()
{
// Create background thread to run ProcessInternal()
}
public void Stop()
{
// Stop the previously created thread
}
public void ProcessInternal()
{
while (runnable)
{
// check queue for messages, process them one at a time,
// then wait indefinitely for more messages
}
}
}
：もちろん、私はキューやプロセスの要求を読むために何かを持っている必要がありますので、私はこれに似たクラスを書きましたデプロイメントルーチンにWindowsサービスを追加する必要があるので、私は現在、Application_Startイベントに新しいQueueProcessorを作成して開始します。私の考えは、スレッドがアプリケーションの稼働中に実行され、IISによってアプリケーションが強制終了された場合、次回誰かがページにアクセスしたときに再び起動するということです。
アプリケーションがIISによって強制終了されたためにキューに入れられたメッセージが処理されない長いアイドル時間を防ぐために、サイトのページの1つで数分ごとに実行するようにwget要求を設定しています。バックグラウンドスレッドが確実に実行されるようにします。
私の質問は、このデザインが非常に頻繁に見られることはありません。それに潜在的な問題があるかどうか疑問に思っていますか？
はEDIT：
テーマにいくつかの読み取りを行った後、私は、このアプローチ（および、そのようなキャッシュの削除コールバック関数と同様のもの）との主要な問題は、彼らがに頼まれた関数の型があることがわかりましたスケーラビリティに関して実行します。たとえば、大規模な更新などを行っている場合、明らかに、すべてのWebサーバーでタスクを実行したくない場合は、更新とデータの損失の可能性があります。
しかし、私の非常に特殊なケースでは、スレッドは、そのサーバーがそのサーバーのメッセージキューにある受信した要求のみを処理しています。したがって、私は5つのサーバーを言うために、このアプリケーションを拡大する場合は、各スレッドは問題なく、各サーバーのキューに入れられたメッセージを処理します。繰り返しますが、データベース内のレコードの順序はそれほど重要ではないため、小さな間隔で複数の異なるサーバーからの同様の要求が問題になるため、このソリューションは私の問題には合理的だと思います。
ウィジェットは余分なものであり、実際には必要ありません。別のポスターで言及されているように、そのスレッドのすべての例外を捕捉/処理している限り、早期に死に至る可能性はまったくなく、アイドル状態のアプリケーションでは待ち行列に入れられていないトラフィックを意味するので、 – Chris