8

在我当前的项目中，我有一个一般要求，即使现有的 XPage 应用程序更快。我们看到的一件事是如何加快一些较慢的预先输入字段，而对此似乎很快的一种解决方案是使用 FTSearch 而不是我们最初拥有的 DBColumn 来实现它。我想就这是否是一种可行的方法获得建议，或者是否有任何建议可以以不同的方式做我们需要的事情。

背景：虽然影响速度的因素有很多（如网络延迟、服务器操作系统、可用服务器内存等），但由于我们使用的是 8.5.3，但我们在总体上尽可能地优化了应用程序，利用使用 IBM Toolkit 来查找问题区域，并使用 IBM 在 8.5.3 中添加的功能来帮助解决此问题（例如，部分执行，使用优化的 JS 和 CSS 选项等）。不幸的是，我们又被困在运行在 32 位 Windows 操作系统和 3.5Gb 内存的服务器上几个月。

响应最慢的元素之一是在某些引用大量文档的提前输入中。最差的情况平均在建议的列表出现之前大约 5 或 6 秒出现在启用预先输入的字段中。它使用 SSJS 调用 java 类以执行 dbcolumn 调用（使用 Ferry Kranenburg 的 XPages Snippet）以从视图中获取唯一列表，然后返回 SSJS，它循环遍历数组以检查每个条目是否包含搜索键值，并且如果找到，它会在单词中的搜索文本周围添加一个突出显示（粗体）的 html 标记，然后将格式化列表返回给浏览器。我添加了一个打印语句来输出运行代码所用的时间，今天在我们的开发服务器上平均大约是 3250 毫秒。

我尝试了一些方法来了解如何让这个过程更快：

  1. 添加了一个 Java 类来执行所有处理（因此不使用 SSJS）。这只平均节省了 100 毫秒。

  2. 使用视图范围的托管 Bean，我在加载页面时将唯一的查找列表加载到内存中。这会产生非常快的预先输入响应（16 毫秒），但我怀疑这是对大型数据集执行此操作的一种非常糟糕的方法 - 如果多个用户正在访问应用程序，可能会真正影响通用服务器。我试图找到关于什么会被认为是一个大对象的信息，但找不到任何关于在内存中存储多少太多的指导或建议（我搜索了 JSF 和 XPage 站点）。有人对此有什么建议吗？

  3. 仍然在 Java 类中 - 我没有执行 dblookup 来获取要搜索的所有值的“列表”，而是让代码运行 FT Search 来获取文档集合，然后循环每个文档以提取我想要的字段值和将它们添加到“SortedSet”（自动不允许重复），然后循环排序集以在搜索词周围插入粗体标签，并将其返回给浏览器。这平均需要 100 毫秒 - 这很棒而且几乎不引人注意。这种方法是否有缺点 - 或者我不应该这样做的原因？

感谢您对此的任何反馈或建议。帕姆。

2013 年 8 月 14 日更新：我尝试了另一种方法（受OpenNtf上的 IBM/Tony McGuckin Insights 应用程序的启发）作为 Company Search type-ahead，它使用托管 bean 并且可以快速处理大量数据。

4. 尽管 Insights 应用程序处理跨多个数据库拆分的数据，但预输入的原理是相似的。我不能使用带有 getAllEntriesByKey 的视图，因为我也需要在文本中搜索字符串，而不仅仅是在条目的开头。我尝试基于视图 FTSearch 创建 ViewEntryCollection，但由于列中有很多重复名称，这并没有给出我想要的唯一列表。然后我尝试在分类视图上使用 NotesViewNavigator，并循环浏览它。这产生了我需要的唯一列表，但结果证明它比上述任何其他方法都慢。（我确实实现了这些ViewNavigator 性能提示）。

4

3 回答 3

4

从我的角度来看，性能可能会受到每个 Domino 应用程序（不仅是 XPages）所包含的许多层的影响。从顶部 - 浏览器（DOM、JS、CSS、HTML...）、网络（延迟、DNS、SSO...）到应用层（有效算法、缓存）、数据库/API（数据量、索引、阅读器名称） ...）和操作系统/硬件（磁盘、内存...）

根据您测试的内容：

  1. 这很有趣，但可以预料到：SSJS 被缓存并且可能使用较低级别的 API 来获取数据 (NAPI)。
  2. 对于您的环境（32 位/3.5G RAM - 我希望您关于 3.5M 的陈述是错字）我不建议缓存大列表，特别是如果您将其作为模式应用于许多字段/表单/应用程序。不过，WeakHashMap 中的缓存可能更稳定。
  3. 使用 FT 搜索非常好，除非您需要经常更新的数据。FT 指数需要一些时间和资源来更新。

我的建议是：如果它解决了您的问题，请选择 FT。当然，首先在您的服务器上进行一些繁重的性能测试中对 FT 性能进行故障排除。

于 2013-08-12T20:11:56.857 回答
1

（由于我的声誉低，我无法发表评论）

我最近一直在处理类似的问题。以下是一些需要考虑的额外要点：

  • 视图中是否有很多重复的关键字？考虑为@DbColumn 创建一个分类视图。

  • 我相信 FTSearching 视图通常比数据库慢。请参阅Andre Guirard 的文章。如果可能，请考虑使用db.FTSearch()和优化您的 FT 查询以包含视图的选择 @Formula。

  • FT 索引可以使用 以编程方式更新db.updateFTIndex()。如果关键字很少添加，但需要立即可用，您可以在关键字文档的 QuerySave 事件（或类似事件）中执行索引更新。当关键字存储在不同（小得多）的数据库中并且更新非常快时，我们使用了这种方法。

  • 可以通过以下方式检查内存消耗：

    1. 从 OpenNTF安装XPages Toolbox 。
    2. 打开您的应用程序。
    3. 创建 JVM 内存转储（会话转储 - 生成堆转储）。
    4. 安装Eclipse 内存分析器工具
    5. 将IBM 诊断工具框架安装到内存分析器中。
    6. 将内存转储加载到 MAT 中。您将看到每个 Java 对象及其大小。

最后，我相信您的问题没有单一的通用答案。您需要测试不同的方法以在您的环境中找到最快的解决方案。

于 2013-08-14T07:34:50.297 回答
1

FT 搜索的一个问题是这个错误：

此数据库的全文索引正在使用中

根据我的经验，当索引器任务开始索引数据库时，这将发生一段时间（可能是几秒钟）。如果您的用户要求不是很高，他们可以再试一次，它可能会奏效。

但在许多情况下，您希望最大限度地减少用户遇到的错误，并且必须很好地处理此错误。我已经构建了自己的FTSearch方法，该方法稍等片刻，然后再试一次，直到没有收到错误为止。这将对用户显示为缓慢而不是错误。

于 2013-08-14T12:39:01.547 回答