在尝试提高性能时,为什么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,并循环使用它.这产生了我需要的唯一列表,但结果比上面任何其他方法慢.(我确实实现了这些 ViewNavigator性能提示).

Answer 1

从我的角度来看，性能可能会受到每个 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 性能问题。