重新索引和自定义 IndexingProvider 时的 Sitecore 搜索性能

Question

我们使用 Sitecore 6.4，并使用共享源高级搜索模块，当 Sitecore 重新索引过程启动并将更改更新到 Web 数据库时，我们发现站点搜索性能大幅下降。

当我们开始完整的站点发布时，索引管理器会获取更改并处理历史记录，从而对每个受影响的项目重新建立索引。由于每个项目都会发生这种情况，因此您可以在查看目录时看到磁盘上的 Lucene 索引发生变化（文件数量在您观看时会增长和变化）。

如果发生这种情况时您尝试在公共网站上进行搜索，则搜索可能需要明显更长的时间才能完成；在重负载下，重新索引过程完成可能需要长达 15 秒的时间。

我可以看到这个过程是由 IndexingProvider 类控制的。有什么方法可以重写这个类并实现我们自己的类吗？

我们已经查看了搜索逻辑，可以看到每次请求搜索时都会创建一个 IndexSearchContext 对象，进而创建一个新的 IndexSearcher。我们更改了一些逻辑，以便将 IndexSearchContext 保留为单例，这当然意味着同一个 Lucene IndexSearcher 可以服务多个请求。这大大减少了内存消耗，因为建议使用相同的搜索器来提高性能。

然而，在执行此操作时，在创建新的 IndexSearcher 之前，不会拾取对索引的更改。我们需要一种方法来通知我们的代码索引过程已完成，然后我们可以重置我们的单例 IndexSearchContext 对象。我们如何将此逻辑集成到 Sitecore 配置代码中？

手动重建索引只需要大约 5 秒即可完成。显然，这有效地删除了索引，然后再次创建它，但是为什么逐项更新需要这么长时间？有没有更好的办法既可以做到不逐项更新又不影响公众网站？

我预计其他人也会受到这个问题的影响，所以我很想听听人们如何解决这个问题。

编辑 - 来自 Sitecore 论坛的附加信息

Sitecore.Search 代码似乎确实大量使用了为单个操作创建/处置新的 Lucene 对象。对于大型环境来说，它似乎没有过度的可扩展性，这就是为什么当我看到代码时我感到惊讶的原因。特别是当索引很大并且每天有大量内容更新/发布时。

通过 dotPeek 查看这些类，我看不到如何重写 IndexUpdateContext，因为它是在非虚拟方法中创建的。自定义 DatabaseCrawler 可以获得一些访问权限，但只能访问已创建的上下文对象。

我注意到我们可以在 web.config 中为每个索引定义我们自己的索引实现。我们还可以重新实现爬虫（我们已经从共享模块中安装了高级爬虫），并且也许可以对索引过程进行一些控制。我不愿意将太多的 Sitecore 代码提取到我们自己的实现中，因为它可能会影响未来的更新。

我有一个关于 IndexingProvider 的问题。在以下方法中：

private void UpdateItem(HistoryEntry entry, Database database)
    {
      int count = database.Indexes.Count;
      if (count != 0 || this.OnUpdateItem != null)
      {
        Item obj = database.GetItem(entry.ItemId, entry.ItemLanguage, entry.ItemVersion);
        if (obj != null)
        {
          if (this.OnUpdateItem != null)
            this.OnUpdateItem((object) this, (EventArgs) new SitecoreEventArgs("index:updateitem", new object[2]
            {
              (object) database,
              (object) obj
            }, new EventResult()));
          for (int index = 0; index < count; ++index)
            database.Indexes[index].UpdateItem(obj);
        }
      }
    }

它触发更新事件，该事件由 DatabaseCrawler 处理，因为它附加到 IndexingProvider.OnUpdateItem 事件；但是为什么上面的方法还调用了Sitecore.Data.Indexing.Index.UpdateItem方法呢？我认为命名空间在 6.5 版本中被贬值，所以我很惊讶地看到新旧命名空间之间的链接。

因此，看起来 DatabaseCrawler 正在处理更新，它会删除该项目，然后将其再次添加到索引中；然后旧的 Sitecore.Data.Indexing.Index 也尝试更新它。这里面肯定有什么问题吧？我不知道，所以如果我错了，请纠正我，这就是我在没有任何调试的情况下跟踪反编译代码时的样子。

Answer 1

我建议两件事：

1. 使用高级数据库爬虫 (v2 是最新版本），它覆盖了Sitecore.Search 命名空间。这使得将 Lucene.NET 与 Sitecore 结合使用变得非常容易。

2. 每天完全重建索​​引。这会对索引进行碎片整理，因为随着时间的推移，碎片会降低性能（这可能是您的问题）。

Answer 2

我以前也遇到过类似的问题。当我分析发生了什么时，所有时间都花在打开每次搜索的索引上。

我们最终解决这个问题的方法是绕过 Sitecore 的索引类并直接使用 Lucene。 Lucene 提供了“重新打开”方法，该方法仅打开修改后的段文件，而不是像 Sitecore 那样打开所有段文件。

所以我们所做的是：

1. 如果我们还没有索引阅读器，则打开索引阅读器
2. 创建对它的应用程序级别引用，以便我们可以重复使用它
3. 在每次搜索时，对应用程序索引阅读器调用“重新打开”
4. 搜索

看一下在 Lucene.Net.Index.IndexReader.Reopen 方法 文档

您可以从 Sitecore.Search.Index.CreateReader() 创建索引阅读器