IBM zSeries 上的 Lotus Domino 7

随着 Notes/Domino 7 及其所产生的良好基准数值的发布，很多客户会提出问题，“这将为我在生产环境中带来多少价值？”在本文中，我们讨论了将 zOS for zSeries 上的两个 IBM 生产 Domino 服务器从 Domino 6.5.x 升级到 Domino 7 时，我们所观察到的性能结果。我们给出了运行在这些 DPAR（Domino Partition Server）中的各种 Domino 任务的性能，帮助您理解 Domino 7 在您的环境中所能带来的好处。

我们知道，不是所有客户都将从迁移到 Domino 7 中获得相同的结果。有些客户可能看到比已发布的基准更好的数值，而有些客户可能看到较小的改进。另外，即使在同一客户站点，有的 DPAR 可能看到比同一位置的另一台 DPAR 更好的数值。通过理解 Domino 中的哪些进程得到性能改进，您将能更好地预测您在自己的 DPAR 上可能看到的性能改进。

在本文中，我们将：

• 回顾升级 Domino 7 DPAR 的环境。
• 概括用于度量生产 DPAR 的方法学。
• 记录从生产 DPAR 升级中获得的结果（多达 28% 的 CPU 使用率改善）。

我们假定您是一名有经验的 Domino 管理员。有关 Domino 7 中所有新功能的介绍，请参阅 developerWorks Lotus 文章 "Lotus Domino 7.0 中的新特性"。

硬件和软件配置

本文讨论的两个 z/OS DPAR（称为 D01MLC83 和 D01MLC96）驻留在相同物理硬件的相同 LPAR（逻辑分区）中，称为 ML96。机器还有另一个 LPAR，上面有几个其他的 DPAR。ML96 LPAR 的硬件和软件配置如下所示：

D01MLC83 DPAR 于 2004 年 12 月 9 日从 Domino 6.5.3 升级到 Domino 7 (Milestone 3)，有大约 335 个注册用户。我们后来将此 DPAR 升级到 beta 3（2005 年 1 月 27 日）和 beta 4（2005 年 4 月 29 日），然后在 2005 年 8 月 26 日升级到 Domino 7 Gold candidate build。在 beta 版本期间，注册用户的数量从 335 增长到 900。D01MLC83 当前有 870 个注册用户，具有 348 个用户的 “15 分钟活动” 率（换句话说，平均每间隔 15 分钟，就有 348 个用户是活动的），活动率是 40%。（在本文后面我们将谈到有关 “15 分钟活动” 率。）邮件模板使用情况如下：85% 运行 Notes 6 邮件模板，10% 运行 Notes 5，3% 运行 Notes 4.5，2% 运行其他版本。

D01MLC96 DPAR 于 2005 年 2 月 26 日从 Domino 6.5.3 升级到 Domino 7 (Milestone 4)，有 3,483 个注册用户。从那以后，我们已经将此 DPAR 升级到 beta 4（2005 年 4 月 29 日），然后在 2005 年 9 月 9 日升级到 Domino 7 Gold candidate build。在 beta 版本期间，注册用户的数量从 3,483 变为 3,280。D01MLC96 当前有 3,280 个注册用户，具有 1,150 个用户的 “15 分钟活动” 率（占 36%）。邮件模板使用情况如下：89% 运行 Notes 6 邮件模板，7% 运行 Notes 5，3% 运行 Notes 4.5，1% 运行其他版本。

我们在两台服务器上运行以下服务器任务：

• ServerTasks=Update, Adminp, CalConn, Collect, Router, Sched, Amgr, http, dbscan mail1.box, dbscan mail2.box, dbscan mail3.box, tmmscan, tmmscan
• ServerTasksAt1=Catalog
• ServerTasksAt2=UpdAll

我们只在 D01MLC83 上运行带 SSL 支持的 HTTP。在两台服务器上，我们已经配置了 SMTP 用于入站和出站邮件。我们使用一个包含 495,000 个条目的 Extended Directory Catalog，并使用 Directory Assistance for edircat，以及另一个辅助目录（用于 public 组）。我们还在 D01MLC83 上启用 LDAP for Domino Web Access 身份验证。我们没有任何代理限制，因此用户可以运行个人代理。我们设置了 Admin4.nsf，这样它只在空闲期间进行复制。我们在每个 DPAR 上有三个 Mail.box 文件。

我们略微修改了服务器的 Notes.ini 文件，使其包括以下设置：
AMgr-DisableMailLoopup=1
DEBUG_THREADID=1
Disable_BCC_Group_Expansion=1
FT_FLY_INDEX_OFF=1
IOCP_DISABLE_ASYNC_NOTIFICATION=1
MAILBOXDISABLETXNLOGGING=1
NSF_BUFFER_POOL_SIZE_MB=256 (在 D01MLC96 上), 172 (在 D01MLC83 上)
NSF_DBCACHE_MAXENTRIES=2300 (在 D01MLC96 上), 516 (在 D01MLC83 上)
RouterEnableMailByDest = 1
SERVER_ENABLE_THREADPOOL=1
SERVER_MAX_CONNCURRENT_TRANS=-1 (对于 zOS，将默认值设置为不受限制。)
SERVER_POOL_TASKS=125 (我们建议保留此值的默认值，即 100。我们在调试/问题分析期间将此值从默认值 100 更改为 125。)
SERVER_SESSION_TIMEOUT=31
TRANSLOG_HARDWARECOMPRESS=1

为了提供备份，我们在相同的 LPAR 上运行 Tivoli Storage Manager 服务器作为 Domino 服务器。启用事务日志记录，并使用存档日志记录。完全备份和增量备份只能空闲期间（off shift）运行，带有一天内的存档日志备份。我们还为事务日志记录运行 zSeries 硬件压缩（Domino 7 的一个特性）。

其他软件包括 Trend Micro Scanmail（每 DPAR 使用两个 tmmscans），以及 IBM Tivoli Monitoring for Messaging and Collaboration。

度量生产 DPAR

在我们讨论结果之前，首先需要解释一下如何度量生产 DPAR。这与基准测试完全不同，其中的环境完全受到控制。在基准测试环境中使用的度量方法不一定可以应用到生产环境，在生产环境中，工作负载可能发生变化，不仅仅是每天、每小时有变化，甚至每分钟都有变化。

为了比较 Domino 7 和 Domino 6.5，我们需要在它们运行 Domino 6.5.x 代码时，比较来自两个 DPAR 的数据。对于 D01MLC83，这是在 2004 年 12 月 12 日之前，而对于 D01MLC96，这是在 2005 年 2 月 26 日之前。对于本文，我们将考察主要工作时间（prime shift）这些 DPAR 的性能（主要工作时间定义为周一到周五，DPAR 的本地时间上午 8 点到下午 4 点）。

与度量生产工作负载相比，度量基准工作负载相当直接。在基准测试环境中，您可以控制安装，正确地设置哪些程序运行在服务器上，从基准测试客户端以某个特定的比率。您还可以改变参数，某行代码，或者工作负载项，甚至可以重新运行基准测试以获得好的度量结果。

在生产工作负载中，事情就变得有些复杂了。在任何给定时间，您不知道服务器被用户驱动了哪些工作负载。除了度量被服务器消耗的资源外，还必须度量服务器上正被驱动的工作负载。Domino 有许多不同的组件可能影响您的服务器资源。

下面只是一些可能对服务器造成重大影响的示例情况：

• 使用某个新功能的用户。
• 显著增加消息工作负载的大量邮件投递（或邮件病毒）。
• 改变处理现有工作负载方式的客户端或服务器代码的新版本。
• 在任何给定的服务器上，由于合并和损耗，注册/活动用户的数量不断变化。
• 随季节趋势（休假/节假日）不断变化的用户活动。
• 新的用户代理开始运行。
• 改变复制/集群计划。
• 正被使用的不同视图/索引。
• 启动管理进程（AdminP、Fixup、Compact、备份/恢复，等等）。

生产负载和基准负载之间另一个大的不同是您选择度量什么？在基准测试中，您通常会遇到一段起步时期（ramp-up period），可能会花费数小时。在用户已经与服务器建立连接后，您就达到了度量的 "稳定状态"。此起步时期的工作负载不包括在基准测试的稳定状态度量中。在生产负载中，必须计划好有足够的容量来应付尖峰负载，而不是平均的稳定状态。用户经常来来去去您的 DPAR。最坏的情况是假日的第一天，或者在主要工作时间重启 DPAR，这时会有大量用户在很短的时间内全部登录到 DPAR。从一个版本发展到另一个版本时，这些尖峰负载的变化就是您需要规划的，而不能只考虑平均工作负载。

在图 1 中，您可以看到 IBM 的一组生产 DPAR 上 15 分钟活动用户的年趋势。这种趋势反映了一年来在这些 DPAR 上活动用户的典型使用情况。可以看到，在感恩节和圣诞节/新年之际有明显的下降。另外，还有一个从大约 2 月份开始的年趋势。这时，活动用户的数量开始减少，在整个夏天的几个月有较大幅度的下降。注意，在我们的大型生产 DPAR 上，从 8 月中期到 9 月中期活动用户有多达两位数的增长（CPU 使用也随之增长），这不是一个异常。

图 1. 15 分钟活动用户的年趋势

部分活动用户的减少也归结于随时间的推移在任何给定 DPAR 上的损失率。如果一年期间没有新用户加入，DPAR 就会开始损失用户（因为他们可能离职、退休等）。这反映在过去一年里 D01MLC83 和 D01MLC96 上注册用户数的变化中。在一年内，Notes/Domino 管理员有时还会将用户添加到 DPAR 以替代损失的用户。您必须在分析中将这些随时间推移的变化计算在注册和活动用户人数中。

在检查 DPAR 上的用户活动时，应该考察 Domino 的活动用户数，而不是服务器用户数。活动用户率表明有多少不同的用户在规定间隔内是活动的。server.users 数表明有多少用户连接到您的 DPAR。这些用户在其会话被 DPAR 超时或者客户端结束会话之前进行计数。通过改变 SERVER_SESSION_TIMEOUT Notes.ini 参数，您可以对 server.user 数产生重要影响，哪怕 DPAR 吞吐率仍然是相同的。这一统计数据不代表用户数的绝对指示，但却相对于 SERVER_SESSION_TIMEOUT 值。因此，它不是您的生产环境工作负载的有效指示。如果您正在比较的 DPAR 上有不同的值， 这一点尤其为真。

例如，假定您改变了超时值，从两小时设置为默认值 4 小时，然后继续运行相同的用户负载。您的 server.users 值可能会上升 20%。这并不意味着您在 DPAR 上有更多的活动用户；它意味着您的 DPAR 正为相同的工作负载管理更多已连接的用户。您并没有通过更改此值添加了 20% 的用户，或者通过降低此值减少了活动用户数。这是在基准测试环境中通常应该注意的，server.user 数不会改变，因为（正如 NotesBench 所定义的那样）所有用户都是每隔 15 分钟活动的。我们在度量生产环境中的用户活动时，发现 Domino 的 15 分钟活动用户统计数据（即 server.users.active15min）是非常有用的。

理解这些工作负载模式让我们可以计划和预测 DPAR 的工作负载增长（在本例中，在 9 月份的劳动节附近）。如果我们不理解这些工作负载周期，将无法看到此时间段内所使用的资源增长，可能认为出现了问题。我们认为此工作负载的变化印证了 DPAR 使用量随时间变化的事实，因此，我们不要误解为随着与工作负载变化相关的性能增强/降低而出现 CPU 的变化。

您可能还会被使用 Domino 事务数来度量工作负载所诱惑。这一计数与 NotesBench 运行的事务数完全不同。NotesBench 运行的事务数派生自客户端，而不是 Domino 服务器统计数据。DPAR 上的 Domino 事务数统计数据用于度量发生在该 DPAR 上的 NRPC (Notes Remote Procedure Calls) 数。

对于从 Domino 5 升级到 Domino 6 的内部和外部用户，我们看到 DPAR 上驱动的事务数在夜间的可度量的变化。虽然活动用户数是相同的，但每活动用户的事务数发生了变化。这就是某个时间间隔的活动用户总数除以该时间间隔的事务总数。事务数的不同有时源自 DPAR 上新版本的代码。Notes 客户端能够利用不同的调用来完成相同的工作。我们可能看到既有增长，也有下降，最大的差距几乎达到每用户 20%。另外，如果您升级到 Notes 客户端，可以看到事务数上升或下降的趋势，这是因为更多的用户现在能够为其现有的负载使用新的调用或函数。

与使用事务数相关的其他问题还有，不是所有事务都是相同的。对于两个 DPAR 来说，很可能粗略地显示相同的事务数，但它们有不同的 CPU 使用量，因为在每个 DPAR 上可能驱动着不同的事务。一个 DPAR 可能正在运行客户端上几乎所有本地复制工作，并且除了复制之外不做其他事情，而另一个 DPAR 可能其所有 Notes 客户端都正在直接访问 DPAR 上的邮件数据库。与使用事务数相关的其他问题还有，这只适用于 NRPC 工作负载。如果正使用其他客户端（Web、IMAP、POP3 等），事务数不会反映报告这些活动的标准方式。要记住的关键一点是，服务器上的 Domino 事务数统计数据是 Notes 客户端和 Domino 服务器之间调用数的度量，而不是正请求 DPAR 完成工作量的基本度量。

图 2 给出了过去一年中针对两个 DPAR（D01MLC83 和 D01MLC96）的事务总数。图中的点 A 表示 D01MLC83 升级的时候，而点 B 表示 D01MLC96 升级的时候。

图 2. 每个 DPAR 的事务总数

在图 2 中，注意在 1 月到 3 月的时间段中，D01MLC83（红线）的事务总数有一次大的下降，然后增长。如果划分到每用户事务数，我们将看到不同的趋势（参见图 3）。

图 3. 每用户事务

在图 3 中的 A 点，D01MLC83 中每活动用户的事务数有一个增长（大约在第一次发布 Domino 7 beta 期间）。在 B 点，我们可以看到 D01MLC83 上出现每用户事务数的大下降，这对应于总体事务下降。在 C 点，我们可以看到每用户事务数的进一步稍微下降，这时注册用户（和 15 分钟活动用户）倍增。

我们知道在 3 月份有较多的用户添加到 D01MLC83，而此时 15 分钟活动事务线仍然保持平坦，因此可以说，事务总数的增长归功于更多用户（更多的用户完成相同的工作负载）。不过，D01MLC83 中事务总数在 1 月份的下降反映了性能和工作负载特征的某些变化（用户数相同，但每用户事务少了），或者环境变化（代码级别、网络）导致了事务差异。如果只考察 12 月份和 3 月份的总事务数，我们只是粗略地看到相同的统计数，哪怕是活动用户从 12 月到 3 月增长了将近两倍。虽然 D01MLC96 的总事务数显示了全年的一些波动，但此 DPAR 上每活动用户的事务数相对平稳。

但是，D01MLC96 和 D01MLC83 的行为不同。点 D 表明 D01MLC96 第一次升级到 Domino 7 beta 版本。我们可以看到，每用户的事务数并没有发生重大变化。我们还可以看到，D01MLC96 的比率相比前两个月有下降的趋势，然后再次上升。这种上升趋势与前几个月的 D01MLC83 线是相匹配的。

为了准确地用动态工作负载度量生产服务器的性能，我们需要度量每 15 分钟活动用户的成本。要完成这项任务，我们将取得在一个时间间隔中使用的总体 CPU 时间，然后用该时间间隔中 15 分钟活动用户总数除以它。如果此每 15 分钟活动用户的成本保持平坦，但总的 CPU 时间线上升（或下降），我们就可以断定，这是一个与工作负载或容量相关的问题。如果每 15 分钟活动用户的成本上升/下降，我们更可能认为这是一个性能相关的问题（或者在本例中，是因为新版本带来的性能改进）。

我们在 zSeries 上监视的另一个方面是 DPAR 中的信号量使用情况。虽然这无法直接转换成 CPU 数，但我们可以通过理解信息量使用情况中的变化，看到潜在的瓶颈或匮乏。

图 4 是我们研究期间 D01MLC96 最繁忙的信息量（总数）的一个例子。可以清楚地看到，在 2 月 26 日，信号量使用情况有一次变化，这是由于第一次发布 Domino 7 beta。您还可以看到使用 Domino 7 后此生产工作负载中信号量的减少。图 4 中两个标记为 ‘__unknown’ 的信号量是新的 Domino 7 信号量，在撰写本文时，我们的当前制表进程还没有一个这样的图。

我们可以针对每种信号量类型进一步将信号量分解成各种锁（读、写）和级别（最低到操作系统级别锁定）。我们可以看到 Domino 7 所带来的好处，它 采用管理信号量的方式，减少类似工作负载所需的信号量。

图 4. D01MLC96 最繁忙信息量的例子

Notes/Domino 6 与 7 的比较

图 5 显示了过去一年针对 MLC83 和 MLC96 的每用户成本。

图 5. 每用户 CPU 成本

2004 年 12 月在 D01MLC83 上的 Domino 7 第一次发布标识在 A 点，而且伴随着一次每用户成本的较大增长。此第一次 beta 版本包括了当时所需的所有的调试代码。您可以看到，自此之后，每用户成本逐步下降，其中有两次大的下降在 B 点和 C 点。点 B 反映了一次新的 beta 版本发布，而点 C 反映了一次新的 beta 版本和 D01MLC83 上的一次用户增长。

虽然这些数值看起来很好，但我们需要注意，这是经过了一段扩展时期的生产环境，各种进程将以一个级别在一个示例 (Domino 6) 中运行，而不是以相同级别在其他示例 (Domino 7) 中运行。诸如 Compact、Fixup、AdminP、Updall 和其他维护任务（比如备份和恢复）等进程都是非常 CPU 敏感的，并且与用户工作负载不是直接相关的。不必查找在主要工作时间这些任务未运行的个别天数，我们将它们从 Domino 6 和 7 的多周示例中忽略掉。我们还要忽略掉用于 TMSCAN 的 CPU，因为这不是 Domino 7 代码的一部分，而是正在运行的反病毒管理程序。

为了完成这一点，我们需要确定每 Domino 任务消耗的 CPU 量。通过描绘 D01MLC83 上的这一数据，我们看到结果如图 6 所示。

图 6. 每 Domino 任务 (D01MLC83) 消耗的 CPU 量

而 D01MLC96 的结果显示在图 7 中。

图 7. 每 Domino 任务 (D01MLC96) 消耗的 CPU 量

针对这些维护任务这两个 DPAR 中的 CPU 数量不是非常大。但它们确实改变了每用户成本的百分比，多达几个百分点。在每 15 分钟活动用户成本上，D01MLC83 赢得了几个百分点，而 D01MLC96 损失了几个百分点。正如我们和其他用户看到的那样，如果这些任务只出现在您的示例中，而不在其他示例中，这些任务可能对您的数量产生较大的影响。通过查看 DPAR 中个别进程使用情况，我们可以看到这些任务对我们的数据产生什么影响。

虽然 D01MLC96 上使用的 CPU 总秒数（CPU 下降）看起来比 D01MLC83 上使用的 CPU 总秒数（CPU 实际上增长）好很多，但夏天几个月中 D01MLC96 上用户数的减少使得每 15 分钟活动用户的成本增加，而 D01MLC83 上活动用户的增加抵消了 CPU 使用量增量，因此实际上在 D01MLC83 上每用户成本更低。

下图显示了针对每一正在运行的主要 Domino 任务每 15 分钟活动用户 CPU 秒数的减少。在图 8 中，我们可以看到，所使用 CPU 最大的下降是 Server 任务，紧接着是 Logasio 任务。

图 8. 进程产生的每 15 分钟活动用户所使用的 CPU 秒数减少

图 9 显示了针对每一运行在两个 DPAR 上的主要任务，CPU 使用量节省（正值）或损失（负值）的百分比。记住，大部分 CPU 周期由 Server 任务使用。而有些其他任务显示出较大的变化，与图 9 中使用的总 CPU 相比，实际 CPU 使用量的此百分比会更小些。

图 9. 15 分钟活动用户的 CPU 节省百分比

我们可以看到 Domino 7 增强功能所带来的 Server 任务的节省。我们还可以看到，对于事务日志程序，硬件压缩的 zSeries 实现在 Logasio 任务中有 80% 到 90% 的节省。需要记住，大部分用于事务日志记录的 CPU 周期不在 Logasio 任务中，而在驱动数据库更改的各种其他任务中（Server、Agent Manager HTTP、IMAP 等）。这些任务还将获得一些为事务日志记录使用 zSeries 硬件压缩的节省。

注意 Router 中的负节省（表示每 15 分钟活动用户的更多 CPU 使用量）。如果我们考察由 Router 任务处理的每消息成本，我们可以看到，在 Domino 7 中只有较小的 CPU 成本（参见图 10）。

图 10. 由 Router 任务处理的每消息成本

这表明 Domino 7 的每消息成本更低，但我们的数据显示，在我们的 Domino 7 度量中，Router 任务更昂贵。这表明，在我们的 Domino 6 和 Domino 7 示例之间，每用户的消息量增加了。图 11 显示了过去一年中每用户消息量的增长。

图 11. 消息增长

另一个生成某些引人关注的数量的方面是 NSF 数据库缓存使用量。图 12 显示了 NSF 数据库缓存中正在使用的条目的百分比。Domino 可以动态地扩展此缓存中条目的百分比，多达 50%。因此，如果 DPAR 需要扩展条目，我们可能期望看到超过 100% 的值。注意 D01MLC83 和 D01MLC96 的缓冲池中条目数的较大下降。

图 12. NSF 数据库缓存中正在使用的条目

虽然 Notes/Domino 7 代码在管理数据库缓存条目时可能有些不同，但另一个数据负载变化的指标是初始化和所处理的副本数。对于复制不频繁的数据库（或者较少的数据库被复制），我们在 DBCache 中需要较少的活动条目。图 13 显示了由每个 DPAR 初始化的数据库副本数。

图 13. 由每个 DPAR 初始化的副本

对于复制和集群，大部分 CPU 使用量花在 Server 任务，而不是 Replica 或 Clustering 任务。

对于 D01MLC83 和 D01MLC96，我们可以看到从 Domino 6 到 Domino 7 时间段副本数的下降。由于针对 D01MLC83 的比较是在去年 11/12 月，其副本差异比 D01MLC96 更大（针对 D01MLC96 的比较是在今年 1/2 月）。这还表明为什么针对 D01MLC83 的 Server 任务存在较大差异，因为对于该 DPAR，其 Domino 6 基数的副本数变化/百分比要比 D01MLC96 及其基数更有说服力。

在图 14 中，您可以看到将 DPAR 升级到 Domino 7 的结果以及它所带来的节省。我们已经给出了每个 DPAR 使用的总 CPU 和每 15 分钟活动用户的 CPU。绿色的条表示与前几周（假日除外）运行 Domino 6 相比，Domino 7 使用的每 DPAR 的 CPU 使用量的百分比不同。蓝色的条说明了相同的比较，但我们用总 CPU 除以 15 分钟活动用户数。

图 14. 从 Notes/Domino 6 到 7 的比较结果

这表明，在 Domino 6 和 7 之间， D01MLC96 所使用的 CPU 有较大的下降，这与度量其总体 CPU 利用率一样。不过，当此 CPU 使用量针对工作负载进行调整后，我们发现，在每 15 分钟活动用户成本方面，D01MLC83 实际上带来较好的节省。

了解在处理复制时有些变化，我们可以说，这影响了 D01MLC83 的每 15 分钟活动用户 CPU 节省，相比 D01MLC96 要更显著。另外，在 beta 版本中，每 15 分钟活动用户的邮件消息数增加了，这也影响了我们的结果。我们断定，D01MLC96 的每 15 分钟活动用户 CPU 应该比图 14 中显示的更高，而 D01MLC83 的每 15 分钟活动用户 CPU 应该更低。我们不能确定的是，如果这些变化在 beta 版本中没有发生，所带来的节省将是什么。我们可以说，Domino 7 所带来的节省将是根据 DPAR 的特定工作负载而变化的。

结束语

根据我们的观察，Domino 7 在生产环境中带来了节省。正如预期的那样，我们看到，不同的 DPAR 从 Domino 7 升级中获得不同的好处，这源于它们正在运行不同的工作负载。在已发布的针对 Domino 7 的 NotesBench NRPC 基准测试中，我们已经看到，在 Server 任务上大致有 25% 的节省。对于这些基准测试，只能运行 Server 和 Router 任务。

在我们的度量中，我们试图比较两个版本之间正在运行的各种组件，以了解在 Domino 7 中这些其他任务将带来什么样的节省。不过，由于 beta 版本不断扩展的本质（大概每 6 个月），我们发现，在用户工作负载和活动/注册用户数方面有了实质性的变化，这让我们质疑来自两个 DPAR 的数量。

应该注意的是，本文的结果来自一个邮件 DPAR 而不是一个应用程序 DPAR。应用程序 DPAR 将会运行不同的工作负载，使用不同于邮件 DPAR 的调用。您不应期望对您的应用程序 DPAR 获得和本文一样的结果。

当仅使用 CPU 和事务度量您自己的生产服务器时，要确保小心操作，因为经过一段扩展时期后这些数值可能会令人费解。您必须能够度量和记录不断变化的、随时间推移发生在生产服务器上的工作负载，因为这些变化将正面或负面地影响您的数值。

在生产环境中，您将运行比 Server 和 Router 更多的任务。例如，假定您的 CPU 使用量有 50% 来自这两个任务，则仍有 50% 来自其他 Domino 任务。如果这些其他任务没有一个得到改进，则 25% 的基准测试节省将变成在您的服务器上的 12.5% 的节省。随着更多的 CPU 周期被不会带来性能好处的任务所消耗，潜在的节省将会消耗殆尽。另外，第三方管理程序（比如 TMSCAN 反病毒程序）是总体 CPU 使用量的一部分，它们将增加您的部分 CPU 周期，而不会带来从 Domino 7 获得的 CPU 好处。

在几个大型生产 DPAR 从 Domino 6.5.x 迁移到 Domino 7 之后，我们将发表接下来的文档。度过一个周末后，每个 DPAR 都将升级完成，因此我们将能够构建一个清晰而全面的、DPAR 及其使用量在进程级别的视图，然后比较针对各自工作负载的利用率。这样，我们不仅可以比较本文所描述的平均负载，而且可以比较前面提到的尖峰负载（15 分钟快照）。我们还可以更详细地理解针对任何给定生产 DPAR，来自 Domino 7 的潜在节省。