Web 应用程序也应配置成利用 OLE DB 资源池，该资源池由 Microsoft SQL Server 7.0 的中间层 OLE DB 提供程序自动管理。通过基于每页创建连接对象并立即释放它们，数据库可以处理数千个并发用户，而使用的开放式数据库连接数少得多。这可保留数据库资源并提供更大的可缩放性。应通过跟踪数据服务器上的用户连接数（使用性能监视器）监视此性能增强。随着吞吐量增加，当池控制数据服务器上实际创建的连接数时，用户连接数应保持稳定。
针对数据库调节应用程序的过程对实现性能目标至关重要，并且必须作为因素计入开发循环。这应包括优化分配内存的大小、应用程序在磁盘驱动器和控制器上的分布以及 ActiveX 组件的计算机位置。要特别考虑尽可能消除进程间的数据封送处理，因为这是非常昂贵的操作。
运行压力测试的时间应比应用程序在实际用户环境中不中断运行的预计时间长百分之五十。许多问题，尤其是内存泄漏，只有在应用程序运行时间超过预期时间后才会暴露出来。
压力测试期间查找的内容每个性能监视器计数器的平均值取决于特定的应用程序和硬件配置。因此，当压力测试运行时，应该检查每个计数器中是否有任何偏离这些平均值的异常偏差。
监视 Internet Information Server当查找瓶颈时，在 Internet Information Server 计算机上监视的最重要方面如下： CPU 使用率 内存使用 吞吐量
根据设计的应用程序环境，在压力测试期间可能还有其他要跟踪的性能方面。下列任何可能的情况可能表明应用程序有问题，在最终发布前应修复这些问题。
CPU 使用率
CPU 使用率的减少可能表明应用程序性能的降低，可能是线程争用问题。
当监视用户时间和内核时间之间的 CPU 时间比时，记住作为规则，用户时间应是 CPU 总时间的百分之八十至九十。因此，超过百分之二十的内核模式时间表明有内核级别 API 调用争用。
为了使计算机物有所值，应该在峰值负载期间注册超过百分之五十的处理器使用率。更低的使用率值可能提示您需要解决系统中的其他瓶颈。
内存使用
内存使用暴涨或逐步增加是另外一个问题，这个问题经常被认为是长期运行的服务器应用程序的常见问题。通常，这是内存和资源泄漏在测试阶段暴露出来的地方。
吞吐量
监视 Active Server Pages 每秒请求数计数器使您得以确定应用程序开始什么时候以及是否有性能问题。该计数器在实际的应用程序中通常有所不同，但是通过认真地设置线程数和并发连接数（例如，通过 Web 应用程序压力工具配置屏幕进行设置），将能够模拟稳定的请求数。该计数器值的突然减少预示着麻烦。
可选测试方面
下面的是压力测试期间可能发现值得监视的其他方面的示例： 总队列长度。通常，性能监视器中的Total Queue Length计数器会上下变动。因此，如果总队列长度从不增加且您正以低处理器使用率运行，这可能表明站点运行平稳，具有的容量比该压力负载需要的大。或者，如果队列长度正在上下变动但是处理器使用率低于百分之五十，这可能表明一些请求正被阻塞，可能需要进一步优化。 浏览器响应时间。可以定期从浏览器访问 Active Server Pages 以监视响应时间并确保压力测试正在正确运行，并且 Web 站点仍可以正确地服务 ASP 页。建议在压力测试期间每天至少执行两次此测试。 超时错误。在浏览器测试期间，留心由 Internet Information Server 返回的超时错误；这些错误可能表明有太多用户正同时访问应用程序。监视数据服务器
文章来源于领测软件测试网 https://www.ltesting.net/
