数据显示在100并发用户数下，每秒可处理89.26个请求，其中响应时间最长的页面是任务执行，平均响应时间是1.66秒。
测试最好由多台客户机来测试，不要在一台测试机上设置超大的连接数Stress Level值，且这些测试机分布在不同的地方。在你测试服务器的内网会出现网页无法显示，访问其他网站的网页也打不开，这时可以让不跟你在同一个局域网内的朋友访问试一下你的服务器。不断的增加或减少连接数，经过多次测试才知道这个服务器能承受多大压力。如果是IIS搭建的服务器还可以修改允许的最大连接数。得到数据后分析数据，服务器资源分布，响应处理速度，大量用户或遭到攻击时该采取哪些相应的措施，以及性能优化。
结论：最好的习惯
客户机器。密切监视每个客户端的系统资源利用率。如果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是你发布网站之前模拟用户使用你的网站的好工具。使用性能测试工具对于成功的网站程序发布有重要作用。这些工具允许你清楚你的程序的性能特征，那么你就会清楚你的程序在高负载情况下会如何表现。你在操作网站的过程中得到的惊奇越少，你的站点就越可靠。
随着Internet应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成 本低廉。对于能够适应用户需求不断变动的可定制页面来说，静态HTML已经退出了舞台，比如内容根据
客户请求变化的页面就是其中一例。这一切都要求系统保 存相关的数据，例如有关用户本身以及用户可能请求哪些信息的数据。
紧跟这些趋势的Web开发者已经开始提供可定制的Web网站。象搜索数据之类的任务现在可以由服务器执行而无需客户干预。然而，这些变革也导致了一个结果，这就是许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。 我们可以使用以下几种方法来解决这些问题： 1. 优化ASP代码。 2. 优化数据库调用。 3. 使用存储过程。 4. 调整服务器性能。
优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。
这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预 先从数据库提取信息写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的 生成。
当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。
为了保证能够在合适的时间更新静态HTML页面，把下面的代码加入到相应的ASP页面前面：
随 着Internet应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成本 低廉。对于能够适应用户需求不断变动的可定制页面来说，静态HTML已经退出了舞台，比如内容根据客户请求变化的页面就是其中一例。这一切都要求系统保存 相关的数据，例如有关用户本身以及用户可能请求哪些信息的数据。
紧跟这些趋势的Web开发者已经开始提供可定制的Web网站。象搜索数据之类的任务现在可以由服务器执行而无需客户干预。然而，这些变革也导致了一个结果，这就是许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。 本文来自无涯教程网:http://www.wuyapc.com
我们可以使用以下几种方法来解决这些问题： 1. 优化ASP代码。 2. 优化数据库调用。 3. 使用存储过程。 4. 调整服务器性能。
优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。
这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预 先从数据库提取信息写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的 生成。
当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。
为了保证能够在合适的时间更新静态HTML页面，把下面的代码加入到相应的ASP页面前面：
每当该页面被调用，脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值，Update.asp脚本就会运行；否则，该ASP页面把余下的HTML代码发送给浏览器。
最后更新时间从Application变量得到，它的第一次初始化由global.asa完成。具体的更新时间间隔应根据页面内容的更新要求调整。
如果每次访问ASP页面的时候都要提供最新的信息，或者输出与用户输入密切相关，这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。
如果数据库内容由客户通过适当的ASP页面更新，要确保静态页面也能够自动反映数