实体框架的性能问题

Question

手头的技术：

• C＃.NET 4.0
• SQL Server 2014
• 实体框架4.3.1
• Code First
• ANTS Performance Profiler 7
• SQL Server 2014 Profiler 2
• Google搜索

问题：
我正在做一些软件的性能工作。有一个特殊的问题会导致严重的减速。如果 EF DataContext包含大约43个ADDED个实体，那么DataContext.SaveChanges()方法会占用大量时间。

使用 SQL事件探查器我可以看到插入的持续时间为（约）0ms。这是预期的。

使用 ANTS Profiler 我可以看到DataContext.SaveChanges()拍摄（约） 1,500ms 。深入研究，此时99.9%花费在SNINativeMethodWrapper.SNIReadSyncOverAsync内。

使用谷歌，很少有用的结果（没有，因此这个问题）。很长一段时间以来，我第一次发现自己正在研究Google结果的第2页及其后（未知的水域！）。

有几个关于SO的问题引用了这种方法，但是来自不同的背景：

• snireadsyncoverasync-performance-issue
• snireadsyncoverasync-and-waitforsingleobject-blocking-ef-performance

我正在寻找一种不需要任何解决方案的解决方案：

• 将EF升级到V6 +（或任何其他版本）
• 离开CodeFirst
• 不使用DataContext.SaveChanges（）
• 重新设计软件

我应该补充说我已禁用以下EF设置。这总体上具有积极影响（如预期的那样），但对问题域没有影响。

• Context.Configuration.ValidateOnSaveEnabled = false;
• Context.Configuration.AutoDetectChangesEnabled = false;

问题：
任何人都可以建议可以解决或避免此问题的代码更改吗？

Answer 1

正如评论中所建议的那样：

实际上，对于dbcontext中的这几个条目（怀疑不是环境DbContext），我不认为手头的问题实际上是对数据库的插入/显示更改，但实际上数据库调用本身（如创建连接，验证）这是此性能损失的主要问题。我实际上可以想象连接池会提高性能。

对于这些感兴趣的人：每一个＆＃34;实际＆＃34; Db调用（即不是查询准备，但实际上是将数据读取/写入数据库），如果给出连接字符串/数据库名称，EF将首先建立连接，或者使用DbContext中给出的连接（Connection，bool contextOwnsConnection） = true）上下文构造函数的重载。每次实际调用数据库的查询都会发生这种情况。对于某些数据库，这种连接的建立可能需要相当多的时间，而循环通过上下文实体并根据状态发出DELETE / UPDATE / INSERT调用应该采取（至少对于这些少数条目）没有那么多时间