.net 使用nHibernate选择具有多个子集合的实体时性能不佳

当我试图从数据库加载~7700条记录时，我正在使用的系统出现性能问题。与使用SqlDataReader的相同查询相比，NHB的加载时间要长10倍。显然，使用NHB会有一些性能开销，但与ADO.NET相比，时间是前者的10倍似乎太多了。据我所知，NHB是一个问题，特别是它如何处理挂起实体的集合

当我们试图加载大量的实体时，当实体本身有大量的集合挂在它们上面时，我们的系统中就有这个普遍的问题

我希望有人能就我如何改进这个问题提供一些建议

查询很简单

var employees = session.QueryOver<Employee>().List();

下面是执行1000次的5个测试的平均计时。当我创建/处置NHB会话时，计时开始/停止，它不包括会话工厂的创建

00:00:00.7080910 - 7677 records loaded/entity instantiation/manual map using ADO.NET
00:00:01.6055084 - 7677 entities - session - Fields Only
00:00:01.7866198 - 7677 entities - session - Fields + 1-1 Relationships
00:00:11.3384154 - 7677 entities - session - Fields + 1-1 Relationships + 1-* Relationships
00:00:10.9083002 - 7677 entities - stateless session - Fields + 1-1 Relationships + 1-* Relationships

需要明确的是，这不是DB/网络/延迟抓取问题。国际海事组织的问题似乎在于国家公路局如何为这些实体提供水合物

编辑：即使fNHB映射指定了缓存，它也在会话工厂中被禁用。我明确地从映射文件中删除了它们以进行验证，并且持续时间保持不变

我还使用了ANTS来分析代码，似乎大部分时间都花在TwoPhaseLoad.InitializeEntity上。忽略下面未显示的其他50%的时间。它的nHibernates会话工厂，这不是性能问题的原因

环境：

---

nHibernate 3.3.1.4000、FNHbernate 1.3.0.733、MS SQL Server 2008、c 4.0、Windows 7-64。

编写查询时，必须将.FetchManyFunc lambda nHibernate扩展包含到IQueryable

例如，如果查询具有条形图的一对多foo：

class Foo 
{
    IList<Bar> Bars
}

而不是

session.Query.ToList；全部

你应该写

session.Query.FetchMany src=>src.bar.ToList

---

这将告诉nhibernate在每一行上获取join而不是fetch select。

我猜这与缓存有关，您使用的缓存提供程序是什么？当然，ADO.NET没有生成缓存密钥和检查缓存的开销。86个1-*关系是一个很高的数字。@JamieIde不，不是缓存。我应该这么说。尽管我们的fNHB映射包含缓存项，但会话工厂通常是在禁用缓存的情况下创建的，我们发现二级缓存在我们的应用程序中导致了严重的性能问题application@JamieIde也许86个1-*关系对NHB来说太难处理了，如果是这样的话，我也无能为力。不过我希望看到一些具体的东西，因为似乎很少有关于多少就是太多的信息。它会增加线性吗？那么，如果只添加11-*个集合，那么时间是什么呢？是的，Employee可能是核心实体之一，但我认为@Firo是在询问是否所有从Employee派生的集合都是必要的。最好只映射应用程序实际需要的关系，并小心地正确识别根聚合并相应地对关系建模。仅仅因为关系可以在事物的C端建模并不意味着它应该被建模。请阅读问题。这不是问题所在。我特别指出，也没有出现Select n+1/延迟抓取问题

class Foo 
{
    IList<Bar> Bars
}