2

これが以前に尋ねられた場合は申し訳ありませんが、頭の中にある特定の質問をまだ見つけていません。

私が構築している Web サイト (ASP.NET MVC を使用) の場合、パフォーマンスは重要な機能です。また、アプリケーション プールが 20 分ごとに (またはメモリのしきい値に達した場合はそれよりも早く) リサイクルされる環境で、サイトがホストされる可能性があります。セッション変数に依存することから完全に独立し、代わりに GUID のような値を Cookie に保存したいと考えています。私の理由は、AppPool のリサイクルのためにセッションがどれくらい続くか分からず、セッションが途中でタイムアウトして繰り返しログインしなければならないことを望まないからです。

Cookie の GUID 値は、セッションに似た情報 (ユーザー ID 値など) を格納するテーブルへのルックアップ キーとして機能します。したがって、そのデータが必要な場合は、データベースから取得できます。Session_OnEnd イベントを使用して、「最後のアクティビティ」の値が 20 分以上前の行のセッション テーブルをクリアします (または、長いセッションが続くように構成されています)。したがって、セッション変数ではなく、セッション状態を引き続き使用すると思います。

繰り返しますが、私の懸念はパフォーマンスに関するものです。したがって、ユーザーが誰であるかを知り、サイトへのアクセスを「セッションのような」方法で管理する機能を維持しながら、セッション変数の使用を回避するためのより良い方法があるかどうかに興味がありました。私はまだ MVC の初心者ですが、長年にわたって ASP.NET で十分な経験を積んできたので、私の質問が理にかなっていることを願っています。

編集: SQL セッション状態を使用することを少しためらっています。共有 SQL サーバー ホスティング環境にいる可能性が高く、削除に必要な場合にジョブを作成/実行する機能を備えたログインを持っているとは思わないからです。 AppPool のリサイクル シナリオで Cookie を使用して Session_OnEnd に依存することに本当の欠点はありますか? AppPool のリサイクル時に現在のセッションに対して Session_OnEnd が実行されない可能性はありますか?

4

4 に答える 4

5

セッションは作業プロセスにのみ保存されると想定しています。SQL 状態セッションを持つことができます。先に進む前にこのリンクを確認してください。

于 2009-12-08T18:50:36.277 に答える
1

データベースを使用して、Web ファーム/ガーデン全体で「永続的な」永続性を提供することは、一般的な手法です。また、サーバーや再起動の際にセッション状態データを利用できるようにするために使用できる 分散キャッシュ システムもあります。

たとえば、私が見た分散システムの 1 つは、UDP を使用して複数のサーバー間でセッション データを共有しています。データはサーバーのメモリに保存されるため、分散キャッシュを使用するとパフォーマンスが向上すると予想されます。そのため、データベース ルックアップはありません。

于 2009-12-08T18:52:24.860 に答える
1

インプロセス状態を使用できない場合は、データベースである可能性が高い外部リポジトリに戻す必要があります。

では、セッション状態を DB に保存しないのはなぜでしょうか? そのための組み込みのサポートがあり、セッション状態が小さく保たれている場合に許容可能なパフォーマンスを維持しながら、リサイクルの問題を効果的に解決します。

于 2009-12-08T18:52:49.040 に答える
0

カスタム キャッシング メカニズムを調べます。あなたが言ったように、あなたのウェブサイトは負荷分散されるように聞こえるので、セッション変数を使用することはできませんか? アプリ プールからのリサイクルにより、セッションが変更される場合があります。また、View State のオーバーヘッドも必要ありません (これを使用できますが、パフォーマンスに影響します)。

キャッシングと他の前述のモデルとの間には、3 つの重要な違いがあります。

  1. キャッシングはスレッドセーフです
  2. キャッシュ内のアイテムは自動的に削除されます
  3. キャッシュ サポート依存関係のアイテム
于 2009-12-08T18:52:57.417 に答える