535
社区成员
发帖
与我相关
我的任务
分享Domino应用程序性能优化指南
Domino应用程序性能优化指南
应用程序性能是衡量应用程序在某些环境中，在特定工作负荷情况下如何有效运行的一种标准。您能衡量应用程序性能吗？答案是可以，它所需要的是一种独立的测试环境，包括与生产环境类似的网络、仿真用户及其工作的负荷测试软件以及大量时间。与服务器性能测试不同，在测试服务器性能时您可以不考虑CPU、RAM、NIC等变量，而应用程序性能测试涉及一次次小心翼翼地测试一个视图中一张表格的一个字段。考虑到某些定制的Notes应用程序的复杂性，这类测试不仅仅单调乏味，而且似乎永无止境。谁知道您需要花费多长的时间来减少一个设计因素、公式、脚本程序或属性，它们有可能阻碍应用程序的正常运行。
我们提供了一种简便的方法并将在本文中介绍。基于多年来评估定制的Notes应用程序来诊断性能问题方面的丰富经验，我们编译了影答复用程序性能的最通用的属性。我们在一系列文章的第一篇文章中介绍众所周知的影答复用程序性能的数据库、视图和表格属性。我们将阐述何时使用某些属性，何时不使用某些属性以获得最佳性能，适当时我们为您提供备选解决方案。本文假设您是一位富有经验的Notes应用程序开发人员。
数据库属性
当应用程序成为一种产品时数据库属性经常被忽略。但事实是通过启用和禁用某些属性，您可以提高性能且不会造成功能、开发时间和管理资源方面的损失。我们将讨论以下影响性能的通用数据库属性：
不保留未读标记
不覆盖空闲空间
保留LastAccessed 属性
不支持指定的答复层次
Web访问：需要SSL连接
所有这些属性都包含在数据库属性对话框中。前四个属性位于Advanced标签，最后一个属性位于Database Basics标签。
不保留未读标记
无可否认，这一属性让人迷惑，因为它读起来就像双重否定一样，但缺省情况下，数据库对所有读和未读文档都进行了标记。这可以用于用户希望了解在讨论论坛中哪些主题和答复是新的和未读的。但是，跟踪读和未读的文档会影响应用程序的性能。例如，假设您有一个有1,000,000 份文档的知识数据库。有10,000名用户访问该数据库，其中许多用户使用选择的复制公式本地复制该数据库。当用户复制时，它遇到了最初的延迟，因为本地和服务器复制器同步它们的未读标记（Unread Marks）表。这一流程需要与实际数据复制一样长的时间。这意味着当用户复制时他们将遇到长延迟。同样，当访问服务器上的数据库的用户最初打开数据库时也会遇到延迟，因为该程序必须读取未读标记表，以确定显示哪些文档为读/未读文档。这一延迟可能只持续数秒，但在用户的脑海中，它算得上是一次反对您的应用程序的罢工了。
要禁用这一功能，选择数据库属性对话框"高级"标签上的不保留未读标记选项。在R5 和Notes/Domino 6中，这一功能将影响整个数据库，而不仅仅是某个视图。
不覆盖空闲空间
在Notes Release 3和更早的版本中，Notes 保留了删除的数据-未加密的数据-直到删除了empty space或white space为止。在版本4中对这一功能进地了微妙的改进，从而删除的数据用随机字符覆盖，以便可以对其进行重新检索。(这称为覆盖空闲空间。)在Release 5 和Notes/Domino 6中，您可以选择启用/禁用这一功能。覆盖空闲空间将对数据库性能产生负面影响。
为了帮助您了解这一特性，例如，我们考虑从您的桌面PC中删除一些文件。当您在Windows 操作系统中删除文件时，它直接放到回收站。然后您可以清空回收站，系统显示该文件已经永久删除。现在我们讨论当清空回收站后，您意识到实际上很需要这份文件。该文件就这样永久消失了吗？ 不是这样的-它不再存在您的回收站中，但它仍旧在您的计算机中。在适当软件工具(例如Norton Utilities)的帮助下您可以检索到这一已删除的文件。
因此，做为一种安全性措施，当您删除Notes文档时，Notes覆盖已删除的数据，以防止任何人重新检索到它。当您按下F9或选择视图- 刷新时，该文档被删除。设想您的Notes文档从：
The quick brown fox jumped over the lazy dog
到：
XX XXXXXXXXXXXXX XXXXXXXXXXX XX X XXXXXXXXXX
注：这一例子不能准确地阐述Notes是如何覆盖已删除的数据的。
此时，用户是否可以检索到删除的文档已经无关紧要的，因为数据自身已经被破坏了。注意，如果您对文档进行了软删除，Notes不会覆盖该文档。只有硬删除才能激活覆盖功能。
大多数情况下我们无需保留覆盖的数据。但是，也有一些您希望Notes 继续覆盖删除的数据的情形：
服务器和数据库的物理访问受到损害，从而非法用户可以使用它们。
数据库未加密或ACL使数据库易于遭受攻击。
企业部署了需要这一功能的安全性策略。
如果您的企业、服务器或数据库未出现以上任何一种情形，那么考虑禁用这一功能－选择不覆盖空闲空间选项。
维持LastAccessed属性
我们在Release 4中开始引入了维持LastAccessed属性；它跟踪最近访问文档的日期(也就是读或修改文档的最后时间)。缺省情况下，数据库只跟踪最后修改文档的时间，但通过选择维持LastAccessed属性功能，数据库还可以跟踪最后读取文档的时间。当然，为了实现最佳的应用程序性能，您希望取消选定这一功能。
但是，这一功能对正在归档文档的用户很有用。例如，返回我们包含1,000,000 份文档的知识数据库例子，设想每天向数据库增加1,000份新文档。由于要增加如此多的文档，我们发现有必要对早期文档进行归档。我们可以使用维持LastAccessed属性功能，找出最后访问文档的时间，以确定哪些文档要被归档。我们可以保留LastAccessed属性来设置归档特性，以归档在最近18个月内未打开或读取的任何文档。
您可能希望使用这一功能来帮助归档文档到期、过期或短生命周期的任何数据库中的文档，例如，讨论数据库或工作流程数据库。但是，您可能不希望在文档很少访问或无最后访问的日期要跟踪的数据库中使用这一功能，例如，在帮助台应用程序中。
要记住的另外一件事是：LastAccessed属性不适用于Web应用程序。这一属性忽略Web浏览器的读取操作。
不支持指定的答复层次
不支持指定的答复层次使您的应用程序能够充分利用指定的答复@公式：@AllChildren和@AllDescendents。这些功能允许您根据父级文档和所有答复文档的指定标准来构建视图。现在我们以包含10,000主题和100,000答复文档的讨论数据库为例。假设您创建了一些只显示某些类别的视图，如应用程序性能。如果只对100个主题进行了分类，您可能期望该视图能够显示这100个主题以及所有相关的答复文档(以及答复文档的所有答复文档)。Notes传统上依赖于Selection公式，如：
SELECT (Form = "Main Topic" & Categories = "Application Development") | @IsResponseDoc
遗憾的是，这一公式为您提供了所有100,000份答复文档。您大概不希望看到其中大多数文档，因为您的视图将有一个答复层次。但它们全部到位，从而减缓了您的视图索引速度并占用磁盘空间。如果您选择了指定的答复层次(在Release 4中提供， Release 5 和Notes/Domino 6中的可选功能)，那么您可以使用稍微不同的公式：
SELECT (Form = "Main Topic" & Categories = "Application Development") | @AllDescendants
这一公式为您提供您正在查找的一组准确的文档，从而最大限度地减少您的视图索引和磁盘空间需求。
迄今为止，我们只告诉了您启用这一功能的原因(也就是，不选中这一选项)。但是如果您的应用程序未使用那些使用@AllChildren或@AllDescendants的公式，那么该程序没有任何理由来维持这类信息，因此您可以通过选择不支持指定的答复层次来缩短处理时间。
Web访问：需要SSL连接
Web访问：需要SSL连接选项为每个Web事务提供一个SSL(安全套接层)连接，从而对客户机和服务器之间传输的所有数据都进行了加密。在您实现SSL之后，您和您的用户将体验到近10%的性能下降。但是，每个应用程序的架构将影响这一百分比。在实现了SSL后，每个信息包都被加密， 从而需要在客户机和服务器之间进行多次来回传送的应用程序需要多次加密。
例如，假设您有使用SSL对所有表格数据进行加密的表格。该表格包含一个@DbLookup 公式。SSL对客户机和服务器之间的每次事务进行加密，因此，除了对表格数据进行加密之外， SSL还对查询事务进行加密。
有些时候为您的应用程序提供SSL是不可避免的。例如，企业策略可能要求在特殊的应用程序上运行SSL。另外，在某些情形下实现SSL最恰当不过了，例如当客户机位于 一个国家，而服务器位于另一个国家时。如果您不能确定是否可以相信一个网络，最好的方法是实现SSL。如果您有一个值得信任的网络-一个您不认为会受到损害的网络-那么您的应用程序不需要SSL，您和您的用户的性能也不会受到任何影响。
创建个人文件夹/视图
创建个人文件夹/视图是一项ACL功能。获得此项特权的用户可以创建专用视图和文件夹并把它们保存到托管数据库的服务器上。创建多个视图，尤其是大视图，会影响性能，因为它需要额外的索引。同样需要注意的是管理员或开发人员很难删除保存在服务器上的专用视图和文件夹。
compact 和updall 任务
尽管压缩应用程序和运行updall任务来刷新视图索引是不错的数据库优化措施，但它们通常不会明显提高应用程序的性能。但也有例外，如有占非常大比例White Space的数据库。但对具有5%或10%White Space的数据库运行compact 不能实现任何显而易见的性能增益。
应用程序性能是衡量应用程序在某些环境中，在特定工作负荷情况下如何有效运行的一种标准。您能衡量应用程序性能吗？答案是可以，它所需要的是一种独立的测试环境，包括与生产环境类似的网络、仿真用户及其工作的负荷测试软件以及大量时间。与服务器性能测试不同，在测试服务器性能时您可以不考虑CPU、RAM、NIC等变量，而应用程序性能测试涉及一次次小心翼翼地测试一个视图中一张表格的一个字段。考虑到某些定制的Notes应用程序的复杂性，这类测试不仅仅单调乏味，而且似乎永无止境。谁知道您需要花费多长的时间来减少一个设计因素、公式、脚本程序或属性，它们有可能阻碍应用程序的正常运行。
我们提供了一种简便的方法并将在本文中介绍。基于多年来评估定制的Notes应用程序来诊断性能问题方面的丰富经验，我们编译了影答复用程序性能的最通用的属性。我们在一系列文章的第一篇文章中介绍众所周知的影答复用程序性能的数据库、视图和表格属性。我们将阐述何时使用某些属性，何时不使用某些属性以获得最佳性能，适当时我们为您提供备选解决方案。本文假设您是一位富有经验的Notes应用程序开发人员。
数据库属性
当应用程序成为一种产品时数据库属性经常被忽略。但事实是通过启用和禁用某些属性，您可以提高性能且不会造成功能、开发时间和管理资源方面的损失。我们将讨论以下影响性能的通用数据库属性：
不保留未读标记
不覆盖空闲空间
保留LastAccessed 属性
不支持指定的答复层次
Web访问：需要SSL连接
所有这些属性都包含在数据库属性对话框中。前四个属性位于Advanced标签，最后一个属性位于Database Basics标签。
不保留未读标记
无可否认，这一属性让人迷惑，因为它读起来就像双重否定一样，但缺省情况下，数据库对所有读和未读文档都进行了标记。这可以用于用户希望了解在讨论论坛中哪些主题和答复是新的和未读的。但是，跟踪读和未读的文档会影响应用程序的性能。例如，假设您有一个有1,000,000 份文档的知识数据库。有10,000名用户访问该数据库，其中许多用户使用选择的复制公式本地复制该数据库。当用户复制时，它遇到了最初的延迟，因为本地和服务器复制器同步它们的未读标记（Unread Marks）表。这一流程需要与实际数据复制一样长的时间。这意味着当用户复制时他们将遇到长延迟。同样，当访问服务器上的数据库的用户最初打开数据库时也会遇到延迟，因为该程序必须读取未读标记表，以确定显示哪些文档为读/未读文档。这一延迟可能只持续数秒，但在用户的脑海中，它算得上是一次反对您的应用程序的罢工了。
要禁用这一功能，选择数据库属性对话框"高级"标签上的不保留未读标记选项。在R5 和Notes/Domino 6中，这一功能将影响整个数据库，而不仅仅是某个视图。
不覆盖空闲空间
在Notes Release 3和更早的版本中，Notes 保留了删除的数据-未加密的数据-直到删除了empty space或white space为止。在版本4中对这一功能进地了微妙的改进，从而删除的数据用随机字符覆盖，以便可以对其进行重新检索。(这称为覆盖空闲空间。)在Release 5 和Notes/Domino 6中，您可以选择启用/禁用这一功能。覆盖空闲空间将对数据库性能产生负面影响。
为了帮助您了解这一特性，例如，我们考虑从您的桌面PC中删除一些文件。当您在Windows 操作系统中删除文件时，它直接放到回收站。然后您可以清空回收站，系统显示该文件已经永久删除。现在我们讨论当清空回收站后，您意识到实际上很需要这份文件。该文件就这样永久消失了吗？ 不是这样的-它不再存在您的回收站中，但它仍旧在您的计算机中。在适当软件工具(例如Norton Utilities)的帮助下您可以检索到这一已删除的文件。
因此，做为一种安全性措施，当您删除Notes文档时，Notes覆盖已删除的数据，以防止任何人重新检索到它。当您按下F9或选择视图- 刷新时，该文档被删除。设想您的Notes文档从：
The quick brown fox jumped over the lazy dog
到：
XX XXXXXXXXXXXXX XXXXXXXXXXX XX X XXXXXXXXXX
注：这一例子不能准确地阐述Notes是如何覆盖已删除的数据的。
此时，用户是否可以检索到删除的文档已经无关紧要的，因为数据自身已经被破坏了。注意，如果您对文档进行了软删除，Notes不会覆盖该文档。只有硬删除才能激活覆盖功能。
大多数情况下我们无需保留覆盖的数据。但是，也有一些您希望Notes 继续覆盖删除的数据的情形：
服务器和数据库的物理访问受到损害，从而非法用户可以使用它们。
数据库未加密或ACL使数据库易于遭受攻击。
企业部署了需要这一功能的安全性策略。
如果您的企业、服务器或数据库未出现以上任何一种情形，那么考虑禁用这一功能－选择不覆盖空闲空间选项。
维持LastAccessed属性
我们在Release 4中开始引入了维持LastAccessed属性；它跟踪最近访问文档的日期(也就是读或修改文档的最后时间)。缺省情况下，数据库只跟踪最后修改文档的时间，但通过选择维持LastAccessed属性功能，数据库还可以跟踪最后读取文档的时间。当然，为了实现最佳的应用程序性能，您希望取消选定这一功能。
但是，这一功能对正在归档文档的用户很有用。例如，返回我们包含1,000,000 份文档的知识数据库例子，设想每天向数据库增加1,000份新文档。由于要增加如此多的文档，我们发现有必要对早期文档进行归档。我们可以使用维持LastAccessed属性功能，找出最后访问文档的时间，以确定哪些文档要被归档。我们可以保留LastAccessed属性来设置归档特性，以归档在最近18个月内未打开或读取的任何文档。
您可能希望使用这一功能来帮助归档文档到期、过期或短生命周期的任何数据库中的文档，例如，讨论数据库或工作流程数据库。但是，您可能不希望在文档很少访问或无最后访问的日期要跟踪的数据库中使用这一功能，例如，在帮助台应用程序中。
要记住的另外一件事是：LastAccessed属性不适用于Web应用程序。这一属性忽略Web浏览器的读取操作。
不支持指定的答复层次
不支持指定的答复层次使您的应用程序能够充分利用指定的答复@公式：@AllChildren和@AllDescendents。这些功能允许您根据父级文档和所有答复文档的指定标准来构建视图。现在我们以包含10,000主题和100,000答复文档的讨论数据库为例。假设您创建了一些只显示某些类别的视图，如应用程序性能。如果只对100个主题进行了分类，您可能期望该视图能够显示这100个主题以及所有相关的答复文档(以及答复文档的所有答复文档)。Notes传统上依赖于Selection公式，如：
SELECT (Form = "Main Topic" & Categories = "Application Development") | @IsResponseDoc
遗憾的是，这一公式为您提供了所有100,000份答复文档。您大概不希望看到其中大多数文档，因为您的视图将有一个答复层次。但它们全部到位，从而减缓了您的视图索引速度并占用磁盘空间。如果您选择了指定的答复层次(在Release 4中提供， Release 5 和Notes/Domino 6中的可选功能)，那么您可以使用稍微不同的公式：
SELECT (Form = "Main Topic" & Categories = "Application Development") | @AllDescendants
这一公式为您提供您正在查找的一组准确的文档，从而最大限度地减少您的视图索引和磁盘空间需求。
迄今为止，我们只告诉了您启用这一功能的原因(也就是，不选中这一选项)。但是如果您的应用程序未使用那些使用@AllChildren或@AllDescendants的公式，那么该程序没有任何理由来维持这类信息，因此您可以通过选择不支持指定的答复层次来缩短处理时间。
Web访问：需要SSL连接
Web访问：需要SSL连接选项为每个Web事务提供一个SSL(安全套接层)连接，从而对客户机和服务器之间传输的所有数据都进行了加密。在您实现SSL之后，您和您的用户将体验到近10%的性能下降。但是，每个应用程序的架构将影响这一百分比。在实现了SSL后，每个信息包都被加密， 从而需要在客户机和服务器之间进行多次来回传送的应用程序需要多次加密。
例如，假设您有使用SSL对所有表格数据进行加密的表格。该表格包含一个@DbLookup 公式。SSL对客户机和服务器之间的每次事务进行加密，因此，除了对表格数据进行加密之外， SSL还对查询事务进行加密。
有些时候为您的应用程序提供SSL是不可避免的。例如，企业策略可能要求在特殊的应用程序上运行SSL。另外，在某些情形下实现SSL最恰当不过了，例如当客户机位于 一个国家，而服务器位于另一个国家时。如果您不能确定是否可以相信一个网络，最好的方法是实现SSL。如果您有一个值得信任的网络-一个您不认为会受到损害的网络-那么您的应用程序不需要SSL，您和您的用户的性能也不会受到任何影响。
创建个人文件夹/视图
创建个人文件夹/视图是一项ACL功能。获得此项特权的用户可以创建专用视图和文件夹并把它们保存到托管数据库的服务器上。创建多个视图，尤其是大视图，会影响性能，因为它需要额外的索引。同样需要注意的是管理员或开发人员很难删除保存在服务器上的专用视图和文件夹。
compact 和updall 任务
尽管压缩应用程序和运行updall任务来刷新视图索引是不错的数据库优化措施，但它们通常不会明显提高应用程序的性能。但也有例外，如有占非常大比例White Space的数据库。但对具有5%或10%White Space的数据库运行compact 不能实现任何显而易见的性能增益。
...全文
请发表友善的回复…
发表回复
following80 2004-03-19
- 打赏
- 举报
好
lanzhoulamian 2004-03-19
- 打赏
- 举报
收下了
chenzb 2004-03-19
- 打赏
- 举报
kankan
ibm123 2004-03-19
- 打赏
- 举报
缓存和非缓存参数
缓存和非缓存参数适用于所有@Db公式。如果您规定了缓存参数，公式值将被保存到缓存中以便于检索。如果您规定了非缓存参数，公式值将不被保存到缓存中，因此每次查找都基于数据库来进行。开发人员经常超额使用非缓存参数并且更多的资源用于从数据库检索数据而不是从缓存。不要对您认为重要的数据使用非缓存参数。
用户反而考虑数据更改的程度：数据更改得越频繁，您就越想使用非缓存参数。对于不频繁更改的数据，使用缓存参数。例如，假设您有一个讨论数据库，其中用户可以使用规定的关键字，它们创建了新类别。(也就是每次用户创建新主题时，他或她可以为该主题规定任何类别。)在这种情况下，这类数据可能相对不重要，但您仍然需要使用非缓存参数，从而在一行中输入两个或三个主题的用户发现新类别在下一主题的关键字字段中立即反映出。为了提高性能，使用非缓存参数和ODBC访问："在索引中产生唯一的关键字"选项，它已经在第一部分中讨论过。记住："在索引中产生唯一的关键字"选项只列出唯一的类别来维护一个较小规模的视图索引。
举一个反例，假设您查找薪水信息。这是一类至关重要的信息，但是，通常每隔几个月薪水才会更改一次，从而使这类数据成为缓存的一个很好的候选对象。
LotusScript方法
Lotus测试来确定在获得一组文档方面，谁是表现最好的最常使用的LotusScript 方法-实际上在LotusScrip任何部分程序代码中最常运行的任务。在这一小节，我们比较以下常用的LotusScript方法：
db.FTSearch
db.Search
view.GetAllDocumentsByKey
view.GetDocumentByKey
在这类测试过程中，使用不同大小的数据库(10,000、100,000和1,000,000份文档)来了解每种方法是如何很好地运行的。
db.FTSearch方法
在对数据库的全文检索后，db.FTSearch返回文档集合。它运行良好，但需要当前的全文索引，也许对语法更深入的了解。此外，根据服务器的Notes.ini 设置，对返回的文件集合的大小施加了限制。当然，如果您的查找是基于多文本字段的内容，那么这是您唯一切实可行的选择。
db.Search方法
在使用视图选择公式进行数据库查找之后，db.Search返回文档集合。对于大数据库中的小规模集合来说这是相对低效率的执行程序。例如， 如果您的数据库中有100,000份文档并且您只需查找5或10份文档，您可能希望避免使用db.Search。在另一方面，它不需要全文索引和预先创建的视图，因此它是一种非常方便的查询方法。例如，如果您对几乎不能控制的数据库进行查询，这可能是您唯一可靠的选择。
view.GetAllDocumentsByKey方法
从Release 5开始，这种方法成为检索文件集合最快的方式。唯一的缺点是需要建立相关的视图。但是，只要您精简了您的视图设计和不使用昂贵的时间/日期敏感的公式(正如第一部分所讨论)，这些视图对性能和磁盘空间的影响应可以降低以最小，程序使用view.GetAllDocumentsByKey从这些视图获得文件集合的速度将非常迅速。
通常，当遍历使用任何这些方法检索到的大量文件时，您的程序应使用
set doc = DocumentCollection.GetNextDocument ( doc )
而不是
set doc = DocumentCollection.GetNthDocument ( i )
其中i从1增加到DocumentCollection.count。 对于文档小集合来说-和对于单独运行的程序来说，如预定的代理-性能下降为最小，但对于文档大集合来说-或者许多用户同时运行的程序来说会影响性能，它使GetNth成为不明智的选择。GetNth方法通常适用于您想要从集合中挑选文档的情形，而不是简单地遍历整个集合。
view.GetDocumentByKey方法
这是唯一一种不将一组文档保存到内存中的方法。view.GetDocumentByKey而是使用已经构建的视图索引作为其集合并且一次只把一份文档放到视图中。这种方法与view.AutoUpdate = False一同使用，它非常迅速且不需要内存来保存可能的大文件集合。
注：如果前一份文档已经从视图中删除，当有机会访问视图中的下一文档时，view.AutoUpdate = False主要用于避免错误信息，但它还可以显著提升性能以便运行代理。当更改文档中的数据时，使用view.AutoUpdate = False您会看到视图中有显著的改进。
事件、共享的要素和其它
以下是必须记住的一些编程注意事项：
注意表单中事件的数量，不要"overcode"
当删除程序时，注意完全删除它。不要只是重新标记它为删除，或者部分删除程序。您可以根据circle/squiggle是填满还是清空来告诉事件是否有程序代码。
共享的要素是低效率的执行程序，但是它们可以在多个位置使用，从而弥补了其糟糕的性能。
使用共享的元素来保存某些工作以及重复一个要素来提升性能时仔细考虑。
如果您实施了错误检测，确保当遇到错误时检测停止。
在精心编程的情形下，通过当它逻辑上应结束时使其继续运行，这可以确保您的程序不会"漏掉"。
大规模的子表单是低效率的执行程序。
大规模的子表单会影响应用程序的性能。如果您在应用程序中未多次使用大规模的子表单，考虑在每个表单中重复这类字段，而不是使用子表单。
使用较少的字段。
在文档中使用较少的字段与性能相关，而不是文档的大小。使用具有较多数据的较少字段，如多值字段，而不是使用较少数据的比较多的字段可以提升应用程序的性能。由于许多传统的编程人员对Notes/Domino应用程序开发不熟悉，这可能一些概念直观，但实际测试很明显地验证了这一概念。
使用view.Autoupdate=False 来阻止视图刷新。
正如前面介绍，同时使用view.GetDocumentByKey方法和这一属性可以是高效率的执行程序。
使用StampAll方法来立即修改大量文档。
当您需要使用静态值来标记大量文档时这种方法极其有效，如当前日期/时间或值的标记集。
ForAll 语句是遍历循环的最快方法。
固定数组是比动态数组更卓越的执行性能。
动态数组是比固定数组稍微低效率的执行性能，但动态数组的规模恰如其分，在您选择固定还是动态数组之前请预以权衡。
缓存和非缓存参数适用于所有@Db公式。如果您规定了缓存参数，公式值将被保存到缓存中以便于检索。如果您规定了非缓存参数，公式值将不被保存到缓存中，因此每次查找都基于数据库来进行。开发人员经常超额使用非缓存参数并且更多的资源用于从数据库检索数据而不是从缓存。不要对您认为重要的数据使用非缓存参数。
用户反而考虑数据更改的程度：数据更改得越频繁，您就越想使用非缓存参数。对于不频繁更改的数据，使用缓存参数。例如，假设您有一个讨论数据库，其中用户可以使用规定的关键字，它们创建了新类别。(也就是每次用户创建新主题时，他或她可以为该主题规定任何类别。)在这种情况下，这类数据可能相对不重要，但您仍然需要使用非缓存参数，从而在一行中输入两个或三个主题的用户发现新类别在下一主题的关键字字段中立即反映出。为了提高性能，使用非缓存参数和ODBC访问："在索引中产生唯一的关键字"选项，它已经在第一部分中讨论过。记住："在索引中产生唯一的关键字"选项只列出唯一的类别来维护一个较小规模的视图索引。
举一个反例，假设您查找薪水信息。这是一类至关重要的信息，但是，通常每隔几个月薪水才会更改一次，从而使这类数据成为缓存的一个很好的候选对象。
LotusScript方法
Lotus测试来确定在获得一组文档方面，谁是表现最好的最常使用的LotusScript 方法-实际上在LotusScrip任何部分程序代码中最常运行的任务。在这一小节，我们比较以下常用的LotusScript方法：
db.FTSearch
db.Search
view.GetAllDocumentsByKey
view.GetDocumentByKey
在这类测试过程中，使用不同大小的数据库(10,000、100,000和1,000,000份文档)来了解每种方法是如何很好地运行的。
db.FTSearch方法
在对数据库的全文检索后，db.FTSearch返回文档集合。它运行良好，但需要当前的全文索引，也许对语法更深入的了解。此外，根据服务器的Notes.ini 设置，对返回的文件集合的大小施加了限制。当然，如果您的查找是基于多文本字段的内容，那么这是您唯一切实可行的选择。
db.Search方法
在使用视图选择公式进行数据库查找之后，db.Search返回文档集合。对于大数据库中的小规模集合来说这是相对低效率的执行程序。例如， 如果您的数据库中有100,000份文档并且您只需查找5或10份文档，您可能希望避免使用db.Search。在另一方面，它不需要全文索引和预先创建的视图，因此它是一种非常方便的查询方法。例如，如果您对几乎不能控制的数据库进行查询，这可能是您唯一可靠的选择。
view.GetAllDocumentsByKey方法
从Release 5开始，这种方法成为检索文件集合最快的方式。唯一的缺点是需要建立相关的视图。但是，只要您精简了您的视图设计和不使用昂贵的时间/日期敏感的公式(正如第一部分所讨论)，这些视图对性能和磁盘空间的影响应可以降低以最小，程序使用view.GetAllDocumentsByKey从这些视图获得文件集合的速度将非常迅速。
通常，当遍历使用任何这些方法检索到的大量文件时，您的程序应使用
set doc = DocumentCollection.GetNextDocument ( doc )
而不是
set doc = DocumentCollection.GetNthDocument ( i )
其中i从1增加到DocumentCollection.count。 对于文档小集合来说-和对于单独运行的程序来说，如预定的代理-性能下降为最小，但对于文档大集合来说-或者许多用户同时运行的程序来说会影响性能，它使GetNth成为不明智的选择。GetNth方法通常适用于您想要从集合中挑选文档的情形，而不是简单地遍历整个集合。
view.GetDocumentByKey方法
这是唯一一种不将一组文档保存到内存中的方法。view.GetDocumentByKey而是使用已经构建的视图索引作为其集合并且一次只把一份文档放到视图中。这种方法与view.AutoUpdate = False一同使用，它非常迅速且不需要内存来保存可能的大文件集合。
注：如果前一份文档已经从视图中删除，当有机会访问视图中的下一文档时，view.AutoUpdate = False主要用于避免错误信息，但它还可以显著提升性能以便运行代理。当更改文档中的数据时，使用view.AutoUpdate = False您会看到视图中有显著的改进。
事件、共享的要素和其它
以下是必须记住的一些编程注意事项：
注意表单中事件的数量，不要"overcode"
当删除程序时，注意完全删除它。不要只是重新标记它为删除，或者部分删除程序。您可以根据circle/squiggle是填满还是清空来告诉事件是否有程序代码。
共享的要素是低效率的执行程序，但是它们可以在多个位置使用，从而弥补了其糟糕的性能。
使用共享的元素来保存某些工作以及重复一个要素来提升性能时仔细考虑。
如果您实施了错误检测，确保当遇到错误时检测停止。
在精心编程的情形下，通过当它逻辑上应结束时使其继续运行，这可以确保您的程序不会"漏掉"。
大规模的子表单是低效率的执行程序。
大规模的子表单会影响应用程序的性能。如果您在应用程序中未多次使用大规模的子表单，考虑在每个表单中重复这类字段，而不是使用子表单。
使用较少的字段。
在文档中使用较少的字段与性能相关，而不是文档的大小。使用具有较多数据的较少字段，如多值字段，而不是使用较少数据的比较多的字段可以提升应用程序的性能。由于许多传统的编程人员对Notes/Domino应用程序开发不熟悉，这可能一些概念直观，但实际测试很明显地验证了这一概念。
使用view.Autoupdate=False 来阻止视图刷新。
正如前面介绍，同时使用view.GetDocumentByKey方法和这一属性可以是高效率的执行程序。
使用StampAll方法来立即修改大量文档。
当您需要使用静态值来标记大量文档时这种方法极其有效，如当前日期/时间或值的标记集。
ForAll 语句是遍历循环的最快方法。
固定数组是比动态数组更卓越的执行性能。
动态数组是比固定数组稍微低效率的执行性能，但动态数组的规模恰如其分，在您选择固定还是动态数组之前请预以权衡。
ibm123 2004-03-19
- 打赏
- 举报
ODBC访问
ODBC访问属性"在索引中产生唯一的关键字"为数据库的相互关联提供唯一的关键字。您可以使用这一属性来进行快速查找。方法是：假设您有包含10,000 个主题和100,000份答复文档的讨论数据库。该数据库包括只显示10,000 个主题的隐藏视图，旨在查找所有现有的类别。如果您选择了隐藏视图的ODBC访问属性，您可以将每个类别的文档数量减少到一份。这一属性取消了所有复制的文档。使用隐藏视图上的@DbLookup将实现快速查找，因为它显著缩小了视图的大小。例如，如果在数据库中只有50个独一无二的类别，这种隐藏式查找视图将只包括50份文档而不是10,000份。
注：如果您的文档有多个类别，您需要在视图列公式中使用程序代码 ，以确保可以显示和查找到所有类别。
表单属性
只有一种表单属性真正影响应用程序的性能：自动刷新字段。如果您在表单中激活了自动刷新功能，每次您从一个字段移动到另一个字段时，自动刷新功能更新所有先前的字段。例如，当您移动到表单中的第二个字段时，自动刷新功能更新表单中的第一个字段，当您移动到第三个字段时，它更新第一个和第二个字段。这一功能最新将影响应用程序的性能，尤其是表单使用工作流程和查找时。对于包含验证公式的简单表单来说，自动刷新功能几乎不会影响性能。对于较复杂的表单来说，考虑使用退出事件而不是自动刷新。
前台/后台编程
当谈到编程时，我们简单的区别有时也称为的前台程序和后台程序。前台程序是从应用程序的用户界面（UI）运行的程序，例如，从操作菜单手动运行一项代理。这类程序的优势在于易于诊断，因为您可以通过手工测试很容易地确定程序运行良好和低效率运行。前台程序的性能问题经常与字段、按钮、代理相关-某些您可以更改的UI元素。正如在第一篇文章中建议的，一个良好的测试环境可以帮助您隔离这类故障。
后台程序是在后台运行的程序。这包括预定的代理，它不时成为与系统性能相关的故障的来源。例如，您可能拥有一个清除数据库保存/复制冲突的预定的代理，您可能发现该代理在不正常的时间范围内完成其任务，或者它消耗大量紊乱的系统资源来完成这一项任务。要测试后台程序，审视您的日志是否异常，如完成一项任务的长时间流逝。如果您正在测试的后台程序是代理，检查代理日志，查看代理是如何很好地完成其任务的。
现在，我们区分了前台程序和后台程序，那么我们讨论一些影响这两者性能的常见程序错误。
临时变量
编程时开发人员最容易犯的一个错误是不能使用临时变量作为检索昂贵的数据的占位符。最明显的一个例子是依靠@DbLookup 公式结果的程序。如果您的程序使用要查找多次的数据，那么将该数据设为局部变量。现在您可以根据需要多次使用这一数据，包括：
检查错误条件时
将数据分解成更小的单元时(例如，多值列表)
对数据进行排序时
另一个典型例子是拥有大量数据和用户的文档，用户可以通过点击按钮，以不同的方式对数据进行排序。这种功能旨在模似悬浮的视图排序功能，但发生在文档的大表格内部。很明显，这是一个将您的大量数据设为局部变量，然后对局部变量进行排序的恰如其分的环境。它带来的性能方面的差异令人惊讶。在作者过去需要花费一分多钟时间来运行的程序通过局部变量的使用降低到一秒内。
最后，第三个例子是查找数据库中特定名称的视图的程序。您可能被通过db.views 属性进行循环所吸引，但您可以通过第一次设定局部变量，如viewLIST = db.views来缩短程序运行时间，然后您可以反复使用该临时变量以实现最佳的性能。
计算字段
限制文档中计算的次数可以提升性能。文档中计算执行的次数越多，程序运行的速度就越慢。无论什么时候您以读模式打开一份文件，系统要进行一些计算。当您以编辑模式打开一份文件，或从读模式切换到编辑模式时，系统要进行其它计算。用户应该了解以读模式打开文件和以编辑模式打开文件所用时间的比例，从而确定要减少的字段/计算。以下介绍每种情况的一些例子：
如果文件经常读取，而不是编辑
在这种情况下，系统触发@DbLookup和@DbColumn公式，从而字段包含这些程序公式在读模式下不要运行。例如，您可以在检查@IsDocBeingEdited 的IF语句中把这类公式用括号括起来。关键字字段是这一程序的首要候选对象，因为它们经常包含@DbLookup或@DbColumn公式，例如，一个称为Klist的关键字字段可能有以下公式：
@If(@IsDocBeingEdited; @DbColumn("Notes"; ""; ViewName; 1); kList)
注：在Else条件语句中，我们按原样保留字段的内容，从而在读模式中，无论已经选择了何值系统都将显示，但不会进行进一步计算。此外，您可以选择向按钮添加程序代码，用户可以点击该按钮来运行程序。注：在读模式中，运行显示字段计算，从而确信这些字段不会使用这些耗时的公式。
如果文件经常读取，然后切换到编辑模式
在这种情况下，确保您阻止执行的任何程序（如前面所述）在切换到编辑模式之后开始执行。例如，当用户以读模式打开文件时使用@DbLookup或 @DbColumn公式的关键性字段为防止运行的首要候选对象。但如果用户将文件切换到编辑模式，使用postModeChange事件强迫文件刷新(例如，if source.editmode then call source.refresh)。此外，选择关键性字段选项"文件刷新选项。" 在选定该选项之后，当用户从读模式切换到编辑模式时，文件自动刷新一次并强迫关键性字段重新求值。
如果文件经常以编辑模式打开
在这种情形下，您可以希望尽可能多的把昂贵(性能方面)的程序转移到按钮中，从而频繁的编辑不会陷入困境。这假设即使在编辑文件时，大多数用户不需要更改所有关键性字段。
您可能认为上述建议需要更多的计算，而不是少数计算。从某种意义上讲，这是对的。只有采用这些步骤才能避免昂贵的计算，如@Db 公式，同时不用括号把简单的@properCase的括起来，例如使用@If(@IsDocBeingEdited)。它不值得做。
刷新字段值
通过选择表格属性对话框表格信息标记上的自动刷新字段选项，您可以设置字段值为自动刷新。
这样做会对您的性能产生负面影响，因为每次用户把鼠标移到表格字段时所有以前的字段都重新计算。这一繁重计算的目的是首先检查Input Translation和Input Validation公式，但实际上所有程序都运行。
当用户选择特定值时，如果您需要刷新计算的字段中的关键字表，选择字段属性对话框控制标记上的"当关键字改变时刷新域"选项。例如，假设您在表格中有多个关键字字段，关键字字段二、三和四的值不同，取决于用户在关键字字段一中选择的值。在这种情况下，使用"当关键字改变时刷新域"功能。这就像按下F9键一样，只是每次这一关键字字段中的值更改后它自动运行。这提供了胜过表单对话框中"自动刷新域"选项的性能，因为文档只在第一个关键字字段中的值更改后才刷新，而不是任何值更改后都刷新。注：您必须为其它关键字字段设置字段选项"当文档刷新时刷新选择"。任何无需参与这一动态关系的关键字字段无需设置这一项功能，因此当第一个关键字字段的值更改后它们无需刷新。
使用"创建时计算"的域类型
当用户创建文档时创建时计算计算字段的值。您可以使用创建时计算来延续这些值，或者如果某些其它程序将设置一个字段，但您希望它保留原值。例如，响应文件中名为OriginalSubject的字段包含公式Subject。如果用户创建响应文件，该字段沿袭选定的主文件，再也无需计算。另一个例子是称为DateClosed的字段，它由运行操作条上按钮的程序代码。由于从未想过这一字段更改自己的值，我们将其设为创建时计算并使用公式DateClosed。这使其可以做为占位符公式来运行。它只在第一次计算时才尝试计算(在这种情况下，我们假设无沿袭值在使用)，此后只采用强行输入的值。注： 只要用户保存了文件，创建时计算的域向输入到其中的值应用正确的数据类型。
您可能会问，在这两个例子中使用创建时计算的域 和计算域 有什么区别。主要的区别很简单，每次编辑、刷新和保存文件时计算域都计算，即使它没有真正的工作要执行也是如此。如果有大量与上述一样简单的公式，那么这一字段类型会给您的应用程序的性能带来稍许差异。但是，如果在您的表单中有许多类似的字段，您将看到性能方面的差异。在此例中，由于设置这一字段为计算字段不会带来任何优势，您的用户可以获得更好的性能。一个真正不劳而获的例子！
ODBC访问属性"在索引中产生唯一的关键字"为数据库的相互关联提供唯一的关键字。您可以使用这一属性来进行快速查找。方法是：假设您有包含10,000 个主题和100,000份答复文档的讨论数据库。该数据库包括只显示10,000 个主题的隐藏视图，旨在查找所有现有的类别。如果您选择了隐藏视图的ODBC访问属性，您可以将每个类别的文档数量减少到一份。这一属性取消了所有复制的文档。使用隐藏视图上的@DbLookup将实现快速查找，因为它显著缩小了视图的大小。例如，如果在数据库中只有50个独一无二的类别，这种隐藏式查找视图将只包括50份文档而不是10,000份。
注：如果您的文档有多个类别，您需要在视图列公式中使用程序代码 ，以确保可以显示和查找到所有类别。
表单属性
只有一种表单属性真正影响应用程序的性能：自动刷新字段。如果您在表单中激活了自动刷新功能，每次您从一个字段移动到另一个字段时，自动刷新功能更新所有先前的字段。例如，当您移动到表单中的第二个字段时，自动刷新功能更新表单中的第一个字段，当您移动到第三个字段时，它更新第一个和第二个字段。这一功能最新将影响应用程序的性能，尤其是表单使用工作流程和查找时。对于包含验证公式的简单表单来说，自动刷新功能几乎不会影响性能。对于较复杂的表单来说，考虑使用退出事件而不是自动刷新。
前台/后台编程
当谈到编程时，我们简单的区别有时也称为的前台程序和后台程序。前台程序是从应用程序的用户界面（UI）运行的程序，例如，从操作菜单手动运行一项代理。这类程序的优势在于易于诊断，因为您可以通过手工测试很容易地确定程序运行良好和低效率运行。前台程序的性能问题经常与字段、按钮、代理相关-某些您可以更改的UI元素。正如在第一篇文章中建议的，一个良好的测试环境可以帮助您隔离这类故障。
后台程序是在后台运行的程序。这包括预定的代理，它不时成为与系统性能相关的故障的来源。例如，您可能拥有一个清除数据库保存/复制冲突的预定的代理，您可能发现该代理在不正常的时间范围内完成其任务，或者它消耗大量紊乱的系统资源来完成这一项任务。要测试后台程序，审视您的日志是否异常，如完成一项任务的长时间流逝。如果您正在测试的后台程序是代理，检查代理日志，查看代理是如何很好地完成其任务的。
现在，我们区分了前台程序和后台程序，那么我们讨论一些影响这两者性能的常见程序错误。
临时变量
编程时开发人员最容易犯的一个错误是不能使用临时变量作为检索昂贵的数据的占位符。最明显的一个例子是依靠@DbLookup 公式结果的程序。如果您的程序使用要查找多次的数据，那么将该数据设为局部变量。现在您可以根据需要多次使用这一数据，包括：
检查错误条件时
将数据分解成更小的单元时(例如，多值列表)
对数据进行排序时
另一个典型例子是拥有大量数据和用户的文档，用户可以通过点击按钮，以不同的方式对数据进行排序。这种功能旨在模似悬浮的视图排序功能，但发生在文档的大表格内部。很明显，这是一个将您的大量数据设为局部变量，然后对局部变量进行排序的恰如其分的环境。它带来的性能方面的差异令人惊讶。在作者过去需要花费一分多钟时间来运行的程序通过局部变量的使用降低到一秒内。
最后，第三个例子是查找数据库中特定名称的视图的程序。您可能被通过db.views 属性进行循环所吸引，但您可以通过第一次设定局部变量，如viewLIST = db.views来缩短程序运行时间，然后您可以反复使用该临时变量以实现最佳的性能。
计算字段
限制文档中计算的次数可以提升性能。文档中计算执行的次数越多，程序运行的速度就越慢。无论什么时候您以读模式打开一份文件，系统要进行一些计算。当您以编辑模式打开一份文件，或从读模式切换到编辑模式时，系统要进行其它计算。用户应该了解以读模式打开文件和以编辑模式打开文件所用时间的比例，从而确定要减少的字段/计算。以下介绍每种情况的一些例子：
如果文件经常读取，而不是编辑
在这种情况下，系统触发@DbLookup和@DbColumn公式，从而字段包含这些程序公式在读模式下不要运行。例如，您可以在检查@IsDocBeingEdited 的IF语句中把这类公式用括号括起来。关键字字段是这一程序的首要候选对象，因为它们经常包含@DbLookup或@DbColumn公式，例如，一个称为Klist的关键字字段可能有以下公式：
@If(@IsDocBeingEdited; @DbColumn("Notes"; ""; ViewName; 1); kList)
注：在Else条件语句中，我们按原样保留字段的内容，从而在读模式中，无论已经选择了何值系统都将显示，但不会进行进一步计算。此外，您可以选择向按钮添加程序代码，用户可以点击该按钮来运行程序。注：在读模式中，运行显示字段计算，从而确信这些字段不会使用这些耗时的公式。
如果文件经常读取，然后切换到编辑模式
在这种情况下，确保您阻止执行的任何程序（如前面所述）在切换到编辑模式之后开始执行。例如，当用户以读模式打开文件时使用@DbLookup或 @DbColumn公式的关键性字段为防止运行的首要候选对象。但如果用户将文件切换到编辑模式，使用postModeChange事件强迫文件刷新(例如，if source.editmode then call source.refresh)。此外，选择关键性字段选项"文件刷新选项。" 在选定该选项之后，当用户从读模式切换到编辑模式时，文件自动刷新一次并强迫关键性字段重新求值。
如果文件经常以编辑模式打开
在这种情形下，您可以希望尽可能多的把昂贵(性能方面)的程序转移到按钮中，从而频繁的编辑不会陷入困境。这假设即使在编辑文件时，大多数用户不需要更改所有关键性字段。
您可能认为上述建议需要更多的计算，而不是少数计算。从某种意义上讲，这是对的。只有采用这些步骤才能避免昂贵的计算，如@Db 公式，同时不用括号把简单的@properCase的括起来，例如使用@If(@IsDocBeingEdited)。它不值得做。
刷新字段值
通过选择表格属性对话框表格信息标记上的自动刷新字段选项，您可以设置字段值为自动刷新。
这样做会对您的性能产生负面影响，因为每次用户把鼠标移到表格字段时所有以前的字段都重新计算。这一繁重计算的目的是首先检查Input Translation和Input Validation公式，但实际上所有程序都运行。
当用户选择特定值时，如果您需要刷新计算的字段中的关键字表，选择字段属性对话框控制标记上的"当关键字改变时刷新域"选项。例如，假设您在表格中有多个关键字字段，关键字字段二、三和四的值不同，取决于用户在关键字字段一中选择的值。在这种情况下，使用"当关键字改变时刷新域"功能。这就像按下F9键一样，只是每次这一关键字字段中的值更改后它自动运行。这提供了胜过表单对话框中"自动刷新域"选项的性能，因为文档只在第一个关键字字段中的值更改后才刷新，而不是任何值更改后都刷新。注：您必须为其它关键字字段设置字段选项"当文档刷新时刷新选择"。任何无需参与这一动态关系的关键字字段无需设置这一项功能，因此当第一个关键字字段的值更改后它们无需刷新。
使用"创建时计算"的域类型
当用户创建文档时创建时计算计算字段的值。您可以使用创建时计算来延续这些值，或者如果某些其它程序将设置一个字段，但您希望它保留原值。例如，响应文件中名为OriginalSubject的字段包含公式Subject。如果用户创建响应文件，该字段沿袭选定的主文件，再也无需计算。另一个例子是称为DateClosed的字段，它由运行操作条上按钮的程序代码。由于从未想过这一字段更改自己的值，我们将其设为创建时计算并使用公式DateClosed。这使其可以做为占位符公式来运行。它只在第一次计算时才尝试计算(在这种情况下，我们假设无沿袭值在使用)，此后只采用强行输入的值。注： 只要用户保存了文件，创建时计算的域向输入到其中的值应用正确的数据类型。
您可能会问，在这两个例子中使用创建时计算的域 和计算域 有什么区别。主要的区别很简单，每次编辑、刷新和保存文件时计算域都计算，即使它没有真正的工作要执行也是如此。如果有大量与上述一样简单的公式，那么这一字段类型会给您的应用程序的性能带来稍许差异。但是，如果在您的表单中有许多类似的字段，您将看到性能方面的差异。在此例中，由于设置这一字段为计算字段不会带来任何优势，您的用户可以获得更好的性能。一个真正不劳而获的例子！
ibm123 2004-03-19
- 打赏
- 举报
视图属性
有许多影响视图性能的关键领域：
时间/日期敏感的公式(选择或列公式)
时间/日期敏感的公式(选择或列公式)
阅读者名称字段!
ODBC 访问
时间/日期敏感的视图
时间/日期敏感的视图是一种包含具有时间/日期公式（如@Modified 或@Now）的列或具有时间/日期公式的选择公式的视图。这些视图可以提供强大的功能，但它们也是高成本的性能方法。每隔15分钟， Domino服务器运行更新任务来刷新数据库中的所有视图索引。用户不能对这一项任务进行配置(也就是说您不能配置该任务来按不同的时间表运行)。假设在上午9:00该项任务运行以刷新数据库中的所有视图。在上午9:02，修改该数据库中的文档。在上午9:15，该更新任务再次运行，注意系统已经修改了这一数据库中的文档。它可能已经被邮寄、复制、创建、更新、删除，但不管怎样，自从上次更新任务运行后文档修改发生了，因此必须检查该数据库以查找过期的视图。
此时，系统把有可能包含修改的文档的所有视图标记为过时视图。并且所有时间/日期敏感的视图被标记为将要过时的视图。因此，除了更新您合理假设需要更新的视图外，索引指示器还需要更新所有时间/日期敏感的视图。但事情变得更糟糕了。这些视图不能被刷新；它们必须重建，重建工作需要非常长的时间。为了形成这一时间观念，如果您进行某些敏感的诊断工作，您将发现普通视图需要100毫秒的时间来刷新，但普通的时间/日期敏感的视图需要10-50秒(不是毫秒)来刷新，因为它们是真正的在重建。在一台繁忙的服务器上，每15分钟有许多的数据库需要检查，有许多视图需要更新，您的运行环境承担不起在单个视图上花费这么长的时间。
同样需要注意的是设置视图属性对话框刷新字段为手工刷新(相对于自动刷新或一段时间后自动刷新)可以迅速地打开视图且不会影响15分钟的更新任务。
如果视图刷新未设为手动，那么每次用户打开该视图时，它强迫进行重建。当然，使用这一设置意味着当用户打开该视图时，它没有必要是最新的，因此您必须权衡性能优势和过期数据潜在的劣势。
时间/日期敏感的视图是一项非常有用(但极其昂贵)的功能，因此请小心使用。
检查日志文件
如果您不能确定刷新或重建视图的时间，请使用日志文件。在服务器配置文件中选择Log_update=2，以记录索引指示器刷新/重建视图的时间。它列出刷新/重建的每个数据库中的每个视图，从而使您能够跟踪对某一视图或数据库花费了多长时间。经过一些实践，您就可以相当迅速地找出服务器上发生的任何故障。
时间/日期备选方案
我们提供您可以为时间/日期敏感的视图实施的备选方案：
根据 http://www-1.ibm.com/support/docview.wss?uid=swg27003557 上的《Time/Date Views in Notes: What Are the Options? 》中介绍，在选择公式中使用 @Text。这种备选方案有一定局限性，但非常有用，它是一个不错的执行程序。
运行代理来标记将在时间/日期敏感的视图中显示的文档。例如，如果您有一个显示状态为"Open"且DueDate 为在今天之前的文档的视图，您可以夜间运行代理，用OverDueFlag = "是"来标记这类文档，从而您的视图选择公式只需要检查这类标记。文档关闭后这类标记也将被删除。虽然这是单服务器数据库的重要解决方案，如果您的用户经常使用本地复制文档，它并不是最佳的解决方案，因为它们必须复制每天代理的数据更改。同样，如果您的数据库复制到全球的数十台服务器，您可能不希望使用这一功能。
创建根据日期对文档进行分类的视图。这一解决方案很简单，因而经常被忽视。使用上面的例子，创建一个根据DueDate对所有状态＝"Open"的文档进行分类的视图。用户可以轻松地检查过期的文档或将到期的文档，只需简单地滚动到正确的日期类别。
列排序
列排序是允许用户按升序、降序或两者对视图中的列进行排序的一项功能。视图列上的每个排序箭头增加了视图索引以及它用于刷新该视图的时间。从用户界面和维护角度来看，最好是拥有大量排序箭头的单一视图，而不是多个视图。但是，从性能角度来看， 关键是避免向视图添加过多的排序箭头且不减少视图的整体数量。为了给出一些特殊的标准，您将发现向视图添加两个排序箭头将增加近似两倍的索引工作/时间，四个排序箭头增加四倍的视图索引工作/时间。
提示：检查只用于查找的隐藏视图，在这些视图中并未使用排序箭头，因此如果存在它们应该被删除。
读者姓名字段
读者姓名字段并不是视图的属性，但它们会影响视图的性能。读者姓名字段可以为文档提供安全性，但会对显示包含读者姓名字段的文档的视图产生负面影响。例如，假设您为10,000 名员工建立了一个人力资源数据库并假设有一个显示所有10,000 份文档的平面视图（未分类视图）。由于阅读者姓名限制，每位员工只能看到自己的文档。当员工打开数据库时，Domino服务器对文档进行排序来确定将向该位用户显示的文档。通常，如果没有读者域，系统将向用户全屏显示前30份文档。您可以打开视图，按向下箭头来进行一次快速测试，以确定这一点。您可以迅速滚动浏览十几行；然后稍微停顿一下，通常时间低于一秒，同时服务器读取另外一块将被显示的数据。滚动浏览以30行重新开始，然后发生另一次停顿。
但是，在HR应用程序中，服务器不能在用户显示界面上全屏显示数据。这不是问题，但服务器无法知道它不能全屏显示，因此它继续对所有10,000份文档进行排序，旨在查找用户可以看到的更多的文档。最后，遍览所有文档之后，服务器放弃，并显示一份文档，但延迟时间可能会很长。在独立的运行环境中，延迟时间可能为数秒，但在真实的生产环境中，有许多用户正在尝试执行相同的任务，由于延迟， 大多数用户会出现超时。
有数种备选方案可以帮助您避免这一问题：
对视图进行分类，选择"首次打开数据库时折叠所有的文档"选项取消视图中的类别。虽然这一设置会稍微影响性能，这是真的，但是在这种情况下它将带来大量的优势。
不要选择"不显示空分类"选项以只显示包含文档的类别。选择这一功能将产生与使用平面视图相同的结果：在向用户显示任何事件之前服务器必须检查所有10,000份文档。
使用显示一个类别的嵌入式视图。使用@UserName公式来显示属于该位用户的文档。这是一个奇妙的执行程序，它也将杰出地为Web浏览器工作。
注：视图中与读者姓名字段相关的性能问题是一样的，与用户是使用Web浏览器还是Notes客户机无关。
有许多影响视图性能的关键领域：
时间/日期敏感的公式(选择或列公式)
时间/日期敏感的公式(选择或列公式)
阅读者名称字段!
ODBC 访问
时间/日期敏感的视图
时间/日期敏感的视图是一种包含具有时间/日期公式（如@Modified 或@Now）的列或具有时间/日期公式的选择公式的视图。这些视图可以提供强大的功能，但它们也是高成本的性能方法。每隔15分钟， Domino服务器运行更新任务来刷新数据库中的所有视图索引。用户不能对这一项任务进行配置(也就是说您不能配置该任务来按不同的时间表运行)。假设在上午9:00该项任务运行以刷新数据库中的所有视图。在上午9:02，修改该数据库中的文档。在上午9:15，该更新任务再次运行，注意系统已经修改了这一数据库中的文档。它可能已经被邮寄、复制、创建、更新、删除，但不管怎样，自从上次更新任务运行后文档修改发生了，因此必须检查该数据库以查找过期的视图。
此时，系统把有可能包含修改的文档的所有视图标记为过时视图。并且所有时间/日期敏感的视图被标记为将要过时的视图。因此，除了更新您合理假设需要更新的视图外，索引指示器还需要更新所有时间/日期敏感的视图。但事情变得更糟糕了。这些视图不能被刷新；它们必须重建，重建工作需要非常长的时间。为了形成这一时间观念，如果您进行某些敏感的诊断工作，您将发现普通视图需要100毫秒的时间来刷新，但普通的时间/日期敏感的视图需要10-50秒(不是毫秒)来刷新，因为它们是真正的在重建。在一台繁忙的服务器上，每15分钟有许多的数据库需要检查，有许多视图需要更新，您的运行环境承担不起在单个视图上花费这么长的时间。
同样需要注意的是设置视图属性对话框刷新字段为手工刷新(相对于自动刷新或一段时间后自动刷新)可以迅速地打开视图且不会影响15分钟的更新任务。
如果视图刷新未设为手动，那么每次用户打开该视图时，它强迫进行重建。当然，使用这一设置意味着当用户打开该视图时，它没有必要是最新的，因此您必须权衡性能优势和过期数据潜在的劣势。
时间/日期敏感的视图是一项非常有用(但极其昂贵)的功能，因此请小心使用。
检查日志文件
如果您不能确定刷新或重建视图的时间，请使用日志文件。在服务器配置文件中选择Log_update=2，以记录索引指示器刷新/重建视图的时间。它列出刷新/重建的每个数据库中的每个视图，从而使您能够跟踪对某一视图或数据库花费了多长时间。经过一些实践，您就可以相当迅速地找出服务器上发生的任何故障。
时间/日期备选方案
我们提供您可以为时间/日期敏感的视图实施的备选方案：
根据 http://www-1.ibm.com/support/docview.wss?uid=swg27003557 上的《Time/Date Views in Notes: What Are the Options? 》中介绍，在选择公式中使用 @Text。这种备选方案有一定局限性，但非常有用，它是一个不错的执行程序。
运行代理来标记将在时间/日期敏感的视图中显示的文档。例如，如果您有一个显示状态为"Open"且DueDate 为在今天之前的文档的视图，您可以夜间运行代理，用OverDueFlag = "是"来标记这类文档，从而您的视图选择公式只需要检查这类标记。文档关闭后这类标记也将被删除。虽然这是单服务器数据库的重要解决方案，如果您的用户经常使用本地复制文档，它并不是最佳的解决方案，因为它们必须复制每天代理的数据更改。同样，如果您的数据库复制到全球的数十台服务器，您可能不希望使用这一功能。
创建根据日期对文档进行分类的视图。这一解决方案很简单，因而经常被忽视。使用上面的例子，创建一个根据DueDate对所有状态＝"Open"的文档进行分类的视图。用户可以轻松地检查过期的文档或将到期的文档，只需简单地滚动到正确的日期类别。
列排序
列排序是允许用户按升序、降序或两者对视图中的列进行排序的一项功能。视图列上的每个排序箭头增加了视图索引以及它用于刷新该视图的时间。从用户界面和维护角度来看，最好是拥有大量排序箭头的单一视图，而不是多个视图。但是，从性能角度来看， 关键是避免向视图添加过多的排序箭头且不减少视图的整体数量。为了给出一些特殊的标准，您将发现向视图添加两个排序箭头将增加近似两倍的索引工作/时间，四个排序箭头增加四倍的视图索引工作/时间。
提示：检查只用于查找的隐藏视图，在这些视图中并未使用排序箭头，因此如果存在它们应该被删除。
读者姓名字段
读者姓名字段并不是视图的属性，但它们会影响视图的性能。读者姓名字段可以为文档提供安全性，但会对显示包含读者姓名字段的文档的视图产生负面影响。例如，假设您为10,000 名员工建立了一个人力资源数据库并假设有一个显示所有10,000 份文档的平面视图（未分类视图）。由于阅读者姓名限制，每位员工只能看到自己的文档。当员工打开数据库时，Domino服务器对文档进行排序来确定将向该位用户显示的文档。通常，如果没有读者域，系统将向用户全屏显示前30份文档。您可以打开视图，按向下箭头来进行一次快速测试，以确定这一点。您可以迅速滚动浏览十几行；然后稍微停顿一下，通常时间低于一秒，同时服务器读取另外一块将被显示的数据。滚动浏览以30行重新开始，然后发生另一次停顿。
但是，在HR应用程序中，服务器不能在用户显示界面上全屏显示数据。这不是问题，但服务器无法知道它不能全屏显示，因此它继续对所有10,000份文档进行排序，旨在查找用户可以看到的更多的文档。最后，遍览所有文档之后，服务器放弃，并显示一份文档，但延迟时间可能会很长。在独立的运行环境中，延迟时间可能为数秒，但在真实的生产环境中，有许多用户正在尝试执行相同的任务，由于延迟， 大多数用户会出现超时。
有数种备选方案可以帮助您避免这一问题：
对视图进行分类，选择"首次打开数据库时折叠所有的文档"选项取消视图中的类别。虽然这一设置会稍微影响性能，这是真的，但是在这种情况下它将带来大量的优势。
不要选择"不显示空分类"选项以只显示包含文档的类别。选择这一功能将产生与使用平面视图相同的结果：在向用户显示任何事件之前服务器必须检查所有10,000份文档。
使用显示一个类别的嵌入式视图。使用@UserName公式来显示属于该位用户的文档。这是一个奇妙的执行程序，它也将杰出地为Web浏览器工作。
注：视图中与读者姓名字段相关的性能问题是一样的，与用户是使用Web浏览器还是Notes客户机无关。
