对 Windows DNA 应用程序中的数据访问组件进行压力测试

内容

介绍
为什么要对应用程序进行javascript:;" onClick="javascript:tagshow(event, '%D1%B9%C1%A6%B2%E2%CA%D4');" target="_self">压力测试？
准备运行压力测试
运行压力测试
计算压力测试结果
成功运行压力测试的提示
结束摘要

介绍

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 应用程序，用户体验最为关键。然而，使应用程序经过压力测试过程有许多充足的理由，包括：

• 在开发中运行很好的应用程序在高压力环境下运行时可能表现很差。例如，当多个应用程序同时使用 Internet Information Server 或 SQL Server 计算机时，如果没有将应用程序设计为可在该方案中正确运行，则将新的应用程序添加到这些应用程序中会干扰、甚至可能会中断现有应用程序。
• 客户将在最初几次使用应用程序时形成对其最重要的印象。如果因为压力问题使最初印象不好，则即使以后解决了该问题，也很难改变他们的印象。另一方面，通过在部署前对应用程序进行充分压力测试，您可以在客户中树立良好的声誉，证明您是创建又好又快且按预期运行的应用程序的开发商。
• 负责部署和维护应用程序的 IT 团队将和客户一样（甚至比客户更加）赞赏您的压力测试。他们身处一线，并且将首先听到意见和评论。如果可以可靠地预见将影响 IT 团队的可缩放性问题，则该团队成员在您需要他们的技术时更愿意帮助您。
• 潜在的业务伙伴也应该包括在客户满意度矩阵中。如果他们决定将您的应用程序作为一个部分包括在更大的应用程序软件包中，则他们可以大大提高您的应用程序成功率。

准备运行压力测试

要确定最佳情况下的服务器分析值（也称为基准），应首先在受控环境中测试试验系统配置。其次，应该在模拟生产环境中测试以确定生产环境配置如何影响试验系统的结果。

在准备开发循环的压力测试阶段时，需要注意以下方面：

• 硬件与软件的配置
• 服务器配置
• 安全配置
• 用户负载配置
• 选择正确的压力工具

硬件与软件配置

试验系统应尽可能镜像生产系统。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 应用程序压力工具能够模拟来自每个单独工作站的多个客户端，所以具有的可用客户端计算机不必与生产应用程序具有的一样多。

注意 当运行压力测试时，注意不要增加客户端的压力水平，以免测试计算机在线程间的上下文切换上花费的时间比实际运行所用的时间多。若要确保线程分布于各个客户端，请在运行基于 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 或查询字符串传递到每一页。

注意 根据实际的应用程序，可能有必要为测试准备 ASP 页。一些页可能要求硬编码通常由应用程序生成的和 Web 压力工具不能动态生成的参数值。

当在 Internet Information Server 中运行应用程序时，应该（使用性能监视器）监视以下计数器：

• Active Server Pages：每秒请求数、被拒绝的请求数、总队列长度和当前会话数
• Inetinfo process：专用字节数、虚拟字节数和打开句柄数
• Processor：百分比用户时间与百分比特权时间相比

注意 如果应用程序在 Windows NT 4.0 中自己的内存空间中运行（或者在 Windows 2000 中的 Stress Properties 页上的设置为 Application Protection: High [Isolated]），则应监视 mtx.exe（或 Windows 2000 中的 dllhost 进程）而不是监视 Inetinfo 进程。

如下图所示，性能监视器中的 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 时间比时，记住作为规则，用户时间应是 CPU 总时间的百分之八十至九十。因此，超过百分之二十的内核模式时间表明有内核级别 API 调用争用。

为了使计算机物有所值，应该在峰值负载期间注册超过百分之五十的处理器使用率。更低的使用率值可能提示您需要解决系统中的其他瓶颈。

内存使用

内存使用暴涨或逐步增加是另外一个问题，这个问题经常被认为是长期运行的服务器应用程序的常见问题。通常，这是内存和资源泄漏在测试阶段暴露出来的地方。

吞吐量

监视 Active Server Pages 每秒请求数计数器使您得以确定应用程序开始什么时候以及是否有性能问题。该计数器在实际的应用程序中通常有所不同，但是通过认真地设置线程数和并发连接数（例如，通过 Web 应用程序压力工具配置屏幕进行设置），将能够模拟稳定的请求数。该计数器值的突然减少预示着麻烦。

可选测试方面

下面的是压力测试期间可能发现值得监视的其他方面的示例：

• 总队列长度。 通常，性能监视器中的 Total Queue Length 计数器会上下变动。因此，如果总队列长度从不增加且您正以低处理器使用率运行，这可能表明站点运行平稳，具有的容量比该压力负载需要的大。或者，如果队列长度正在上下变动但是处理器使用率低于百分之五十，这可能表明一些请求正被阻塞，可能需要进一步优化。
• 浏览器响应时间。 可以定期从浏览器访问 Active Server Pages 以监视响应时间并确保压力测试正在正确运行，并且 Web 站点仍可以正确地服务 ASP 页。建议在压力测试期间每天至少执行两次此测试。
• 超时错误。 在浏览器测试期间，留心由 Internet Information Server 返回的超时错误；这些错误可能表明有太多用户正同时访问应用程序。

监视数据服务器

内部处理数据服务器的各种 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 合并到应用程序中时。

注意 在压力情况下成功运行的基本要求是在开发周期中采取最佳惯例方法。这就意味着为负载条件下的性能测试和调整应用程序以达到性能目标的时间调度必须考虑到开发过程中。

负载下的压力测试和反复调节应用程序的好处是简单明了：

• 获得需要的信息以确保应用程序取得最好的吞吐量结果。
• 可以精确地评定应用程序的可缩放性特征，以便可以调整应用程序达到指定的性能目标。
• 可以尽早发现降低性能和吞吐量的设计问题，并且在将应用程序部署到生产之前可以进行调整。
• 应用程序将因为其高性能可信赖性而在客户与业务伙伴中树立起声誉。