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

简介

在开发和部署 Microsoft Windows DNA 应用程序时，对应用程序进行强度测试这一步骤常被忽略，而它却能保证，在生产环境中有大量授权用户访问应用程序时，它能正常执行。本文着重介绍，在利用“Microsoft 数据访问组件 (MDAC)”开发应用程序时，进行强度测试的重要性，另外还提供轻松完成该过程的一些技巧。

本文旨在帮助有经验的开发人员和 IT 专业人士，设计和实现一个完整的强度测试方案，诊断测试结果，并针对方案的缺陷提出改进意见。本文假定读者已熟悉 Microsoft Windows NT Server、Microsoft SQL Server、Microsoft Internet 信息服务器 (IIS)、Active Server Pages (ASP)、Microsoft ActiveX Data Objects (ADO) 等技术，以及“Microsoft 组件服务”环境（若使用 Windows NT，则为 Microsoft Transaction Server [MTS]）。

在 COM 或 DCOM 组件（包括 ADO 组件）中，应强调业务逻辑和数据访问过程的正确实现。为性能和可靠性起见，这些过程不应驻留在 Active Server Pages 中。如果您关心自己的应用程序在强度下运作的情况，那么您很可能已将应用程序设计为利用这些组件，并利用“组件服务”环境的有利因素。

本文不打算讨论客户端浏览器或带宽限制导致的强度问题，而重点关注服务器端的数据访问组件，及其与“Internet 信息服务器”的交互作用。本文也不涉及因使用“远程数据服务 (RDS)”而产生的复杂问题。

为什么对我的应用程序进行强度测试？

在生产环境下部署应用程序之前，都应进行强度测试。对启用 Web 的应用程序进行强度测试，其根本目的在于实现以下内容：

• 精确度量系统增加了整体用户负载之后的单个用户的体验
• 确定应用程序使用的硬件的最大容量，并以此确定，在生产环境中部署该应用程序之前，是否有必要将硬件升级
• 根据应用程序用户的平均页面响应时间，确定能接受的性能阈值
• 确保在系统承受估计的最高并发用户负载时，其性能阈值仍保持在可接受的水平

就大多数 Web 应用程序而言，用户的体会是，只要应用程序成功了，其他都不在话下。然而，有许多很好的理由说明，您的应用程序需要通过强度测试，理由如下：

• 在开发过程中状态良好的应用程序，在强度测试环境中会表现得很差。例如，当多个应用程序同时使用“Internet 信息服务器”或 SQL Server 机器时，若再向其中增加新的应用程序，而您又未将该应用程序设计为在该情形下正常运作的话，就会干扰甚至中断已有的应用程序。
• 您的客户在最初几次使用您的应用程序时，会形成其对应用程序的最重要的印象。如果因为强度问题使客户的这一印象不佳，则很难扭转这个印象，即使您事后已解决了那些问题。从另一方面来讲，如果您的应用程序在部署前经过了充分的强度测试，那么作为一个创建了既好又快且能按客户需要运行的应用程序的开发人员，您自然能在客户心中建立起声誉。
• 负责部署和维护此应用程序的 IT 小组，甚至比您的用户更感激您做了强度测试。他们站在第一线，将最先听到用户的意见和看法。如果您能提前确切地想到可伸缩性问题，而这个问题会影响到 IT 小组，那么这个组的成员会在您需要他们的技术时，积极主动地帮助您。
• 针对客户满意的考虑中还包括潜在的合作伙伴。如果他们决定将您的应用程序纳为其更大的应用程序软件包的一部分，就会使您的应用程序增添更大的成功。

进行强度测试前的准备工作

要确定最佳情况下服务器分析值（亦称基线），应首先在控制环境中测试引导系统的配置。接下来应在模拟的生产环境下测试，以确定生产环境的配置对引导系统结果的影响情况。

在开发周期的强度测试准备阶段，应着重考虑以下几个方面：

• 硬件和软件配置
• 服务器配置
• 安全配置
• 用户负载配置
• 选择正确的强度工具

硬件和软件配置

引导系统应尽可能地镜像生产系统。CPU、RAM 和网络带宽的硬件配置，是强度测试中需针对的最重要的领域。要尽最大努力复制软件配置，如适当的 Microsoft Windows 版本和服务包、MDAC 版本、“Internet 信息服务器”配置，以及在实际的生产系统中同一机器上运行的所有其他应用程序。安装和注册中间层业务规则和数据访问 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 信息服务器”配置为镜像生产服务器。Internet 服务管理器属性页为 IIS 提供各种不同的调节选项。其中尤为重要的是，确定是否启用日志（它可显著地减慢系统的速度），以及在性能选项卡下选择期望每日访问的数量。

在数据服务器中，大多数与强度相关的问题都是有可能解决的。为了更有效地执行查询，严格意义的数据库设计的正常化势在必行。因此，对您的应用程序即将涉及的实际数据库进行强度测试，也是势在必行的，而且您还应确保那些表植入了您的应用程序所能产生的最大量的数据。另外，要保证您的测试数据服务器的配置选项（最重要的是使用的锁定和单独级别以及优化技术 — 例如，表索引）与生产数据服务器的配置选项相一致。

安全配置

在您的应用程序的安全方案中，会有在强度下影响到应用程序的严重性能问题，尤其是在系统包含加密技术（如 Microsoft Cryptography API）的情况下。因此，您应将测试系统配置为使用同一安全方案，但不必使用同一凭证。Microsoft Windows NT LAN Manager (NTLM) 通过验证系统，也许是访问后端数据存储的 intranet 应用程序的最通用的安全协议。如果可能，您应当考虑使用“组件服务”内部的角色（若在 Windows NT，则为 MTS），来简化和优化安全验证进程，从而提高性能和稳定性。

用户负载配置

首先确定预期访问您的应用程序的最大用户量，再把这个数加倍；成功的应用程序非常可能为远远多于预计数量的用户而使用。另外，再计算每天大多数用户需要访问的时间，然后确定那个时间段的网上负载。这个策略使您能测试用户负载的影响，以及系统范围内的硬件配置，以保证应用程序在网络高峰期能够照常响应。

选择正确的强度工具

在实际的数据中心环境下，Web 服务器总是处于高的连接水平，因为许许多多客户，通过公司 intranet 或者 Internet 连着 Web 应用程序。Web 强度工具应当有能力模拟大量带有足够线程的并发连接，在缩小发送至 Web 服务器的程序包大小的同时，最大限度地增加并发连接。很高兴的是，已经有了不少这样的工具，它们可以精确地模拟这些情况。其中一例，就是 Microsoft 的 Web“应用程序强度工具”，这是当前可从 Microsoft（站点 http://webtool.rte.microsoft.com/（英文））免费获得的工具。它提供了所有必需的能力，以及一些最好的附加功能，例如，扩展的报告功能。

Web 应用程序增加强度工具

Web 应用程序增加强度工具，通过实际模拟多个请求 Web 应用程序的页面的浏览器，来激活测试环境，并且允许从您的浏览器访问想要包括在协议中的页面，从而能够记录脚本。于是，该脚本能够在任何安装了此应用程序的 Windows NT 或 Windows 2000 客户机上保存和运行。因为 Web 应用程序增加强度工具能够模拟每个独立工作站上的多个客户机，所以没必要配备和您的生产应用程序所配备的一样多的客户机。

注意   在运行增加强度工具时，请小心不要增加客户机上的强度级别，免得您的测试机器在线程间的上下文切换上所花费的时间，比做实际工作花的时间还多。要保证线程确实分布在多个客户机上，请在对基于 Web 的应用程序进行测试时使用多个客户机，从而减轻单一的客户机对资源的限制。

性能监视器

为了有效地对数据访问组件进行强度测试并正确诊断结果，监视和记录运作统计数据的方法是极其重要的。“性能监视器”是随 Microsoft Windows NT 和 Microsoft Windows 2000 一起提供的工具；无论是在“Internet 信息服务器”上，还是在您的数据服务器上，“性能监视器”都是监视和记录这些统计数据的最好工具。

其他工具

除了利用“Internet 信息服务器”上的“性能监视器”之外，还要监视数据服务器上的一些自定义的计数器。性能最好的数据服务器应用程序（如，Microsoft SQL Server、Oracle 和 Microsoft Exchange Server）中，都含有自定义的性能监视器计数器，用它们可以测量应用程序的健壮性和运行此应用程序所用的硬件的健壮性。

进行强度测试

当您仔细策划好测试策略之后，具体的测试工作便非常简单了。性能测试的第一个任务即使用工具，如 Microsoft Web 应用程序增加强度工具，以对 Web 站点增加强度，测量每秒钟 Web 站点能够处理的最大请求数。这是定量测试。第二个任务是，确定阻碍了每秒请求数进一步增长的资源，是 CPU、内存，还是后端相关领域；这个过程与其说是精确的测量技术，不如说是一种艺术。

首先，运行计划要运行的 ASP 页。（寻找 Web 站点中运行得最慢的页，并使用它们。）具体的选择，取决于哪些页面访问数据库最频繁，而且使用最大和最复杂的查询。这样选择非常重要：最好所含页面比需要的再多些，以免漏掉某些重要的代码路径。同时，尽可能考虑让您的测试应用程序以指定的顺序访问一系列页面，并将 cookie 或者查询串传送到每个页面，就像此应用程序在真实世界中所做的那样。

注意   根据实际的应用程序，可能需要准备测试用的 ASP 页。部分页可能要求您硬编码参数值，这些值通常由应用程序生成，而 Web 增加强度工具是无法动态生成的。

在“Internet 信息服务器”内部运行您的应用程序时，应当监视（用“性能监视器”）下列计数器：

• Active Server Pages：每秒请求数、被拒绝的请求、总的查询长度和当前会话数
• Inetinfo 进程：私有字节、虚拟字节和打开的句柄数
• 处理器：用户时间百分比与特权时间百分比

注意   在 Windows NT 4.0（在 Windows 2000 中则使用强度属性页中的应用程序保护：高（单独） 设置）中，如果您的应用程序运行在它自己的内存空间，则应监视 mtx.exe（在 Windows 2000 则监视 dllhost 进程），而不是监视 Inetinfo 进程。

如下图所示，“性能监视器”中 Active Server Pages 每秒请求数计数器将显示您的应用程序的实际吞吐量（在此例中为 1.000 个请求/秒）。这个统计数据使您能够诊断“Internet 信息服务器”在强度情况下的性能，并指出了潜在的瓶颈。也就是使您能够调整应用程序的能力，使它在用户数量达到最多时还能提供可接受的响应时间。

图 3. 性能监视器

运行 ASP 技术的 Web 服务器，从启动时确定的缓存中，给每个页面请求分配一个线程；如果所有的线程都用了，后面的页面请求则放入队列中。利用“性能监视器”监视总的查询长度，即可确定有多少客户机正在等待服务器的响应。

有两个最常见的非硬件强度相关的数据库问题，即死锁和锁定并发。在数据服务器中，利用数据存储可提供的自定义“性能监视器”计数器，起码可监视以下内容：

• 锁定请求
• 每秒死锁
• 每秒表锁定扩大
• 用户连接
• 活动的事务

您的 Web 应用程序还应当配置成利用缓存的 OLE DB 资源，在 Microsoft SQL Server 7.0 中，该资源是由中间层 OLE DB 提供者自动管理的。如果在每页的基础上创建连接对象，并立即释放它们，数据库便能用很少的打开的数据库连接，来处理数以千计的并发用户。这样做，节省了数据库资源，并能提供极大的可伸缩性。在数据服务器上，这样的性能提高，可以通过跟踪用户连接数（使用“性能监视器”）来监视。随着吞吐量的增加，用户连接数应保持稳定，因为缓存控制着数据服务器上自动创建的连接数。

针对数据库而调整应用程序，对于实现性能目标是十分重要的，而且应归属于开发阶段。这种调整包括优化分配内存的大小，优化应用程序在磁盘驱动器和控制器上的分布，以及 ActiveX 组件的机器位置。应十分重视消除进程间的数据汇集，因为这种数据汇集是一种极其昂贵的操作。

连续进行强度测试的时间周期，应比此应用程序在实际的用户环境中所希望的运行时间长 50％。在应用程序尚未运行到延长的时间周期之前，要对许多问题（特别是内存泄漏问题）下结论为时尚早。

强度测试期间的针对内容

每个“性能监视器”计数器的平均值，取决于您的特定应用程序和硬件配置。因此，在进行强度测试时，应检查每一个计数器，以发现与这些平均值的反常差异。

监视“Internet 信息服务器”

寻找瓶颈时，监视器在“Internet 信息服务器” 机器上的最重要部分如下：

• CPU 利用率
• 内存的使用
• 吞吐量

因具体的应用程序环境而异，还可以选择在进行强度测试时需要跟踪的其他一些性能方面。下面可能方案中的任何一个，都可能发现应用程序中的问题。在最终发布之前，这些问题都是应当解决的。

CPU 利用率

CPU 利用率的下降，可以表示应用程序性能的下降，可能是线程的争用出了问题。

在监视用户态和核心态所占的 CPU 时间时，要记住，一般情况下用户态占用的时间，应当是总的 CPU 时间的 80 到 90％。因此，如果核心态占用的 CPU 时间超过了 20％，则说明存在核心级 API 调用的争用。

若要充分利用您的机器，请将高峰期间的处理器利用率注册在 50％ 以上。较低的利用率说明在系统中还有需要解决的其他瓶颈。

内存的使用

对长时间运行的服务器应用程序来说，内存使用的突跳或渐增，是经常标识为常见问题的另一个领域。通常，这说明在测试阶段中还存在内存和资源的泄漏。

吞吐量

监视 Active Server Pages 每秒请求数计数器，能使您识别应用程序何时或是否开始出现性能问题。在实用的应用程序中，该计数器通常总是在变化的；但是，如果细心地设置线程数和并发连接数（例如，从“Web 应用程序强度工具”配置屏幕），就能够模拟稳定的请求数。该计数器的突降意味着出现了故障。

可以选择的测试方面

下面举例说明在强度测试期间极为值得注意的其他方面：

• 总查询长度。   通常，“性能监视器”中的总查询长度计数器总是在上下变化。因此，如果总查询长度从不增加，而您正在低的处理器利用率下运行，这可能说明您有一个平稳运行的站点，其能力已经超过了强度负载的需要。或者，若是您的查询长度正在上下变化，但是您的处理器运行在 50％ 以下，这可能说明您的一些请求已被阻塞，并要求进一步优化。
• 浏览器响应时间。   您可以定期从浏览器访问您的 Active Server Pages，以监视响应时间，并保证这次强度测试能顺利进行，而且 Web 站点仍能正常服务于 ASP 页面。我们建议，在强度测试期间，这样的测试每天至少执行两次。
• 超时错误。   浏览器测试期间由“Internet 信息服务器”返回的超时错误。这些错误可能表示当前正有太多的用户同时访问此应用程序。

监视数据服务器

供 Web 应用程序使用的服务器资源，多半消耗在用数据服务器内部处理各种各样的 MDAC 服务以及格式化要显示的数据上面。因此，在对应用程序进行强度测试时，当这些组件与此应用程序的数据访问和数据处理方面有关时，对它们的性能予以特别的考虑已是势在必行。

数据库用户连接、锁定争用和死锁，是监视数据服务器的主要选项。在您的数据库的管理控制台（例如，在运行 SQL Server 的机器上，在“SQL 企业管理器”的当前活动区）上定期查看进程信息。检查阻塞的服务器进程 ID，不返回响应的数据查询的常见原因。这是个争用问题，通常要求数据库设计或应用程序逻辑做重大更改。

识别死锁的方法很多。识别死锁的最常见方法，是用“性能监视器”中的死锁数/每秒自定义计数器。您的应用程序应当已经检查过死锁问题，并得到了适当的响应，因为允许数据服务器指定死锁的受害者（即，为了解决死锁，可以取消该用户或会话）可能会使您的应用程序出错。当遇见死锁并因此而作出响应时，此应用程序应当检测死锁的条件。对死锁的常见响应是等待几个毫秒，然后重试这次操作；通常，死锁仅为简单的时间敏感错误，在重试操作时便会消失。

评估强度测试的结果

在完成强度测试并可检查测试结果时，目标性能基准与测试过程中收集到的统计数据之间的对比将表明所需要的更改，以保证用户要求的吞吐量。下面是为修正性能应查看和评估的几个方面：

• 硬件
• 数据库设计
• ActiveX 组件
• 客户机游标
• ASP 执行
• IIS 负载

硬件

增加应用程序吞吐量的最容易最省钱的解决方案是硬件升级。一般来说，与组织一支开发队伍来改写应用程序的多个部分相比，更新硬件要合算得多。例如，简单地添加服务器的 RAM，就可以使应用程序的吞吐量翻番。然而，要是测试结果说明您的 CPU 利用率是瓶颈，则升级可能更昂贵，因为要想增加 CPU 的数量和速度，恐怕整台机器都要升级。

其他硬件方面的增强包括提高硬盘驱动器和控制器的速度，添加更快的或附加的网卡。

数据库设计

在评估数据库设计的相关问题时，请找出热点。分析死锁的统计数据，并确认您的应用程序在避免死锁的问题上已经尽量优化了。如果一定要避免争用的话，可以考虑更改数据访问的算法。试验不同的索引方案。检查数据服务器的查询执行计划，以保证您的查询使用正确的索引，如此等等。

ActiveX 组件

为了尽量优化引用了“ActiveX 数据对象”类型库的 ActiveX 组件，应对它仔细分析。不要使用 ADO 中允许的默认属性。为了避免偶然使用默认属性，请始终指定属性，例如，游标类型和游标位置等等。

客户机游标

如果您的 Web 应用程序要消耗海量内存，那么游标位置的不恰当使用可能是问题的原因。当使用客户机游标 (recordset.cursorlocation = adUseClient) 时，要记住，这客户机实际上是“Internet 信息服务器”，不是浏览器。（本规则的例外是当使用“远程数据服务”时，它的内容已不在本文讨论之列。）常见的开发人员错误是以为使用客户机游标将整个记录集移动到浏览器，而不是移动到运行 IIS 的机器。因此，记住您实际上正在将记录集存储到运行 IIS 的机器上，将使您更加清楚所使用的资源。

例如，如果您的应用程序要求访问含有有效州代码和国家/地区代码的表，而这个信息存储在数据服务器内，那么使用客户机游标创建常驻在 IIS 机器上的记录集，然后在本地访问这些代码，将是非常高效的，每当应用程序访问这些信息时，不必再在与数据服务器之间来回传输。您一定要懂得如何平衡，如果内存不够则不要用大的内存需求使 IIS 过载。

ASP 执行

如果包含数据访问过程的 ASP 页面的执行时间太长，可能需要将数据访问代码从 ASP 页面移动到 ActiveX 组件，因使用的操作系统而异，最好将它们放入“Microsoft 事务服务器”（在 Windows NT）内部的软件包内，或者“组件服务”（在 Windows 2000）内部的软件包内。这样编译的代码，比 Active Server Pages 内部的解释脚本码，其运行效率要高得多。

“Internet 信息服务器”负载

监视正在使用“Internet 信息服务器”的应用程序的数量和类型。您可能需要添加附加的服务器，将应用程序移动到另一个服务器上，或考虑实现“Windows 负载平衡服务”。

成功地进行强度测试的技巧

• 应该做的事情：
  • 将所有业务逻辑放入 ActiveX 组件，并用 ASP 页作为粘结剂将所有内容捆绑在一起。将可重用的代码封装到库中。
  • 使用 MTS（Windows NT 用户）。这是一个大的工具，它为服务器端的 COM 对象提供附加的线程和资源缓存，并很容易管理这些对象。另外，MTS 还提供了处理事务的能力。
  • 使用资源/连接缓存。这是默认情况下启用的 MDAC 特性，但应当监视它，以保证它工作正常。
  • 调整数据存储。尽可能使用存储过程。
  • 若要将数据访问操作减至最少，请对要输入、输出和转换的数据采用缓存。
  • 尽可能采用进程内的应用程序和 ActiveX 组件。
  • 在生产环境中，一定要禁用调试程序。调试程序时会强加线程关系。
  • 在 intranet 环境中，尽可能将工作交给客户机浏览器去做。
  • 升级到 Windows 2000。在这次新的发布中增强的性能和可伸缩性，在对应用程序进行强度测试时可立竿见影。
  • 如果这时不能升级到 Windows 2000，至少升级到 Microsoft Visual Basic Scripting Edition (VBScript) 5.0 是个好主意；在这个新版本中，性能和功能将有明显改善。
  • 考虑使用“Microsoft 消息队列服务器 (MSMQ)”。正确使用异步通知，将增强对大量用户响应次数的感知。
• 不应该做的事情：
  • 在 Active Server Pages 中使用应用程序或会话级对象。
  • 将数据访问代码放入 Active Server Pages。使用脚本代码与 ActiveX 组件内部的数据访问函数和业务规则通信。
  • 除了绝对需要的地方，在其他地方也使用“HTTPS/安全套接字层”。实现这个验证协议的成本太高。
  • 在不必要时也使用应用程序状态或会话状态。

总结

Internet 向比传统的客户机－服务器应用程序多得多的潜在用户开放了您的应用程序。随着越来越多的组织将 Web 视作他们经营策略的一部分，他们需要保证所选用的技术能够满足日益苛刻的要求。除了容易使用的工具之外，这些组织还要求基础的架构能满足他们用户负载的需求。因此，将强度测试作为测试计划的基本部分要高于一切，尤其是当您的应用程序合并了 MDAC 之后。

注意   在强度测试条件下，应用程序能够正常运转的最起码条件，是在开发过程中采取最好的、从实际中来的方法。这意味着必须在开发阶段留出这两步的时间：一是加载测试的时间，二是为实现性能目标而调试程序的时间。

在加载条件下进行强度测试和反复调试程序，有下列显而易见的好处：

• 可以获得为保证应用程序有较高吞吐量所需的信息。
• 您可以准确地获得应用程序的可伸缩性特征，因此可以有的放矢地调整应用程序。
• 很容易发现使性能和吞吐量下降的设计问题，能在将应用程序部署到生产环境之前进行调整。
• 在您的客户和商业伙伴中间，您的应用程序将获得高性能的良好声誉。

原文转自：http://www.ltesting.net