实体框架的性能问题

本文关键字：问题 性能 框架 实体 | 更新日期: 2023-09-27 18:25:36

现有技术：

  • C#.NET 4.0
  • SQL Server 2014
  • 实体框架4.3.1
  • 代码优先
  • ANTS性能档案器7
  • SQL Server 2014事件探查器2
  • 谷歌搜索

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

使用SQL事件探查器，我可以看到插入的持续时间为（大约）0ms。这是意料之中的事。

使用ANTS Profiler，我可以看到DataContext.SaveChanges()正在进行（大约）1500ms。深入研究，这段时间中的99.9%是在SNINativeMethodWrapper.SNIReadSyncOverAsync内部度过的。

使用谷歌，很少有有用的结果（好吧，没有，因此这个问题）。很长一段时间以来，我第一次发现自己在谷歌搜索结果的第二页和第二页之外（未知的水域！）。

关于SO，有几个问题引用了这种方法，但来自不同的上下文：

  • sniredsyncoversync性能问题
  • sniredsyncoversync和waitforsingleobject阻塞ef性能

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

  • 将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调用（至少对于这几个条目）所需的时间没有那么长。

相关文章：