9

状態を保存するためにセッションを大幅に利用するASP.NetMVCアプリケーションがあります（大規模なデータ収集を含む）。現在、単一のWebサーバーでホストされています。セッションはデフォルトのInProcに設定されています。

多くのユーザーがオンラインになっていると、一部のユーザーのアプリケーションがフリーズするという問題が発生します。これは、InProcセッションのスケーリングがあまり良くなく、プロセスで使用できるメモリが非常に多いためだと思います。（メモリ需要が使用可能なメモリを超えた場合はどうなりますか？ディスクにスワップアウトしますか？）

スケーラビリティに役立つソリューションをいくつか考えています。（a）SQLサーバーのセッション状態。（b）AppFabricキャッシングを使用するようにセッション状態を構成します。最初のオプションは、パフォーマンスに影響を与え、保存されたアイテムをシリアル化できるようにする必要があることを除けば、優れたソリューションのように見えます。

単一のWebサーバーがキャッシュホストとしても使用される環境でAppFabricキャッシング（別名Velocity）を使用するようにセッション状態を構成するのはどうですか？これは、この単一サーバー環境でのInProcとどのように異なりますか？これにより、InProcよりもスケーラビリティと使用可能なメモリが提供されますか、それとも基本的に同じ制約になりますか？

4

2 に答える 2

9

シナリオにAppFabricキャッシュを実装することをお勧めします。システムが大きくなるにつれて、新しいWebノードごとにキャッシュサーバーの数を増やすことができます。これは、追加コストなしではSQLServerでは簡単に実行できないことです。SQL Serverライセンスは、WindowsServerライセンスにバンドルされているAppFabricよりもはるかに高額です。

SQL Serverが提供する唯一の利点は回復可能性ですが、必要なものについては、おそらくやり過ぎです。

セッションについては、AppFabricCacheとSQLServerについて説明している関連するSOの投稿を参照してください。

AppFabricキャッシュとInProcの比較...

メモリの制限に直面している場合は、 AppFabricキャッシュを別のサーバーに配置できます。InProcではこれを行うことはできません。

AppFabricキャッシュのその他の利点は次のとおりです。

  1. ローカルキャッシュをサポートして、シリアル化/逆シリアル化に関連する取得コストを高速化します。
  2. キャッシュの削除および有効期限ポリシーに関して、よりきめ細かい制御を提供します。
  3. セッションコンテンツの圧縮をサポートして、ネットワーク帯域幅を削減します。
  4. 大きなオブジェクトのデータ取得を改善するためのBlobモードと単一アイテムの取得。
  5. 同じセッション状態ストアを複数のアプリケーションで使用できます（sharedIdを介して）。
于 2012-07-31T19:22:49.680 に答える
0

最も重要なことは、セッションがアプリプールのリサイクル、さらにはアプリケーションの再デプロイ後も存続することです。

また、AppFabricはIXmlSerializableオブジェクトをシリアル化することもできます[Serializable]。アウトオブプロセスのASP.NETセッションサービスを使用しようとすると、皮肉なことに、IXmlSerializableなどのオブジェクトをシリアル化できませんXElement。必要に応じて、完全にカスタマイズされたシリアル化を行うこともできます。AppFabricを使用すると、そのように移動した場合でも、アプリははるかに「Azure」に対応できます。

もちろん、必要に応じて他のデータをキャッシュするために使用できます。

于 2013-02-23T10:36:25.110 に答える