c# - 非常に遅いパフォーマンス構造

Question

エラーがないので、ここでこの質問をするのが適切かどうかわかりません。そうでない場合は、適切なフォーラムを教えてください。ともかく...

私はソーシャル ネットワーク プロジェクトに取り組んでいますが、現在は実行が非常に遅く、一部のページの読み込みに 5 ～ 15 秒ほどかかります。「キャッシュ」構造がありますが、これを行った人は誰でもCache、c# .net から既にビルドするのに使用していませんでした。代わりにList<object> 、システムのキャッシュとして静的を作成しました。タフトでも大丈夫、私はそれを処理することができます...

問題は、すべてのページ要求で、これからユーザー データをロードする必要があることです。これcacheは非常に大きく、ユーザー構造も非常に大きいため、ページが要求されるたびにキャッシュからユーザー データをロードするのではなく、疑問に思っていました。写真、名前、ニックネーム、ID など、すべてのページで最も使用されるデータを使用していくつかのセッションを作成し、一般的ではないユーザーから他の種類のデータをロードする必要がある場合は、キャッシュから要求します。 ..

これが正しいアプローチであるかどうかはわかりませんが、これが質問するのに適切な場所であるかどうかはわかりませんが、この問題をかなりひどく解決する必要があります。ここで専門家からのアドバイスをお願いします。

Answer 1

パフォーマンスの問題の一部は、アイテムのキャッシュをスキャンする必要がある場合があります。キーでアイテムを取得できるので、辞書の方が良いかもしれません。これは、ネイティブキャッシュ構造に近い実装です。

セッションは、Webサイトのスケーラビリティに悪影響を及ぼします。これがFacebookか何かと同じくらい大きいことを計画しているなら、キャッシュのためにセッションを使うことはあなたを殺します

この他の関連する質問を参照してください：

大きな一時的な「セッション」データをWebアプリケーションに保存するための良い方法は何ですか

そして別のまともな質問

セッションを使用してトラフィックの多いWebサイトに状態を保存するのはなぜ悪い考えですか？

Answer 2

ジェイソンに同意 +1

あなたのコメントから、ユーザーオブジェクトにはキー（ID）があります。

キーがあれば、辞書の方がはるかに高速です。さらに、オブジェクトに Int32 として表現できる自然キーがある場合は、gethash と equals をオーバーライドします。10,000 に対するディクショナリ ルックアップはミリ秒である必要があります。

鍵付きのコレクションは、あなたが必要としているもののように聞こえます。キー付きコレクションでは、プロパティ (ID) の 1 つがキーになります。
鍵付きコレクション

これが静的リストである場合、データベースを介して辞書に移動します。単一のキー辞書があるため、データベースよりも優れています。複合キーの場合は、インデックス付きルックアップ用のデータベースを使用する必要があります。