| 级别: 初级 IBM, 2003 年 5 月 01 日 应用程序性能是衡量应用程序在某些环境中，在特定工作负荷情况下如何有效运行的一种标准。您能衡量应用程序性能吗？答案是可以，它所需要的是一种独立的测试环境，包括与生产环境类似的网络、仿真用户及其工作的负荷测试软件以及大量时间。与服务器性能测试不同，在测试服务器性能时您可以不考虑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 不能实现任何显而易见的性能增益。
视图属性
有许多影响视图性能的关键领域：
- 时间/日期敏感的公式(选择或列公式)
- 时间/日期敏感的公式(选择或列公式)
- 阅读者名称字段!
- 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访问
ODBC访问属性"在索引中产生唯一的关键字"为数据库的相互关联提供唯一的关键字。您可以使用这一属性来进行快速查找。方法是：假设您有包含10,000 个主题和100,000份答复文档的讨论数据库。该数据库包括只显示10,000 个主题的隐藏视图，旨在查找所有现有的类别。如果您选择了隐藏视图的ODBC访问属性，您可以将每个类别的文档数量减少到一份。这一属性取消了所有复制的文档。使用隐藏视图上的@DbLookup将实现快速查找，因为它显著缩小了视图的大小。例如，如果在数据库中只有50个独一无二的类别，这种隐藏式查找视图将只包括50份文档而不是10,000份。
注：如果您的文档有多个类别，您需要在视图列公式中使用程序代码 ，以确保可以显示和查找到所有类别。 表单属性
只有一种表单属性真正影响应用程序的性能：自动刷新字段。如果您在表单中激活了自动刷新功能，每次您从一个字段移动到另一个字段时，自动刷新功能更新所有先前的字段。例如，当您移动到表单中的第二个字段时，自动刷新功能更新表单中的第一个字段，当您移动到第三个字段时，它更新第一个和第二个字段。这一功能最新将影响应用程序的性能，尤其是表单使用工作流程和查找时。对于包含验证公式的简单表单来说，自动刷新功能几乎不会影响性能。对于较复杂的表单来说，考虑使用退出事件而不是自动刷新。 结语
在本文中，我们讨论了一些将影响应用程序性能的最普通的属性；但是，定制的应用程序会有一些将影响性能的独特的属性组合。虽然您有可能体验到改进的性能启用或禁用本文中介绍的功能，您仍将发现测试您的应用程序以查看是否可以实现进一步改进很有用-记住，应用程序性能测试是一项艰验、耗时的工作。在本系列文章的下一篇文章中，我们讨论将影响应用程序性能的代理和程序代码。
关于作者
| |
| |
|
IBM has authored this article |
|
