Duwamish Online
Aaron Ching, Pedro Silva, and Allen Wagner
Microsoft Developer Network
January 2001
摘要:这篇文章讨论了性能测试对于成功发布一个网络应用的重要性,集中讨论了微软的Web Application Stress (WAS)这个用于测试Duwamish Online的性能的工具。
内容
介绍
使用WAS的好处
WAS的缺陷
安装WAS
创建测试脚本
配置测试脚本
运行测试脚本
结论:最好的习惯
介绍
性能测试是成功发布一个网络应用的关键因素。当越来越多的用户访问你的站点时,清楚地知道你的应用程序和你的服务器群是怎样工作的就显得非常重要了。
为了给你的网络应用程序模拟出那种类型的使用,你可以协同几百甚至上千的真实用户在一段设计好的时间段里访问你的站点,你也可以只与一个能复制这么多用户负载的测试工具一起工作,
许多性能测试工具可以帮你的忙。基本上,这些工具都允许你以有限的客户端模拟大量的虚拟用户,并发地访问预先确定的页面或网站的
URLs (Uniform Resource Locators)。每一个虚拟用户都能精确地仿效在真实浏览器和网站服务器之间进行通讯协议。
在这篇文章里,我们将专注于其中一个这样的工具:Microsoft® Web Application Stress (WAS)工具。你可以在微软的Microsoft Windows® 2000 Resource Kit CD (WAS version 288)里面找到这个工具。
注意
WAS不能再从Microsoft的网站下载了,Visual Studio .NET 的企业架构 和 企业开发版本都包含一个新的网络压力测试工具,这个工具叫做Application Center Test,是受Microsoft技术支持的工具。这个工具包含在Visual Studio .NET安装时的Enterprise Development Tools部分。在写这篇文章时,Application Center Test还没有正式公开发表。关于如何得到Visual Studio .NET,请访问Visual Studio网站。
使用WAS的好处
首先,我们来讨论一下使用WAS测试你的应用程序的好处。
它简单
WAS允许你以不同的方式创建测试脚本:你可以通过使用浏览器走一遍站点来录制脚本,可以从服务器的日志文件导入URL,或者从一个网络内容文件夹选择一个文件。当然,你也可以手工地输入URL来创建一个新的测试脚本。
不像其它的工具,你可以使用任何数量的客户端运行测试脚本,全部都有一个中央主客户端来控制。在每一个测试开始前,主客户机透明地执行以下任务:
・
与其他所有的客户机通讯
・
把测试数据分发给所有的客户端
・
在所有客户端同时初始化测试
・
从所有的客户端收集测试结果和报告
这个特性非常重要,尤其对于要测试一个需要使用很多客户端的服务器群的最大吞吐量时非常有用。
它的高可用性
WAS是被设计用于模拟Web浏览器发送请求到任何采用了HTTP1.0或1.1标准的服务器,而不考虑服务器运行的平台。
除了它的易用性外,WAS还有很多其它的有用的特性,包括:
・
对于需要署名登录的网站,它允许创建用户帐号。
・
允许为每个用户存储cookies 和Active Server Pages (ASP) 的session信息
・
支持随机的或顺序的数据集,以用在特定的名字-值对
・
支持带宽调节和随机延迟(“思考的时间”)以更真实地模拟显示情形。
・
支持Secure Sockets Layer (SSL)协议
・
允许URL分组和对每组的点击率的说明
・
提供一个对象模型,可以通过Microsoft Visual Basic® Scripting Edition (VBScript)处理或者通过定制编程来达到开启,结束和配置测试脚本的效果。
WSA的缺陷
除了优势外,WAS的确有一些缺陷存在。当前知道的bug和有关事项都列在WAS的网站上了。以下是当前WAS不支持的特性:
・
以前面所发请求返回的结果为基础,修改URL参数的能力。
・
运行或模仿客户端逻辑的能力
・
为所分配的测试指定一个确定数量的测试周期的能力。
・
对拥有不同IP地址或域名的多个服务器的同时测试能力
注意
你可以使用多个主客户端来同时测试多个服务器。然而,如果你想把所有测试结果联系起来成为一个整体,则需要整理从各个WAS数据库得到的数据
・
支持页面在不同IP地址或域名间的重定向的能力
・
从Web浏览器直接记录SSL页面的能力
注意
WSA已经支持SSL页面的测试,但是没有记录它们。你需要在脚本录制完后,手工地为每个设计好的URL打开SSL支持
虽然对这些限制有一些相应的解决办法,但是如果你的应用依赖一个或多个这样的功能的话,你也许不能完全享受WAS带来的好处。
安装WAS
WAS要求Microsoft Windows NT® 4.0 Service Pack 4或以上版本,包括Windows 2000平台。还要求Internet Explorer 4.0以上版本,与Internet Explorer 5.0工作更好。
要安装WAS,首先下载最新版本的setup.exe程序,按照安装向导的指示。拷贝并在你的测试机器上安装。
注意
在本文介绍的所有步骤均以WAS version 293为蓝本。
创建测试脚本
虽然你可以手动地创建测试脚本,WAS可以通过记录浏览器活动,导入服务器日志文件或评估Web文件夹的内容来帮助你创建测试脚本。在本文,我们将主要通过记录览器活动的方式来创建测试脚本。采用这个方法而不用其它的方法有几个原因,包括:
・
记录览器活动的方式以精确的方式捕捉所有用户的交互活动。任何从浏览器发往服务器的URL指向,应用程序参数和HTTP头部信息都会被自动地记录在新的测试脚本里。
・
导入服务器日志文件的方法在站点已经进入投入使用阶段,有了真实的用户流量的情况下使用最好。但是,一个新的站点未必有这么多的真实用户使用数据,进一步说,可能还需要合并大量的日志文件来达到较好地体现用户活动的目的,这将需要创建大量的测试脚本,将需要客户端更多的系统资源。
・
选取Web内容文件夹的方法最好用在测试多数是静态HTML文件的站点。这种方法允许在已有服务器的Web页面的基础上快速创建测试脚本。然而,这种方法并不捕捉任何由大多数应用程序文件产生的参数,像Common Gateway Interface (CGI)程序或Active Server Pages (ASP).
你只需要在主客户机器创建和存储你的测试脚本,当测试由主客户端初始化时,测试脚本会自动地分发到其他的测试客户端。
准备测试客户端机器
如果你正在你的内部网通过代理服务器使用WAS ,并且从内部网外的客户端发送请求页面,而且你的公司使用Microsoft Proxy Server,那么按照以下的步骤建立你的客户端:
1.
从开始菜单,指向设置\控制面板。双击管理工具图标,然后是服务图标。
2.
双击WebTool服务打开属性对话框
3.
点
Log On As标签,然后点
This account选择按钮添加你的网络用户名和密码。使用domain\user name的格式
4.
停止并重起WebTool服务
5.
然后,安装Microsoft Windows Proxy client 2.0,也叫Winsock Proxy 客户端,可以在Microsoft Proxy Server CD里找到(更多有关怎样安装和设置这个软件的信息,请参考包含在CD里面的文档)
6.
对于希望使用代理服务器的每个测试客户端,重复步骤1-5。
如果你的公司使用其他的代理服务器,就要安装该代理服务器的代理客户端。
准备浏览器
在开始录制一个脚本前,你需要准备好你的浏览器,清除你的浏览器的缓冲cache。否则,WAS也许不能记录所需的浏览器活动,因为浏览器可能从缓冲区而不是从所请求的服务器取得请求页面。
关掉
IE
的缓冲区
1.
在工具菜单,点
Internet
选项
2.
点常规标签,然后点删除文件。。。按钮。
如果使用IE5。0或以上版本则不需要修改代理设置,因为5。0以上版本的IE允许WAS改变这些设置。然而,对于IE4。0或早期版本,WAS使用一个内置的代理服务器来记录浏览器活动。
按WAS的需要指定代理设置
1.
在工具菜单,点
Internet
选项
2.
在连接标签里,修改代理设置以使代理服务器指向
Localhost并且使用端口8000
3.
不选
对于本地地址不使用代理服务器
记录脚本
在你的浏览器和客户端已经准备好记录后,做下面的操作:
1.
当你第一次运行WAS时,你会看到一个
Create new script的对话框(Figure 1),询问你以什么样的方式创建一个新的测试脚本。
2.
点
Record 按钮 。如果之前你选择了
Don't display at startup,
Create new script将不会显示出来。你可以在
Script菜单选择
Record 然后
Create.
3.
在
Browser Recorder ―
Step 1 of 2对话框,你会被要求指定一些记录设置。在这里,清除所有的选择框点
Next继续。
4.
在
Browser Recorder ―
Step 2 of 2对话框,点
Finish。一个新的IE窗口会出现以便记录浏览器活动,同时WAS会被置于记录模式。
5.
在新出现的IE窗口的地址栏,输入你的目的站点的地址。在WAS的窗口你将看到HTTP 信息在跟随你的浏览活动而实时改变着。
6.
当完成了你的站点浏览后,转回WAS窗口―还处于记录状态―点
Stop Recording按钮。就会终止记录并产生一个新的测试脚本。
在右边窗口的底部,你将看到一个列出所有脚本的列表。
对于需要安全连接的站点,WAS支持SSL页面。然而不允许SSL的记录。要解决这些限制,你可以在服务器端关掉SSL,记录脚本,然后再重新激活服务器上的SSL。
设置测试脚本
新录制的脚本还不能立即用来测试。还必须完成以下设置:
・
调节脚本项和他们的属性
・
调节测试脚本的测试
・
建立页面组和点击百份比
・
建立用户帐号
・
建立客户端
・
建立性能计数器
调节脚本项
在修改一个测试脚本的脚本项时需要考虑几点,我们将在下面介绍。
去掉不需要的脚本项
去掉冗余项以减少在测试中的噪声因素,或者去掉那些无效的URL。当要调整一项特殊的功能时,去掉所有指向图象,样式表单和其他辅助静态文件的脚本项。
为脚本项指定思考时间
脚本项表单的最后一项叫做“延迟”。这项允许你在执行脚本项之前指定特定的延迟时间(也叫思考时间)。
对于性能测试来说,如何定义思考时间并没有一个单独的标准。有些人使用零思考时间,有些人考虑使用30秒为思考时间。
主要取决于站点的内容和测试的目的。例如,有长页面内容的站点需要比简单页面的站点使用长一点的时间,因为用户需要使用多点的时间来读页面内容。
另外,如果你的目的是快速地决定一个只有少量客户端的Web服务器的吞吐量,你可以考虑零思考时间。没有思考时间的话,WAS的每个线程以最快速度对Web服务器施加压力。
为脚本项设置一系列的值
WAS允许你为一个脚本项的一对名字-值赋值,而不是对每一个请求都使用相同的值。这个特性对于模拟真实情形很重要,没有用户会不停的以相同的数据值请求同一页面吧?
例如,其中一项测试脚本是请求一个ASP页面展示一个产品的详细信息。我们可以设置WAS随机地从一列预先定义的产品ID选取不同的值,而不是每次都用相同的产品ID请求ASP页面。
为脚本项建立一列值
1.
在WAS窗口的脚本项,双击脚本项最前面的方型按钮(在表单的第一列)打开这项的详细菜单。
2.
在
Querystring标签里(也叫Querystring Editor,如Figure 3所示),选定
Format data to CGI standard。相应的名字-值对会出现在check box下的表单里。
3.
点选定的名字-值对的值,一个新的按钮会出现
4.
点这个按钮打开
Field Values对话框
5.
在
Field values对话框输入一串值,每一行一个值。你也可以通过剪切,粘贴一个电子表格的数据文件来输入。
6.
在Querystring Editor里,在表单中点有相同名字-值对的
Distribution一列。在下拉菜单选择
Random
。
为脚本项设置SSL
为特定的脚本项激活SSL,需要作以下操作:
1.
在WAS窗口的脚本项,双击脚本项最前面的方型按钮(在表单的第一列)打开这项的详细菜单。
2. 在 SSL标签里,选
Use SSL. (注意在你激活SSL时确保端口值应该在80到 443之间)。
调整脚本设置
为了您能满意地运行你的性能测试,你需要修改你的测试脚本的设置。通过双击左边的脚本名展开脚本的信息,你会找到一个
Settings标签,在这里你可以为你的测试脚本指定很多设置。点击它将在右边窗口打开Settings视图。
指定目标Web服务器
默认地,目标服务器是“localhost”,应该替换为IP地址或目标服务器的域名。
改变设置
1.
在左边的窗口点测试脚本的名字
2.
在右边窗口顶部的
Server输入目标服务器的IP地址或域名
注意
如果你想对有Network Load Balancing(网络负载均衡)的服务器群组进行测试,就像Duwamish Online一样,则需要输入IP地址群。
设置并发连接数
在设置里的
Concurrent Connections部分,你可以指定
Stress level (threads)的值和
Stress multiplier (sockets per thread)来控制对目标服务器的压力/负载程度。Stress level是全部客户端所产生的Windows NT线程的总数。每个线程能产生多个socket而每个socket就是一个并发的请求。
以下公式解释了他们之间的关系:
Total Concurrent Requests = Stress level (threads) x Stress multiplier
(sockets per thread) = Total Number Sockets
在我们的实验室,我们使用不同的Stress层次来 性能测试。例如,我们使用过100, 200, 300, 400, 500, 750, 1000, 1500,和2000的值来连续测试以研究我们的服务器群组是如何对连续增长的负载作出反应的。
你应该在初步测试的结果基础上调整这些数值。通常来说,你需要在低负载度时收集更多的数据点,因为这时候系统的吞吐量会随线程的增长而线性增长。另一方面,你可以在高负载度时运行较少的测试以节省时间和精力,尤其是系统吞吐量已经高于峰值时。
注意我们的第一次测试将设定在1000个线程。目的是运行足够的请求以建立我们程序的数据缓冲。因为程序的性能会因为有没有缓冲而表现大不相同,这将帮助我们为负载测试保持一个一致的环境。
设定测试运行时间
在设置视图的
Test Run Time部分,你可以以日,小时,分钟,秒来设定总的运行时间。取决于你的脚本项的预期反应时间,建议你运行测试脚本至少若干分钟以便产生足够的请求,避免变形的测试结果。你的程序的反应时间越高,测试进行的时间就应该越长,以便产生大量的数据。
你可以运行短而密集的测试以便监测你的站点的任何问题。另外,你需要运行更长的测试时间(例如,30天),看看你的站点的性能是否随时间而退化,尤其是在中级或高级的负载压力下。
在Duwamish Online这个站点,大多数的性能测试都运行7到10分钟,以便有足够时间来稳定测试结果。
设置随机延迟时间
在设置视图的
Request Delay部分,你可以在执行测试前为每个脚本项选择加入随机延迟时间(或思考时间)。如果
Use random delay选项框被选中,每个WAS线程会空转一段随机的时间(在最大值和最小值之间)加上为每个脚本项指定的固定的思考时间。
下面的公式解释了延迟时间的计算方法:
每项的延迟时间=随机延迟时间+每项的固定延迟时间
随机延迟时间的特性在固定延迟时间被指定给脚本项时尤为重要。如果没有使用随机延迟时间,所有的线程会在几乎相同的时间发送请求到Web服务器,然后等待几乎相同的固定延迟时间然后发送下一个请求。随机延迟时间在向Web服务器施加负载时有助于压平峰值和谷值,因此为所需的负载水平呈现一个更为精确的环境。
设定挂起时间
在设置视图的
Suspend部分,你可以以日,小时,分钟,秒来设定
warmup 和
cooldown时间。Warmup时间就是初始化测试运行时间,在这段时间里不会收集和计算性能数据。类似地,cooldown时间就是指定结束阶段的测试时间,也不收集数据。Warmup 和 cooldown被用于最小化测试结果的失真。
通常,在一个新测试运行的初始化阶段,很多系统资源是被特定的活动所消耗,像组件或应用程序的缓冲初始化。Warmup时间有助于在任何测试数据被收集之前稳定系统的环境。
另一方面,cooldown时间有助于在测试运行的结束阶段避免数据的变形,这时额外的系统资源被用于停止测试和开始从客户端收集数据。另外,socket连接可能会过早地停止,造成大量的socket错误。
在Duwamish Online,我们使用30 到 60秒作为大多数性能测试的warmup 和 cooldown时间
指定带宽瓶颈
在设置视图里的
Bandwidth部分,WAS允许你模拟从14.4 Kbps的modem连接到T1 (1.5 Mbps)的Local Area Network (LAN)连接的网络带宽。这个特性的最大好处是可以支撑大量的并发连接到目标服务器。这是大多数Web站点(用户使用低速modem连接)所体验的情形。
激活带宽瓶颈
1.
在设置视图里的
Bandwidth部分,选择
Throttle bandwidth选项框。
2.
在下拉菜单,选择一个代表大多数用户的连接吞吐量的带宽。
在Duwamish Online里,我们试过不同的带宽瓶颈的设置。初始化时。我们把用户连接设在56 Kbps,想明白我们的程序在大多数Web站点的情况下是如何表现的。我们也试过把用户连接设在ISDN Dual Channel (128 Kbps)以模拟未来宽带趋势下,我们的大多数用户通过快速的连接访问我们的站点。最后,我们以没有带宽瓶颈的情形测试我们的站点。有趣的是,我们发现这种设置产生的负载条件与用128 Kbps连接的一样。
不管你如何设置带宽瓶颈,务必要在你想比较测试结果的所有测试中保持一致性。
指定其他设置
在设置视图的其他部分,我们保持默认值,除HTTP重定向外。我们故意去掉
Follow HTTP redirects选项。这在创建脚本过程中你录制脚本时已经录制了URL的重定向的时候是必须的。你不需要重复两次地运行那些URL。
设置页面组
在WAS里,你可以把一系列的脚本项组织成所谓的页面组。这个特性允许你把所有的页面元素(包括HTML文件,图象文件,样式表单等)或多个相连的页面组织成一个逻辑单元。你可以为每个页面组指定不同的点击率,那样就能控制哪个页面或相连的页面会访问更多或更少。如果你有你的网站的使用方法―像目录浏览或购物车―页面组允许你以你希望你的站点会获得的点击率来运行。
建立页面组
1.
展开左边窗口的脚本的信息
2.
点
Page Groups节点在右边窗口打开相应的视图
你会看到默认的以100%分布率的页面组已经创建好了。所有的脚本项默认都初始化为这个组。
3.
在组表单的空白行,在
Group列输入新的组名(像"Home"作为主页),在
Distribution列输入数值。分布率会被用于计算这个页面组的点击率,见
Percent列。重复这个步骤添加更多的页面组。
4.
点左边窗口的脚本名回到该脚本项的视图
5.
在脚本项表单的
Group列,从下拉菜单选择其中一个页面组。为每个脚本项重复这个步骤。所有关联的页面都应该选同样的页面组。
Figure 5. Example of page groups definition
6.
点左边窗口的脚本名回到该脚本项的视图
7.
在脚本项的表单的Group一列,从下拉菜单选则其中一个页面组。
8.
重复6到7为每一个脚本项选择一个页面组。所有相关项(像ASP 页面,样式表单和图象文件)应该选择相同的页面组。
另一种创建和指定页面组的方法是在录制脚本时指定页面组。要使用这种方法,在浏览器跳到新的页面之前返回到WAS窗口(见Figure 2)。点
Change Group按钮然后在
New Group对话框输入组名。以后录制的脚本项都会被指定到这个新的组。
指定用户
测试需要署名登录的Web站点时,WAS提供一个特性叫做
Users,可用于存储多个用户的用户名,密码和cookie信息。
当一个测试开始时,所有的用户被分配到给定压力系数设置的各线程中。当请求开始时,每个线程使用从与该线程连接的共享池中获得的用户名,密码,和cookie。如果WAS配置的用户数比线程少,一些线程就会没有用户―所有的署名登录页面会登录取失败,任何与cookies的交互会被禁止。所以,当测试需要个人认证的网站时,拥有的用户数比线程多是很重要的。
对于可以在WAS中创建的用户数没有硬性的规定和限制。然而,因为每个用户都会需要一定的内存和资源,所以如果使用大量的用户,将会使你的测试启动和停止时间更长些。
创建新用户
1.
在左边窗口展开脚本的信息
2.
点
Users节点在右边窗口打开相应的视图
3.
双击
Default用户组打开用户视图。
注意默认已经创建了200个用户。你可以简单地修改用户名和密码就行了。
你也可以做以下操作来创建一系列新的用户
1.
点
Remove All清除所有的记录
2.
在
Number of new users,输入你想创建的新用户的数量
3.
在
User name prefix,你可以在用户编号的前面输入前缀值,例如“User.”
4.
在
Password,输入密码。相同的密码会赋给所有用户。
5.
最后,点
Create按钮。用户表单就会填满指定数量的用户
如果你想使用定制的用户名和密码列表,你可以从一个预定格式的文本文件导入它们。参考WAS帮助文件的“Importing user names and passwords”部分。
建立各客户端机器
WAS允许你使用多个客户端机器测试你的网站。当一个测试开始时,WAS会自动地与所有客户机取得联系,向他们传输所有的测试信息(包括测试脚本项,页面组和用户定义信息),启动和停止他们的测试,然后收集测试结果。
使用其中一个客户机器作为你的主客户端。这个主客户端应该是你用来记录和设置测试脚本的机器。
建立测试客户端
1.
在左边窗口展开脚本信息
2.
点
Clients节点在右边窗口打开相应的视图
3.
双击
Default客户端打开客户端视图
本地客户端的记录(在你工作的主客户端)已经默认被创建。
4.
要想加入新的客户端,在
Machine name输入IP地址或域名。
5.
点
Add按钮,新的客户端会以
Connected的状态被加到表单中去。
6.
重复步骤5和6,直到全部客户端机器都被加入。
当添加新的客户端时,尽量加那些大致相同处理能力的机器。我们发现添加一个明显比其他机器速度慢的机器比不添加它还要产生更多的socket错误。
我们也发现如果我们设置一台专注的机器作为主客户端,但是这台机器不参与产生负载。这样的设置,我们会产生较少的socket错误,而且测试结束得更快。
要这样设置的话,从客户端列表去掉主客户端的名字。如果你有一台慢的机器而你不打算用做负载产生机器,它可以作为你的主客户端而不会影响测试的输出。注意,这台主客户端仍然做所有的产生报告和分发测试脚本的工作。一台慢速度的主客户端意味着你的测试启动和结束的速度会慢些,而且要更多的时间来产生报告。
设置性能计数器
WAS可以与Windows NT性能监视器结合简化测试数据的收集。你可以为每个脚本存储你最喜欢的性能监视计数器,WAS 会像其它信息一样收集它们的数据。
把性能监视计数器加到你的脚本
1.
在左边的窗口展开脚本的信息
2.
在右边的窗口点
Perf Counters节点打开相应的视图
3.
在
Collection Interval,输入收集时间间隔。这是以秒计算的取样时间。
4.
点
Add Counter按钮
5.
从
Add counter to report对话框,通过点
Add按钮选机器,对象和你感兴趣收集的计数器。
在WAS帮助文件的"Common performance monitor counters"部分有一系列的通用性能计数器的介绍。
如果你在使用这个特性时遇到什么问题,请参考WAS的基本知识介绍。
运行测试脚本
一旦你设置好了测试脚本,就准备好了在你的客户机运行脚本
启动主客户端的测试
1.
点需要测试的脚本
2.
从
Scripts菜单选
Run
也可以点工具栏上的
Play按钮运行脚本。
检查测试报告
测试完成后,你应该先检查测试报告看是否有socket 或 HTTP错误
从报告中检查这些错误
1.
从
View菜单选
Reports打开相应的视图,见Figure 7.
2.
在左边窗口,双击脚本打开测试报告,如果需要的话
3.
点测试报告名(有测试运行时间指定),如果需要的话。你会看到右边窗口显示报告的概要。
4.
在报告概要,检查
Socket Errors部分是否有任何的socket有关的错误(值不为0)。这里列出每种socket错误的解释:
・
Connect―客户端不能与服务器取得连接的次数。如果这个值偏高,检查在客户端与服务器之间产生的任何潜在的错误。从每个客户端Ping服务器或telnet服务器的端口80验证你得到正确的回应。
・
Send―客户端不能正确发送数据到服务器的次数。如果这个值偏高,检查服务器是否正确地工作着。在客户端打开一个浏览器然后手工点击站点页面验证站点正确地工作着。
・
Recv―客户端不能正确从服务器接收数据的次数。如果这个值偏高,执行和
Send错误相同的操作。还要检查一下如果你减低负载系数,错误是否跟着减少。
・
Timeouts―超时的线程的数目,而且随后就关闭了。如果这个值偏高,在客户端打开一个浏览器然后手工点击站点页面验证是否即使只有一个用户你的程序也会很慢。再做一个不同负载系数的压力测试,看看你的程序的潜在特征。
5.
如果socket错误很低或为0,拉下报告视图找到
Result Codes部分。
6.
检查一下是否所有结果代码都是200,表示所有请求都被服务器成功地返回了。如果找到大于或等于400的结果,继续下面的步骤以查找哪个脚本项(URL)产生这些HTTP错误的。
7.
在左边窗口展开脚本信息
8.
双击
Page Data节点展开所有的脚本项
9.
点每个脚本项在右边窗口看页面数据的报告
10.
在每项脚本的页面数据报告检查
Result Codes部分,验证是否有那项产生了HTTP错误。如果要看常见的结果代码列表,请参考WAS帮助文件的"HTTP result codes"部分。
运行脚本
在准备好以上介绍的测试脚本后,你现在就可以准备运行测试及收集数据了。
你可以按照前面介绍的步骤手工运行每项测试。然而,这将会是一项耗时的过程。
WAS有一个对象模型,允许你创建自己的Microsoft Visual Basic Scripting Edition (VBScript)脚本来控制和配置测试运行。
当测试运行时,你应该监视和记录不同的性能相关的系统计数器,包括跟踪系统吞吐量的计数器,反应时间和资源利用率。
结论:最好的习惯
客户机器。密切监视每个客户端的系统资源利用率。如果CPU或内存使用高于80%,客户端可能已经过载,你应该考虑使用更多的客户端机器来测试。压迫客户端机器会导致不可靠结果和在与服务器连接时产生socket错误。
给服务器设置多层负载。估计一下需要并发请求的最大用户量以便在预备测试中把你的Web服务器群推到100%的使用率。
当没有足够的客户端机器来使服务器群到达极限时,就需要设置更高的负载倍数,例如,如果你发现使用4,000个线程,都乘一倍的负载系数,你还是不能把服务器推到极限的话,把负载系数加大。然而,使用大于1的负载系数会产生不精确的Web程序页面的TTLB。如果有可能,增加更多的机器比靠增加负载系数要好。
使用
Session
跟踪。使用Session跟踪来记录WAS 和Web服务器之间的详细连接。当定义一个新的WAS脚本时,确保所有的URL都正常工作而且Web服务器返回的是所需要的结果。如果不是,那么很有可能你得到改进的性能结果,但是Web服务器返回的却是错误的响应。
你应该设置SessionTrace为1,类型为REG_DWORD。SessionTrace线程跟踪可以在注册表的\HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \WAS注册。最后,记得在确认了新的脚本后关掉SessionTrace(0),否则,你的磁盘会很快就满了。
监视
Web
服务器的日志文件。要准备重新部署或清除你的Web服务器日志文件。太多的性能测试会使它膨胀的很快,尤其对于长时间的测试。你也可以把日志文件作为故障检查员帮助你检查WAS报告的应用程序错误。
限制脚本的项数和用户数。避免创建多于1000脚本或用户,除非有特殊原因需要多于这个数目的对象。虽然允许的数目限制是由客户端的内存决定的,你会发现初始化这么多的脚本和用户会花费太多的时间
跟踪HTTP重定向的选项。如果脚本已经录制了重定向的URL就不要再使用这项选项。如果你使用这项选项,重定向的页面将会计算两次。
用户名和密码。 WAS的帮助文件说用USERNAME 和 PASSWORD填表是指定每一个WAS用户的方法。在我们的测试过程中使用USERNAME 和 PASSWORD会大大地增加关闭各个客户端的脚本的时间。从一些WAS的内部使用者得到建议,我们在
QueryString
里指定USER 和 PASSWORD名字-值对。通过为USER 和 PASSWORD设置顺序访问机制,我们保证了密码总是和用户名对应。
除了WAS的一些缺陷外,WAS是你发布网站之前模拟用户使用你的网站的好工具。使用性能测试工具对于成功的网站程序发布有重要作用。这些工具允许你清楚你的程序的性能特征,那么你就会清楚你的程序在高负载情况下会如何表现。你在操作网站的过程中得到的惊奇越少,你的站点就越可靠。