アプリケーションプールリサイクルの応答時間が非常に長くなる

Question

私はどこかで読んだことがあります。アプリケーションプールのリサイクルはエンドユーザーにはあまり目立たないようにしてください。オーバーラップが有効になっている場合は少なくとも10倍長くなります（通常の100msからの応答時間は5000msまでになります）。また、これは単一のリクエストではなく、プールのリサイクル直後のいくつかのものです（これをテストするときに〜10の同時接続を使用していました）。

だから、質問は次のようになります。私は、アプリケーションの起動に長い時間がかかるだろう何かを、行いません。私の意見で

1. - 一般的には、それが唯一のIoCコンテナとルーティングの初期化で、またしてもI何かをするでしょう - それは重なり合いが気にするべきか、そうでないのでしょうか？
2. プールのリサイクル中にsql接続プールが破壊されることがあります。これが応答時間が長い理由ですか？
3. 何が最長の時間をとっているのかをプロファイルするにはどうすればよいでしょうか？また、アイデアがあるかもしれません。何がIIS/.NET側から長くかかるのでしょうか、それを避ける方法です。唯一の重複

Answer 1

1. 新しいものが開始されている間、古いワーカープロセスが実行して保管されることを意味します。新しいものが開始されるとすぐに、すべての要求の処理を開始します。 「開始済み」とは、初期化（Application_Start、アプリケーションの静的コンストラクタ、またはプロキシ構築のような重大なタスク）が完了したことを意味しません。これは、たとえ「古い」ワーカープロセスが短時間で利用可能であっても、これらのプロセスが完了している間に新しい要求が待機する必要があることを意味します。また、アプリケーションでキャッシュの種類が使用されている場合、新しいキャッシュは「コールド」になります。つまり、キャッシュがウォームアップされるまでに追加の処理時間が必要になります。

2. はい - 新しいアプリケーションには新しいSQL接続プールがあります。

3. 私の経験では、十分にテストされたコードと一貫した高性能を必要とするアプリケーションでは、アプリケーションプールのリサイクルを完全に無効にすることを選択しました。アプリケーションプールのリサイクルは、IISが不安定であるという認識と戦うために導入された「機能」です。実際には通常は本当に不安定なのは、ホストしていたアプリケーションでした。私の意見では、それは人々が安定したコードよりも少なく配置することを可能にする松葉杖です。問題を引き起こしている場合は、アプリケーションをオフにして、アプリケーションにメモリリークなどがないことを確認して、長期的なアプリケーションの不安定さを招く可能性があります。