|
|
本帖最后由 橙子0012 于 2018-2-28 15:10 编辑
当我们从传统的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 ... /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页面是否在正确的执行。一旦你熟悉了这个工具，你就可以指向你实际的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就可以了。
|
|
/1 
关于我们
发表于 2018-2-28 15:05:33
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
发表于 2020-12-30 09:50:22
