19
大規模サイトでのバックグラウンドタスクのサービス
StackOverflowの興味深い問題を扱っています。 私たちには、「すぐにやる必要がある」小さなタスクがたくさんあります。例は、「関連する質問」リストの更新です。過去に行ったことは、これらのタスクを一部のユーザーのページロードにピギーバックすることです。 これは決して理想的ではありませんでしたが、それほど目立ちませんでした。SOが1,000,000の疑問符を通過したので、それらの不運なユーザーはそれを感じ始めています。 自然な解決策は、これらのタスクを実際にバックグラウンドにプッシュすることです。私が検討しているこれを行うには2つの広い方法があります。 1. IISでカスタムスレッドプール/ワークキューとして 基本的に、IISに干渉しないようにいくつかのスレッド（非ThreadPool）をスピンアップし、Funcsを入れているコレクションにサービスを提供します。 ここでの大きな利点はシンプルです。マーシャリングについて心配する必要も、外部サービスが起動して応答することを確認する必要もありません。 また、すべての共通コードにアクセスできます。 欠点は、バックグラウンドスレッドを使用しないことです。私が知っている異議はすべて、IISの飢star（ThreadPoolを使用している場合）とスレッドのランダムな消滅（AppPoolのリサイクルのため）に集中しています。 ランダムスレッドデスを非問題にするための既存のインフラストラクチャがあり（基本的にタスクの検出は中止されています）、スレッド数の制限（および非スレッドプールスレッドの使用）も難しくありません。 IISプロセスのスレッドプーリング/ワークキューに他の異議がありませんか？ ここでは実際には対処されなかったため、StackOverflowに移動しました。 2.サービスとして サードパーティのソリューション、またはカスタムソリューションのいずれか。 基本的に、プロセスの境界を越えて何らかのサービスにタスクをマーシャリングし、それを忘れます。おそらく、生のSQL +接続文字列の一部のコードをリンクしている、または制限しているのでしょう。 プロは、これを行うための「正しい方法」であるということです。 短所は、できることが非常に制限されているか、このサービスをコードベースと同期させるために何らかのシステムを作成する必要があることです。また、監視とエラーログのすべてをなんらかの方法で接続する必要があります。これは、「IIS内」オプションで無料で取得できます。 サービスアプローチには他の利点や問題がありますか？ 簡単に言えば、アプローチ＃1を実行不可能にする予測不可能で克服できない問題がありますか。もしそうなら、アプローチ＃2を検討する必要がある優れたサードパーティサービスはありますか。