8

クエリ/アプリケーションのパフォーマンスを向上させるためにビューを事前に生成する、比較的大きな Entity Framework モデル (約 300 テーブル) があります。

アプリケーションの負荷が最小の場合、アプリケーション内のメモリ消費量が 6 ～ 7 時間かけて徐々に増加します。約に達すると。4GB の場合、アプリケーション プールがリセットされ、プロセスが繰り返されます。

ここに画像の説明を入力

図 1: 8 ～ 9 時間にわたるアプリケーションのメモリ消費量を示す

このアプリケーションはリポジトリ パターンのバリエーションを使用し、ObjectContext のインスタンスがトランザクションごとに実現可能な最短時間で再インスタンス化および破棄されるようにします。また、リソースをクリーンアップするために、すべてのリポジトリ/インターフェイスに IDisposable を実装しています。

Red Gate の ANTS プロファイル、WinDbg などのメモリ プロファイラーを使用してアプリケーションで広範なテストを実行しましたが、これまでメモリの問題の正確な原因を特定できませんでしたが、次の点に注意しました。

Red Gate ANTS プロファイラー テストは、作成されている Entity Framework MetadataWorkspace が多すぎることを示しており、多くの余分なオブジェクト マッピングと関連する SQL コマンド テキストが保持されています。また、MetadataWorkspace を含む特定のリポジトリに myEntities の単一のインスタンスがあり、InitializerMetadata キャッシュには、ストレス テストの最後に 351 のエントリが含まれています。これらの 351 のエントリにはそれぞれ myEntities の別のコピーがあり、それぞれに MetadataWorkspace があり、それぞれに何百ものオブジェクト マッピングがあります。

私のコアソリューションは次のように構成されています。

  • プレゼンテーション - ASP.NET MVC 3
  • ビジネス - オブジェクト、ViewModel、インターフェイス
  • インフラストラクチャ - エンティティ フレームワーク モデル
  • データ アクセス - ADO.NET ダイレクト データ アクセス

誰かが何か指針を提供できるなら、私はとても感謝しています。

4

2 に答える 2

3

問題はEFであると自動的に想定しています。できる、できない。データアクセスインフラだけでなく、気をつけなければならない点がたくさんあります。

データアクセスが発行され、EF のみを使用しているため、簡単な.AsNoTracking()方法で迅速に改善できます。コンテキスト プールの管理に役立つServiceLocatorを採用します。

ReadOnly の状況では、EF の代わりにDapperを使用することもできます。

最後になりましたが、より複雑なクエリと最速の実行のために、純粋な ADO.NET を使用してください。

ActionFilterをリファクタリングして、すべてのコントローラーが継承する「BaseController」を使用しないようにすることも良い方法です。

.Dispose(bool)パターンを採用して、IDisposable クラスが本当に CG によって抑制されているかどうかを確認します。

アプリケーション プールのリサイクルによってのみ解放されるキャッシュ変数を永遠に保持しないようにしてください。

これは単なるヒントですが、コードへのアクセス権を持つあなたには大変な作業が伴います。:)

幸運を！

于 2014-10-31T17:04:00.080 に答える
0

セッションにプロキシ エンティティが保存されているかどうかを確認します。一方、 で明示的 Dispose()に呼び出す必要はありませんDbContext。これをチェックしてくださいhttp://blog.jongallant.com/2012/10/do-i-have-to-call-dispose-on-dbcontext.html#.U6WdzrGEeTw

于 2015-02-20T15:53:42.753 に答える