在尝试提高性能时，为什么FTSearch不能成为XPage中Type-Ahead的DBColumn的合适替代品？

Question

我当前的项目中有一个通用要求，可以更快地创建现有的XPage应用程序。我们看到的一件事是如何加速一些较慢的预先输入字段，并且一个似乎很快的解决方案是使用FTSearch而不是我们原来的DBColumn来实现它。我想得到关于这是否是一个好的方法，或者是否有任何建议以不同的方式做我们需要的建议。

背景： 虽然影响速度的因素很多（如网络延迟，服务器操作系统，可用的服务器内存等），但正如我们使用8.5.3一样，我们已经尽可能地优化了应用程序，利用了IBM Toolkit用于查找问题区域，还使用IBM在8.5.3中添加的功能（例如，部分执行，使用优化的JS和CSS选项等）。不幸的是，我们仍然坚持在32位Windows操作系统上使用3.5Gb Ram运行服务器几个月。

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

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

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

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

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

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

2013年8月14日更新：我尝试了另一种方法（灵感来自于OpenNtf上的IBM / Tony McGuckin Insights应用程序），因为公司搜索类型优先使用托管bean，而且速度很快数据。

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

Answer 1

从我的观点来看，performance可能会受到每个Domino应用程序（不仅是XPage）所包含的任何层的影响。 从顶部 - 浏览器（DOM，JS，CSS，HTML ...），网络（延迟，DNS，SSO ......）到应用层（有效算法，缓存），数据库/ API（数据量，索引，读者名称） ...）和OS /硬件（磁盘，内存......）

根据您测试的内容：

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

我的建议是：去FT，如果它能解决你的问题。当然，troubleshoot FT在您的服务器上进行了一些重要的性能测试。

Answer 2

（由于我声誉不佳，我无法发表评论）

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

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

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

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

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

  1. 从OpenNTF安装XPages Toolbox。
  2. 打开您的申请。
  3. 创建JVM内存转储（会话转储 - 生成堆转储）。
  4. 安装Eclipse Memory Analyzer Tool
  5. 将IBM Diagnostic Tool Framework安装到Memory Analyzer中。
  6. 将内存转储加载到MAT中。您将看到每个Java对象及其大小。

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

Answer 3

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

  

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

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

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