4

Mauricoとcodekaが最初に述べたように、セッションがWebサイトの再コンパイルやアプリケーションのリサイクルの影響を受けないようにする場合は、デフォルトのInProcセッションを使用しないでください。

ウェブサイト全体が再コンパイルされる原因のリスト：

  1. デフォルトでは、Webサイトの最上位ファイルに変更が加えられると、サイト全体が再コンパイルされます。トップレベルファイルには、global.asaxファイルと、bin/およびApp_Code/フォルダー内のすべてのファイルが含まれます。

  2. web.configの変更

  3. SectionInformation.RestartOnExternalChangesプロパティがtrueの場合、構成にはファイルの変更が含まれます

    <section name = "MyAppSettings" type = "System.Configuration.AppSettingsSection、System.Configuration、Version = 2.0.0.0、Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a" restartOnExternalChanges = " true " requirePermission = "false" />

ノート：

参照：

Webサイトプロジェクト（Webアプリケーションプロジェクトではない）がそれ自体を再コンパイルする原因となる変更とファイルの種類を示す情報はどこにありますか？

私が尋ねている理由は、ユーザーがセッションを失ってほしくないからです。したがって、ライブWebサイトを更新可能な変更は、朝のごくわずかな時間にのみ更新したいと考えていますが、それらを迅速に処理するために、日中に変更を加えることをお勧めします。最初にステージングサーバーにプロモートしてそこで監視しますが、事前に決定的なリストがあれば便利です。

4

1 に答える 1

7

Webサイトが再コンパイルされるときだけでなく、IISワーカープロセスがリサイクルされるときにもセッションが失われます。技術的には、これはいつでも発生する可能性があります（最小化する方法はありますが、とにかくワーカープロセスのリサイクルに耐えられるアプリケーションを設計することを好みます）。したがって、セッションが重要な場合は、実際にそれらをアウトプロセスで保存する必要があります。 。

ASP.NETには、セッション状態を格納する単なるWindowsサービスである「状態サーバー」が組み込まれています。もう1つのオプションは、SQLServerセッション状態ストレージを使用することです。

多くの人がSQLServerにセッション状態を保存することはパフォーマンスの問題であると言うでしょうが、私は同意しません。プロセスのリサイクルによるセッションの喪失は、SQLServerのパフォーマンスよりも懸念事項です。さらに、ASP.NET状態サーバーは、それが本当に必要な場合は高速です（また、電源の入れ直しを乗り切りたい場合は、状態をNoSQLデータベースに格納するカスタムプロバイダーを作成することもできます）。

于 2010-04-12T23:39:04.017 に答える