实体框架5的性能问题

Question

现在我正在研究一个非常复杂的数据库.我们的对象模型旨在映射到数据库.我们将EF 5与POCO类一起使用,手动生成.

一切正常,但有些人抱怨表演.我从来没有遇到EF的性能问题,所以我想知道这次我是不是做了一件非常错误的事情,或者问题可能存在于其他地方.

主查询可以由动态参数组成.我有几个if和switch块在概念上是这样的:

if (parameter != null) { query = query.Where(c => c.Field == parameter); }

此外,对于一些复杂的和/或组合,我正在使用来自Albahari的LinqKit扩展.

该查询针对包含数年和数年的"订单"的大表.平均使用是2个月的范围过滤器.

现在,当组成主查询时,它将使用Skip/Take组合分页,其中Take设置为10个元素.

毕竟,IQueryable通过层发送,到达使用Automapper的MVC层.

在这里,当Automapper开始迭代(因此查询确实被执行)时,它会调用一堆导航属性,这些属性有自己的导航属性等等.根据EF建议,所有内容都设置为延迟加载,以避免在包含超过3或4个不同实体的情况下急切加载.我的场景是这样的:

• 订单(最多10个)
  • 订单下的许多导航属性
    • 其中一些还有其他导航(本地化实体)
  • 订单详情(每个订单的订单详情很多)
    • 每个订单细节下的许多导航属性
      • 其中一些还有其他导航(本地化实体)

对于单个呈现的"页面",这很容易导致总共300多个查询.这些查询中的每一个都非常快,在几毫秒内运行,但仍有两个主要问题:

• 延迟加载的属性按顺序调用而不是并行调用,因此需要更多时间
• 作为前一点的结果,每个查询之间存在一些死区时间,因为数据库必须接收sql,运行它,为每个查询返回等等.

只是为了看看它是怎么回事,我试着用急切的加载来制作相同的查询,正如我预测的那样,这是一场彻底的灾难,翻译的sql超过7K行(是的,七千)并且总体上更慢.

现在我不愿意认为EF和Linq不是这种情况的正确选择.有人说,如果他们要编写一个存储过程来获取所有需要的数据,那么它的运行速度将提高数十倍.我不相信这是真的,我们将失去所有相关实体的自动实现.

我想到了一些我可以做些改进的事情,比如:

• 表拆分以减少选定的列
• 关闭对象跟踪,因为此方案是只读的(具有未跟踪的实体)

尽管如此,主要的抱怨是结果页面(在MVC 4中完成)渲染速度太慢,经过一些诊断后,它似乎都是"服务器时间"而不是"网络时间",大概是从8到12服务器时间秒.

根据我的经验,这不应该发生.我想知道我是否以错误的方式接近这个查询需求,或者我是否必须将注意力转向别的东西(可能是一个配置不好的IIS服务器,或者其他任何我真的无能为力).有人说,数据库的索引还可以,我们的dba非常仔细地检查.

因此,如果有人有任何提示,建议,最佳实践,我对此缺失,或者只是可以告诉我,在这种情况下使用EF与延迟加载我是错误的...你们都欢迎.

Answer 1

需要考虑的一点是，EF 确实有助于缩短开发时间。但是，您必须记住，当您从数据库返回大量数据时，EF 正在使用动态 SQL。这意味着EF必须1.创建SQL，2.SQL Server然后需要创建执行计划。这发生在查询运行之前。

使用存储过程时，SQL Server 可以缓存执行计划（可以对其进行编辑以提高性能），这确实比使用 EF 更快。但是...您始终可以创建存储过程，然后从 EF 执行它。我会将任何复杂的过程或查询转换为存储过程，然后从 EF 调用。然后您可以看到您的性能增益并从那里重新评估。