为什么 Orchard 在执行内容项查询时如此缓慢? [英] Why is Orchard so slow when executing a content item query?
问题描述
假设我想查询所有 Orchard 用户 ID,并且我还想包括那些已被删除(又名软删除)的用户.该数据库包含大约 1000 个用户.
Lets say i want to query all Orchard user IDs and i want to include those users that have been removed (aka soft deleted) also. The DB contains around 1000 users.
选项 A - 大约需要 2 分钟
Orchard.ContentManagement.IContentManager lContentManager = ...;
lContentManager
.Query<Orchard.Users.Models.UserPart, Orchard.Users.Models.UserPartRecord>(Orchard.ContentManagement.VersionOptions.AllVersions)
.List()
.Select(u => u.Id)
.ToList();
选项 B - 以几乎无法察觉的延迟
Orchard.Data.IRepository<Orchard.Users.Models.UserPartRecord> UserRepository = ...;
UserRepository .Fetch(u => true).Select(u => u.Id).ToList();
在使用选项 A 时,我没有看到在 SQL Profiler 中执行任何 SQL 查询.我猜这与 NHibernate 或缓存有关.
I don't see any SQL queries being executed in SQL Profiler when using Option A. I guess it has something to do with NHibernate or caching.
有没有办法优化选项A?
推荐答案
可能是因为 IContentManager
版本正在通过 InfoSet
访问数据(基本上是数据),而 IRepository
版本使用实际的数据库表本身.
Could it be because the IContentManager
version is accessing the data via InfoSet
(basically an xml representation of the data), where as the IRepository
version uses the actual DB table itself.
我似乎记得读过虽然 Infoset 在许多情况下很棒,但是当您通过排序/过滤处理更大的数据集时,直接转到表更有效,因为使用 Infoset 需要解析每个 xml 片段在获取数据之前提取的元素.
I seem to remember reading that though Infoset is great in many cases, when you're dealing with larger datasets with sorting / filtering it is more efficient to go direct to the table, as using Infoset requires each xml fragment to be parsed and elements extracted before you get to the data.
自转变"以来,Orchard 会同时使用这两种方法,因此您可以使用最适合您需求的方法.我现在找不到解释它的文章,但这解释了 shift &信息集非常好:
Since 'the shift', Orchard uses both so you can use whichever method best suits to your needs. I can't find the article that explained it now, but this explains the shift & infosets quite nicely:
希望对您有帮助吗?
这篇关于为什么 Orchard 在执行内容项查询时如此缓慢?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!