asp.net - セッション変数に入れるもの

Question

私は最近、すべての DB データオブジェクトと DB 接続オブジェクトを含む、セッション変数に大量のものを入れる ASP 1.1 Web アプリケーションに出くわしました。途端に巨大化。Web セッションがタイムアウトすると (ユーザーがアプリケーションの使用を終了してから 4 時間後)、データベーストランザクションがロールバックされることがあります。これは、IIS がセッションを強制終了したときに DB 接続が適切に閉じられていないことが原因であると想定しています。

とにかく、私の質問はセッション変数に何を入れるべきですか? 明らかにいくつかのものがそこにある必要があります。ユーザーはメイン画面で編集するプランを選択するため、プラン ID がセッション変数に入ります。ユーザー（およびそのマネージャーなど）に関するすべての詳細と、ユーザーが編集している計画をセッション変数に保存することで、DB の負荷を軽減しようとする方がよいでしょうか、それともセッション変数の内容を最小限に抑えるように努めるべきでしょうか。 Page_Load イベントで必要なものすべてを DB に照会しますか?

score 6 · Accepted Answer

これは非常にアプリケーション固有であるため、答えるのがかなり難しいですが、私が使用するいくつかのガイドラインを次に示します。

セッションにはできるだけ入れないようにします。
特定の訪問中にのみ持続する必要があるユーザー固有の選択は、適切な選択です
多くの場合、ユーザーがサイトにアクセスしている間、複数のページからアクセスできるようにする必要のある変数 (ページからページへの変数の受け渡しを避けるため) も、セッションに入れるとよいでしょう。

あなたのアプリケーションについてあなたが少し言ったことから、私はおそらくデータベースからあなたのデータを選択し、セッションをロードするのではなく、それらのクエリの影響を最小限に抑える方法を見つけようとします.

score 5 · Accepted Answer

セッションにデータベース接続情報を入れないでください。

キャッシュに関しては、可能であればセッションをキャッシュに使用することは避けたいと思います。ユーザーが使用しているデータを他の誰かが変更するという問題が発生し、キャッシュされたデータをユーザー間で共有することもできません。ASP.NET キャッシュ、またはその他のキャッシュユーティリティ (Memcached や Velocity など) を使用します。

セッションに含まれるものに関しては、ユーザーがサイトに対して開いているすべてのブラウザーウィンドウに適用されるもの(ログイン、セキュリティ設定など) はすべてセッションに含まれている必要があります。表示/編集されているオブジェクトなどは、実際には画面間で渡される GET/POST 変数である必要があるため、ユーザーは複数のブラウザーウィンドウを使用してアプリケーションを操作できます (それを防ぎたくない場合)。

score 2 · Accepted Answer

UI オブジェクトをセッションに入れないでください。

それを超えて、私はそれが異なると思います。インプロセスセッションを使用していない場合、セッションが多すぎると速度が低下する可能性があります。これは、大量のシリアライズとプロバイダーの速度が必要になるためです。Cache と Session は慎重に慎重に使用する必要があります。あなたができる、または便利だからといって、ただセッションに入れないでください。座って、それが理にかなっているかどうかを分析してください。

score 1 · Accepted Answer

理想的には、ASP のセッションは、処理できる最小量のデータを格納する必要があります。システムリソース (特にデータベース接続) を開いたままにしているオブジェクトへの参照を格納すると、明らかにスケーラビリティが損なわれます。また、コミットされていないデータをセッション変数に保存することは、ほとんどの場合、悪い考えです。全体として、現在の実装は、セッションオブジェクトを乱用して、ステートレスと思われる環境でステートフルアプリケーションをシミュレートしようとしているように思えます。

非常に悪意がありますが、隠しフィールドを介して自動的に状態を管理する ASP.NET モデルにより、セッション変数に何かを保持する必要性の大部分が実際に排除されるはずです。

私の経験則では、アプリのスケーラビリティ (ユーザー数/ヒット数の点で) が高いほど、セッション状態を使用して回避できることは少なくなります。ただし、トレードオフがあります。ユーザーが同じデータに繰り返しアクセスし、通常、サイトを使用するたびにかなり長いセッションが発生する Web アプリケーションの場合、一部のキャッシュ (セッションオブジェクトで必要な場合) は、DB サーバーの負荷を軽減することで実際にスケーラビリティを向上させることができます。ここでの考え方は、バックエンド DB よりもプレゼンテーション層を構築する方がはるかに安価で複雑ではないということです。もちろん、すべての場合において、このアドバイスは適度に受け止めるべきであり、すべての状況に当てはまるわけではありませんが、かなり単純な社内 CRUD アプリの場合は、うまくいくはずです。

score 0 · Accepted Answer

ナビゲーションキューをセッションに保存するのは注意が必要です。同じユーザーが複数のウィンドウを開くことができ、変更が紛らわしい方法で伝播されます。DB接続は絶対に保存しないでください。ASP.NET が接続プールを維持します。独自の魔術に頼る必要はありません。短期間のものをキャッシュする必要があり、データセットのサイズが比較的小さい場合は、可能なオプションとして ViewState を検討してください (ページサイズにより多くのバルクをロードするという犠牲を払って)

score 0 · Accepted Answer

A: 1 人のユーザーのみに関連するデータです。IE: ユーザー名、ユーザー ID。せいぜいユーザーを表すオブジェクトです。場合によっては、URL 相対データ (誰かを連れて行く場所など) またはエラーメッセージスタックをセッションにプッシュすると便利です。

異なるユーザー間で共有する可能性がある場合は、アプリケーションストアまたはキャッシュを使用します。彼らははるかに優れています。

score 0 · Accepted Answer

以前、PHP セッションに関して非常によく似た質問がありました。基本的に、セッションは、複数のページ読み込みでアクセスする必要があるユーザー固有のデータを保存するのに最適な場所です。セッションは、データベース接続参照を格納するのに最適な場所ではありません。ある種の接続プーリングソフトウェアを使用するか、ページの読み込みごとに接続を開いたり閉じたりすることをお勧めします。セッション内のデータのキャッシュに関する限り、これはセッションデータの保存方法、必要なセキュリティの程度、およびデータがユーザー固有のものであるかどうかによって異なります。より良い方法は、データのキャッシュに別のものを使用することです。

score 0 · Accepted Answer

スティーブン、
あなたは「I」で始まる会社で、「BC」で始まるウェブサイトを持っていますか? これは、私が最初に .net で開発を始めたとき (そして若くて愚かだったとき) に行ったこととまったく同じように聞こえます。セッションとアプリケーションに考えられるすべてのものを詰め込みました。言うまでもなく、それは倍加悪いです。
一般に、セッションはできるだけ避けてください。確かに、シリアル化できないオブジェクト (データベース接続など) をそこに格納するべきではありませんが、大きなシリアル化可能なオブジェクトでさえ格納すべきではありません。オーバーヘッドが必要ないだけです。

score 0 · Accepted Answer

私はいつもセッションでほとんど情報を保持しませんでした。セッションは、高価なサーバーメモリリソースを使用します。セッションに保存する値が多すぎると、サーバーの負荷が増加し、最終的にサイトのパフォーマンスが低下します。負荷分散サーバーを使用すると、セッションの使用に問題が発生する可能性があります。したがって、私が行っているのは、最小限のセッションを使用するか、セッションをまったく使用せず、情報がそれほど重要でない場合は Cookie を使用し、隠しフィールドをより多く使用し、データベースセッションを使用することです。

asp.net - セッション変数に入れるもの

9 に答える 9

Related

Reference