J.D. Meier
September 27, 1999
内容
介绍
剧情
测试需求
介绍测试工具WAS
分析测试结果
影响表现和可测性的因素
模拟多用户
运行需要登录认证的测试
WAS的应用技巧
资源
介绍
当我们从以往的CS结构的应用程序转到当前流行的Web空间的程序时，我们发现我们在尝试跟上不断增长的可测性需求和性能要求。其中一个最大的挑战在于如何确定你的程序能最多支持多少个用户的访问。你如何面对这一挑战？设定清晰的性能目标并使用Web压力测试工具会是一个好的开始。
这篇文章将会介绍如何对你的ASP程序进行压力测试，同时将会介绍微软的压力测试工具- Web Application Stress test Tool (WAS).在接着的一章，你将会学习到压力测试的条件，同时还会学到一些必要的技巧，通过这些学习，你将可以根据测试的结果更加有效的测试和更改你的程序。
剧情
假设你将要发布一个预期有1000用户使用的ASP程序。你清楚的知道你的程序至少能处理两个并发的用户的访问，因为你和你的伙伴能整天地点击这个ASP程序而不会出现任何的问题。你在怀疑到底两个用户能否精确地反映你的程序的受压能力。当然你可以使用标准的测试方法（发布你的程序，然后期待最好的结果出现），然而你还是决定预先测试你的程序的表现。这是一个好兆头！
测试需求
为了更好的测试你的ASP程序，你首先需要决定你的程序将来需要面对多大的压力。通俗的说，压力或负载可以分解成以下数字：
· 最低用户数量。（这个程序的使用者的最低数量是多少？通常这个数值可以是每日或没周或每月的点击量—当然你也可以分解成一个更可控的数值—每小时访问量，）
· 并发用户的总量. (在最高峰时的糟糕状况是啥？作出相应的计划. 希望在有压力的情景下工作正常有效.)
· 请求高峰值. (每秒钟需要发生多少ASP页面? 这也许是在衡量一个ASP程序对用户请求作出反应的能力时的一个最重要的因素.)
为你的程序决定用户量和并发用户数通常是很艰难的事情，而且是在你的程序在被实际使用之前。尤其是网络程序。即便是局域网程序也经常要面对用户增加的问题，所以准确的预计用户量将会是艰难的。当你不晓得怎么开始时，最好从基础的开始：
Internet需要研究的问题：
· 分析你已经有的IIS日志。这个数值会暗示出一些实际的几率
· 你的站点将会有多流行？流行的站点一天会有100万或更多的访问量。不会那么流行？那么假设一些不一样的情景？假设你有1000以上的用户群？你能通过增加更多的硬件设备来处理扩展性问题么？或，你的程序的架构会成为瓶颈么？
· 啥是最糟糕的情景？问一下你的朋友这些情况会发生么？
Intranet需要研究的问题：
· 同样地，分析你已经有的IIS日志。
· 这个ASP程序是可以给每个人用的么？在公司内部网有多少台机器？你的系统管理员可以告诉你有关网络高峰流量的东西么？
· 这个程序有特定的用户对象么？只是HR人力资源部？有多少个人力资源部的员工在使用？
· 最糟糕的情景是怎样的？
假如你不能提前决定适当的负载，那么确定你的程序的最高上限将是你最好的决策。如果被10个用户点击，你能在1秒内发生多少的ASP响应结果？100个呢？1000个呢？10000个呢？记录你的基准。当你从实际使用中得到你的流量日志显示你正在接近你的极限时，你将不仅会为你知道你当前的极限是啥，而且你会有时间准备解决的措施。
介绍测试工具WAS
虽然有许多的压力测试工具可供选择，可是在本文，我会主要集中介绍WAS（就是以前所谓的Homer），WAS是当前微软的标准网页压力测试工具。假如你已经对WebCat很熟悉了，你会激动的发现WAS可以很方便地导入现有的WebCat脚本。假如你以前用过InetMonitor，你会激动的发现WAS也是基于GUI的（对于很多使用命令行的WebCat的用户来说这将会是一个很好的附加特性）。另外一个好处是它是免费的，我的一个好朋友常说，“假如是免费的，那么就是我的。”除了它的价钱优势外，这个工具还提供了完整的功能，而且还在不断地升级更新中。Microsoft.com我们时常要使用它，所以他们会明白这个工具的重要性。
可是你不用过多地理会我的话，只管自己去尝试。我在文章的结尾会提供一个列表，列出一些第叁方的压力测试工具，你可以自己决定选什么工具。底线是你需要一个工具，能够把你的ASP程序放到负载下，在发布之前测试它。
开始使用WAS
我会教你怎样第壹次使用这个工具来测试一个ASP页面。我也会介绍怎样使用署名登录的测试和多用户并发访问的测试，因为这些东西会使初学者找不着东南西北。
首先你需要下载和安置这个工具。你能从下面的链接中得到最新版本
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/intranet/downloads/webstres.asp. 在这个网站上还会有关于这个工具的入门指导，你可以随时回去瞧瞧。
以下是在安置时需要谨防的几点：
· 不要把WAS安置在你的测试目标服务器上，安置在别的机器以确保得到准确的测试结果。
· 在安置WAS的机器上需要有ADO2。1以上的版本。如果oledb32.dll的版本不是2.10.3711或以上，ADO会被WAS自动安置。
· 在安置后你会有一个完整的安置日志，默认会在\Program Files\Microsoft Web Application Stress Tool\INSTALL.LOG.
· 假如你已经安置了旧版本的WAS，更新时会保存数据文件完好。WAS使用Access .mdb文件作为数据存储文件。WAS的初始.mdb包是WAS.mdb，可以在程序安置路径找到。
· WAS在注册表的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WAS存储注册信息。
在运行我们新安置的WAS之前，我们建立一个容易的ASP脚本作为测试页面。建立一个新的叫做MyASPPage.asp 的ASP页面，然后插入以下脚本：
MyASPPage.asp
<%@ Language=VBScript %>
<HTML>
<BODY>
<% CONST ForAppending = 8
set oFSO = server.CreateObject("Scripting.FileSystemObject")
'translate our virtual directory into a physical path
strFilePath = Server.MapPath(Request.ServerVariables("PATH_INFO"))
'grab the root of the virtual directory
strFilePath = left(strFilePath, (InstrRev(strFilePath, "\")))
strFilePath = strFilePath & "MyFile.txt"
'write out to the screen the full file path
Response.Write(strFilePath & "<BR>")
set oTS = oFSO.OpenTextFile(strFilePath,ForAppending, true)
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()))
%>
</BODY>
</HTML>
这个ASP脚本将在一个文本文件中插入SessionId及其活动时间，这样我们可以方便地确认我们的ASP页面是否在正确的执行。一旦你熟悉了这个工具，你就可以指向你实际的ASP页面以作真实的测试。
在服务器的恰当的目录放置你的ASP页面以使它可以被匿名访问。我们在后面将会再试署名访问的测试，可是目前我们需要运行一个最基本的测试。用全路径URL浏览你的页面，包含你的服务器名。例如，一个完整的URL看起来像http://MyServer/MyVirtualDirectory/MyASPPage.asp。一旦你能成功地浏览你的ASP页面（务必检查MyFile.txt这个文件，这个文件会被程序写在虚拟目录的物理位置），你就可以运行WAS做实际的测试了。
当你第壹次运行WAS时，将会出现下面的对话框：
Figure 1. Create a new script
虽然其它选项也很诱人，目前我们先选Manual 这项。将来你还可以从菜单的Scripts或在工具拦点取New Script图标来建立一个新的脚本。
欢迎来到脚本浏览界面。左手边的窗口以树型结构列出了你的脚本。在右手边的窗口里你可以更改你的脚本设置。
在左手边的窗口里的树状列表单击New Script可以激活脚本的浏览。在Server输入框输入你的服务器的称号。在Script Item的第壹项，选择GET作为你的动作。在PATH输入你的ASP地址，以虚拟目录为开始符。见图Figure 2如下：
Figure 2. Enter the URL in the Path field
这时期，你可以点工具条上的Run Script箭头符号来执行你的脚本（务必确保你在左边的窗口点取了正确的脚本）。在发生一个概要的性能报告之前，这个脚本需要运行大概1分钟的时间。
分析测试结果
你可以点工具条上的Reports图标来看引发的报告。这将发生一个与Script tab相临的新的tab。报告被存储在一个纲领视图里。首先，在你的报告下面点Result Codes，这个将给你一个迅速的印象，这次测试是否出现了啥问题。假如你看到的状态代码不是200，你也许需要调查一下出现了啥问题，通常的问题包含署名和不正确的URL路径。
点Overview，你将看到这个测试活动的一个简要迅速的分析。从ASP的技术角度看，Request per Second，是一个需要深入分析的关键值。这个值越高越好。通常，假如你不能从使用报告和预算中决定出一个特定的目标，你可以让ASP 的Requests per Second值高于30，当然这个ASP是没有连数据库或使用其它组件的。因为可以预见，连接数据库将增加程序的担子。
虽然有Request per Second这个计数器默认包含在WAS里，你也许想增加其它的计数器。你可以在点了Perf Counters的图标后通过点Add Counter来增加其它的计数器。一个特别有用的计数器是ASP Requests Queued，这个计数器往往是在识别一个阻塞或长期驻留的页面或组件时的关键。关于分析ASP性能的资源有：
· Tuning Internet Information Server Performance
· Navigating the Maze of Settings for Web Server Performance Optimization
· IIS 4 Resource Kit
影响性能和可丈量性的因素
服务器组成，数据库访问，和其它因素会大大降低ASP的Request per Second值。不一样的配置选择也会起到不一样的作用，在这里我要指出几个常出现的因素：
· 假如你在访问一个数据库，你是否有做连接池？关于连接池的详细资料请看Pooling in the Microsoft Data Access Components.
· 你是否在使用ASP Session 变量来存储状态？Session 变量会很快地影响可测性。它们需要服务器资源，而且假如你想增加机器以扩展性能，它们会起阻碍作用，因为Session是与特定机器相关连的。无状态是最大化可扩展性的要领。关于Session的替代请参考这篇文章: HowTo: Persisting Values without Session.
· 你是否在Session状态中存储有Visual Basic的组件？现在就去掉它们。Session中的Visual Basic对象会造成线程相关性而且会干扰打击IIS的线程池。这是一个复杂的主题，可是满足它的经验方法是：不要在Session中存储Single-threaded Apartment (STA) objects。假如你需要在Session中保存对象，它们应该被标记为”Both”，而且你需要自己聚合这些自由线程成为一个集合。Active Template Library (ATL)可以建立这样的怪物。
· 你的网络程序是被限定运行在它自己的内存空间的么？其实我们推荐进程保护。然而，假如你需要榨出一些额外的性能，在进程中运行你的网络程序将会节省一些交叉进程集合的开销。
· 当涉及Microsoft Transaction Server (MTS) components时，如果组件是作为服务器包而运行的而不是库包，那么将会有明显的性能区别。一个通常的建议是设置网络程序在它自己的内存空间中运行，然后在库包中运行MTS组件。
模拟多用户的情景
我会简要的介绍怎样在WAS中模拟多用户请求的情景。你需要做两件事：
1. 在Settings面板改变Concurrent Connections。
2. 在Users建立用户，至少要建立多于你在Concurrent Connections里指定的用户数。
要改变并发用户数，点Settings图标。如果少于100个用户，你可以直接设置Stress Level，要模拟多于100个用户，你还须设置Stress Multiplier。基本公式为：用户数（线程数）= Stress Level * Stress Multiplier.如果要模拟1,000个用户，你可以设置Stress Level为100而Stress Multiplier为10。
假如你在没有设置充分的用户前尝试运行脚本，你将会得到一个警告。通过点Users图标可以更改你的用户数，你将在右边的窗口看到一个默认的Default组。双击Default组展开你的用户列表，假如你被允许匿名访问，那么你仅需容易的填入新客户的代码然后点Create即可。
运行需要署名登录的测试
假如你想运行需要署名登录的页面，那么你需要建立适当的用户名和密码以便WAS在运行时可以使用。这同样是在Users设置的。你可以一开始就通过Remove All去掉当前的用户列表，然后添加你期望的用户，你也可选择从文本文件导入用户名和密码。
可是不管咋样，需要确保这些用户拥有有效的帐号，而且他们都能访问IIS服务器。假如你使用的是BASIC基本认证用户帐号，你可以通过在你的浏览器提交证书来测试这个帐号，在文本文件写出Request.ServerVariables("AUTH_USER")这个值将会有很大的帮助作用。我们更改后的ASP代码将看起来是这样的：
oTS.writeline("Session Id: " & Session.SessionId & chr(32) & _
"Time: " & Cstr(now()) & "AUTH USER: " & chr(32) & Request.ServerVariables("AUTH_USER"))
使用WAS的技巧和提示
作为结束，我会提供一些技巧和提示，还有一些经验总结：
· 调整你的网站的日志文件的存储,因为这个文件将会迅速的增大（见IIS文档）
· 通过设置注册表中的HKEY_LOCAL_MACHINE\Software\Microsoft\WAS\SessionTrace的DWORD为1，你可以以调试的形式追踪WAS的活动
· 假如你的WAS报告显示错误,务必检查Event Log，在工具外用浏览器浏览你的页面，然后检查服务器的日志：\WinNT\system32\LogFiles\W3SVCi
· 假如你的测试客户端机器的处理器使用率超过了%85，你也许需要添加更多的测试客户端
· 一些更有趣的话题会在WAS的文档里出现：Page Groups, Query Strings, Cookies, Web Application Stress Object Model和Active Server Page Client (这个会让你有能力通过Web远程操控测试客户端)
请注意这是个没有技术支援的工具，发送你的问题到webtool@microsoft.com。你可以在Web Application Stress Tool这个网沾上搜索一些常见的问题。你也可以对这个工具进行编程，在同样的网站上有对象模型的参考。
资源
要想获取更多的信息，WAS的网站上的tutorial是一个好去处。当然，请务必读一下随WAS附带的在线帮助—尤其是一个叫Web stress testing overview的话题。
· WebHammer。一个由ServerObjects做的用于测试网络程序和服务器的工具
· LoadRunner .一个由Mercury Interactive做的压力测试工具,可以用来预见企业级程序的系统表现和性能
· Enterprise Monitor .由MediaHouse Software公司出品，用于监视，通报和恢复你的intranet 和 internet网络
· Extreme Soft's PerfMon。为Microsoft Transaction Server而做的工具，能从性能监视中提供直接的MTS监视。
J.D. Meier在美国东海岸诞生并成长。自从留意了Greeley的建议以后，他就成了一名开发支持工程师，专注于服务器端的组件和涉及MTS和ASP技术的Windows DNA应用。
