Web压力测试是目前比较流行的话题，利用Web压力测试可以有效地测试一些Web服务器的运行状态和响应时间等等，对于Web服务器的承受力测试是个非常好的手法。Web 压力测试通常是利用一些工具，例如微软的Web Application Stress、Linux下的siege、功能全面的Web-CT等等，这些都是非常优秀的Web压力测试工具。
虽然这些工具给我们测试服务器承受能力带来方便，但是它们的危害却更是惊人，甚至于利用随便一种比较全面的测试工具就可以对一台小型的 Web服务器发动灾难性的拒绝式攻击。下面我就带大家利用微软的Web Application Stress进行一次Web压力测试，其目的是为了让大家看到它的巨大危害。
一、工具简单介绍
Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的客户端计算机仿真大量用户上线对网站服务所可能造成的影响，在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。就是因为这些特性，才使它具备了D.O.S轰炸的功能。
小提示：D.O.S（拒绝服务攻击）通过使你的服务计算机崩溃或把它压跨来阻止你提供服务。简单来说，就是让你的计算机提供可能多的服务从而使你的计算机陷入崩溃的边缘或崩溃。
二、工具简单设置
打开Web Application Stress Tool，很简洁的一个页面（如图1），上面是工具栏，左下方是功能选项，右下方是详细设置选项。在对目标Web服务器进行压力测试之前，先对它进行一些必要的设置。
图1
1. 在“settings”的功能设置中（如图2），一个是Stress level (threads)这里是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，更加形象的就是说设置多少轰炸的线程数。一般填写 500～1000，因为这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么设置的越高，轰炸的效果越好。
要改变并发用户数，点Settings图标。如果少于100个用户，你可以直接设置Stress Level，要模拟多于100个用户，你还须设置Stress Multiplier。基本公式为：用户数（线程数）= Stress Level * Stress Multiplier.如果要模拟1,000个用户，你可以设置Stress Level为100而Stress Multiplier为10。
图2
2.在“Test Run Time”中来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别，你根据实际情况来设置吧！
3.其余的选项不太重要，这里就不再浪费笔墨，朋友们可以自己尝试一下设置。
三、压力测试
工具介绍完了，下面来准备条件：这里与一个朋友商量好进行测试，他是单机上网，机器配置是CPU:Athlon XP2500+、内存512MB、硬盘80GB等，机器配置还不错。他在机器上安装了IIS，架设了一台对外的Web服务器，Web服务中的程序是动网 7.0。我就利用压力测试工具对这台服务器进行测试。
步骤1：在工具中点右键，选择Add命令，增加了一个新的测试项目：New script，对它进行设置，在主选项中的server中填写要测试的服务器的IP地址。在下方选择测试的Web连接方式，这里的方式Verb选择 get，path选择要测试的Web页面路径，这里填写/Index.asp,即动网的首页文件（如图3）。
图3
步骤2：在“Settings”的功能设置中将Stress level (threads)线程数设置为1000。完毕后，点工具中的灰色三角按钮即可进行测试（如图4）。测试完毕，等待朋友把任务管理器以及连接查看的截图发过来！
图4
攻击开始后，朋友从任务管理器中可以看到CPU使用率已经达到100%，损耗率达到最大（如图5）。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服务器上的80端口进行了非常多的连接（如图6）。而且它的Web网站已经打不开了，提示过多用户连接，达到了跟 D.O.S攻击一样的目的。
图5
图6
试想，如果利用多台肉鸡对一台服务器进行Web压力测试，那么对这台服务器来说将是灭顶之灾，所以朋友们在使用它之前一定要慎重考虑。
分析测试结果
你可以点工具条上的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_MACHINESoftwareMicrosoftWASSessionTrace的DWORD为1，你可以以调试的方式追踪WAS的活动
· 如果你的WAS报告显示错误,务必检查Event Log，在工具外用浏览器浏览你的页面，然后检查服务器的日志：WinNTsystem32LogFilesW3SVCi
· 如果你的测试客户端机器的处理器使用率超过了%85，你也许需要添加更多的测试客户端
· 一些更有趣的话题会在WAS的文档里出现：Page Groups, Query Strings, Cookies, Web Application Stress Object Model和Active Server Page Client (这个会让你有能力通过Web远程控制测试客户端)
请注意这是个没有技术支持的工具，发送你的问题到webtool@microsoft.com。你可以在Web Application Stress Tool这个网沾上搜索一些常见的问题。你也可以对这个工具进行编程，在同样的网站上有对象模型的参考。