针对IBM Lotus Notes开发人员的性能基础知识

在 Lotus Notes 中开发简单的应用程序非常容易 并且在用户和文档的数量很少时 一般不会遇到性能 问题 然而 只要应用程序是成功的 用户和数据的数量就会逐渐增多 如果在设计时没有考虑到性能问 题 那么您的应用程序此时将会变得异常缓慢 这份白皮书讨论影响 Notes Domino 应用程序的性能的主要因素 并且解释开发人员如何才能获得最佳 的性能 这并不是一份详尽的指南 相反 我们主要关注最常见 最严重的设计问题 这份白皮书的主要目的是帮助您识别 Notes 客户端应用程序的问题 并指导您找到解决办法 Web 应用 程序也存在类似的设计问题 但它们的问题主要在另外两篇文章中解答 即 Appendices Group C of the IBM Redbooks 出版物 Performance Considerations for Domino Applications 和 IBM Business Partner 文档 Performance Engineering Notes Domino Applications 主要因素 一般而言 以下因素对应用程序的性能影响最大 视图的数量及其复杂性 视图的数量及其复杂性 删除不使用的视图或合并相似的视图 对于包含相同文档但使用不同排 序的视图 使用一个可重新排序的列合并它们 删除不需要的列 并简化选择和视图列公式 检 查是否存在您不能访问的 服务器私有 视图或其他视图 在视图选择公式或列选择公式中使用在视图选择公式或列选择公式中使用 cnnew1 Today cnnew1 Today 和和 Now Now 尽量避免这种情况 参见 IBM Support Web 站点技术文档 Time Date views in Notes What are the options 并阅读本文下面的视图小节 文档数量 文档数量 文档越多打开的速度就越慢 可以考虑压缩旧文档或将主文档合并为单一文档 例如 如果您的主文档是一个 订单 那么将订单上的每个 排列项 放到独立的文档中就是一个糟 糕的做法 Lotus Notes 不是关系数据库 而是面向文档的数据库 储存在文档中的摘要字段的数量 储存在文档中的摘要字段的数量 不属于富文本的字段称为 摘要 字段 尽管这个称呼过于简 单化 文档包含的摘要字段越多 将其编入到视图索引中所需的时间就越长 如果存在几百个 字段 那么所需的时间将增加 30 只要字段存在 即使不在视图中使用它们 也会造成一样 的结果 有时使用更少的文档却需要更多的字段 反之亦然 必须仔细考虑才能为提升性能做出 正确的选择 表单的复杂性 表单的复杂性 尝试将表单的数量限制为与实际需要的字段相等 表单越长 打开 刷新和保存 它们所需的时间就会大大延长 并且视图索引器需要处理的字段也会增多 修改文档 修改文档 对文档进行不必要的修改会增加索引器的负担 从而降低了视图索引的速度 并且还 会影响复制和全文本索引的速度 删除文档的数量 删除文档的数量 当删除一个文档时 就会留下一个称为 删除存根 的标记 复制程序需要根 据这个标记决定是否从其他副本中删除相同的文档 或将 缺失 的文档复制到该副本 删除存 根最终会过期 默认为 90 至 120 天 因此只要数据库保持正常的删除文档数量 就不会造 成问题 然而 我们见过一些应用程序包含的删除存根要比文档多好几倍 如果使用代理程序在夜间执行文档删除 然后从其他外部数据源创建新的文档 那么通常会出现这种情况 不要使用这种方法 您可以使用更高级 的算法比较文档和源数据 从而确定应该更新或删除哪些文档 参见 Lotus Sandbox download 了解更多 信息 ReaderReader 字段 字段 如果有必要使用 Reader 字段 那么必须使用它 没有其他方法能够提供它 所提供的安全性 但要注意它对视图的性能造成的影响 尤其是用户仅访问大量文档中的一小部 分文档时 这份白皮书的视图小节讲述了一些减小该字段的影响的技巧 另外 developerWorks 文章 Lotus Notes Domino 7 application performance Part 2 Optimizing database views 也讨论了类似的主题 用户数量 用户数量 如果服务器上存在大量用户 那么将会影响应用程序和服务器的性能 当应用程序的 性能已经处于临界状态时 添加新的用户会导致性能恶化 改良设计会有所帮助 但您还需要在 其他服务器上创建副本 尤其是集群服务器 或鼓励用户创建更 快的本地副本 数据库级别的性能因素 参考 Domino Designer 帮助文档 Properties that improve database performance 的数据库选项列 表 您可以利用它调试性能 在很多情况下 这些选项通过削弱性能来获得其他功能 因此 对于特定应 用程序不需要的功能 可以禁用它 对性能有巨大影响的选项包括 Don tDon t maintainmaintain unreadunread marksmarks Don tDon t maintainmaintain thethe Accessed Accessed In In thisthis file file documentdocument propertyproperty 如果 不进行维护 您就不知道最后一次读取文档的时间 对长时间不读取的文档进行归档时 这个信息非常有帮助 DisableDisable specializedspecialized responseresponse hierarchyhierarchy informationinformation 如果禁用该项选 就不能使用 NotesDocument Responses 属性 也不能使用 AllDescendants 或 AllResponses 它们偶尔 用于视图选择公式和复制公式 DisableDisable transactiontransaction logginglogging 这个选项对性能的影响取决于管理员如何在服务器上设置它 以及用户的数量 如果用户很多 使用事务日志能得到更佳的性能 尝试启用和禁用该选项造成 的影响 事务日志用于恢复 OptimizeOptimize DocumentDocument TableTable MapMap 如果应用程序包含的各种类型的文档大致相等 并且大多数视 图仅显示一个类型 例如 SELECT Form xyz Lansing 返回 True 如果这正是您需要的 当然很好 但如果您查找的是包含 Lansing 值的条目 那么应 该使用 或 IsMember 这些函数更加快 因为如果第一个字符不匹配 它们就不再扫描 整个字符串 For For 和 While While 通常可以被更高效的 Transform 代替 或被其他对整个列表进行一次性操作 的函数代替 Unique Unique 必须将列表中的每个值与其他值进行比较 因此执行时间与列表中的项数的平方成正比 对于其中的各个值都具有惟一性的列表 这个函数的表现会更好 后面还将对此进行讨论 NameLookup NameLookup 类似于 DbLookup 但它仅用于目录信息 DbLookup DbLookup 和和 DbColumn DbColumn 过度使用和错误使用这些函数是造成表单延迟的主要原因 下面将对 此进行详细讨论 我们通常不必要地使用了宏语言中的循环函数 尽管没有在这个 Domino Designer 帮助文档中阐述宏函数 但几乎所有接受字符串参数的宏函数都可以对列表进行操作 例如 Left x 其中 x 是一个列表 它返回一个所有元素都被 左置 的列表 注意 注意 在以前 UserRoles UserRoles 和 UserNamesList UserNamesList 函数都会造成严重的性能问题 但从 Lotus Notes 6 0 开始 这些函数的结果都将被缓存 DbLookup DbLookup 和和 DbColumn DbColumn 影响 DbLookup 和 DbColumn 的性能的 3 个主要因素是 是否使用缓存 正在查找的视图是否高效 是否不必要地使用它们 使用缓存使用缓存 许多开发人员过度地使用 NoCache 选项 尤其是在关键字公式中 这种现象很容易观察到 因为在开 发和首次测试期间需要经常编辑关键字 因此 NoCache 不使用缓存 是 正确的选择 然后 在应用程序投入使用之后 就不会经常编辑关键词 在出现新值时 迟一些再提供给用户可以得到 更好的性能 这种代价是可以接受的 务必在必要时才使用 NoCache 选项 有 3 个缓存选项 Cache 默认 仅对在应用程序会话期间对视图的首次查询起作用 它会记住该查找结果供 以后使用 直到您退出应用程序 NoCache 绕过缓存直接指向视图 如果存在同一查找的缓存值 将不更新缓存 ReCache 是一个容易忽略的选项 它通常直接指向视图 但它也使用查找值更新缓存 通过 使用 ReCache 您可以在特定时间更新缓存 比如在保存查找所引用的文档时 在其他时候也可 以使用缓存值 因为您知道对于用户输入的信息而言 这个值至少是最新的 为查找选择正确的视图为查找选择正确的视图 有时对 Db 函数最高效的视图并不是最好的 例如 U nique DbColumn NoCache InvoicesByCompany 1 存在几个问题 它在这里不应该使用 NoCache 您并不是每天都添加一个公司 即使添加 也可以在 Invoice 表单的 Postsave 中使用 ReCache 选项 让新添加的名字立即可用 当前的数据库是用表达式 指定的 相反 应该使用 因为 不仅带 有更多容易混淆的标点 而且它的计算速度也要慢一些 不要查找带有重复值的列表 然后再使用 Unique 删除重复内容 相反 您应该查找其值具有 惟一性的视图列 因为它们来自一个已分类的列 最后一点特别重要 因为使用 100 个测试数据文档时能够很好工作的列查找 在实际使用中性能就会急 剧下降 因此此时应用程序面对的是数千个文档 尤其是在服务器上使用该应用程序时 需要通过网络将 视图列的完整内容发送给用户工作站 这是需要时间的 从视图读取已经存在的惟一值要快得多 注意 注意 在获取惟一值列表时 似乎可以使用 Generate unique keys in index 选项代替已分类的列 但实际上它存在一些缺点 因此不适合该用途 查找需要花很长时间索引的视图也是不明智的 尤其是在选择公式或列公式中使用 Today 或 Now 的视 图 如果您仅需查找特定日期的文档 那么可以对仅包含这些文档的视图使用 DbColumn 对包含所有按 日期排序的文档的视图使用 DbLookup 并提供日期作为查找键 避免重复查找避免重复查找 不必要地使用 Db 函数的方式有好几种 这里给出一些常见的方式 在公式中重复在公式中重复 If IsError DbLookup NoCache SomeView CustID 3 DbLooku p NoCache SomeView CustI D 3 这个公式不仅使用了不需要的 NoCache 并且进行了两次查找 实际上一次查找就可以了 下面是两个 修改后的公式 tmp DbLookup SomeView CustID 3 If IsError tmp tmp 或 DbLookup SomeView CustID 3 FailSilent 在读模式中使用不必要的关键字查找在读模式中使用不必要的关键字查找 当打开文档进行查看时 对于某些类型的关键字字段 Notes 客户端不需要知道选择列表 但复选框和单 选按钮字段除外 在其中甚至以读模式显示所有选项 并且所有使用关键字的内容都是同义词 Display text value 因为文档仅储存 value 而表单必须显示 Display text 但是在其他情况中 需要编写该关键字公式来延迟查找 直到您实际需要选择列表为止 t If IsDocBeingEdited DbColumn Customers 1 Return Unavailable If IsError t t 通过在文档的读模式下返回 Unavailable 公式会再次通知表单 让它询问随后是否需要选择列表 这 将在用户切换到编辑模式并且指针点击该字段时发生 因此 在用户仅查看文档时 您不仅要避免进行查找 并且要分散编辑文档时的延迟 8 个半秒延迟肯定 没有一个 4 秒延迟那么烦人 如果用户的指针没有指向该字段 那么他们根本不需要进行查找 在只需一个查找的位置使用多个查找在只需一个查找的位置使用多个查找 假设您将一个客户 ID 储存在 invoice 文档中 并想通过这个 ID 查找和显示客户的名称 地址和购 买联系人姓名 这样 表单上就有几个 Computed for Display 字段 每个字段包含一个使用 DbLookup CompanyByID CustID x 的公式 其中 x 是列号或字段名 使用一个列来包含您需要的所有值会更高效 您可以从中找出每个字段值 因此这个列公式应该为 CustName StreetAddress City State Zip PurchasingContact 在您的表单上 添加一个隐藏的 Computed for Display 字段 名为 CustDetails 如下所示 DbLookup CompanyByID CustID 4 假设合并的列为列 4 然后 您就可以在需要显示名称的地方使用公式 CustDetails 1 等等 在刷新时重复查找在刷新时重复查找 假设您在组建表单时需要在计算字段中查找客户的经理的名字 如下所示 DbLookup VOLE 1 EmpData nsf EmpByName Name CN Username Manager 每次刷新表单时 都重新计算已计算的字段 许多表单需要经常刷新 因为您启用根据关键字字段的变化 刷新字段的选项 因此这会严重影响速度 将字段设置为 Computed when Composed 会更好 如果不需要将字段储存在文档中 记住 不要储存不需要存储的字段 然后对它使用 Computed for Display 但这个例子中 需要按照以下步骤避免在刷新时重复查找 If IsDocBeingLoaded DbLookup VOLE 1 EmpData nsf EmpByName Name CN Username Manager ThisValue 使用使用 DbColumn DbColumn 分配序列号分配序列号 这是一个经常犯的错误 当设计人员必须为每个文档创建一个惟一的 ID 时 他们通常向最新的现有文档 的编号加 1 因此他们的公式如下所示 tmp DbColumn NoCache RequestsByNumber 1 nextNumber If tmp 1 ToNumber Subset tmp 1 1 Right 000000 Text nextNumber 7 这是一个非常糟糕的主意 随着文档数量的增长 DbColumn 的执行时间会越来越长 此外 当应用程序 有多个用户时 它不能保证 ID 是惟一的 尤其是存在多个副本时 如果在文档保存之后再给它分配序列号 那么序列号在此之前是不可用的 这很不方便 不过 如果在创 建文档时就给它分配序列号 这将留有充足的时间让其他人使用相同的序列号创建并保存文档 您可能需要重新考虑自己的需求 有时应用程序实际上仅需要惟一的非数字标识符 而我们却总是要求使 用序列号 仔细查看 Unique 函数 它生成一个很短但基本上是惟一的值 通过一些额外的工作就可以 保证惟一性 例如为每位用户添加一个惟一的 前缀 通常是他们的名称的首字母 如果您决定真的需要使用序列号 那么请阅读 developerWorks 文章 Generating sequential numbers in replicated applications 它为使用序列号提供一种合理 高效的方法 一篇更多地讨论这个主题的 developerWorks 文章即将发布 表单设计 在这个小节中 我们将解决一下值得关注的问题 能使用能使用 ComputedComputed forfor DisplayDisplay 字段就不要使用字段就不要使用 ComputedComputed 字段字段 因为存储字段一般都会使应用程序变慢 所以如果能够在需要时轻松地计算这些值 就应该避免存储值 这里有一个折中 当文档以读模式打开时 不会计算 Computed 字段 因此如果它是一个很慢的公式 则 最好储存值 这样能够改善读模式的性能 另一方面 这还意味着它会过期 但一定不要使用 Computed 字段重新显示另一个字段的值 这样会存储相同信息的两个副本 大量使用字段大量使用字段 在一个表单中使用大量字段的最常见原因是 一个表有多个行和列的信息 并且每个单元格有一个字段 超出了支持的行数 这是一种棘手的情况 因为到目前为止使用表单是最简单的办法 不过 还有其他办法可以管理表的值 最常见的办法是将表放到一个富文本字段中 然后让用户根据需要 进行填充 在富文本字段的默认公式中使用 GetProfileField 从配置文件文档读取一个 starter 表 这样做的缺点是用户在填写表格时不能获得帮助 要是存在私有字段的话 就可以提供关键字列表 转 换和验证 不过 有时这也是一种可接受的办法 现在已经发布一些工具和技术 可以在对话框中每次仅编辑表的一行 然后在表中显示结果 例如 Lotus Sandbox 中的 Domino Design Library Examples 包含一组设计元素 可用于在表中编辑和显示数 据 而不要求每个单元格必须有一个字段 在名为 Table Editor 的数据库文档中 将详细描述这个系 统 需要付诸一定的努力才能实现它 但它对性能非常有帮助 有时 我们在大部分文档中可以看到包含许多空字段的表单 例如 大约 5 的文档需要一个包含 50 个 字段的 Regulatory Approval 部分 而其余 95 的文档则存储了这些空字段 这不仅浪费空间 而且 还造成糟糕的性能 对于这种情况 使用两个不同的表单可能更好 一个包含必需字段的主表单 和一个分开的 Regulatory Approval 表单 它可能是对原始文档的响应 或者仅在需要时创建 在这里 可以通过 使用额外的文档来避免使用更多的字段 不要忘记多值字段 除了通过 5 个字段让用户输入 5 个不同的值之外 还可以使用一个可以输入多个值 的字段 对条目的数量没有任何限制 除非您选择必须使用一个 并且生成的值在视图和公式中更容易 使用 注意 注意 如果应用程序已经因为字段过多而变慢 仅编辑设计元素是于事无补的 您必须编写代理程序遍历 现有文档 并从中删除多余的条目 已经出现一些业务合作产品可以简化这个过程 不过 如果您的更改 是一个重大的重组 比如将一些字段移动到特定的响应文档中 那么代理程序的编写是相当复杂的 设计 时从长远考虑 争取第一次就把事情做好 这能节省很多时间 图像过多图像过多 有些表单无节制地使用图像 对背景使用大型位图以及使用许多其他图像修饰 大图像需要更长的加载时 间 占用设计元素的缓存 并且查看表单时需要更长的图像呈现时间 创建表单时稍加注意就可以得到比 较专业的外观 并且不会对性能造成太大的影响 下面是一些技巧 不要将图像复制粘贴到表单上 相反 要么使用图像资源设计元素 要么导入图像 如果您计划 在多个表单中使用同一个图像 那么可以使用图像资源 因为它允许客户端将图像与表单设计分 离 然后再缓存它 即使您不打算 在多个表单中使用同一个图像 将图像作为资源也是一个不 错的主意 因为以后其他人可能需要使用该图像创建另一个表单 将图像放到表单上之后 不要随意缩小它的尺寸 使用图像编辑器 比如 GIMP 将原始图像缩 小为您所需的尺寸 即使您需要的是同一图像的多个大小不同的图像资源 也必须这么做 如果图像的格式为 JPEG 那么可以尝试不同的压缩设置 看看能不能减小它的体积 JPEG 压缩是 有损 耗 的 因此压缩后图像可能会失真 但如果您在不影响视觉效果的情况下最大限度地压缩图像 可以加 快表单的加载速度 您可以购买图像工具 它们能帮助您找到一个平衡点 对图像使用正确的文件格式 如果图像使用有限的调色板 就像大部分徽标 GIF 格式的图像 文件可能是最小的 如果使用全色照片或绘画 JPEG 可能是更好的选择 不要使用 BMP 格式的 文件 因为它们的压缩比很小 呈现表单元格和图像单元格的背景需要一定的时间 隐藏单元格边框的表单比显示边框的表单的 呈现速度快 尤其是使用 3 D 效果的边框 与嵌套在其他表内部的表相比 使用合并单元格的 表的呈现速度更快 存储表单存储表单 不要使用存储表单 自动刷新字段自动刷新字段 一般不要使用表单选项 Automatically refresh fields 这个选项会在编辑表单时频繁刷新它 重新 计算已计算字段和输入转换公式 从而造成延迟 使用字段级别的选项 Refresh on keyword change 或字段事件 Onchange 或 Onblur 会更好 它们只在需要时进行刷新 过多的共享设计元素过多的共享设计元素 表单可以从其他设计元素获取信息 比如图像资源 共享字段 共享操作 子表单 摘要 样式表和脚本 库 打开一个文档可能会从除表单之外的许多其他设计元素读取信息 读取过程是需要时间的 共享设计 元素的优点是使应用程序的维护更加容易 而它的不足之处是访问多个元素需要更长的加载时间 Lotus Notes 缓存设计信息 因此不需要每次都从原始设计元素读取设计信息 然而 首次加载可能是个 问题 缓存意味着使用共享设计元素可以提升性能 如果需要在许多不同的表单中使用相同的子表单或图 像的话 共享操作不会损害性能 因为仅有一个设计元素包含共享操作 所以多添加几个共享操作与使用一个共享 操作所需的开销是一样的 共享视图列也不会影响性能 由于共享设计元素有利于维护 所以除非采取各种措施仍然不能得到可以接受的性能 否则不推荐取消设 计元素共享 视图视图 由于以下原因 低效和不必要的视图会造成延迟 打开视图时需要时间更新索引 当在 Db 函数中使用视图时 需要时间获取信息 服务器上的更新任务会定期检查每个视图 看看是否需要使用最近修改的文档更新它们 因此视 图越多 或越复杂 就越长时间地占用服务器 导致所有应用程序变慢 视图打开缓慢的另一个常见原因是数据库中存在大量文档 当您打开视图时 Lotus Notes 将检查在最后 一次视图索引更新之后是否修改了某些文档 您拥有的文档越多 检查所需的时间就越长 即使最终结果 是 没有最近修改的文档 视图中的视图中的 Now Now 或或 Today Today 已经有许多文章介绍在不使用 Today 或 Now 时如何提供基于日期 时间的视图 其中的一个例子就是 IBM Support Web 站点技术文档 Time Date views in Notes What are the options 它提供一些创建 基于日期 时间的视图的方法 现在我们对其他几个方面进行讨论 首先 经常建议使用的 TextToTime Today 是不完整的 现在 它仅适用于第一天 您必须修改它 让它能够正确地工作 为什么 一般情况下 当您打开一个视图时 Lotus Notes 就会查看 视图索引 视图中存储的文 档和行值的列表 并仅检查自索引最后一次更新之后创建或修改的文档 以决定是否将它们添加到视 图 或删除它们 或重新计算它们的列值 如果自从最后一次使用视图之后没有修改任何文档 这个过程 就会很快 不过 如果您使用 Today 旧的视图索引就没有用了 例如 假设选择公式为 SELECT Status Processing Sections Financials Total 10000 False If 函数的执行时间比 运算符长 但如果能够通过它避免执行一些不必要的大开销函数 您就领先一 步了 过度使用多个分类过度使用多个分类 分类是非常有用的 它们允许在同一视图的多个标题下列出某个文档 但不要过度使用它 因为在一个视 图任务中两次列出某个文档所需的时间几乎翻了一倍 如果每个文档分别列出在 50 个类别中 再乘以文 档数就得出总行数 那么服务器需要存储和计算多少个行 这会给服务器带来很大的压力 即使您不使用多个 分类 经过分类的视图仍然比使用简单排序的视图慢 所需的时间取决于行数 而不 是文档数 并且每个文档和类别标题都是一个行 过度使用索引过度使用索引 视图属性对话框包含一组控制视图索引的选项 这些选项很少用到 但选择正确的索引选项能够大大提升 性能 例如 假设数据库包含特定的关键字文档 您需要频繁查找它们以填充表单上的关键字列表 关键字文档 是很少更改的 但应用程序中的其他文档则需要经常更改 在讨论 DbLookup 时我们已经知道对这种查找使用缓存是最好的 但第一次必须直接访问视图 因为还 不存在缓存值 当您执行这个过程时 Lotus Notes 发现在最后一次使用视图之后文档被更改了 然后将 花时间查找被更改的文档 并发现它们并不在视图中 对于在关键词值 DbLookup 中使用的视图 不需要在每次使用时都进行重新索引 对于这种视图 使用 索引选项 Auto at most every x hours 比较合适 见图 2 图图 2 2 视图索引选项视图索引选项 如果没有人使用这些视图 服务器仍然会更新它们 但时间间隔要长些 偶尔可能会有不幸运的用户刷新 索引 但这会导致平均查找时间更短 并且同一个用户在复杂表单的每个查找中都碰到刷新的机会不大 因此使用该选项后表单的打开速度会更快 如果仅在每个季度的季度审核时才使用视图 那么将索引保留 45 天没有任何意义 将其设置为在 2 天 之后丢弃 这样能够减轻服务器的工作 在其他情况下 选择适当的索引选项能够改善性能 想办法确定您的视图应该使用什么设置是值得的 注意 注意 可以通过程序在当前的副本中刷新索引 比如使用 NotesView Refresh 方法 假设一个索引在正 常情况下很少更新 但当您保存某个向视图提供数据的表单时 则必须更新视图 以在查找中使用新的数 据 在表单的 Postsave 代码中 对视图使用 Refresh 方法 同时 您可以使用带有 ReCache 的 Db 函数 将特定查找的缓存更新到视图 ReaderReader 字段字段 当您需要 Reader 字段时 没有什么东西可以代替它 但它可能会大大损害视图性能 当您打开包含带有 Reader 字段的文档时 Lotus Notes 会对行进行扫描 查找您可以访问的行 当行的数量填满屏幕时 将停止查找 如果您仅能访问一个文档 它必须查看视图中的每个行进行确认 这可能需要花很长时间 对此 您可以 使用比较短的 Reader 字段值 在单一角色中检查成员关系要比根据一个长长的访问名称列表比 较它们快 使用角色还便于维护 避免在这种应用程序中使用视图 如果用户仅能访问一两个文档 您可以提供其他访问方式 例 如 向他们发送包含有这些文档链接的电子邮件 使用嵌入式单类别视图 这种视图仅显示包含 它们的 文档的类别 使用设置为显示空类别 即未包含文档的类别 的分类视图 当然 这样做使得用户查找文档更 加困难 除非您为用户提供导航 因此您应该将该功能和 SetViewInfo 结合使用 以仅显示用 户所需的类别 注意 注意 使用分类视图存在安全问题 即您在文档中向用户显示了一个字段 类别 他们本来是不可以访 问该字段的 要确保使用这种办法是可行的 鼓励用户使用本地副本 因为本地副本仅包含用户能够访问的文档 因此不需要花功夫隔离他们 不能访问的文档 不要单独使用 Reader 字段作为导航帮助 例如 这是一种帮助用户方便地查找所需文档的方法 因为它 们是用户能够在视图中看到的所有文档 如果文档中的信息不是隐私的 还有其他更好的方法可以帮助用 户找到所需的文档 如前一小节和下一小节所述 PrivatePrivate onon firstfirst useuse 在共享视图的选择或列公式中使用 UserName 和 UserRoles 时 不能得到满意的结果 这是开发人员 创建仅显示 My Documents 的 Private on first use 视图的常见原因 这些视图可能存储在服务器 上 将从总体上影响应用程序的性能 或者存储在用户的本地 桌面 文件中 桌面视图不会直接影响服务器的性能 但当打开其中一个视图时 将像其他视图一样进行重新索引 以显 示最近的更改 这意味着用户工作站必须向服务器请求自从最后一次使用之后修改的所有文档 这个过程 可能造成用户等待 如果许多用户执行该操作 服务器还可能会因为大量发送数据请求而陷入困境 注意 视图索引仅使用摘要 数据 因此大型的富文本字段和文件附件在这里不构成问题 除了性能问题之外 私有视图还面临维护方面的问题 因为开发人员没有简单的方法更新用户私有副本的 设计 在这种情况下 共享列也不起作用 因为要在视图中更新共享列 执行更新的人员必须能够访问该 视图 通常可以使用 Notes 视图的 single category 功能避免 Private on first use 例如 如果您正 在显示 My Documents 您可以使用根据所有者分类的视图 然后要么使用 single category 公式 将该视图嵌入到表单或页面中 要么在视图中的 Postopen 事件中使用 SetViewInfo 仅对当前用户进 行显示 因为只有一个共享视图 所以总体索引开销降至最低 并且私有用户不必像在桌面私有视图中那 样等待 因为索引几乎总是最新的 代码 当您开始编写 LotusScript 或 JavaTM 代码时 您可能就开始逐步损害性能 在这里 我们讨论一些常 见的问题 GetNthDocumentGetNthDocument 使用 NotesDocumentCollection GetNthDocument 遍历集合是非常慢的 应该改用 GetFirstDocument 和 GetNextDocument 对于某些类型的集合使用 GetNthDocument 也一样高效 但不使用它事情更好办 表单或视图包含的操作代码过多表单或视图包含的操作代码过多 如果表单 视图或文件夹有许多操作 您就需要在设计元素中为每个操作编写代码 使用共享操作也是如 此 这样就存储了许多代码 每次使用设计元素时都必须将它们加载到内存中 在大部分时间 仅用到许多操作中的其中一两个 因此您需要等待加载所有操作 如果操作出现在多个地 方 您就在设计缓存中多次缓存了相同的代码 从而占用应该用于其他用途的内存 可以考虑将一些操作移动到代理程序中 这样 当有人请求运行操作时 仅在内存中加载一个代码副本 可以用宏语言编写操作按钮 以使用 Command RunAgent 调用代理程序 这能大大减少随设计元素一 起加载的代码 如果您允许用户创建私有视图或文件夹时 这尤为重要 因为他们的文件夹将多次复制操作代码 这不仅 占用空间 而且还不能进行更新 除非用户手动删除私有视图 脚本库过多脚本库过多 加载多个脚本库所需的时间并不是线性增长的 即加载 10 个脚本库所需的时间比加载 5 个脚本库所需 的时间的 2 倍还要多 脚本库使用了其他库时尤其如此 这在未来可能会得到改变 尽管如此 也存在一个平衡点 访问两个设计元素比访问一个包含相同数量代 码的设计元素所需的时间长 将经常一起使用的脚本库合并起来能够节省加载时间 尽管有时会加入不需 要在特定代理程序中调用的代码 ComputeWithFormComputeWithForm NotesDocument 的 ComputeWithForm 方法是在文档中更新计算字段但不复制代码的便捷方法 不幸的是 这比 手动 计算和分配新字段值更慢 如果您的代理程序很慢并且使用了 ComputeWithForm 向 ComputeWithForm 添加几行用于为特定字段赋值的代码就能够大大加快程序的速度 自动更新视图自动更新视图 默认情况下 使用 NotesView 对象时 它将为视图实现常规的索引刷新属性 例如 假设您更新一组 Vegetable 文档 作为这个过程的一部分 您必须在同一数据库下的 Pests 视图中查找破坏该植物 的害虫 但是当您保存了一个 Vegetable 文档时 另一个文档又被更改了 当您处理下一个文档 并查找 Pests 视图时 Lotus Notes 就知道视图索引已经过期 然后刷新它 您所做的更改不会影响 Pests 视图 但在检查已更改的文档之前 Lotus Notes 并不知道这点 对于这个例子 使用 NotesView 的 AutoUpdate 属性告诉 Lotus Notes 不必更新视图索引是个不错的主 意 除非您使用 Refresh 方法显式地请求它 这能够大大提升速度 即使您所做的更改影响到 NotesView 的内容 也可以使用这种方法 只要您的更改对自己正在做的事情 没有影响即可 例如 您知道更新将从视图删除文档 但这没有关系 因为您已开始处理下一个文档 不能使用基于高效集合的方法不能使用基于高效集合的方法 NotesDocumentCollection 类有一些以 All 结尾的方法 它们能够处理集合中的所有文档 您应该了 解这些方法 因为它们比遍历集合和操作每个文档快得多 除非您需要对每个文档执行多个操作 否则 遍历会更快 每个文档仅需保存一次 重复开销大的操作重复开销大的操作 内置类中的某些方法和属性非常慢 如果不需要 就避免使用这些函数 这能让代码的运行更快 例如 假设您处理一个文档集合 必须使用每个文档的一个字段作为查找值 以从其他视图获取信息 Dim view As NotesView Set docCur coll GetFirstDocument Do Until docCur Is Nothing Set view db GetView CustomersByID oops Don t do this in the loop Set docCust view GetDocumentByKey docCur CustI D 0 True Set docCur coll GetNextDocu ment docCur Loop 在这段样例代码中 如果 collcoll 包含 1000 个文档 我们将调用开销很大的 GetView 方法 1000 次 如果调换 DoDo UntilUntil 和 SetSet viewview 代码行的位置 代码的运行就会快得多 因为 GetView 仅被调用一次 使用代理程序探查器查找这类东西是个不错的方法 developerWorks Lotus 文章 Troubleshooting application performance Part 1 Troubleshooting techniques and code tips 和 Troubleshooting application performance Part 2 New tools in Lotus Notes Domino 7 将对此进行描述 保存未更改的文档保存未更改的文档 还记得吗 影响性能的因素之一就是修改文档的频率 当您编写处理文档的代理程序时 应该避免不必要 地保存文档更改 在为每个项赋值时 检查它是否已经拥有该值 如果最终没有修改任何东西 就不要调 用 Save 方法 通常 您可以使用搜索方法从文档集合中过滤出不需要处理的文档 如果您总是检查各个项以确定是否更改它们 代理程序的运行可能慢些 但也可能不变慢 因为保存文档 比在内存中比较信息需要更多时间 如果总是执行检查 应用程序的其他部分会更高效 比如复制 视图 索引和全文本索引 避免不必要的保存也可以减少复制冲突 复制使用项 修改时间 它并不将整个文档发送给其他副本 而 是仅发送修改的项 所以 即使最终需要保存文档 如果只修改需要新值的项 那么就能减少复制时间 使用本地副本的用户将受益匪浅 搜索文档的方法搜索文档的方法 大部分代理程序必须做的一件事情是查找一组需要处理的文档 有很多查找文档的方法 但不同的方法适 用于不同的情况 developerWorks Lotus 文章 Lotus Notes Domino 7 application performance Part 1 Database properties and document collections 讨论搜索和处理文档集的不同方法 下面概括地介绍一下 如果视图包含您需要的文档 并且以有用的方式进行排序 那么从视图读取文档就会更快 例如 使用 GetAllDocumentsByKey 方法 对于包含大量文档的数据库 FTSearch 方法比 NotesDatabase Search 方法要快