NHibernate Profiler 中的查询持续时间
我有一个 ASP .Net MVC 应用程序,它使用 Fluent NHibernate 访问 Oracle 数据库。我还使用 NHibernate Profiler 来监视 NHibernate 生成的查询。我有一个非常简单的查询(从具有 4 个字符串列的表中选择所有行)。它用于创建 CSV 格式的报告。我的问题是查询运行时间很长,我想更深入地了解 nhprof 显示的持续时间。对于 65.000 行,需要 10-20 秒,尽管“仅数据库”持续时间仅显示大约 20 毫秒。这次网络延迟应该不会很大,因为服务器位于同一个千兆位 LAN 上。我不希望人们能够准确地为我指出瓶颈在哪里,但我想知道的是有关如何在 NHibernate Profiler 中读取持续时间测量值的更多详细信息。
“仅数据库”部分包含哪些内容,“总时间”部分包含哪些内容?总时间是否还包括填充 C# 对象后完成的处理,因此该时间实际上是整个 http 请求的时间?了解更多这件事有望使我能够消除一些因素。
NHibernate 映射类如下所示:
Table("V_TICKET_DETAILS");
CompositeId()
.KeyProperty(x => x.TicketId, "TICKET_ID")
.KeyProperty(x => x.Key, "COLUMN_NAME")
.KeyProperty(x => x.Parent, "PARENT_NAME");
Map(x => x.Value, "COLUMN_VALUE");
nh profiler 生成的查询如下所示:
SELECT this_.TICKET_ID as TICKET1_35_0_,
this_.COLUMN_NAME as COLUMN2_35_0_,
this_.PARENT_NAME as PARENT3_35_0_,
this_.COLUMN_VALUE as COLUMN4_35_0_
FROM V_TICKET_DETAILS this_
视图非常简单,仅在 2 位整数上连接两个表。
我绝不是数据库专家,因此我很高兴收到所有能为我指明正确方向的评论。
I have an ASP .Net MVC application which uses Fluent NHibernate to access an oracle database. I also use NHibernate Profiler for monitoring the queries generated by NHibernate. I have one query which is really simple (selecting all rows from a table with 4 string columns). It is used for creating a report in CSV format. My problem is that the query is taking very long to run, and I would like to get a bit more insight into the durations displayed by nhprof. With 65.000 rows, it is taking 10-20 seconds, even though the "Database only" duration only shows something like 20 ms. Network lag should not make out a lot of this time, because the servers are on the same gigabit LAN. I don't expect people to be able to pinpoint for me exactly where the bottleneck is, but what I would like to know is some more details about how to read the duration measurements in NHibernate profiler.
What is included in the "Database only" part, and what is included in the "Total time"? Does the total time also include the processing done after populating the C# objects, so that this time is actually for the entire http request? Knowing more about this would hopefully make me able to eliminate some factors.
This what the NHibernate mapping class looks like:
Table("V_TICKET_DETAILS");
CompositeId()
.KeyProperty(x => x.TicketId, "TICKET_ID")
.KeyProperty(x => x.Key, "COLUMN_NAME")
.KeyProperty(x => x.Parent, "PARENT_NAME");
Map(x => x.Value, "COLUMN_VALUE");
And the query generated by nh profiler is like this:
SELECT this_.TICKET_ID as TICKET1_35_0_,
this_.COLUMN_NAME as COLUMN2_35_0_,
this_.PARENT_NAME as PARENT3_35_0_,
this_.COLUMN_VALUE as COLUMN4_35_0_
FROM V_TICKET_DETAILS this_
The view is really simple, only joining two tables on a 2-digit integer.
I am by no means a database expert, so I would be happy for all comments that would point me in the correct direction.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
总时间仅用于调用 nHib 查询。
但是,除了数据库中的时间之外,它还包括 nHib 填充实体(水合作用)所需的时间。这很可能就是你的罪魁祸首。
我遇到过类似的问题,也许其中的一些建议可能对您有帮助。
底线是 nHib 并不是真正打算加载大型数据集。
如果我得到的建议都没有帮助到您,我会提出以下建议:
1. 您的用户不太可能需要同时查看 65,000 行数据。也许您可以找到一种方法来过滤数据,以便结果集更小(并且更易读)。
2. 否则 - 如果正如您所说,这是仅在生成报告时发生的“特殊”情况 - 您不必使用 nHib。你可以只使用,比如说,好的 ol' ADO.Net 类......
The total time is for the call to the nHib query only.
However, it includes, in addition to the time in the db, the time it takes nHib to populate your entities (hydration). and that's likely your culprit.
I've had a similar problem, perhaps some of the suggestions there may help you.
The bottom line is that nHib is not really intended to load large datasets.
If none of the suggestions I got helped you, I would suggest a couple of things:
1. It's unlikely that your user needs to view 65,000 rows of data at the same time. perhaps you can find a way to filter the data so that the result set is smaller (and more readable).
2. otherwise- if it's, as you say, an 'special' case that only occurs when you generate a report- you don't have to use nHib. you can just use, say, good ol' ADO.Net classes...
还有用于此类情况的 IStatelessSession。它没有会话缓存,可以节省大量工作。应该会快很多。
there is also
IStatelessSession
which is intended for such situations. It doesnt have a session cache and saves a lot of work. It should be a lot faster.