c# – 实体框架的性能问题

2023年5月21日 194次阅读

手头的技术：

> C#.NET 4.0
> SQL Server 2014
>实体框架4.3.1
>代码优先
> ANTS Performance Profiler 7
> SQL Server 2014 Profiler 2
>谷歌搜索

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

使用SQL事件探查器,我可以看到插入的持续时间(大约)为0毫秒.这是预期的.

使用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;

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

最佳答案 正如评论中所建议的那样：

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

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

点赞