回答:
Tech Ed 2003で、プレゼンターはこの質問をされました。その答えは、毎日の境界で発生するのを防ぐために不規則なサイクルを望んでいたということです。
...(29は)24の後の最初の素数であり、他のサーバープロセスとの規則的なパターンで発生する可能性が最も低くなります。問題の調査を容易にする
別のサイトがこれを確認しているようです:
(Wade Hilmo)は、24を超える最小の素数であるという単純な理由で29時間を提案しました。
OK、これは私を悩ませていたので、私は周りを掘り下げ、最終的にIISチームにいたらしい男からこの投稿を見つけました:
IIS6がデフォルトで29時間ごとにリサイクルする理由(そして私たちには理由がありました
IIS6がデフォルトで29時間ごとにリサイクルされる理由(そしてデフォルト値として29時間を選択する理由がありました)は、おそらく、それで実行されているWebアプリケーションは信頼できず、文字通り頻繁に再起動する必要があるためです。
したがって、IIS6は、ユーザーのWebアプリケーションが24時間以上連続して実行されないという前提(間違いなく皮肉なこと)に基づいて構築され、それに応じて機能が計画され、デフォルトが選択されます。ワーカープロセスは29時間ごとにリサイクルされ、プロセスの起動とシャットダウンが監視され、プロセスが実行されていることを確認するために絶えずpingされ、プロセスハンドルが追跡され、予期せず終了したときに通知されます。
IIS6は、リサイクルが通常の操作の一部であることを認識し、そのようなリサイクルをエンドユーザーから確実に分離します。エンドユーザーのTCP接続は、カーネルモードの魔法により、リサイクル中に終了することはありません。セッション状態のアウトプロセス(ASP.Net Session State Serviceなど)を保存するユーザーモードアプリケーションと組み合わせることで、Webアプリケーションが1つ1つ処理した後にクラッシュした場合でも、ユーザーに見えるデータ損失のない信頼性の高いアップタイムを保証します。ユーザー要求。
これは、IIS6でできることとほぼ同じです。信頼できないWebアプリケーションが与えられ、エンドユーザーに信頼できるように見せ、信頼できないWebアプリケーションの修正を必要とせずに実行します。
もちろん、すべての信頼できないアプリケーションを信頼できるように見せることができるわけではありません。もしそうなら、私たちはすべて失業しています!-しかし、IIS6は、回復力を高めるためにさらに多くのことを試みています。
あなたの場合、弾力性は永続的でないユーザー状態に副作用をもたらすだけですが、簡単に調整できます。
Webアプリケーションに問題がなく、インプロセスセッション状態のままであると仮定すると、これらのデフォルトを変更する必要があります。1. 29時間の定期的なリサイクルをオフにします2. 20分のアイドルタイムアウトをオフにします
これにより、セッション状態が予期せず失われることを防ぎます。
もちろん、アウトプロセスセッション状態でアプリケーションを使用する場合、すべてをデフォルトのままにして、機能や信頼性の違いに気付くことはありません。