0

私のウェブサイトで頻繁に使用されるテーブルがいくつかあります。たとえば、最大のものは、大量の静的データを保持しているロケーション テーブルです。そのため、ユーザーが私のウェブサイトにアクセスするたびに、これらの場所で検索を行います。約 150 万行を保持します。メモリ プロファイラーを使用してこのテーブルのサイズを調整したところ、メモリ内で約 500 MB になりました。最終的に、非常に迅速にアクセスする必要があるいくつかの静的テーブルがあり、それらは静的です。最後に、メモリ ダンプは最大 1.5 GB のメモリ使用量になります。大量のメモリを使用できる強力なサーバーを使用している間は、これは問題ではありません。しかし、私がその質問をすると、上級開発者やアーキテクチャーは、プロセスがそれほど多くのメモリを占有するべきではないので、プロジェクトを見直すべきだと言っています。しかし、すばやくアクセスする必要があるため、毎回 DB にクエリを実行したくありません。1 秒以内に応答する必要があります。それが、記憶が私にとって道のように見える理由です。より良いアドバイスはありますか？

私はasp.netとms SQL 2008を使用しています。現時点ではFramework 4.0ですが、すぐに4.5になります。私のWebサーバー上のIIS 7.5。

ご協力ありがとうございます。ありがとう。

4

2 に答える 2

1

プロセスは、このメモリ自体を保持するべきではありません。http サーバーは、プロセスを数 (千) 回並行して実行したい場合があり、問題が発生することはありません。これは、データがメモリ内にあってはならないということではありません。ほとんどの場合、すべての Google データはメモリ内にあります。ロード方法に注意する必要があります。

  1. データベース サーバーが正常であれば (そうあるべきです)、データが頻繁にアクセスされるか、適切なキャッシュ ポリシーが設定されていれば、実際にはデータがメモリに保持されます。これにより、多くの作業や奇妙なトリックをまったく行うことなく、適切なパフォーマンスが得られるはずです.
  2. memcachedを使用できます(これが Google のやり方です)。
  3. 特定のユースケースですばやくアクセスできるように設計されたカスタム形式のファイルにデータを保持し、メモリ マッピングを介してアクセスすることができます。
于 2012-10-10T11:12:40.740 に答える
0

本番環境では、大量の静的データを保持することはお勧めしません。あなたのシナリオでわかるように、データセットを正規化し、最小数の初期データセットを管理できます。

もう 1 つの方法は、ビルダーのようなデザイン パターンを使用して、オンデマンドで必要なものだけのデータ セットを構築することです。

このようなアプローチをとることで、不要なデータセットをメモリに保持することを避けることができます。必要なときに必要なものをロードします。ビルダーの基本的な考え方は [1] にあります。

[1].http://www.oodesign.com/builder-pattern.html

于 2012-10-10T11:25:38.140 に答える