Domino 应用程序性能优化指南Word文档格式.docx

Domino 应用程序性能优化指南Word文档格式.docx

《Domino 应用程序性能优化指南Word文档格式.docx》由会员分享，可在线阅读，更多相关《Domino 应用程序性能优化指南Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

在R5和Notes/Domino6中，这一功能将影响整个数据库，而不仅仅是某个视图。

∙不覆盖空闲空间

在NotesRelease3和更早的版本中，Notes保留了删除的数据-未加密的数据-直到删除了emptyspace或whitespace为止。

在版本4中对这一功能进地了微妙的改进，从而删除的数据用随机字符覆盖，以便可以对其进行重新检索。

（这称为覆盖空闲空间。

）在Release5和Notes/Domino6中，您可以选择启用/禁用这一功能。

覆盖空闲空间将对数据库性能产生负面影响。

为了帮助您了解这一特性，例如，我们考虑从您的桌面PC中删除一些文件。

当您在Windows操作系统中删除文件时，它直接放到回收站。

然后您可以清空回收站，系统显示该文件已经永久删除。

现在我们讨论当清空回收站后，您意识到实际上很需要这份文件。

该文件就这样永久消失了吗？

不是这样的-它不再存在您的回收站中，但它仍旧在您的计算机中。

在适当软件工具（例如NortonUtilities）的帮助下您可以检索到这一已删除的文件。

因此，做为一种安全性措施，当您删除Notes文档时，Notes覆盖已删除的数据，以防止任何人重新检索到它。

当您按下F9或选择视图-刷新时，该文档被删除。

设想您的Notes文档从：

Thequickbrownfoxjumpedoverthelazydog

到：

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

注：

这一例子不能准确地阐述Notes是如何覆盖已删除的数据的。

此时，用户是否可以检索到删除的文档已经无关紧要的，因为数据自身已经被破坏了。

注意，如果您对文档进行了软删除，Notes不会覆盖该文档。

只有硬删除才能激活覆盖功能。

大多数情况下我们无需保留覆盖的数据。

但是，也有一些您希望Notes继续覆盖删除的数据的情形：

∙服务器和数据库的物理访问受到损害，从而非法用户可以使用它们。

∙数据库未加密或ACL使数据库易于遭受攻击。

∙企业部署了需要这一功能的安全性策略。

如果您的企业、服务器或数据库未出现以上任何一种情形，那么考虑禁用这一功能－选择不覆盖空闲空间选项。

∙保留LastAccessed属性

在Release4中开始引入了维持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="

MainTopic"

&

Categories="

ApplicationDevelopment"

）|@IsResponseDoc

遗憾的是，这一公式为您提供了所有100,000份答复文档。

您大概不希望看到其中大多数文档，因为您的视图将有一个答复层次。

但它们全部到位，从而减缓了您的视图索引速度并占用磁盘空间。

如果您选择了指定的答复层次（在Release4中提供，Release5和Notes/Domino6中的可选功能），那么您可以使用稍微不同的公式：

）|@AllDescendants

这一公式为您提供您正在查找的一组准确的文档，从而最大限度地减少您的视图索引和磁盘空间需求。

迄今为止，我们只告诉了您启用这一功能的原因（也就是，不选中这一选项）。

但是如果您的应用程序未使用那些使用@AllChildren或@AllDescendants的公式，那么该程序没有任何理由来维持这类信息，因此您可以通过选择不支持指定的答复层次来缩短处理时间。

∙Web访问：

需要SSL连接

需要SSL连接选项为每个Web事务提供一个SSL（安全套接层）连接，从而对客户机和服务器之间传输的所有数据都进行了加密。

在您实现SSL之后，您和您的用户将体验到近10%的性能下降。

但是，每个应用程序的架构将影响这一百分比。

在实现了SSL后，每个信息包都被加密，从而需要在客户机和服务器之间进行多次来回传送的应用程序需要多次加密。

例如，假设您有使用SSL对所有表格数据进行加密的表格。

该表格包含一个@DbLookup公式。

SSL对客户机和服务器之间的每次事务进行加密，因此，除了对表格数据进行加密之外，SSL还对查询事务进行加密。

有些时候为您的应用程序提供SSL是不可避免的。

例如，企业策略可能要求在特殊的应用程序上运行SSL。

另外，在某些情形下实现SSL最恰当不过了，例如当客户机位于一个国家，而服务器位于另一个国家时。

如果您不能确定是否可以相信一个网络，最好的方法是实现SSL。

如果您有一个值得信任的网络-一个您不认为会受到损害的网络-那么您的应用程序不需要SSL，您和您的用户的性能也不会受到任何影响。

所有这些属性都包含在数据库属性对话框中。

前四个属性位于Advanced标签，最后一个属性位于DatabaseBasics标签。

∙创建个人文件夹/视图

创建个人文件夹/视图是一项ACL功能。

获得此项特权的用户可以创建专用视图和文件夹并把它们保存到托管数据库的服务器上。

创建多个视图，尤其是大视图，会影响性能，因为它需要额外的索引。

同样需要注意的是管理员或开发人员很难删除保存在服务器上的专用视图和文件夹。

∙compact和updall任务

尽管压缩应用程序和运行updall任务来刷新视图索引是不错的数据库优化措施，但它们通常不会明显提高应用程序的性能。

但也有例外，如有占非常大比例WhiteSpace的数据库。

但对具有5%或10%WhiteSpace的数据库运行compact不能实现任何显而易见的性能增益。

2.

有许多影响视图性能的关键领域：

∙时间/日期敏感的公式（选择或列公式）

时间/日期敏感的视图是一种包含具有时间/日期公式（如@Modified或@Now）的列或具有时间/日期公式的选择公式的视图。

这些视图可以提供强大的功能，但它们也是高成本的性能方法。

每隔15分钟，Domino服务器运行更新任务来刷新数据库中的所有视图索引。

用户不能对这一项任务进行配置（也就是说您不能配置该任务来按不同的时间表运行）。

假设在上午9:

00该项任务运行以刷新数据库中的所有视图。

在上午9:

02，修改该数据库中的文档。

15，该更新任务再次运行，注意系统已经修改了这一数据库中的文档。

它可能已经被邮寄、复制、创建、更新、删除，但不管怎样，自从上次更新任务运行后文档修改发生了，因此必须检查该数据库以查找过期的视图。

此时，系统把有可能包含修改的文档的所有视图标记为过时视图。

并且所有时间/日期敏感的视图被标记为将要过时的视图。

因此，除了更新您合理假设需要更新的视图外，索引指示器还需要更新所有时间/日期敏感的视图。

但事情变得更糟糕了。

这些视图不能被刷新；

它们必须重建，重建工作需要非常长的时间。

为了形成这一时间观念，如果您进行某些敏感的诊断工作，您将发现普通视图需要100毫秒的时间来刷新，但普通的时间/日期敏感的视图需要10-50秒（不是毫秒）来刷新，因为它们是真正的在重建。

在一台繁忙的服务器上，每15分钟有许多的数据库需要检查，有许多视图需要更新，您的运行环境承担不起在单个视图上花费这么长的时间。

同样需要注意的是设置视图属性对话框刷新字段为手工刷新（相对于自动刷新或一段时间后自动刷新）可以迅速地打开视图且不会影响15分钟的更新任务。

如果视图刷新未设为手动，那么每次用户打开该视图时，它强迫进行重建。

当然，使用这一设置意味着当用户打开该视图时，它没有必要是最新的，因此您必须权衡性能优势和过期数据潜在的劣势。

时间/日期敏感的视图是一项非常有用（但极其昂贵）的功能，因此请小心使用。

检查日志文件：

如果您不能确定刷新或重建视图的时间，请使用日志文件。

在服务器配置文件中选择Log_update=2，以记录索引指示器刷新/重建视图的时间。

它列出刷新/重建的每个数据库中的每个视图，从而使您能够跟踪对某一视图或数据库花费了多长时间。

经过一些实践，您就可以相当迅速地找出服务器上发生的任何故障。

∙时间/日期备选方案：

我们提供您可以为时间/日期敏感的视图实施的备选方案：

∙根据上的《Time/DateViewsinNotes:

WhatAretheOptions?

》中介绍，在选择公式中使用@Text。

这种备选方案有一定局限性，但非常有用，它是一个不错的执行程序。

∙运行代理来标记将在时间/日期敏感的视图中显示的文档。

例如，如果您有一个显示状态为"

Open"

且DueDate为在今天之前的文档的视图，您可以夜间运行代理，用OverDueFlag="

是"

来标记这类文档，从而您的视图选择公式只需要检查这类标记。

文档关闭后这类标记也将被删除。

虽然这是单服务器数据库的重要解决方案，如果您的用户经常使用本地复制文档，它并不是最佳的解决方案，因为它们必须复制每天代理的数据更改。

同样，如果您的数据库复制到全球的数十台服务器，您可能不希望使用这一功能。

∙创建根据日期对文档进行分类的视图。

这一解决方案很简单，因而经常被忽视。

使用上面的例子，创建一个根据DueDate对所有状态＝"

的文档进行分类的视图。

用户可以轻松地检查过期的文档或将到期的文档，只需简单地滚动到正确的日期类别

∙列排序

列排序是允许用户按升序、降序或两者对视图中的列进行排序的一项功能。

视图列上的每个排序箭头增加了视图索引以及它用于刷新该视图的时间。

从用户界面和维护角度来看，最好是拥有大量排序箭头的单一视图，而不是多个视图。

但是，从性能角度来看，关键是避免向视图添加过多的排序箭头且不减少视图的整体数量。

为了给出一些特殊的标准，您将发现向视图添加两个排序箭头将增加近似两倍的索引工作/时间，四个排序箭头增加四倍的视图索引工作/时间。

提示：

检查只用于查找的隐藏视图，在这些视图中并未使用排序箭头，因此如果存在它们应该被删除。

∙读者姓名字段

读者姓名字段并不是视图的属性，但它们会影响视图的性能。

读者姓名字段可以为文档提供安全性，但会对显示包含读者姓名字段的文档的视图产生负面影响。

例如，假设您为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份。

如果您的文档有多个类别，您需要在视图列公式中使用程序代码，以确保可以显示和查找到所有类别。

3.

只有一种表单属性真正影响应用程序的性能：

自动刷新字段。

如果您在表单中激活了自动刷新功能，每次您从一个字段移动到另一个字段时，自动刷新功能更新所有先前的字段。

例如，当您移动到表单中的第二个字段时，自动刷新功能更新表单中的第一个字段，当您移动到第三个字段时，它更新第一个和第二个字段。

这一功能最新将影响应用程序的性能，尤其是表单使用工作流程和查找时。

对于包含验证公式的简单表单来说，自动刷新功能几乎不会影响性能。

对于较复杂的表单来说，考虑使用退出事件而不是自动刷新。

4.前台/后台编程

当谈到编程时，我们简单的区别有时也称为的前台程序和后台程序。

前台程序是从应用程序的用户界面（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事件强迫文件刷新（例如，ifsource.editmodethencallsource.refresh）。

此外，选择关键性字段选项"

文件刷新选项。

在选定该选项之后，当用户从读模式切换到编辑模式时，文件自动刷新一次并强迫关键性字段重新求值。

∙如果文件经常以编辑模式打开

在这种情形下，您可以希望尽可能多的把昂贵（性能方面）的程序转移到按钮中，从而频繁的编辑不会陷入困境。

这假设即使在编辑文件时，大多数用户不需要更改所有关键性字段。

您可能认为上述建议需要更多的计算，而不是少数计算。

从某种意义上讲，这是对的。

只有采用这些步骤才能避免昂贵的计算，如@Db公式，同时不用括号把简单的@properCase的括起来，例如使用@If（@IsDocBeingEdited）。

它不值得做。

∙刷新字段值

通过选择表格属性对话框表格信息标记上的自动刷新字段选项，您可以设置字段值为自动刷新。

这样做会对您的性能产生负面影响，因为每次用户把鼠标移到表格字段时所有以前的字段都重新计算。

这一繁重计算的目的是首先检查InputTranslation和InputValidation公式，但实际上所有程序都运行。

当用户选择特定值时，如果您需要刷新计算的字段中的关键字表，选择字段属性对话框控制标记上的"

当关键字改变时刷新域"

选项。

例如，假设您在表格中有多个关键字字段，关键字字段二、三和四的值不同，取决于用户在关键字字段一中选择的值。

在这种情况下，使用"

功能。

这就像按下F9键一样，只是每次这一关键字字段中的值更改后它自动运行。

这提供了胜过表单对话框中"

自动刷新域"

选项的性能，因为文档只在第一个关键字字段中的值更改后才刷新，而不是任何值更改后都刷新。

您必须为其它关键字字段设置字段选项"

当文档刷新时刷新选择"

。

任何无需参与这一动态关系的关键字字段无需设置这一项功能，因此当第一个关键字字段的值更改后它们无需刷新。

∙使用"

创建时计算"

的域类型