2012-02-27 20 views
2

ViewStateがデフォルトでサーバーに保存されていない理由を誰かに教えてもらえますか?ViewStateがデフォルトでサーバーに保存されないのはなぜですか?

ViewStateの代わりに小さなセッショントークンを送信して、ViewState全体が複数回ポストバックされたり転送されたりするのを防ぐため、サーバー上に必要なViewState情報にマッピングできるようにしてください。

何か不足していますか?

答えて

2

メモリにViewStateを格納することには、いくつかの問題があります。

  1. アプリケーションがリサイクルされると、アプリケーションを使用するすべてのユーザーのVSが失われます。

  2. アプリケーションのメモリ消費量が増加します。サーバーにホストされているアプリがわずかしかない場合でも問題ありません。 1つのボックスに多数のWebサイトがホストされている場合があります。

  3. スケーラビリティ;アプリケーションをアクティブにするほどVSを格納する必要があります。そして、あなたは1-1(1ユーザー - 1 VS)を取ることはできません。ユーザーは複数のタブを開いたり、戻ったり、タブを非アクティブにしたりすることができます。

  4. どのくらいの期間VSを保存しますか?ページにエンコードされたデータを保持することで、ユーザーがサイトをしばらく開いたままにしておくと、そこにデータが残ることが保証されます。

  5. ウェブファームでホストされている場合はどうなりますか。ユーザーが各リクエストで同じマシンを使用することは保証できません。 - 店舗VSを分散メモリ内のMemcacheを使用して

    Memcached-Viewstate

言われていること、いくつかのソリューションがあります。これは理想的ではありません - サーバがVSをそのサーバに保存していた人のためにVSをダウンさせる場合、アプリケーションプールを問題なくリセットすることができます。

SQL-Viewstate - VSをSQLデータベースに格納します。これにより、要求ごとにDB読み取りとDB書き込みが少なくとも1つ追加されます。再度理想的ではありませんが、VSが管理不能になってデータベースからVSを設定するのがHTTP経由で送受信するよりも速いです。

Filesystem-Viewstate - VSをファイルシステムに格納します。 SQL接続よりも安価ですが、分散環境でファイルサーバーを使用する必要があります。

4

スケーラビリティ - 1Mのユーザーが複雑なWebフォームページを表示した場合に必要なサーバーリソースの量を想像してください。サーバーは少なくともセッションタイムアウトの期間ViewStateを保持する必要があります。ビューステートの自動サーバー側のクリーンアップも問題になります。ユーザーは複数のページを一度に表示しているため、すべてのページのViewStateを保持する必要があります。

編集 サーバーにビューステートを移動する方法についてthese postsで議論いくつかの手法があります。しかし、これを行う前に、必要のないコントロール/ページから不要なビューステートを削除することをお勧めします(たとえば、表示のみ/ポストバックなし)。

viewstateが10年ほど前に設計されたとき、32ビットサーバーの1GB RAMはそれほど良好で、MSはおそらく負荷100を望むプロバイダを考える必要があったサーバーごとに。したがって、帯域幅はおそらくサーバーのRAMとディスクストレージよりも安価であると見なされていました。

+0

ViewStateが(多くのユーザーがいても)サーバーのメモリの問題を引き起こすほど大きい場合、HTTP経由で送信しないでください。 – Flash

+0

ViewStateはページごとに 'インスタンス'が表示されます。たとえそれが1ページあたりわずか10kBで、1Mのユーザーで、各ユーザーが3ページ開いていても、サーバー上に30GBのRAMまたはディスクがあります。 – StuartLC

+0

万人の同時ユーザーは大変ですが、これに対処しているサーバーであれば、大量のRAMが必要になることがあります。 – Flash

0

サーバーがメモリ内のすべてを維持する必要がないため、スケーラビリティが向上します。 viewstateをセッションに格納することは可能ですが、一般的には推奨されません。

0

根本的な原因は、サーバーが現在のページの状態を認識していないということです。

ユーザーが気になる場合は、応答を待たずにページの複数の(部分的な)ポストバックを行います。ブラウザは複数の部分的なポストバック要求を送信し、各要求はサーバー側で新しいビュー状態を作成し、ブラウザの初期表示状態を解除します。最後に、ユーザは最後のポストバックを行い、その時点では元のコピーはなくなり、例外がスローされます。

また、サーバーのサイドビューの状態は、サーバーのパフォーマンスとユーザーエクスペリエンスに影響します。ユーザーが1日または長時間ページとやり取りしない場合、サーバー上のビューの状態は失効します。ユーザーが後でそのページをポストバックすると、例外がスローされます。

たとえば、私は長さ40分のYouTubeビデオを視聴します。昨日私は上半身を見て、タブを閉じずに私のコンピュータを借りていた。今日私は最後の半分を監視し続け、何かをポストバックします。ビューの状態がサーバーにあり、期限切れになっていると、ページはエラーになります。

関連する問題