Notes.net 揭秘:改善 Web 站点的性能

这个案例研究描述了 Notes.net 环境中的服务器性能监控和分析。本文介绍了监控工具和技巧、一些更改,以及这些更改对站点性能的影响。

Carol Zimmet, 软件工程师, IBM Lotus

Carol Zimmet 从 1994 年开始在 Iris 工作。她在服务器团队中负责评估性能和开发性能工具。Carol 一直在为常见的性能问题寻找一步式解决方案。Carol 喜欢和她的孩子一起骑自行车和玩短拍壁球。她非常喜欢彩画玻璃!



Susan Barber, 内容开发人员, Susan Barber

Susan 在过去一年里为备受赞誉的 Notes.net 网络杂志发表了题为 Iris Today 的文章。她还撰写并筹备了获奖专题 “History of Notes/Domino”。Susan 于 1999 年 7 月离开 Iris,来到位于波士顿的一家新公司,希望从事与写作有关的工作。



Shawn Harris, 网络管理员, Iris Associates

Shawn 为网站管理各种网络和服务器。在 1997 年 5 月加入 Iris 之前,Shawn 在 Notes Mail 小组和 Domino 团队为 lotus 做 QE 工作。他于 2000 年 3 月离开 Notes.net 和 Iris。



1999 年 8 月 02 日

[编者注:本文是探索 Notes.net 站点运作方式的系列文章的第二篇。在这篇文章中,看看 Notes.net 团队如何分析并改善站点的性能。]

改善 Domino 服务器的性能是一种艺术,没有硬性和速成的规则。除非您了解服务器性能监控和分析的细微之处,否则就不知道如何更改服务器设置来提高性能。每个人的服务器环境都是不同的,这又增加了一层复杂性。Iris 和 Lotus 的专家给出了 改善服务器性能的顶级方法列表,但不能保证这些方法适合您。

没有人比 Notes.net 团队更了解如何改进服务器的性能。大约在 6 个月以前,我们发现 Notes.net 站点的性能下降了。那时,加载一个页面需要好几分钟。这使我们不得不向 Carol Zimmet(Iris 服务器性能专家)和我们的网络管理员 Shawn Harris 求教,试图找到提高 Notes.net 的总体性能的办法。我们怀着可能和您一样的期望走进这个项目 —— 搞清楚如何改进站点的性能,然后实施解决方案。我们很快发现事情没有这么简单。我们现在了解很多关于如何监控服务器并分析监控结果的知识,因此希望和您分享,帮助您改善您的站点的性能。

本文首先概括地介绍了我们的服务器的环境和配置,然后介绍我们收集性能数据时使用的各种工具和技巧。接下来,本文查看了为提升站点性能而进行的更改。最后,我们分析更改的影响,并描述未来为了提高性能可能采取的措施。我们希望您能深入了解这些技巧,并使用它们分析您的 Domino Web 站点。

我们的性能目标

当我们在 1999 年 1 月开始性能监控时,我们的主要目标是改善 Notes.net 站点的性能。我们认为用户数量的增加是导致网络变慢的一部分原因。当时,我们提供 R5 的 Beta 版下载。此外,这个站点的用户越来越多。事实上,我们的日志数据表明,Notes.net 在 1998 年春天每月的点击率为 270 万次,而在一年之后,每月点击率增长到约 1000 万次。我们认识到可以升级服务器硬件配置来改善性能,从而更好地处理这么大的流量。

我们的第二个目标是开始监控服务器,收集关于当前性能级别的数据,以此作为基准度量未来的性能变化。此外,因为我们使用在 Iris 开发的 Domino 服务器,所以能够轻松地将收集到的信息传递给 Domino 开发团队。然后,他们可以根据这些信息适当的改进 Domino 服务器。更重要的是,我们可以和大家分享所有这些信息。

当然,监控 Notes.net 的性能是一个持续的过程。我们信任 Domino 服务器,并且通过使用我们的产品来表示支持。事实上,最新的 R5 Beta 在我们的站点上运行了多长时间、状态有多好是评估最终发布版的发行时间的标准之一。可以确定的是,我们将关注最新版本是否改善站点的性能,因为我们的站点以它为基础。


我们的环境

下图概括地描述了 Notes.net 的环境:

图 1. Notes.net 环境
Notes.net 环境

注意,我们的站点由一个 Domino 集群中的 5 台服务器组成。这个集群位于我们的负载平衡器 Cisco Systems Local Director 之后。当您从 Internet 访问 Notes.net 时,您的请求首先经过我们的 Local Director。Local Director 跟踪每个服务器的负载,因此它能将您的请求指向负载水平最低的服务器。我们还在 Local Director 上使用 “匹配” 设置,从而将来自同一个客户端的多个请求定向到相同的服务器。这意味着您能够持续连接到同一个服务器,当您向应用程序提交表单时,这尤为有用。对于访问站点的终端用户,Local Director 使我们的服务器显示为一个具有惟一 IP 地址的虚拟服务器,并且所有负载平衡都是透明的。(要更多地了解 Local Director 和集群技术,请阅读 “Notes.net Exposed: Using Domino clusters for your Web site”)。

我们的 5 个服务器的配置都稍微不同,因为不同的操作系统有不同的需求,不同的 Domino 版本也有不同的需求。我们还需要经常更新系统上的 Domino。例如,在监控服务器性能期间,我们从 R4.6 升级到 R5 Beta,并且最终会升级到 R5 Gold。使用 Beta 发布版监控服务器的性能是一个挑战,因为 Beta 发布版带来大量调试代码,从而降低了服务器的速度。当您从 Beta 发布版迁移到 Gold 发布版时,性能自然会提升。

下面的表显示了我们在开始监控性能时服务器的配置:

服务器操作系统CPURAM (MB)磁盘结构Domino
服务器 1WinNT 4.0Dual 300MHz Dell PowerEdge 4200512C: OS, Page file
D: Notes Program/Data/Weblogs
Beta R5
服务器 2WinNT 4.0Dual 300MHz Dell PowerEdge 4200512C: OS, Page file
D: Notes Program/Data/Weblogs
R4.6.2
服务器 3WinNT 4.0Dual 300MHz Dell PowerEdge 4300512C: OS, Page file
D: Notes Program/Data/Weblogs
R4.6.2
服务器 4AIX 4.3.1IBM F40 2X700/opt: OS, Swap file, and Notes Program
/local1: Notes Data/Weblogs
R4.6.2
服务器 5WinNT 4.0Dual 300MHz Dell PowerEdge 4200512C: OS, Page file
D: Notes Program/Data/Weblogs
R4.6.2

我们使用的工具

当我们开始监控服务器的性能时,我们使用两个工具:Windows NT Performance Monitor 和一个带有 Probe 工作负载的测试工具。下面的小节阐述这些工具的细节。

为了监控 UNIX 服务器,您可以使用 SAR、VMStat、IOStat、NetStat 或 PerfMeter。您还可以使用一个称为 Performance Toolbox 的工具监控 AIX 服务器。

Performance Monitor

您可以使用 Windows NT Performance Monitor 来监控操作系统统计数据和 Domino 统计数据。它的工作方式是,您将 Domino 服务器添加为 Performance Monitor 内部的一个计数器。当您运行 Domino Install 程序时,您可以选择安装 Performance Monitor 组件。如果您在安装 Domino 服务器时没有选择安装 Performance Monitor,请阅读侧栏 “将 Domino 安装为 Performance Monitor 的计数器”。

Performance Monitor 列出所有 Domino 服务器的统计数据,包括插件程序生成的数据。您可以选择需要在报告或图表中显示、用于分析的特定数据。您还可以使用 Performance Monitor 查看远程服务器的统计数据。要获得使用 Performance Monitor 的完整信息,请查看 Windows NT 文档。

我们在日志模式下运行 Performance Monitor,每隔 15 分钟收集一次数据。为此,选择 View - Log,然后选择 Edit - Add To Log。我们推荐您记录以下对象的日志,因为它们在分析数据时提供很大的帮助:

  • 缓存
  • 逻辑磁盘
  • Lotus Notes
  • 内存
  • 分页文件
  • 进程
  • 系统

然后,通过选择 Options - Log 设置日志选项。指定一个 Periodic Update 间隔并单击 Startstart

将数据收集到日志中之后,您可以使用 Performance Monitor 的图表选项查看数据并对其进行分类。为此,选择 View - Chart;然后选择 Options - Data From 并选择您的日志文件。选择需要以图表显示的对象、计数器和实例。我们查看不同的系统数据统计,比如处理器使用、磁盘时间百分比(磁盘为响应请求而读写数据的时间)、平均磁盘队列长度,以及每个服务器中固定周期内可用的内存。

我们还使用 Lotus Notes 收集 Domino 服务器统计数据,包括 Domino Web 服务器统计数据。Domino Web 服务器统计数据的前缀是 Domino,并且包含 HTTP 服务器信息。我们尤其需要收集特定时间内 HTTP 请求的数量和活动 HTTP 线程的数量。这些统计数据帮助我们构建一个关于统计数据信息的基准(您还可以使用 Domino Statistics and Events 收集这些信息。要更多地了解 Domino Statistics and Events,请查看 Domino 5 Administration Help)。

注意:为了初始化 Logical Disk 对象,需要运行 Diskperf 工具并重启系统。您可以从命令行使用 -Y 开关(例如,diskperf -Y \\ 服务器名)运行 Diskperf 工具。这将系统设置为在重启时开始磁盘性能计数器。如果您使用条带化磁盘,那么需要添加 -E 开关(例如,diskperf -YE \\ 服务器名)。(对于磁盘阵列,条带化 是一种可以提高磁盘驱动器速度的技术。写入到条带化磁盘组的每个文件分散到几个磁盘驱动器)。

Probe 负载

我们使用由内部测试工具执行的 Probe 负载度量站点的响应时间。Probe 负载在指定的时间间隔内打开站点上的一个页面(在这里,间隔为 1 分钟)。我们选择主页 http://www.notes.net/welcome.nsf 作为负载应该打开的页面,因为它是用户在该站点上访问的第一个页面。这个页面需要加载许多对象,因此它能够很好地反映真实负载请求。

内部测试工具记录它打开并完全显示一个页面时所需的时间。尽管在 Notes.net 上使用了 Probe 负载,但我们了解到还需要更改这个工具,确保它确实记录打开一个页面所需的时间。此外,我们改进了该工具,使它能够更好地区分首次连接时间和获取页面的所有对象所需的时间。

在 1999 年 1 月至 4 月底,我们为未来的 Notes.net 性能分析收集了基准测试的数据。我们每周创建一个 Lotus 1-2-3 电子表格,该表格包含每周收集的数据的分析。我们进行对比的是:当全部 Notes.net 服务器都启用时总体站点响应时间和一个或多个服务器没有启用时站点的响应时间。(要查看这些结果,请看侧栏 “Overall response time results”)。我们通过找出每周中每个 HTTP 服务器启用的时间来计算调整信息,并从不同的角度分析这些信息。我们还分析白天和黑夜、平时和周末的 Probe 响应时间的对比。

使用 Performance Monitor 和 Probe 负载收集到一些基准数据之后,我们还尝试用不同的设置来提高性能。更改配置使观察变得很有意思。我们还度量不同更改对服务器的影响,比如硬盘配置更改和 Domino 升级。


我们进行的更改

下面的表总结了我们对环境的所有更改。总体而言,我们先在一个服务器上进行更改,并花几天时间观察它们的影响。然后,我们对其余服务器进行相同的更改。为了让这个表简明易读,我们仅包含最初更改的日期。对于其余服务器的更改和到 R5 Beta 版的多次升级,我们省略了日期。

日期行为
1/22/99开始 Performance Monitor 日志记录
1/26/99修改服务器的磁盘配置
1/27/99将服务器升级到 R5 的 Beta 版
2/12/99增加 HTTP 活动线程,在所有服务器上都设置为 80
添加 NOTES.INI 设置,DominoAnalyzeFormulas=1
查看是否需要提高 Domino 缓存的级别
启用 Domino R5 事务日志记录
3/3/99增加 HTTP 活动线程,设置为 120
3/24/99升级硬件(更快的处理器、更多内存、配置磁盘)
4/5/99将服务器升级到 R5 Gold

下一小节将更加详细地讨论这些更改。

服务器配置更改

正如在性能目标一节中提到的一样,我们认为有必要升级服务器硬件配置,以更好地处理不断增加的站点流量。然而,我们首先检查到网络吞吐量没有问题(使用 Network Associates 提供的网络嗅探器 NetXRay)。我们得到的结果显示服务器的平均网络利用率为 1%。

在 Performance Monitor 中分析性能统计数据之后,我们发现磁盘 I/O 是一个瓶颈。因此,我们决定重新配置服务器的磁盘结构。(要了解为什么需要将 I/O 分配到不同的设备,请阅读侧栏文章 “Top 10 ways to improve server performance”)。我们根据容量需求将操作系统、Notes 程序文件、Notes 数据目录、页文件(或 UNIX 上的交换文件)和事务日志(R5 中的新特性)放到不同的物理磁盘或磁盘阵列,从而将它们隔离开来。(注意:这些文件必须存放在物理 磁盘上。如果您需要使用多个磁盘来增加一个逻辑分区的容量,可以使用 RAID5。RAID5 在保持某些级别的磁盘 I/O 性能的同时提供容错)。要更多地了解 I/O 性能和 RAID 级别,请阅读 “Optimizing server performance: I/O subsystems”。

此外,在大部分服务器上,我们还将内存增加到至少 1GB。您还会注意到,我们还为该站点添加了另一个版本的 UNIX 和 Sun Solaris,以运行 Beta 版的 Domino R5 和处理站点不断增加的流量。

下面给出的表显示了我们的服务器的当前配置:

服务器操作系统CPU >RAM磁盘结构*Domino
服务器 1WinNT 4.0Dual 333MHz Dell PowerEdge 42001GBC: OS
D: Notes Data/Weblogs
N: Notes Program
P: Page file
T: Transaction log
R5.0a
服务器 2WinNT 4.0Dual 333MHz Dell PowerEdge 42001GBC: OS
D: Notes Data/Weblogs
N: Notes Program
P: Page file
T: Transaction log
Daily build server (R5.0.1)
服务器 3WinNT 4.0Dual 450MHz Dell PowerEdge 43001GBC: OS
D: Notes Data/Weblogs
N: Notes Program
P: Page file
T: Transaction log
R5.0a
服务器 4AIX 4.3.1Quad 400 (IBM F40 2X)2GB/: OS
/local1: Notes Data/Weblogs
/opt: Notes Program
/swap: Swap file
/tlog: Transaction log
R5.0a
服务器 5SunOS 5.6 GenericQuad 4004GB/: OS
/local1: Notes Data/Weblogs
/opt: Notes Program
/swap: Swap file
/tlog: Transaction log
Daily build server (R5.0.1)

增加 HTTP 的活动线程

接下来,我们将更改需要调试的各种 Domino 参数。首先,我们增加 HTTP 的活动线程,将其设置从 40(默认值)改为 80,然后再改为 120。HTTP 线程是处理传入的 HTTP 请求的线程。要指定 Domino 服务器上的活动线程的数量,需要使用 Server 文档的 Internet Protocols/HTTP 选项卡上的 “Number of active threads” 字段。通过在服务器控制台中输入以下内容,可以查看 Domino 使用的 HTTP 线程的峰值:

"show statistic domino.threads.active.peak"

在增加 HTTP 活动线程时,您应该会看到响应时间减少了。如果系统将过多的时间花在存在开销的任务上(比如内存交换),则需要指定更少数量的线程。要更多地了解如何调整 HTTP 线程来提升性能,请阅读 “Optimizing server performance: HTTP Threads settings”。

在初次监控时,我们发现活动线程一直增加,最后增加到 120 个。我们尝试通过增加在 Server 文档中指定的活动线程数来增加系统吞吐量。当线程设置为 120 时,实际并没有增长到这个数。要查看我们的 HTTP 线程设置测试结果,请查看侧栏 “增加 HTTP 活动线程”。

然而,我们必须小心,因为随着线程的增加,上下文切换也增加。这可能导致活动线程数封顶。每秒上下文切换是指从一个线程切换到另一个线程的频率。线程切换可以在单个进程内部发生,也可以跨进程发生。当一个线程向另一个线程请求信息时,就可能引起线程切换。或者当一个线程排挤另一个线程时,也可能引起线程切换。对于后一种情况,优先级别更高的线程将先运行。(阅读即将发表的 Iris Today 文章,更多地了解上下文线程切换)。

添加 DominoAnalyzeFormulas 设置

接下来,我们需要利用缓存包含 @functions 的 Web 页面的功能(从 Domino R4.6.1 开始可用)。除了在内存中缓存静态 HTML 页面之外,Domino 还能够缓存包含宏语言(@function)公式的页面。为此,Domino 的 Formula Analyzer 将检查页面上的公式,并根据命令的可修改性决定是否缓存它(例如,如果 Web 页面包含 @Today,将不缓存它),并且更加重要的是,已缓存的命令在什么条件下会失效。

因此,我们通过在服务器上添加 NOTES.INI 设置 DominoAnalyzeFormulas=1 来启用 Formula Analyzer。然后,服务器开始缓存使用 @formulas 的 Web 页面。要更多地了解 Formula Analyzer,请阅读 “Expanded Command Caching in Domino 4.61”。

更改 Domino 缓存级别

在设置 Formula Analyzer 之后,我们希望查看 Domino 服务器的缓存是如何工作的。为此,我们开始监控下面的服务器统计数据:

  • Domino.Cache.Command.Count:Command Cache 包含的实际命令数
  • Domino.Cache.Command.MaxSize:可以缓存的最大命令数
  • Domino.Cache.Command.HitRate:一个有效缓存条目出现在缓存中的次数与为一个缓存条目调查缓存的次数的百分比
  • Domino.Cache.Command.DisplaceRate:一个新缓存命令取代一个旧命令的次数与为一个缓存条目调查缓存的次数的百分比

要更多地了解这些统计数据,请查看 “Expanded Command Caching in Domino 4.61”。

下面的表显示了监控缓存统计数据得出的一些结果。从总体上看,这些结果表明 Domino 没有缓存大量页面。注意,Command.Count 和 Command.MaxSize 的结果一般都是相等的。另外,Command.HitRate 和 Command.DisplaceRate 的结果非常小。

服务器Command.CountCommand.MaxSizeCommand.HitRateCommand.DisplaceRate
服务器 21281284.001
服务器 41281283.690
服务器 21281287.081
服务器 4119(包括重启)1283.320.34

这些结果促使我们进一步调查我们的站点的组成。站点的一些区域是特定于用户的 —— 即我们要求用户通过身份验证才能进入讨论论坛、下载 Beta 发布版和向 Sandbox 提交样例。为了在这些区域中提供缓存页面,对页面的请求必须来自已经使用相同的 URL 访问该页面的用户。因为在这些案例中点击率很低,所以您会看到比较低的替换率。记住,HitRate 统计数据显示一个配对出现在缓存中的次数。我们的替换率比较低,因此没有找到配对。

我们与 Domino 开发人员进行核实,他们建议我们要确保缓存站点的 “门面”。站点的 “门面” 就是站点的主页,也是启动站点的其他子部分的页面。(增加 MaxSize 允许我们缓存更多数据,从而改善性能,但受网站动态内容的影响,HitRate 和 DisplaceRates 可能仍然保持较低的水平)。

为了解决这个问题,我们开始关注 Notes.net 的主页。我们了解到,主页上的 HTML 从来不被缓存,因为它包含 @Today 命令。不过会缓存该页面上的图像。由于大部分页面没有被缓存,因此用户再次返回到主页时,必须重新加载 HTML。解决办法之一是给文档添加一个 $CacheValid 字段,并将字段的值设置为数字文本字符串 N。这使 Domino 在 N 秒之内不执行页面的有效性检查。HTTP 服务器的默认值是 N=0。我们没有实现这个选项,因为我们想先看看其他变更的影响。

Domino R5 事务日志

在升级到 R5 的 Beta 版并最终升级到 R5 Gold 的过程中,我们开始利用 R5 中各种性能改进。Domino R5 事务日志就是这些特性之一。在启用事务日志之后,系统开始捕捉数据库变更并按照先后顺序将它们写到日志中。如果以后出现系统或媒体故障,您可以使用事务日志和第三方备份工具恢复数据库。此外,您还可以获得更快的服务器重启、更佳的数据库完整性和更高的系统可用性。要更多地了解事务日志,请查看 “Optimizing server performance: Transaction logging” 。


我们的更改对性能的影响

在监控性能的几个月时间里,我们收集到大量数据。不过,分析数据更有挑战性。这是因为在测试期间,我们不断地将服务器从 R4.6 升级到不同的 Beta 版 R5,并最终升级到 R5。如前所述,Beta 版本的性能不是最优的,并且它们包含大量使服务器变慢的调试代码。此外,我们还应用了本文描述的所有更改。

当然,在可控环境中性能测试的效果最好,因为您可以改变一项配置并观察它的影响。此外,您还需要观察变更在一段时间内产生的影响。不幸的是,我们使用的是速成的随时变化的环境(就像大部分 Web 站点一样)。我们试图在进行较大更改后至少一周内对系统进行控制,但我们发现一周时间还不足以评估变更的影响。

然而,最重要的是最终结果 —— 站点的性能改善了!我们通过用户收集关于终端用户响应时间改进的反馈(通过站点中每个页面底部的 反馈 链接)。此外,我们的内部测试表明现在仅需几秒钟就能加载主页。我们难以确定是哪个因素改善了性能,但是我们现在获得了基准测试数据,可以用于未来的性能分析。


结束语

在未来,我们计划继续监控站点并为以后的性能分析收集更多数据。我们希望观察向站点添加 UNIX 服务器造成的性能影响。我们还希望创建一个 Notes.net 负载,用于在未来的模拟 Notes.net 环境中进行性能测试。这样,我们就能够控制变更并测试结果,然后在我们的站点上应用它们。

我们希望这些经验对您有帮助,让您找到提高自己的站点性能的方法。我们期待您在这个月的 Developer Spotlight 上分享您的结果,这个板块由性能团队负责。性能团队将查看您的性能监控技术并提供反馈,帮助您分析结果。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Lotus
ArticleID=398589
ArticleTitle=Notes.net 揭秘:改善 Web 站点的性能
publish-date=08021999