强度测试结束后，对目标值与测试中获取的数据进行比较，可以找到为了满足用户的需要而应当做的一些修正。下列是为性能修正而要检查与评估的各个项目，
硬件升级大概是提高程序能力的一个最简单最低廉的解决方案。硬件升级比聘用一组开发员对程序进行重写要经济的多，比如只要增加内存就可以很方便地将程序的吞吐能力提高一倍。但是如果测试结果表明CPU使用是系统的瓶颈，那么升级的费用会相当昂贵，因为几乎整台机器都要升级，才能达到CPU数量和速度增加。
其它一些与硬件升级包括提高硬盘和控制器的速度，以及加上更快或额外的网卡。
如果评估出的结果与数据库的设计有关，则先寻找热点。分析死锁的数据，确认程序已经做了最大程度的优化避免死锁。必要时要考虑改变数据访问逻辑来解决冲突。试验不同的索引方法。检查数据服务器的查询执行方案，确认查询使用了正确的索引，等等。
优化引用了ActiveX Data Objects类型库的ActiveX组件必须小心地进行分析。不要使用ADO的默认属性。始终都指定属性以防止偶然情况的发生，例如Cursor Type和 Cursor Location 属性。
如果Web应用程序占用了异常大量的内存，这个问题可能是由游标位置的不正确造成的。当使用客户游标时(recordset.cursorlocation = adUseClient)，先了解客户端确实是Internet Information Server而不是浏览器。（这种情况的特例是Remote Data Services，不在本文讨论范围）。开发员常犯的错误是假定客户游标在浏览器而不是IIS的整个数据组中移动。因此，牢记数据组实际上是存储在运行IIS的机器上将让你有意识地注意对资源的合理利用。
比如，程序要存取一张有效的州或国家代码，而这些信息都存储在数据服务器上，利用客户游标生成一个数据组并驻留在IIS上，然后在当地访问这些代码的效率会更高，这样可以避免程序对这些信息访问时，数据服务器上额外的信息往返。
如果有数据存取过程的ASP页面需要很长时间来运行，就有必要将这些数据存取的代码转移到ActiveX组件中去，更可行的办法是放在Microsoft Transaction Server (Windows NT) 或 Component Services (Windows 2000)所带的软件包里，这取决于你使用的系统。这些编译过的代码的运行效率要比Active Server Pages所包含的解释脚本的代码快很多。
监测使用Internet Information Server的程序数量与类型。你可能需要增加更多的服务器，将程序转移到另一台服务器上运行或执行Windows Load Balancing Service
| 上一页 | 下一页 |
| 进行强度测试 | 成功执行强度测试的技巧 |
