3

Web アプリケーションを介して実行されるEF クエリと、Profiler によって生成された T-SQL を直接 SQL クエリ ウィンドウに実行する間に、パフォーマンス測定の問題があります。

以下は、Web アプリケーションを介して実行される私の EF クエリです。

IEnumerable<application> _entityList = context.applications
                    .Include(context.indb_generalInfo.EntitySet.Name)
                    .Include(context.setup_budget.EntitySet.Name)
                    .Include(context.setup_committee.EntitySet.Name)
                    .Include(context.setup_fund.EntitySet.Name)
                    .Include(context.setup_appStatus.EntitySet.Name)
                    .Include(context.appSancAdvices.EntitySet.Name)
                    .Where(e => e.indb_generalInfo != null);

                if (isIFL != null)
                    _entityList = _entityList.Where(e => e.app_isIFL == isIFL);

                int _entityCount = _entityList.Count(); // hits the database server at this line

上記の EF クエリを SQL プロファイラーでトレースすると、実行に約221'095 ミリ秒かかったことがわかります。(アプリケーション テーブルには 30,000 以上、indb_generalInfo には 11,000 以上、appSancAdvices には 30,000 以上のレコードがあります)。

ただし、Profiler から T-SQL をコピーしてクエリ ウィンドウから直接実行すると、約4,000 ミリ秒しかかかりません。

なぜそうなのですか？

4

4 に答える 4

6

このクエリの毒は最初の単語にあります: IEnumerable<application>. varそれを(ie )で置き換えるとIQueryable、クエリは最後のCount(). 転送されるデータの量がほとんどゼロになるため、これにはかなりの時間がかかります。

Includeさらに、bobek が既に述べたように、アイテムを数えるだけなので sは必要ありませんcontext.applications。

それとは別に、Entity Framework のような ORM を使用することのオーバーヘッドに常に気付くでしょう。

于 2013-07-04T15:00:04.330 に答える
0

EF には、パフォーマンスの点で間違いなくコストがかかります。しかし、複雑な TSQL に storedprocs を使用する柔軟性も提供します。しかし、私の意見では、それはあなたの最後の手段であるべきです。

于 2013-07-04T14:57:35.580 に答える
0

これは、EF が最初にコードを TSQL に変換する必要があり、これもコストがかかるためです。このリンクを見てください: http://peterkellner.net/2009/05/06/linq-to-sql-slow-performance-compilequery-critical/ LINQ をコンパイルできるようになり、速度が向上するはずです。また、このクエリにそんなに多くのテーブルが本当に必要ですか? たぶん、それをフィルタリングして、必要なものだけを引き出す方法を考えることができますか?

于 2013-07-04T14:36:38.560 に答える