当认真地制定好测试方案后，实际进行测试的过程是很简单的。性能测试的第一步是使用类似Microsoft Web Application Stress Tool的工具对Web站点进行强度测试，测定Web服务器每秒种所能处理的最大请求数，这是定量的测量。第二步确定CPU，内存或终端设备中哪一项限制了每秒请求数达到更高的水平；这个过程与其说是一门测量技术，倒不如说是一门艺术。
先选择你计划运行的ASP页面(寻找并使用站点上最慢的页面)，这要根据访问数据库最频繁和查询量最大最复杂的页面来确定。这一点非常重要，最好是宁可包括一些不在这之内的更多的页面，也不要遗漏一些关键的代码路径。另外如果有可能的话，可以考虑象实际中一样，按照特定的顺序访问一系列页面，将cookie和查询字符串传递到每个页面来测试程序。
注意 根据实际程序的不同，可能有必要为测试准备一些ASP页面。其中的一些页面会需要通常由应用程序生成的代码参数，这些参数Web强度测试工具是不能生成的。
在Internet Information Server上运行程序时，应当对下列指标进行监测（用Performance Monitor）。
注意 如果程序在Windows NT 4.0下运行于独立的内存中(或在 Windows 2000中将Stress Properties页的Application Protection设为High [Isolated] )，就应当监测mtx.exe(在Windows 2000 里是dllhost进程)而不是Inetinfo进程。
如下图所示；Performance Monitor里每秒Active Server Pages请求数将显示程序的实际吞吐能力（在本例中是1.000 Requests/Sec），这一数据使得你能对高强度下Internet Information Server的性能进行分析，然后找到潜在的瓶颈的精确位置。反过来也使你可以判断程序在可接受的响应时间下，所能承受的最大用户数。
图三.性能监控器
使用ASP技术的Web服务器在启动时，从已经建立的大量线程中为每个页面请求都指定一个线程;如果所有的线程都已经被使用了，就将后续的页面请求排在队列中。在Performance Monitor中对总队列长度进行监视，可以确定有多少客户在等待服务器的响应。
最为常见的两个关系到数据库强度性能，与硬件无关的问题就是死锁和并行锁定。在数据服务器上使用数据存储器自带的Performance Monitor监视器时，至少应当对下列各指标进行监视。
Web应用程序的设置同时也应该利用到OLE DB 资源合并的优点，这个应用程序由中间层OLE DB provider for Microsoft SQL Server 7.0自动进行管理的。先创建每一页面基础对象的连接，然后立即释放它们，通过这一方法，可以用很少的打开数据库的连接，处理成千上万个并行用户，这样就保护了数据库的资料，也提高了稳定性，这个增强的性能要用跟踪数据服务器上用户连接数的方法来进行监测（使用Performance Monitor）。当访问量增大时，用户连接数应该保持稳定，因为资源合并控制了在数据服务器上实际生成的连接数。
要达到预期的性能，依据数据库对程序进行调试的过程是非常关键的，所以必须作为开发周期的一个重要环节。这一过程包括对分配内存的大小，程序在各磁盘驱动器和控制器上分布，以及ActiveX组件的机器位置进行优化。只要有可能，就特别应该考虑消除进程之间数据的排队问题，因为这会占用非常大的运算量。
运行测试的时间，应是预期的实际用户环境中程序连续运行时间的一半以上。许多问题，尤其是内存不足，只有当程序运行了较长的一段时间后才会出现。
Performance Monitor中每个指标的平均值是由程序与硬件的配置共同决定的。所以进行测试的时候，应当注意每一个指标是否偏离了平均值。
监测Internet Information Server
在寻找系统瓶颈时，Internet Information Server上最需要进行监测的是下面各项：
- CPU利用率
- 内存使用情况
- 吞吐能力
在测试过程中，根据设计的程序运行的不同环境，会想要跟踪其他的一些性能指标，这些都是可以选择的。程序出现下面任何一种的情况，都表明可能存在问题，需要在最终发布前予以修正。
CPU利用率
CPU使用的下降表明程序的性能有下降，这可能是由线程冲突问题引起的
在对CPU的用户使用时间与内核使用时间的比值进行监测时，请记住用户的使用时间应当占到CPU总使用时间80--90%这条规则。所以内核使用时间超过20%就意味着内核层的API调用指令有冲突。
为了让你对机器的投资有效地得到利用，应使CPU的利用率在负荷达到峰值时超过50%。如果低于这个值，表明在系统其他地方还有需要解决的瓶颈问题。
内存使用情况
长时间运行服务器程序后，内存使用出现突跃或缓慢增长也是常见的一个问题，这是正常的在测试阶段暴露出来的资源不足问题。
吞吐能力
监视Active Server Pages每秒请求数这个指标，能够诊断出程序是否或何时开始出现性能问题。实际环境中这个数值会出现正常的波动，但是小心地设定线程与并行连接的数量（如在Web Application Stress Tool进行设置）可以模拟出一个稳定的请求数。这个数值的突然降低也说明有问题存在。
选择性测试
下列是在测试过程中，其他一些值得进行监测的指标
- 总队列长度. Performance Monitor中总队列长度都会上下波动，这是很典型的。所以如果CPU使用率很低，而总队列长度却始终没有增加，就表明这是一个运行很平稳的站点，它的能力比此负荷所要求的还高出不少。但是，如果总队列长队在上下波动，而CPU的使用率低于50%，那就表明有些请求被阻滞了，需要对程序进行更进一步的优化。
- 浏览器响应时间. 你可以定期的用浏览器访问Active Server Pages监测响应时间，保证测试正在正常地运行和Web站点仍然能正常地提供ASP页面服务。建议在整个强度测试过程中每天至少进行两次。
- 超时错误. 在浏览测试中要注意Internet Information Server返回的超时错误；这些错误可能说明有过多的用户在同时对程序进行访问。
监测数据服务器
数据服务器内部的各种MDAC服务和显示数据的格式化过程，通常都占据了绝大部分Web程序所使用的服务器资源。因此在对程序进行强度测试的时候，对这些组件的性能给予特别的关注是必要的，因为它与程序中数据访问和操作部分是联系在一起。
数据库的用户连接，锁定冲突与死锁是数据服务器上需要监测的主要几个候选参数。定期对数据库控制台中的进程信息进行检查（例如SQL Enterprise Manager中的Current Activity），查找受到阻滞的服务器进程ID，这是一个引起数据查询没有响应的常见原因。它是一个冲突问题，通常要对数据库设计或程序逻辑做很大的调整才能解决。
死锁问题可以用很多方法认定。最常用的是在Performance Monitor里通过Number of Deadlocks/sec的数值来认定。程序的死锁问题必须经过检查，而且要做到能够正常响应才行，因为如果由数据服务器来确定死锁的承受者（即为了解决死锁而被取消的用户或对话）将使程序有很大的毛病。在出现死锁时，程序应能自行能检测到，并做出相应的对策来解决问题，通用的方法是等待几毫秒后再次进行操作，一般来说，死锁都是对时间敏感的错误，重试就能够消除问题。
| 上一页 | 下一页 |
| 强度测试的准备 | 强度测试结果的评估 |
