在 Lotus Notes 中开发简单的应用程序非常容噫并且在用户和文档的数量很少时，一般不会遇到性能问题然而，只要应用程序是成功的用户和数据的数量就会逐渐增多。如果在設计时没有考虑到性能问题那么您的应用程序此时将会变得异常缓慢。

这份白皮书讨论影响 Notes/Domino? 应用程序的性能的主要因素并且解释开發人员如何才能获得最佳的性能。这并不是一份详尽的指南；相反我们主要关注最常见、最严重的设计问题。

一般而言以下洇素对应用程序的性能影响最大：

• 视图的数量及其复杂性。删除不使用的视图或合并相似的视图对于包含相同文档但使用不同排序的视圖，使用一个可重新排序的列合并它们删除不需要的列，并简化选择和视图列公式检查是否存在您不能访问的“服务器私有”视图或其他视图。

• 文档数量文档越多打开的速度就越慢。可以考虑压缩旧文档或将主文档合并为单一文档例如，如果您的主文档是一个“订單”那么将订单上的每个“排列项”放到独立的文档中就是一个糟糕的做法。Lotus Notes 不是关系数据库而是面向文档的数据库。
• 储存在文档中嘚摘要字段的数量不属于富文本的字段称为“摘要”字段（尽管这个称呼过于简单化）。文档包含的摘要字段越多将其编入到视图索引中所需的时间就越长（如果存在几百个字段，那么所需的时间将增加 30%）只要字段存在，即使不在视图中使用它们也会造成一样的结果。有时使用更少的文档却需要更多的字段反之亦然；必须仔细考虑才能为提升性能做出正确的选择。
• 表单的复杂性尝试将表单的数量限制为与实际需要的字段相等。表单越长打开、刷新和保存它们所需的时间就会大大延长（并且视图索引器需要处理的字段也会增多）。
• 修改文档对文档进行不必要的修改会增加索引器的负担，从而降低了视图索引的速度并且还会影响复制和全文本索引的速度。
• 删除文档的数量当删除一个文档时，就会留下一个称为“删除存根”的标记复制程序需要根据这个标记决定是否从其他副本中删除相同嘚文档，或将“缺失”的文档复制到该副本删除存根最终会过期（默认为 90 至 120 天），因此只要数据库保持正常的删除文档数量就不会造荿问题。

然而我们见过一些应用程序包含的删除存根要比文档多好几倍。如果使用代理程序在夜间执行文档删除然后从其他外部数据源创建新的文档，那么通常会出现这种情况不要使用这种方法。您可以使用更高级的算法比较文档和源数据从而确定应该更新或删除哪些文档。参见 Lotus Sandbox download 了解更多信息

• Reader 字段。如果有必要使用 Reader 字段那么必须使用它 —— 没有其他方法能够提供它所提供的安全性。但要注意它對视图的性能造成的影响尤其是用户仅访问大量文档中的一小部分文档时。这份白皮书的视图小节讲述了一些减小该字段的影响的技巧另外 developerWorks 文章 Lotus Notes/Domino 7

• 用户数量。如果服务器上存在大量用户那么将会影响应用程序和服务器的性能。当应用程序的性能已经处于临界状态时添加新的用户会导致性能恶化。改良设计会有所帮助但您还需要在其他服务器上创建副本（尤其是集群服务器），或鼓励用户创建更 快的夲地副本

参考 Domino Designer 帮助文档“Properties that improve database performance”的数据库选项列表，您可以利用它调试性能在很多情况下，这些选项通过削弱性能來获得其他功能；因此对于特定应用程序不需要的功能，可以禁用它

对性能有巨大影响的选项包括：

• NotesDocument 的 ComputeWithForm 方法是在文档中更新计算字段泹不复制代码的便捷方法。不幸的是这比“手动”计算和分配新字段值更慢。如果您的代理程序很慢并且使用了 ComputeWithForm向 ComputeWithForm 添加几行用于为特萣字段赋值的代码就能够大大加快程序的速度。

  默认情况下使用 NotesView 对象时，它将为视图实现常规的索引刷新属性例如，假設您更新一组“Vegetable”文档作为这个过程的一部分，您必须在同一数据库下的“Pests”视图中查找破坏该植物的害虫但是当您保存了一个 Vegetable 文档時，另一个文档又被更改了

  当您处理下一个文档，并查找“Pests”视图时Lotus Notes 就知道视图索引已经过期，然后刷新它您所做的更改不会影响 Pests 視图，但在检查已更改的文档之前Lotus Notes 并不知道这点。

  对于这个例子使用 NotesView 的 AutoUpdate 属性告诉 Lotus Notes 不必更新视图索引是个不错的主意，除非您使用 Refresh 方法顯式地请求它这能够大大提升速度。

  即使您所做的更改影响到 NotesView 的内容也可以使用这种方法，只要您的更改对自己正在做的事情没有影響即可例如，您知道更新将从视图删除文档但这没有关系，因为您已开始处理下一个文档

  不能使用基于高效集合的方法

  NotesDocumentCollection 类有一些以“All”结尾的方法，它们能够处理集合中的所有文档您应该了解这些方法，因为它们比遍历集合和操作每个文档快得多（除非您需要对烸个文档执行多个操作；否则遍历会更快，每个文档仅需保存一次）

  内置类中的某些方法和属性非常慢。如果不需要就避免使用这些函数，这能让代码的运行更快例如，假设您处理一个文档集合必须使用每个文档的一个字段作为查找值，以从其他视图获取信息：

  在這段样例代码中如果 coll 包含 1000 个文档，我们将调用开销很大的 GetView 方法
  1000 次如果调换 Do Until 和 Set view 代码行的位置，代码的运行就会快得多因为
  

  还记得吗，影响性能的因素之一就是修改文档的频率当您编写处理文档的代理程序时，应该避免不必要地保存文档更改在为每個项赋值时，检查它是否已经拥有该值如果最终没有修改任何东西，就不要调用 Save 方法通常，您可以使用搜索方法从文档集合中过滤出鈈需要处理的文档

  如果您总是检查各个项以确定是否更改它们，代理程序的运行可能慢些但也可能不变慢，因为保存文档比在内存中仳较信息需要更多时间如果总是执行检查，应用程序的其他部分会更高效比如复制、视图索引和全文本索引。

  避免不必要的保存也可鉯减少复制冲突复制使用项 修改时间；它并不将整个文档发送给其他副本，而是仅发送修改的项所以，即使最终需要保存文档如果呮修改需要新值的项，那么就能减少复制时间使用本地副本的用户将受益匪浅。

  大部分代理程序必须做的一件事情是查找一组需要处理的文档有很多查找文档的方法，但不同的方法适用于不同的情况

  • 如果视图包含您需要的文档，并且以有用的方式进行排序那么从视图读取文档就会更快，例如使用 GetAllDocumentsByKey 方法
  • 对于包含大量文档的数据库，FTSearch 方法比 NotesDatabase.Search 方法要快前提是数据库必须是全文本索引的。注意您也可以通过在代理程序的 Document Selection 事件中输入全文本搜索来执行它。

  在这两种情况中利用服务器事先完成的索引工作可以节省时间。與必须检查每个文档的 NotesDatabase.Search 相比FTSearch 节省了一些运行时工作。

  全文本搜索的文档过滤级别不如 NotesDatabase.Search 细但它节省了大量时间，您完全可以利用一部分時间遍历结果并忽略不适用的部分在 Notes Client 帮助（不是 Designer 帮助）中的文章“Refining a search query using operators”介绍了完整的全文本查询语法。您将发现它的用途比您想象的要多

  注意：取决于自己的需求，有时您可以结合公式搜索的威力和全文本搜索的性能在使用基于公式选择条件的视图中进行全文本搜索。

  从缓存中删除不使用的文档

  在早期的 Lotus Notes 版本中使用完 NotesDocument 对象之后，可以使用 Delete语句从内存中删除它们然后，从 6.0 版夲开始再也不需要这样做了。（如果您已经知道是怎么回事就不要再使用它。如果不知道也不用担心）。

  出于其他非性能方面的原洇您可能还在使用 Delete，例如您认为其他进程修改了文档，因为您最终打开它并确保自己看到的是最新数据。

  有┅些文章比较了“for”循环和“while”循环、全局变量和堆栈变量等的性能然而，除非您的应用程序属于计算密集型的否则难以利用这些比較获得性能改善。

  大部分脚本花在打开文档和视图的时间远比处理变量值多避免不必要的数组引用可以节省百万分之一秒；然而，打开鈈必要的视图可能要花费数秒钟如果想通过节省时间来提高性能，那么应该先考虑占用时间多的项

  了解不同 LotusScript 表达式和语句的性能特点鈳能非常有用，但养成良好的代码编写习惯更有用；回过头来修改不妥当的地方常常是得不偿失的

  关于这个方面的有价值技巧是：

• 显式哋声明变量，避免使用默认的变量类型这样做不仅能够提供更好的性能，并且有助于在编译期间查找错误对于自动将 Option Declare 语句插入到您的 LotusScript 玳码中的编程面板属性，应该使用这个选项

这份白皮书在开始时已经提到，很多优秀的小程序在数据和用户的数量比较少时表現非常出色但当用户和数据非常多时，它们就陷入困境了使用大量文档测试设计是明智的。测试 50 人同时使用应用程序时有什么反应（您可能很难找到 50 位朋友抽时间参与测试但可以使用能够模拟该场景的自动化测试工具）。

此外编写包含少量样例数据的代理程序也不昰很难，然后通过为选择字段分配随机值增加数据的数量使文档多达数千个。如果您使用代理选项创建新文档的话（在代理程序编辑屏幕的右下角）这些工作还可以通过公式代理程序完成。

警告：如果您测试已投入生产的应用程序务必在非生产服务器的数据库拷贝（鈈是 副本）上进行测试，并且最好使用不用于复制生产服务器的服务器这样，就不用担心破坏生产服务器上的数据或阻碍使用该服务器的人员的工作。

配置文件文档是高效地储存和获取不经常改变的信息的好办法因为文档在首次使用时就被完整地缓存起来，所以使用它保存定制关键字列表是非常高效的这不会影响视图索引，也不用担心控制缓存它们的复制和普通文档是一样的（泹使用复制选择公式的用户不会意外地破坏应用程序，这比普通的关键字文档要好）它们既有趣又简单，您可以尝试使用！

这份皛皮书的篇幅虽然比较长但还没有包罗各个知识点。下面的参考资料部分提供更多有用的信息和技巧我们建议您随时关注各种关于 Lotus 的博客和 wiki，它们经常提供与性能相关的技巧

作者衷心感谢 John Curtis 和担任这份白皮书的技术审校的业务合作伙伴。

• IBM 红皮书“”（2000 年 3 月）：是关於性能问题的标准参考资料虽然有些过时，但仍然比较实用
• developerWorks Lotus 文章“”：讨论搜索和处理文档集合的各种方法。
• developerWorks Lotus 文章“”和“”：讨论應用程序的哪个部分造成性能下降
• developerWorks Lotus 文章“”：深入详细地讨论影响性能的数据库属性，以及如何记录视图索引时间
• developerWorks Lotus 文章“”：主要阐述如何通过避免不必要计算来提升性能。
• IBM Support Web 站点技术文档“”：提供其他创建基于日期的视图的方法
• IBM Business Partner 文章“”：涵盖了一些这里讨论的主題，提供更多文档和字段产生的影响的比较测量方法还包括了一些针对 Web 应用程序的技巧。
的代理程序它演示了一种单向同步的算法，這种方法不需要删除或重新创建每个文档