内部处理数据服务器的各种 MDAC 服务和格式化用于显示的数据通常会消耗专用于 Web 应用程序的大多数可用服务器资源。因此，当对应用程序进行压力测试时，如果与应用程序的数据访问和数据操作区域有关，则必须特别考虑这些组件的性能。
数据库用户连接、锁争用和死锁是数据服务器上要监视的主要对象。定期查看数据库的管理控制台中的进程信息（例如，在运行 SQL Server 的计算机上，是在 SQL 企业管理器的Current Activity区域中)。检查阻塞的服务器进程 ID，它是不返回响应的数据查询的常见原因。这是个争用问题，并且通常要求对数据库设计或应用程序逻辑进行重大更改。
可以用不同的方法识别死锁。识别死锁的最常用的方法是使用性能监视器中的Number of Deadlocks/sec自定义计数器。应用程序应该已经检查死锁问题并适当响应，因为允许数据服务器指定死锁受害人（即，将被取消以解决死锁的用户或会话）会引起应用程序问题。应用程序应在遇到死锁时检测死锁情况，并相应响应。遇到死锁时一般做法是等待几毫秒，然后再重试操作；通常，死锁仅是对时间敏感的错误，当重试操作时该错误将会消失。
计算压力测试结果当完成压力测试并且测试结果可用于检查时，目标性能基准与测试期间收集的统计的比较将指出所需要的更改，以确保用户将需要的吞吐量。以下是需要进行性能改正应检查和计算的特定方面： 硬件 数据库设计 ActiveX 组件 客户端游标 ASP 执行 IIS 负载硬件
也许增加应用程序吞吐量最简单和最经济的解决方案是硬件升级。通常，升级硬件比付钱给开发人员团队重写部分应用程序要经济高效得多。例如，只是通过将更多的 RAM 添加到服务器，您可以使应用程序的吞吐量加倍。然而，如果测试结果表明 CPU 使用率是瓶颈，则升级可能更贵，因为可能必须升级整个计算机来增加 CPU 的使用数量与速度。
其他与硬件有关的增强包括增加硬盘和控制器的速度以及添加更快或附加的网络接口卡。
数据库设计当计算有关数据库设计的问题时，请寻找作用点。分析死锁统计，并确认已经优化了应用程序以尽可能避免死锁。如果有必要，请考虑更改数据访问算法以避免争用。用不同的索引解决方案进行实验。检查数据服务器的查询执行计划以确认查询正在使用适当的索引，等等。
ActiveX 组件应认真分析包含对 ActiveX 数据对象类型库的引用的 ActiveX 组件以进行可能的优化。不要使用 ADO 中允许的默认属性。为避免意外使用默认属性，应总是指定某些属性，例如，Cursor Type和Cursor Location属性。
客户端游标如果 Web 应用程序消耗了异乎寻常的大量内存，则游标定位的不适当使用可能就是问题的原因。当使用客户端游标 (recordset.cursorlocation = adUseClient) 时，注意客户端实际是 Internet Information Server，而不是浏览器。（该规则的例外情况是当使用 Remote Data Services 时，本文不对此进行讨论。）开发人员常犯的错误是假定客户端游标的使用将整个记录集移动到浏览器而不是运行 IIS 的计算机。因此，记住您实际正在将记录集存储到运行 IIS 的计算机上将使您更多地意识到所用的资源。
例如，如果应用程序要求访问列出有效州或县代码的表并且该信息存储在数据服务器中，则使用客户端游标创建驻留在 IIS 计算机上的记录集，然后本地访问该代码将更有效，这样避免了当应用程序访问该信息时需要另外往返于数据服务器。一定要注意利弊关系，如果内存不可用，则不要以大内存要求加重 IIS 的负载。
ASP 执行如果包含数据访问过程的 ASP 页花费太长时间执行，则可能需要将数据访问代码从 ASP 页移动到 ActiveX 组件，该组件一般放置在 Microsoft Transaction Server（在 Windows NT 中）的包中或 Component Services（在 Windows 2000 中）的包中，这取决于正在运行的操作系统。该编辑代码运行效率比包含在 Active Server Page 中的解释脚本代码有效得多。
Internet Information Server 负载监视正使用 Internet Information Server 的应用程序数量和类型。可能需要添加附加的服务器，将应用程序移动到另一服务器，或者考虑实现 Windows Load Balancing Service。
成功运行压力测试的提示 要： 将所有业务逻辑放在 ActiveX 组件中，并使用 ASP 页作为将所有事物连接在一起的胶贴物。将可再次使用的代码封装入库。 使用 MTS（Windows NT 用户）。该出色的工具提供附加的线程和资源池，以用于服务器端 COM 对象并且更容易管理对象。此外， MTS 提供业务功能。 使用资源/连接池。默认情况下，该 MDAC 功能是启用的，但是应该对其监视以确保它正确工作。 调节数据存储区。在可适用的地方使用存储过程。 为了最小化数据访问操作，为输入、输出和转换数据使用缓存。 只要有机会就使用进程内应用程序和 ActiveX 组件。 确保生产环境中调试是禁用的。调试应用程序会强制线程相似性。 在 Intranet 环境中，只要可行，将工作卸载给客户端浏览器。 升级到 Windows 2000。当对应用程序进行压力测试时，包括在该新版本中的性能和可缩放性增强即刻显现。 如果这时无法升级到 Windows 2000，至少应该升级到 Microsoft Visual Basic? Scripting Edition (VBScript) 5.0；在该新版本中性能和功能已大大提高。 考虑使用 Microsoft Message Queue Server (MSMQ)。恰当使用异步消息处理将大大增加可感知的用户响应时间。不要： 使用 Active Server Page 中的应用程序或会话级别对象。 将数据访问代码放在 Active Server Page 中。使用脚本代码与 ActiveX 组件中的数据访问函数和业务规则进行通讯。 使用 HTTPS/安全套接字层，除非绝对必要。实现该身份验证协议非常昂贵。 使用应用程序状态或会话状态（在不必要时）。结束摘要Internet 使您的应用程序可以比传统的客户端－服务器应用程序面向更多的潜在用户。随着越来越多的组织将 Web 作为他们业务策略的策略部分，他们需要确保他们选择的技术可以处理他们苛求的需要。除了容易使用的工具，这些组织还需要基础结构来满足他们用户负载要求。因此，压力测试是测试体系的基础部分这个理念比以前更重要，特别是当将 MDAC 合并到应用程序中时。
注意在压力情况下成功运行的基本要求是在开发周期中采取最佳惯例方法。这就意味着为负载条件下的性能测试和调整应用程序以达到性能目标的时间调度必须考虑到开发过程中。负载下的压力测试和反复调节应用程序的好处是简单明了： 获得需要的信息以确保应用程序取得最好的吞吐量结果。 可以精确地评定应用程序的可缩放性特征，以便可以调整应用程序达到指定的性能目标。 可以尽早发现降低性能和吞吐量的设计问题，并且在将应用程序部署到生产之前可以进行调整。 应用程序将因为其高性能可信赖性而在客户与业务伙伴中树立起声誉。
文章来源于领测软件测试网 https://www.ltesting.net/
