|
Windows DNA 应用程序中的数据访问组件进行压力测试
内容介绍 介绍Microsoft? Windows? DNA 应用程序的开发和部署中经常被忽略的步骤是对应用程序进行压力测试，确保当生产环境中最大数量的授权用户访问该应用程序时，它将按预期执行。本文强调当涉 及使用 Microsoft Data Access Components (MDAC) 开发应用程序时压力测试的重要性，并且提供一些提示使该过程更容易完成。 本文的目的是帮助有经验的开发人员和 IT 专业人员设计和实现完整的压力测试方案，诊断测试结果，并建议进行某些更改以纠正缺陷。本文假设读者熟悉 Microsoft Windows NT? Server、Microsoft SQL Server?、Microsoft Internet Information Server (IIS)、Active Server Pages (ASP)、Microsoft ActiveX? 数据对象 (ADO) 和 Microsoft Component Services 环境（或者如果使用的是 Windows NT，为 Microsoft Transaction Server [MTS]）等技术。 应该强调 COM 或 DCOM 组件中业务逻辑和数据访问过程的正确实现，包括 ADO 组件。由于性能和可靠性的原因，这些过程不应该驻留在 Active Server Page 中。如果您关心应用程序将如何在压力下运行，则您可能已经设计了利用这些组件和组件服务环境益处的应用程序。 本文不尝试讨论由客户端浏览器或带宽限制引起的压力问题，而是主要专注于服务器端数据访问组件和它们与 Internet Information Server 的交互。本文也不处理因使用 Remote Data Services (RDS) 所带来的难题。 为什么要对应用程序进行压力测试？在生产环境中部署应用程序之前应该总是先执行压力测试。对支持 Web 的应用程序进行压力测试的基本目的是达到下列目标：
对于要获得成功的大多数 Web 应用程序，用户体验最为关键。然而，使应用程序经过压力测试过程有许多充足的理由，包括：
准备运行压力测试要确定最佳情况下的服务器分析值（也称为基准），应首先在受控环境中测试试验系统配置。其次，应该在模拟生产环境中测试以确定生产环境配置如何影响试验系统的结果。 在准备开发循环的压力测试阶段时，需要注意以下方面：
硬件与软件配置试验系统应尽可能镜像生产系统。CPU、RAM 和网络带宽的硬件配置是将在压力测试期间被检测的最重要方面。应努力复制软件配置，例如适当的 Microsoft Windows 版本和 Service Pack、MDAC 版本、Internet Information Server 配置和将在实际生产系统中的相同机器上运行的任何其他应用程序。安装和注册中间层业务规则和数据访问 COM 组件，并按应用程序设计要求对它们进行配置。 务必将测试 Web 站点配置成能够在进程内或进程外运行，具体配置成什么样以最终配置的要求为准。选择该选项将确定 Web 应用程序是在 IIS 所在的同一地址空间中运行，还是在它自己的独立地址空间中运行。该配置对于要执行的压力测试有主要影响。下图显示了 Microsoft Windows NT 4.0 和 Microsoft Windows 2000 中进程外应用程序的“压力属性”属性页配置。在 Windows NT 4.0 中，选择“在单独的内存空间运行（独立进程）”复选框以在进程外运行 Web 应用程序。在 Windows 2000 中，选择“中”或“高”的“应用程序保护”设置以在进程外运行 Web 应用程序。
图 1：Windows NT 4.0“压力属性”页
图 2：Windows 2000“压力属性”页 服务器配置配置 Internet Information Server 以镜像生产服务器。“Internet 服务管理器”属性页为 IIS 提供各种可用的调整选项。特别重要的是确定是否启用记录（可以大大减慢系统速度）并且在“性能”选项卡下，选择预期的每天点击数。 数据服务器是可能解决与压力相关的多数问题的地方。为了有效执行查询，必须正确标准化数据库设计。因此，必须用准备与应用程序一起使用的实际数据库 设计进行压力测试，并且应确保用应用程序将生成的最大数据量填充表。此外，确保测试数据服务器配置选项（最重要的是锁定级别和隔离级别以及使用的优化技 术，例如表索引）匹配生产数据服务器的配置选项。 安全配置应用程序的安全方案对压力下的应用程序会有严重的性能影响，特别是系统包含加密技术（如 Microsoft Cryptography API）时更是如此。因此，应该配置测试系统以使用相同的安全方案，但不必使用相同的凭据。Microsoft Windows NT LAN Manager (NTLM) 传递身份验证系统可能是访问后端数据存储区的 Intranet 应用程序的最通用安全协议。如果可能的话，应该考虑使用组件服务（或 Windows NT 中的 MTS）中的角色，以简化安全身份验证过程并提高效率，以及提高性能和稳定性。 用户负载配置首先确定预期访问应用程序的最大用户数，然后将该数字加倍；成功的应用程序所服务的用户数最可能比预期的多。此外，计算多数用户需要访问的时间，然 后确定那段时间（应该是测试应用程序的时间）内的网络负载。该策略使您能够测试用户负载影响以及系统范围的硬件配置，确保应用程序在网络负载高峰期内按预 期响应。 选择正确的压力工具在实际的数据中心情况中，由于太多用户通过 Intranet 或 Internet 连接到 Web 应用程序，Web 服务器经历高连接水平。Web 压力工具应能够模拟发生高并发连接数的情形，并以充足的线程满足最大的并发连接数，同时减小发送到 Web 服务器的数据包大小。幸运地是，有许多可用的工具被设计来模拟这些实际情况。Microsoft 的 Web 应用程序压力工具就是这些工具中的一个，当前可从在 http://homer.rte.microsoft.com 处的 Microsoft 免费获得它。它提供所有必要的功能和一些好的附加功能，例如广泛的报告功能。 Web 应用程序压力工具Web 应用程序压力工具通过实际模拟从 Web 应用程序请求页的多个浏览器来激活测试环境，并允许通过从浏览器访问想要包括到测试中的页来记录脚本。然后，该脚本可以在安装有该应用程序的任何 Windows NT 或 Windows 2000 客户端上保存和运行。因为 Web 应用程序压力工具能够模拟来自每个单独工作站的多个客户端，所以具有的可用客户端计算机不必与生产应用程序具有的一样多。
性能监视器为了有效地对数据访问组件进行压力测试并正确地诊断结果，使用监视和记录运行统计的方法极为重要。性能监视器是随 Microsoft Windows NT 和 Microsoft Windows 2000 一起提供的工具，它是适用于在 Internet Information Server 中和数据服务器上监视和记录这些统计的最好工具。 其他工具除了在 Internet Information Server 上使用性能监视器外，还有必要监视数据服务器上的某些自定义计数器。大多数高性能数据服务器应用程序，例如 Microsoft SQL Server、Oracle 和 Microsoft Exchange Server，都包括自定义性能监视器计数器，可用于测定应用程序和其运行在的硬件的健康情况。 运行压力测试认真地拟定了测试策略后，实际运行测试是容易的。性能测试的第一个任务是使用工具，例如 Microsoft Web 应用程序压力工具，将压力施加到 Web 站点并测量 Web 服务器每秒能处理的最大请求数。这是定量测量。第二个任务是确定哪一个资源阻止每秒请求数的提高，例如 CPU、内存或后端相关性，这个过程更具有艺术性，而不单是一种精确测量的技术。 首先，选择打算运行的 ASP 页。（寻找 Web 站点的最慢页并使用这些页。）具体的选择取决于哪些页最频繁访问数据库并且具有最多或最复杂的查询。该选择非常重要：包括比必需的更多的页比遗漏一些关键 代码路径要好。如果适当的话，还可考虑让测试应用程序按指定的顺序访问一系列页，并像应用程序将在真实情况中所做的那样，将 cookie 或查询字符串传递到每一页。
当在 Internet Information Server 中运行应用程序时，应该（使用性能监视器）监视以下计数器：
如下图所示，性能监视器中的 Active Server Pages 每秒请求数计数器将显示应用程序的实际吞吐量（此例中每秒的请求数为 1.000）。该统计使您能够诊断压力下的 Internet Information Server 性能，并查明潜在的瓶颈。这反过来使您得以判断应用程序以可接受的响应时间服务数量最多的用户的能力。
图 3：性能监视器 运行 ASP 技术的 Web 服务器从启动时建立的池中给每页分配一个线程；如果所有线程都已使用，后面的页请求将被放置在队列中。通过用性能监视器监视总的队列长度，可以确定有多少客户端正在等待服务器的响应。 两个最常见的与压力有关的非硬件数据库问题是死锁和锁定并发。在数据服务器上，使用数据存储区将提供的自定义性能监视器计数器时，应该至少监视下列内容：
Web 应用程序也应配置成利用 OLE DB 资源池，该资源池由 Microsoft SQL Server 7.0 的中间层 OLE DB 提供程序自动管理。通过基于每页创建连接对象并立即释放它们，数据库可以处理数千个并发用户，而使用的开放式数据库连接数少得多。这可保留数据库资源并提 供更大的可缩放性。应通过跟踪数据服务器上的用户连接数（使用性能监视器）监视此性能增强。随着吞吐量增加，当池控制数据服务器上实际创建的连接数时，用 户连接数应保持稳定。 针对数据库调节应用程序的过程对实现性能目标至关重要，并且必须作为因素计入开发循环。这应包括优化分配内存的大小、应用程序在磁盘驱动器和控制器上的分布以及 ActiveX 组件的计算机位置。要特别考虑尽可能消除进程间的数据封送处理，因为这是非常昂贵的操作。 运行压力测试的时间应比应用程序在实际用户环境中不中断运行的预计时间长百分之五十。许多问题，尤其是内存泄漏，只有在应用程序运行时间超过预期时间后才会暴露出来。 压力测试期间查找的内容每个性能监视器计数器的平均值取决于特定的应用程序和硬件配置。因此，当压力测试运行时，应该检查每个计数器中是否有任何偏离这些平均值的异常偏差。 监视 Internet Information Server当查找瓶颈时，在 Internet Information Server 计算机上监视的最重要方面如下：
根据设计的应用程序环境，在压力测试期间可能还有其他要跟踪的性能方面。下列任何可能的情况可能表明应用程序有问题，在最终发布前应修复这些问题。 CPU 使用率 CPU 使用率的减少可能表明应用程序性能的降低，可能是线程争用问题。 当监视用户时间和内核时间之间的 CPU 时间比时，记住作为规则，用户时间应是 CPU 总时间的百分之八十至九十。因此，超过百分之二十的内核模式时间表明有内核级别 API 调用争用。 为了使计算机物有所值，应该在峰值负载期间注册超过百分之五十的处理器使用率。更低的使用率值可能提示您需要解决系统中的其他瓶颈。 内存使用 内存使用暴涨或逐步增加是另外一个问题，这个问题经常被认为是长期运行的服务器应用程序的常见问题。通常，这是内存和资源泄漏在测试阶段暴露出来的地方。 吞吐量 监视 Active Server Pages 每秒请求数计数器使您得以确定应用程序开始什么时候以及是否有性能问题。该计数器在实际的应用程序中通常有所不同，但是通过认真地设置线程数和并发连接数 （例如，通过 Web 应用程序压力工具配置屏幕进行设置），将能够模拟稳定的请求数。该计数器值的突然减少预示着麻烦。 可选测试方面 下面的是压力测试期间可能发现值得监视的其他方面的示例：
监视数据服务器内部处理数据服务器的各种 MDAC 服务和格式化用于显示的数据通常会消耗专用于 Web 应用程序的大多数可用服务器资源。因此，当对应用程序进行压力测试时，如果与应用程序的数据访问和数据操作区域有关，则必须特别考虑这些组件的性能。 数据库用户连接、锁争用和死锁是数据服务器上要监视的主要对象。定期查看数据库的管理控制台中的进程信息（例如，在运行 SQL Server 的计算机上，是在 SQL 企业管理器的 Current Activity 区域中)。检查阻塞的服务器进程 ID，它是不返回响应的数据查询的常见原因。这是个争用问题，并且通常要求对数据库设计或应用程序逻辑进行重大更改。 可以用不同的方法识别死锁。识别死锁的最常用的方法是使用性能监视器中的 Number of Deadlocks/sec 自定义计数器。应用程序应该已经检查死锁问题并适当响应，因为允许数据服务器指定死锁受害人（即，将被取消以解决死锁的用户或会话）会引起应用程序问题。 应用程序应在遇到死锁时检测死锁情况，并相应响应。遇到死锁时一般做法是等待几毫秒，然后再重试操作；通常，死锁仅是对时间敏感的错误，当重试操作时该错 误将会消失。 计算压力测试结果当完成压力测试并且测试结果可用于检查时，目标性能基准与测试期间收集的统计的比较将指出所需要的更改，以确保用户将需要的吞吐量。以下是需要进行性能改正应检查和计算的特定方面：
硬件也许增加应用程序吞吐量最简单和最经济的解决方案是硬件升级。通常，升级硬件比付钱给开发人员团队重写部分应用程序要经济高效得多。例如，只是通过 将更多的 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。 成功运行压力测试的提示
结束摘要Internet 使您的应用程序可以比传统的客户端－服务器应用程序面向更多的潜在用户。随着越来越多的组织将 Web 作为他们业务策略的策略部分，他们需要确保他们选择的技术可以处理他们苛求的需要。除了容易使用的工具，这些组织还需要基础结构来满足他们用户负载要求。 因此，压力测试是测试体系的基础部分这个理念比以前更重要，特别是当将 MDAC 合并到应用程序中时。
负载下的压力测试和反复调节应用程序的好处是简单明了：
|
|
|
