セッション変数に何を入れるか

https://stackoverflow.com/questions/77960

09-06-2019
|

質問

最近、セッション変数にすべての DB データオブジェクトや DB 接続オブジェクトさえも含めた大量のものを配置する ASP 1.1 Web アプリケーションに遭遇しました。それは結局巨大になります。Web セッションがタイムアウトすると (ユーザーがアプリケーションの使用を終了してから 4 時間後)、データベーストランザクションがロールバックされることがあります。これは、IIS がセッションを強制終了するときに DB 接続が適切に閉じられていないためだと思います。

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

解決

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

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

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

他のヒント

するないデータベース接続情報をセッションに入れます。

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

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

しないでください UI オブジェクトをセッションに置きます。

それを超えると、それは異なると思います。インプロセスセッションを使用していない場合、大量のシリアル化とプロバイダーの速度が必要になるため、セッション内での処理が多すぎると速度が低下する可能性があります。キャッシュとセッションは慎重かつ控えめに使用する必要があります。セッションができる、または便利だからという理由だけでセッションを開始しないでください。座って、それが理にかなっているかどうかを分析してください。

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

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

私の経験則では、アプリのスケーラビリティ (ユーザー/ヒット数の点で) が高くなるほど、セッション状態を使用しなくても済むようになります。ただし、トレードオフもあります。ユーザーが同じデータに繰り返しアクセスし、通常、サイトの使用ごとにかなり長いセッションが必要な Web アプリケーションの場合、(セッションオブジェクトで必要な場合に) キャッシュを行うと、DB サーバーの負荷が軽減され、実際にスケーラビリティに役立ちます。ここでの考え方は、プレゼンテーション層をファームする方が、バックエンド DB よりもはるかに安価で複雑さが少ないということです。もちろん、何事においても、このアドバイスは適度に取り入れる必要があり、すべての状況に当てはまるわけではありませんが、非常に単純な社内 CRUD アプリの場合は十分に役立つはずです。

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

ナビゲーションキューをセッションに保存するのは難しいです。同じユーザーが複数のウィンドウを開いている場合、変更は混乱を招く形で反映されます。DB 接続は次のとおりです。 絶対に 保管されないこと。ASP.NET は接続プールを維持するため、独自の魔術に頼る必要はありません。短期間キャッシュする必要があり、データセットのサイズが比較的小さい場合は、可能なオプションとして ViewState を検討してください (ページサイズに大量に読み込むことになります)。

答え:1 人のユーザーのみに関連するデータ。IE:ユーザー名、ユーザーID。で ほとんど ユーザーを表すオブジェクト。場合によっては、URL 相対データ (誰かを連れて行く場所など) やエラーメッセージスタックがセッションにプッシュするのに役立つことがあります。

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

スティーブン
「I」で始まる会社、「BC」で始まるウェブサイトを運営している会社で働いていますか?これは、私が初めて .net で開発を始めたとき (まだ若くて愚かだったとき) にやったこととまったく同じように思えます -- 考えられるすべてをセッションとアプリケーションに詰め込みました。言うまでもなく、それは二重に良くありませんでした。
一般に、セッションは可能な限り避けてください。確かに、シリアル化不可能なオブジェクト (データベース接続など) をそこに保存すべきではありませんが、大きなシリアル化可能なオブジェクトであっても、同様に保存すべきではありません。オーバーヘッドは望ましくないだけです。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow