0

多くの情報を持つユーザーのプロファイルを保持する必要があるWebアプリケーションを設計しています.明らかにデータベースからデータを読み取ります.

現在、私は自分のセッションにユーザー名を持っており、ユーザーの情報が必要になるたびに、セッションを読み取り、(データベースからデータを再度読み取る) プロファイル クラスのオブジェクトを作成して、ユーザーの情報を取得する必要があります。このような問題のベスト プラクティスですか? ?

4

4 に答える 4

1

一般に、「ベスト プラクティス」は、ユーザー プロファイル データをセッションで維持し、必要なすべての情報をデータベースから初めてロードすることです。

つまりProfile、http セッションでクラスのインスタンスを管理します (実装する必要がありますSerializable)。プロファイルは、より頻繁に使用されるすべての情報を保持する必要があります。

「セッションの読み取り」は、HashMap の読み取りに似ていることに注意してください (したがって、パフォーマンスの点で最小のコストがかかります)。のHttpSession有効期限が切れると、プロファイルはガベージ コレクションされます。

更新（コメントに基づく）：

アクティブなユーザーをカウント (または検索) するには (非アクティブなユーザーは他のすべてのユーザーです)、典型的な解決策はインターフェイスをProfile実装することです。HttpSessionBindingListenerがセッションにバインドProfileされると通知されるので、静的カウンター (たとえば、Profile クラスの静的属性) をインクリメントできます。Profile

于 2012-10-06T11:01:30.573 に答える
1

これは、パフォーマンスとメモリ消費の間の典型的なトレードオフです。高速なアプリケーションが必要な場合は、ユーザー プロファイル全体を HTTP セッションに保持しますが、サーバーに十分なメモリがあることを確認してください。

リソースの消費を低く抑えたい場合は、ユーザー ID のみをセッションに保存し、必要なときにデータベースからロードします。これにより、移行するデータが少なくなるため、クラスタリングも簡単になります。

妥当な妥協点は、後者のアプローチをキャッシュとともに使用することです。このようにして、使用頻度の高いユーザー (現在システムを使用している) はメモリに保持されますが、アイドル状態のユーザーや新しいページに頻繁にアクセスしないユーザーはキャッシュから一掃されます (キャッシュが HTTP セッションの数よりも小さいと仮定します)。

于 2012-10-06T11:21:03.747 に答える
1

Obe6 の回答に同意しました。プロファイルがセッションにない場合は、データソースから取得してセッションにアタッチすることをお勧めします。

セッションが無効になると、すべての情報がセッションから削除されます。これに関する IBM の優れた記事があります。 http://www.ibm.com/developerworks/websphere/library/bestpractices/store_objects_in_httpsession.html

于 2012-10-06T11:22:25.663 に答える
0

通常、セッションは、ユーザー プロファイル データを保持するのに十分な場所です。ここで話しているデータの量を定量化する必要があります。セッションごとに 5KB とすると、100 MB の RAM を使用して最大 20000 のユーザー プロファイルをメモリに格納できます。最大に基づいて、それに応じてヒープをJVMに割り当てることができます。サイトで予想されるアクティブなセッションの数。

これは 1 つの側面にすぎません。アプリ サーバーを追加してアプリをスケーリングする場合は、memcached などのプロセス外のキャッシュ/メモリ ストアにセッションを移動することも考えられます。

セッションに保持しているすべてのユーザー プロファイル データが各ページにレンダリングされない場合は、セッションで最小限のデータのみを保持し、必要に応じて他のデータを取得することをお勧めします。

于 2012-10-06T12:45:16.037 に答える