IIS のアプリ プール設定のリサイクルを "要求数の固定" 後にリサイクルすることの影響は何ですか?
この数が 100 で、99 番目の人が私の Web サイトに接続し、100 番目の人が来て、アプリケーション プールのリサイクルをトリガーするとします。
これは、セッション 1 ~ 99 のすべてのセッション情報が失われることを意味しますか (アプリケーション プールのワーカー プロセスが再起動すると、インプロセス セッションは期限切れになります)。
IIS のアプリ プール設定のリサイクルを "要求数の固定" 後にリサイクルすることの影響は何ですか?
この数が 100 で、99 番目の人が私の Web サイトに接続し、100 番目の人が来て、アプリケーション プールのリサイクルをトリガーするとします。
これは、セッション 1 ~ 99 のすべてのセッション情報が失われることを意味しますか (アプリケーション プールのワーカー プロセスが再起動すると、インプロセス セッションは期限切れになります)。
あなたは基本的にそれを正しく持っていますが、それは人ではなく、要求です. アプリケーションで呼び出される各 aspx ページが加算され、しきい値に達すると、アプリケーション プールがリサイクルされ、アプリケーション ドメイン (.Net を使用している場合) がアンロードされ、すべてが再起動します。セッション、アプリケーション、および周りにあるすべての静的変数が失われます。従来の asp または php を使用している場合、すべてのセッションとグローバル変数も失われます。
ヒット数のしきい値は少しやり過ぎです。無効にするか、巨大な数に設定する必要があります。よく思い出せば、既定では、要求がなければ IIS6 アプリケーション プールは 15 分ごとにリサイクルされます。また、アプリケーションが使用するメモリの合計にしきい値を設定して、リサイクルをトリガーすることもできます。
それはかなり正しいです。ある種のセッション ファーム、またはセッション情報のデータベース バッキングを使用しない場合、アプリケーション プールがリサイクルされると失われます。セッション情報を要求しないように努力することをお勧めします。これにより、基になる HTTP のステートレスな性質により密接にマップされるため、アプリケーションのスケーラビリティと信頼性が向上します。