IISがデフォルトで1740分ごとにアプリケーションプールをリサイクルするようになっているのはなぜですか？
なぜIIS既定で一定時間後にアプリプールがリサイクルされるのですか？ほとんどのWebアプリがメモリを慎重に管理していないこと以外に何か特別な理由がありますか？アプリケーションのメモリを適切に管理していることを考えると、先に進んでこれをオフにしても安全ですか？リサイクルをオフにしたり、オンにしたままにしたりすることの利点、アップの利点にはどのようなものがありますか？
はい、デフォルトで1日に1回となるのは、Webアプリでメモリリークが発生する可能性があるためです。頻繁にリサイクルすることの最大の欠点IISアプリプールは、web.configの読み取り、アセンブリの読み込み、およびasp.netページの再コンパイルを引き起こし、（事前に信じていない場合）それらをコンパイルする）コードビハインド。これはかなり重いプロセスであり、アプリプールがリサイクルされた後、ページに対する次のリクエストが発生するまで発生せず、その特定のリクエストが大幅に遅くなります。IIS7には、ダウンロード可能なモジュールが呼び出されます- Application Warm Up この問題の「対処」を支援します。
個人的には、リサイクルをスケジュールするよりも、メモリベースの最大値と、アプリの起動時のログオンを組み合わせて使用することを好みます。これにより、アプリにメモリリークがないと想定でき、アプリプールのリサイクル時に間違っていることが証明されます。
1740分は29時間です。
IIS 6（アプリケーションプールを導入したバージョン）が開発されていたとき）に戻ると、アプリケーションプールが自動的にリサイクルされるときに、定期的な間隔にデフォルトを設定する必要がありました。
ウェイドは24時間で最小の素数であるという単純な理由から、29時間を提案しました。彼は、1日1回よりも頻繁に発生しない、時間をずらして繰り返さないパターンを望んでいました。ウェイドの言葉では、「共鳴するパターンは得られません」。それ以来、デフォルトは1740分（29時間）です。
機能は、クラシックからのホールドオーバーですASPすべてのメモリがリークし、それを実行しなければならなかった日。ほとんどの人々は、Webサーバーで一晩スケジュールされた再起動を行いました。IIS6はこれを自動化し、1740分ごとにアプリプールをシャットダウンしました（またはアプリが20分間アイドル状態の場合）IIS7は伝統を続けました。
当時マイクロソフトから得たアドバイスは、既知のメモリリークがあるレガシーアプリがない限り、これは不要であるというものでした。したがって、純粋にマネージコードを実行している場合は問題ありません。
シャットダウンして、アプリプールを監視します。ほとんどの複雑なエンタープライズアプリケーションは、多くのレガシーコードを使用しており、そのコードの大部分は少し漏れやすいものです。したがって、ほとんどのインストールでは、アプリプールをときどき再起動することは悪い考えではありません。
非アクティブな時間を監視するなど、状況により適した解決策となる可能性のある他のオプションがあります。
アプリプールを起動すると、時間がかかり、アプリケーションの応答性が低下する可能性があるため、アプリを起動したままにするとパフォーマンスが向上します。
実際、これは、存在する可能性のある（ある可能性がある）リークされたリソースをクリーンアップするためだけです。 1740分だけがトリガーイベントでもありません。また、特定の最大数のリクエストの後、または特定の量のワーカープロセスメモリを超えた後にも発生します。それは、MSDNライブラリにかなりよく文書化されています。残念ながら、このポリシーは、セッション状態やシングルトンなどの静的などの問題を解決します。アプリは、ユーザーのエクスペリエンスを妨げないように、必要に応じてユーザーを再認証したり、シングルトンを再初期化したりするのに十分な堅牢性が必要です。 ASP.NETセッションではなく、データベースで認証されたセッションを管理する必要がありました。それ以外の場合、これらのトリガーのいずれかが原因でサーバーがリサイクルしたときはいつでも、ユーザーはログインページに再起動されました。