現在、データベースを使用して、ユーザーの状態情報を (別のテーブルに) 維持しています。ユーザーがアプリケーションにアクセスする (リクエストを送信する) たびにデータベースからその情報を取得し、リクエストの処理後にデータベースで更新します。
これは多くのプロジェクトで非常にうまく機能し、実装も非常に簡単ですが、データベースを呼び出して状態情報を保存するためのオーバーヘッドが追加されます。
この場合、よりうまく機能する他の方法はありますか?
現在、データベースを使用して、ユーザーの状態情報を (別のテーブルに) 維持しています。ユーザーがアプリケーションにアクセスする (リクエストを送信する) たびにデータベースからその情報を取得し、リクエストの処理後にデータベースで更新します。
これは多くのプロジェクトで非常にうまく機能し、実装も非常に簡単ですが、データベースを呼び出して状態情報を保存するためのオーバーヘッドが追加されます。
この場合、よりうまく機能する他の方法はありますか?
すぐに使用できるMS は、StateServer モードを提供します。これにより、1 つ以上の Web サーバーによって共有される単一のサーバー上のメモリにセッション データを格納できます。場合によっては (セッション状態の SQL Server に大きな負荷がかかっている場合)、これによりパフォーマンスが向上することがあります。
既定では、SQL Server セッション プロバイダーはアイテムごとにセッション アイテムをフェッチして保存します。セッションの使用が分かっていて、これが非効率的 (要求ごとに複数の項目を取得して保存する) と思われる場合は、要求の開始時にすべてのセッション項目を取得し、最後にそれらすべてを保存するカスタムSessionState ストア プロバイダーを SQL Server に実装できます。要求の。
その他のリソース:
戦略はいくらでもあります。あなたのセッションが安定していることを願っています (つまり、常に同じマシンにルーティングされている)。この場合、データをローカル (メモリ内) にキャッシュし、DB をバックアップ (「書き込み専用」) にのみ使用できます。さらに、分散キャッシュを提供するmemcachedのようなソリューションがあります。