8

何千ものレコードのデータをデータ テーブルに保存し、ポストバックで維持する必要があります。ビューステート（私が使用したもの）またはセッションに適したオプションはどれですか。ビューステートを使用すると、それを保存するための隠しフィールドが作成され、ページの読み込みが遅くなります。したがって、セッションに保存する際のオーバーヘッド（サーバー側のメモリ消費と応答の遅延）があります。解決策を教えてください

4

1 に答える 1

13

大量のデータの場合、Session の方が効率的です。ユーザーが特定のデータ ブロックの処理を完了したことを検出できる場合は、Session 変数を null に設定して、メモリ オーバーヘッドを軽減します。常にこれを行うことはできませんが、セッションは最終的に期限切れになり、メモリは再利用されます。セッション タイムアウトを下げると一部は改善される場合がありますが、設定が小さすぎないようにしてください。ユーザーを遮断したくないからです。Web.config ファイルでセッションを有効にする必要があります。

Session と ViewState の基本的なガイドラインは次のとおりです。

ViewState: ViewState のバイナリ データ構造は、Base64 でエンコードされてページに配置されます。つまり、元のバイナリ データのサイズの 1.3333 倍 (8/6) になります。このデータは、ページ ビューごとにアップロードおよびダウンロードされます。したがって、ViewState に多くの情報がある場合、ページの応答時間に影響します。Base64 エンコーディングはおそらく高度に最適化されているため、パフォーマンスへの影響はありません。各ページ要求は、ViewState のスペースを割り当ててから解放するため、長期的なメモリ ヒットではありません。データはページ内にあるため、有効期限はありません。

セッション: セッション内のすべてのデータは、ページのロード間で Web サーバーに保持されます。これにより、ページが小さく保たれ、セッション識別子のみを保持する必要があります。欠点として、セッションにデータを格納するために使用されるメモリは、セッションの有効期限が切れるまで割り当てられたままになります。セッションがバイナリ データをコピーするのか、それともポインターを保持するだけなのか疑問に思いました。Base64 エンコーディングと同様に、これは高度に最適化できるため、発生してもパフォーマンスに影響はありません。ユーザーがページ ビュー間で長時間待機すると、セッションが期限切れになることがあります。セッションが期限切れになった場合、ユーザーを Web ページの既知の状態に戻す必要があります。

ここでのもう 1 つの問題は、セッションに情報を保存している場合、セッション ID がクライアント ブラウザーの複数のタブ間で共有される可能性があることです。セッションに保存されたデータの使用方法に注意する必要があります。ユーザーが予期しない結果を得ないように、必ずこれをテストしてください。

(注: ViewState の使用は RESTful ですが、Session はそうではありません。)

于 2012-11-17T08:13:16.570 に答える