《针对IBM Lotus Notes开发人员的性能基础知识》由会员分享，可在线阅读，更多相关《针对IBM Lotus Notes开发人员的性能基础知识（20页珍藏版）》请在金锄头文库上搜索。
1、在 Lotus Notes 中开发简单的应用程序非常容易，并且在用户和文档的数量很少时，一般不会遇到性能问题。然而，只要应用程序是成功的，用户和数据的数量就会逐渐增多。如果在设计时没有考虑到性能问题，那么您的应用程序此时将会变得异常缓慢。这份白皮书讨论影响 Notes/Domino 应用程序的性能的主要因素，并且解释开发人员如何才能获得最佳的性能。这并不是一份详尽的指南；相反，我们主要关注最常见、最严重的设计问题。这份白皮书的主要目的是帮助您识别 Notes 客户端应用程序的问题，并指导您找到解决办法。Web 应用程序也存在类似的设计问题，但它们的问题主要在另外两篇文章中解答，即 Append
2、ices Group C of the IBM Redbooks 出版物 Performance Considerations for Domino Applications 和 IBM Business Partner 文档 Performance Engineering Notes/Domino Applications。主要因素一般而言，以下因素对应用程序的性能影响最大： 视图的数量及其复杂性。删除不使用的视图或合并相似的视图。对于包含相同文档但使用不同排序的视图，使用一个可重新排序的列合并它们。删除不需要的列，并简化选择和视图列公式。检查是否存在您不能访问的“服务器私有”视图或其他视图
3、。 在视图选择公式或列选择公式中使用 _cnnew1Today 和 Now。尽量避免这种情况。参见 IBM Support Web 站点技术文档 Time/Date views in Notes: What are the options?；并阅读本文下面的视图小节。 文档数量。文档越多打开的速度就越慢。可以考虑压缩旧文档或将主文档合并为单一文档。例如，如果您的主文档是一个“订单”，那么将订单上的每个“排列项”放到独立的文档中就是一个糟糕的做法。Lotus Notes 不是关系数据库，而是面向文档的数据库。 储存在文档中的摘要字段的数量。不属于富文本的字段称为“摘要”字段（尽管这个称呼过于简单
4、化）。文档包含的摘要字段越多，将其编入到视图索引中所需的时间就越长（如果存在几百个字段，那么所需的时间将增加 30%）。只要字段存在，即使不在视图中使用它们，也会造成一样的结果。有时使用更少的文档却需要更多的字段，反之亦然；必须仔细考虑才能为提升性能做出正确的选择。 表单的复杂性。尝试将表单的数量限制为与实际需要的字段相等。表单越长，打开、刷新和保存它们所需的时间就会大大延长（并且视图索引器需要处理的字段也会增多）。 修改文档。对文档进行不必要的修改会增加索引器的负担，从而降低了视图索引的速度，并且还会影响复制和全文本索引的速度。 删除文档的数量。当删除一个文档时，就会留下一个称为“删除存根”
5、的标记。复制程序需要根据这个标记决定是否从其他副本中删除相同的文档，或将“缺失”的文档复制到该副本。删除存根最终会过期（默认为 90 至 120 天），因此只要数据库保持正常的删除文档数量，就不会造成问题。 然而，我们见过一些应用程序包含的删除存根要比文档多好几倍。如果使用代理程序在夜间执行文档删除，然后从其他外部数据源创建新的文档，那么通常会出现这种情况。不要使用这种方法。您可以使用更高级的算法比较文档和源数据，从而确定应该更新或删除哪些文档。参见 Lotus Sandbox download 了解更多信息。 Reader 字段。如果有必要使用 Reader 字段，那么必须使用它 没有其他方
6、法能够提供它所提供的安全性。但要注意它对视图的性能造成的影响，尤其是用户仅访问大量文档中的一小部分文档时。这份白皮书的视图小节讲述了一些减小该字段的影响的技巧，另外 developerWorks 文章 Lotus Notes/Domino 7 application performance: Part 2: Optimizing database views 也讨论了类似的主题。 用户数量。如果服务器上存在大量用户，那么将会影响应用程序和服务器的性能。当应用程序的性能已经处于临界状态时，添加新的用户会导致性能恶化。改良设计会有所帮助，但您还需要在其他服务器上创建副本（尤其是集群服务器），或鼓励
7、用户创建更 快的本地副本。 数据库级别的性能因素参考 Domino Designer 帮助文档“Properties that improve database performance”的数据库选项列表，您可以利用它调试性能。在很多情况下，这些选项通过削弱性能来获得其他功能；因此，对于特定应用程序不需要的功能，可以禁用它。对性能有巨大影响的选项包括： Dont maintain unread marks。 Dont maintain the Accessed (In this file) document property。如果“不进行维护”，您就不知道最后一次读取文档的时间。对长时间不读取的
8、文档进行归档时，这个信息非常有帮助。 Disable specialized response hierarchy information。如果禁用该项选，就不能使用 NotesDocument.Responses 属性，也不能使用 AllDescendants 或 AllResponses，它们偶尔用于视图选择公式和复制公式。 Disable transaction logging。这个选项对性能的影响取决于管理员如何在服务器上设置它，以及用户的数量。如果用户很多，使用事务日志能得到更佳的性能。尝试启用和禁用该选项造成的影响。事务日志用于恢复。 Optimize Document Table
9、 Map。如果应用程序包含的各种类型的文档大致相等，并且大多数视图仅显示一个类型（例如，SELECT Form = “xyz” & .），这个选项就非常有用。如果视图选择公式都采用这种方式，并且先对表单进行检查，那么视图索引就会变快，因为这能立即排除不使用该表单的文档。 使用 NSFDB2（在 DB2 数据库中存储 Domino 数据）并不能提升性能，事实上，使用传统的 NSF 文件还会更快一些。NSFDB2 的目标是添加功能，而不是提升性能。全文本索引可能会占据大量的磁盘空间，但这通常是物有所值的。您可以利用全文本索引在代理中执行更快速的搜索，如果没有这个索引，用户必须使用更慢的搜索方法，这
10、将导致长时间占用服务器，从而造成性能下降。注意：在 8.0 版本的 Notes 中，一个新数据库属性使您可以关闭非全文本索引数据库的“全文本”搜索。一般而言，即使您拥有全文本索引，该选项也是很有用的；它确保索引被意外删除之后，用户会看到一条消息，而不仅是觉得性能无缘无故突然下降。对于数据库，除了属性对话框之外，您还可以设置的另一个地方是 ACL 对话框。限制用户创建视图和文件夹能够减少服务器的负载（见图 1）。图 1. ACL 对话框如果您取消选择“Create personal folders/views”，用户仍然能够创建私有视图，但创建的视图必须储存在本地的桌面文件中，而不是存储在服务器
11、上。因此不会对应用程序的性能造成太大的影响。桌面私有视图肯定会对性能造成影响，因为索引它们时用户必须从服务器实时提取数据。因此过多地使用桌面私有视图还会使服务器陷入困境。所以要避免为启用“Private on first use”选项的用户自动创建个人视图。（下面会对此进行详细阐述）。公式性能大部分 函数都是相当快的，但有一小部分比较慢。因此要谨慎地使用它们： Contains 的开销还不是十分大，通常用于测试列表是否包含某个值，这是一种低效的方法。例如，如果 Cities 包含值“East Lansing”，则表达式 Contains(Cities; “Lansing”) 返回 True。如
12、果这正是您需要的，当然很好；但如果您查找的是包含“Lansing”值的条目，那么应该使用 =、*= 或 IsMember。这些函数更加快，因为如果第一个字符不匹配，它们就不再扫描整个字符串。 For 和 While 通常可以被更高效的 Transform 代替，或被其他对整个列表进行一次性操作的函数代替。 Unique 必须将列表中的每个值与其他值进行比较，因此执行时间与列表中的项数的平方成正比。对于其中的各个值都具有惟一性的列表，这个函数的表现会更好。后面还将对此进行讨论。 NameLookup 类似于 DbLookup，但它仅用于目录信息。 DbLookup 和 DbColumn。过度使用
13、和错误使用这些函数是造成表单延迟的主要原因。下面将对此进行详细讨论。 我们通常不必要地使用了宏语言中的循环函数。尽管没有在这个 Domino Designer 帮助文档中阐述宏函数，但几乎所有接受字符串参数的宏函数都可以对列表进行操作。例如，Left(x; “,”)，其中 x 是一个列表，它返回一个所有元素都被“左置”的列表。注意：在以前，UserRoles 和 UserNamesList 函数都会造成严重的性能问题，但从 Lotus Notes 6.0 开始，这些函数的结果都将被缓存。DbLookup 和 DbColumn影响 DbLookup 和 DbColumn 的性能的 3 个主要因素
14、是： 是否使用缓存 正在查找的视图是否高效 是否不必要地使用它们 使用缓存许多开发人员过度地使用“NoCache”选项，尤其是在关键字公式中。这种现象很容易观察到，因为在开发和首次测试期间需要经常编辑关键字，因此NoCache（不使用缓存）是“正确的选择”。然后，在应用程序投入使用之后，就不会经常编辑关键词。在出现新值时，迟一些再提供给用户可以得到更好的性能，这种代价是可以接受的。务必在必要时才使用“NoCache”选项。有 3 个缓存选项： “Cache”（默认）仅对在应用程序会话期间对视图的首次查询起作用，它会记住该查找结果供以后使用，直到您退出应用程序。 “NoCache”绕过缓存直接指
15、向视图。如果存在同一查找的缓存值，将不更新缓存。 “ReCache”是一个容易忽略的选项，它通常直接指向视图，但它也使用查找值更新缓存。通过使用 ReCache，您可以在特定时间更新缓存，比如在保存查找所引用的文档时。在其他时候也可以使用缓存值，因为您知道对于用户输入的信息而言，这个值至少是最新的。 为查找选择正确的视图 有时对 Db 函数最高效的视图并不是最好的。例如，U nique(DbColumn(“”:“NoCache”; “”:“”; “InvoicesByCompany”; 1) 存在几个问题： 它在这里不应该使用 NoCache。您并不是每天都添加一个公司，即使添加，也可以在 Invoice 表单的 Postsave 中使用“ReCache”选项，让新添加的名字立即可用。 当前的数据库是用表达式 “”:“” 指定的。相反，应该使用 “”，因为 “”:“” 不仅带有更多容易混淆的标点，而且它的计算速度也要慢一些。 不要查找带有重复值的列表，然后再使用 Unique 删除重复内容。相反，您应该查找其值具有惟一性的视图列，因为它们来自一个已分类的列。 最后一点特别重要，因为使用 100 个测试数据文档时能够很好工作的列查找，在实际使用中性能就会急剧下降，因此此时应用程序面对的是数千个文档。尤其是在服务器上使用该应用程序时，需要通过网络将视图列
