ユーザー セッション固有のデータを保存して、ページの読み込みやそのセッション全体で保持したい従来の ASP アプリケーションの修正を継承しました。少し復習する必要があります。
過去に、私は単純にセッション変数を使用していました。Session("SomeVar") = SomeVal.
運用ボックスの IIS で、ASP / セッション プロパティ / セッション状態を有効にする = false に気付きました。これを True に設定すると、セッション変数の使用を正常に開始できました。
サーバーで必要以上のリソースを消費したくありません。以前は、従来の ASP のセッション変数がクライアント側に格納されているという妄想的な誤解をしていたと思います。これを今再検討します - データはサーバー側に保持されます。
保存している文字列は、約 3000 の接続クライアントの GUID です。
これを実装すると、どのようなサーバーへの影響が見られますか? また、クライアント側の Cookie を使用する方が適切でしょうか?
これを少し分析してみましょう。GUIDは文字列として約40文字を使用するため、Unicodeでは80バイトであり、100バイトと呼びます。100 * 3000=300KB。サーバーはこれのために300Kを節約できますか？答えがノーの場合、サーバーはすでに問題を抱えていると思います。
ただし、セッション状態を有効にする他の影響があります。セッションが有効になると、ASPは独自のCookieをクライアントに追加します。これは、サイズの観点から、GUIDをセッションではなくCookieとして保存する場合に必要となるCookieとおそらく同じです。Cookieに保存されているこのセッションIDは、より予測可能なアルゴリズムを使用していることに注意してください（私自身はその証拠を持っていません）。したがって、GUIDを何らかの形式の承認として使用している場合は、GUIDをCookieとして直接保存する方がよい場合があります。
セッション状態が有効になっている場合に発生するさらに重要な変更があります。クライアントからのASP要求はシリアルに処理する必要があり、サーバーは同じクライアントからの複数の要求を並列に処理しません。これは、Sessionオブジェクトがシングルスレッドであり、クライアントからの各要求がそれにアクセスする必要があるため、要求を同時に処理できないためです。
この最後の点は、特にAJAX技術、複数のIFrame、またはサーバーに同時にASP要求が送信される他の技術が使用されている場合に、クライアントが見る既存の動作とパフォーマンスに大きな影響を与える可能性があります。
したがって、私の選択の要件は、GUIDをCookieに保存し、セッション状態をオフのままにすることです。
複数のサーバー/サーバー ファーム? その場合、ロードバランサーが「スティッキー」に設定されておらず、毎回同じサーバーに送信されるように設定されていないと、Session を使用して問題が発生する可能性があります。デバッグするのは本当に頭が痛いので、気をつけてください。