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

http://www.microsoft.com/china/MSDN/library/archives/others/vStudio/DNAstress.asp
 

Windows DNA应用程序数据访问组件的强度测试 Mike Schelstrate 摘要:本文论述了对Microsoft 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® Data Objects (ADO)和Microsoft Component Services environment (或 Microsoft Transaction Server [MTS]，如果使用的是Windows NT) 必须强调的一点是，在包括ADO的COM或DCOM组件中使用的商业逻辑和数据访问过程一定要正确。出于性能和可靠性的原因，这些过程不可以驻留在Active Server Pages里。如果你关心应用程序在高强度下的使用情况，那似乎就表明你已经使用了这些组件来进行程序设计，也利用了Component Services 环境的优点。 本文不准备讨论由客户端浏览器或带宽限制而引起的强度问题，而主要集中讨论服务器端数据访问组件和它们与Internet Information Server之间交互作用所引起的强度问题，对于使用Remote Data Services (RDS)所引起的问题也不予讨论。 为什么要对应用程序进行强度测试？ 在应用程序正式推广到生产环境中进行使用前，常常需要进行强度测试，对网络应用程序进行强度测试是要达到如下的几点基本目的： 获得系统总用户负荷增加时单个用户真实的个人体验 确定运行该应用程序硬件的最大负荷，从而决定在将应用程序推广到实际应用中去前，是否有必要对硬件进行升级。 根据平均页面响应时间，为程序的使用者确定可接受的运行性能的阈值 确保系统在预期的最大并行用户负荷时，性能的阈值仍然处于可接受的水平 虽然对于绝大多数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中Stress Properties属性页的设置。在Microsoft Windows NT 4.0 中，选择Run in separate memory space (isolated process)复选框使Web应用程序运行于进程之外。在Windows 2000中，则将Application Protection选项设为Medium或High来使Web应用程序运行于进程之外。 图一。Windows NT 4.0 的Stress Properties 属性页 图二。Windows 2000 的Stress Properties属性页 服务器配置 配置Internet Information Server来模拟实际中的服务器。Internet Services Manager属性页提供了对IIS进行调整各个选项。较为重要的是要决定是否激活日志选项（激活这一选项将明显地降低系统运行速度），另外要在Performance标签里选择每天预期的点击数。 多数有待解决的与强度有关的问题存在于数据服务器上。为了更有效地执行查询过程，有必要对数据库的设计进行适当的正规化，所以进行强度测试的数据库必须与程序实际将要使用的相同，同时要保证表格集中在程序将要生成的最大数量的数据上。另外还要确保进行测试的数据服务器的配置选项与实际中的相一致（尤其是锁定与隔离层以及使用的优化技术—例如表格索引） 安全性设置 应用程序的安全性方案对处于高强度下的程序有相当严重的影响，特别是假如这个系统使用了例如Microsoft Cryptography API加密技术的话。所以你必须为有待测试的系统设置相同的安全性方案，但不一定需要相同的证书。关于在intranet中对终端存储数据进行访问的应用程序的安全性协议，最常用的大概是Microsoft Windows NT LAN Manager (NTLM)认证体系。如果可能，你应当考虑使用Component Services (或Windows NT 中的MTS)来简化与合理化安全认证过程，并增强系统的性能和稳定性。 用户负荷的设置 首先确定你所期望的访问此程序用户的最大数量，然后加倍；一个成功的应用程序非常可能会有比预期的要多得多的用户。然后，计算一天中大多数用户将进行访问的时间，确定那段时间内网络的负荷，这也就是你将进行测试的时间。这一策略使得你能对用户负荷的影响和系统硬件的配置进行测试，以保证程序在网络高峰期也能有预期的响应。 选择合适的测试工具 在实际数据中心的环境中，由于有大量的用户将经由公司的intranet或Internet来连接Web程序，所以Web服务器将处于很高的连接水平上。Web程序强度测试的工具应当在控制发送给Web服务器数据包大小的同时，有足够的线程数来最大化并行连接数，这样才能够模拟出很高的并行连接数量。幸运的是现在有许多工具都可以模拟出这样精确的环境。其中的一种就是Microsoft的Web Application Stress Tool，可以免费地从Microsoft 的http://webtool.rte.microsoft.com/ 站点获得，它提供了所有必需的功能，还有一些附加的优秀功能，比如多种记录特征。 Web应用程序强度测试工具 Web Application Stress Tool真实地模拟大量浏览器向web程序提出页面请求的过程，创造测试环境，同时也将浏览器所访问的希望在测试中包括的页面记录在一个脚本程序中。这一脚本程序可以保存下来，然后在安将了此应用程序的Windows NT 或 Windows 2000 客户机上运行。由于Web Application Stress Tool 能够在单独的一台工作站上模拟大量的用户，所以测试时并不需要与实际中同样多的客户机。 注意   当你进行强度测试时，请注意不要提高客户机的强度水平，因为那样的话，进行测试的机器将在线程的转换上花费大量的时间，而不是在真正地进行工作。当对一个基于Web的应用程序进行测试时，应多使用几台客户机，以保证线程分布于各台客户机上，从来降低对每一台客户机资源的要求。 性能监控器 要想对数据访问组件进行有效的测试及正确分析所得的结果，最为重要的就是要有一套对运行信息进行监视和记录的方法。Microsoft Windows NT 和 Microsoft Windows 2000附带的Performance Monitor，就是现成的对种信息进行监视和记录的工具，它对Internet Information Server和数据服务器都是适用的。 其他工具 除了在Internet Information Server上运行Performance Monitor以外，还应当注意数据服务器上自带监视器。许多高性能的数据服务器应用程序，例如Microsoft SQL Server, Oracle 和 Microsoft Exchange Server都带有自带的性能监视器，可以利用它来衡量程序和运行此程序的硬件的稳定性。 进行强度测试 当认真地制定好测试方案后，实际进行测试的过程是很简单的。性能测试的第一步是使用类似Microsoft Web Application Stress Tool的工具对Web站点进行强度测试，测定Web服务器每秒种所能处理的最大请求数，这是定量的测量。第二步确定CPU，内存或终端设备中哪一项限制了每秒请求数达到更高的水平；这个过程与其说是一门测量技术，倒不如说是一门艺术。 先选择你计划运行的ASP页面(寻找并使用站点上最慢的页面)，这要根据访问数据库最频繁和查询量最大最复杂的页面来确定。这一点非常重要，最好是宁可包括一些不在这之内的更多的页面，也不要遗漏一些关键的代码路径。另外如果有可能的话，可以考虑象实际中一样，按照特定的顺序访问一系列页面，将cookie和查询字符串传递到每个页面来测试程序。 注意   根据实际程序的不同，可能有必要为测试准备一些ASP页面。其中的一些页面会需要通常由应用程序生成的代码参数，这些参数Web强度测试工具是不能生成的。 在Internet Information Server上运行程序时，应当对下列指标进行监测（用Performance Monitor）。 Active Server Pages:每秒请求安息，被拒绝的请求数，总队列长度和当前对话数 Inetinfo进程:私有字节，虚拟字节和打开的句柄数量 处理器:用户使用时间和特许时间百分率的比值 注意  如果程序在Windows NT 4.0下运行于独立的内存中(或在 Windows 2000中将Stress Properties页的Application Protection设为High [Isolated] )，就应当监测mtx.exe(在Windows 2000 里是dllhost进程)而不是Inetinfo进程。 如下图所示；Performance Monitor里每秒Active Server Pages请求数将显示程序的实际吞吐能力（在本例中是1.000 Requests/Sec），这一数据使得你能对高强度下Internet Information Server的性能进行分析，然后找到潜在的瓶颈的精确位置。反过来也使你可以判断程序在可接受的响应时间下，所能承受的最大用户数。 图三。性能监控器 使用ASP技术的Web服务器在启动时，从已经建立的大量线程中为每个页面请求都指定一个线程;如果所有的线程都已经被使用了，就将后续的页面请求排在队列中。在Performance Monitor中对总队列长度进行监视，可以确定有多少客户在等待服务器的响应。 最为常见的两个关系到数据库强度性能，与硬件无关的问题就是死锁和并行锁定。在数据服务器上使用数据存储器自带的Performance Monitor监视器时，至少应当对下列各指标进行监视。 锁定请求 每秒死锁数 每秒运算表格锁定的增加 用户连接 正在进行的处理 Web应用程序的设置同时也应该利用到OLE DB 资源合并的优点，这个应用程序由中间层OLE DB provider for Microsoft SQL Server 7.0自动进行管理的。先创建每一页面基础对象的连接，然后立即释放它们，通过这一方法，可以用很少的打开数据库的连接，处理成千上万个并行用户，这样就保护了数据库的资料，也提高了稳定性，这个增强的性能要用跟踪数据服务器上用户连接数的方法来进行监测（使用Performance Monitor）。当访问量增大时，用户连接数应该保持稳定，因为资源合并控制了在数据服务器上实际生成的连接数。 要达到预期的性能，依据数据库对程序进行调试的过程是非常关键的，所以必须作为开发周期的一个重要环节。这一过程包括对分配内存的大小，程序在各磁盘驱动器和控制器上分布，以及ActiveX组件的机器位置进行优化。只要有可能，就特别应该考虑消除进程之间数据的排队问题，因为这会占用非常大的运算量。 运行测试的时间，应是预期的实际用户环境中程序连续运行时间的一半以上。许多问题，尤其是内存不足，只有当程序运行了较长的一段时间后才会出现。 测试中应寻找的问题 Performance Monitor中每个指标的平均值是由程序与硬件的配置共同决定的。所以进行测试的时候，应当注意每一个指标是否偏离了平均值。 监测Internet Information Server 在寻找系统瓶颈时，Internet Information Server上最需要进行监测的是下面各项： CPU利用率 内存使用情况 吞吐能力 在测试过程中，根据设计的程序运行的不同环境，会想要跟踪其他的一些性能指标，这些都是可以选择的。程序出现下面任何一种的情况，都表明可能存在问题，需要在最终发布前予以修正。 CPU利用率 CPU使用的下降表明程序的性能有下降，这可能是由线程冲突问题引起的 在对CPU的用户使用时间与内核使用时间的比值进行监测时，请记住用户的使用时间应当占到CPU总使用时间80--90%这条规则。所以内核使用时间超过20%就意味着内核层的API调用指令有冲突。 为了让你对机器的投资有效地得到利用，应使CPU的利用率在负荷达到峰值时超过50%。如果低于这个值，表明在系统其他地方还有需要解决的瓶颈问题。 内存使用情况 长时间运行服务器程序后，内存使用出现突跃或缓慢增长也是常见的一个问题，这是正常的在测试阶段暴露出来的资源不足问题。 吞吐能力 监视Active Server Pages每秒请求数这个指标，能够诊断出程序是否或何时开始出现性能问题。实际环境中这个数值会出现正常的波动，但是小心地设定线程与并行连接的数量（如在Web Application Stress Tool进行设置）可以模拟出一个稳定的请求数。这个数值的突然降低也说明有问题存在。 选择性测试 下列是在测试过程中，其他一些值得进行监测的指标 总队列长度.   Performance Monitor中总队列长度都会上下波动，这是很典型的。所以如果CPU使用率很低，而总队列长度却始终没有增加，就表明这是一个运行很平稳的站点，它的能力比此负荷所要求的还高出不少。但是，如果总队列长队在上下波动，而CPU的使用率低于50%，那就表明有些请求被阻滞了，需要对程序进行更进一步的优化。 浏览器响应时间.    你可以定期的用浏览器访问Active Server Pages监测响应时间，保证测试正在正常地运行和Web站点仍然能正常地提供ASP页面服务。建议在整个强度测试过程中每天至少进行两次。 超时错误.     在浏览测试中要注意Internet Information Server返回的超时错误；这些错误可能说明有过多的用户在同时对程序进行访问。 监测数据服务器 数据服务器内部的各种MDAC服务和显示数据的格式化过程，通常都占据了绝大部分Web程序所使用的服务器资源。因此在对程序进行强度测试的时候，对这些组件的性能给予特别的关注是必要的，因为它与程序中数据访问和操作部分是联系在一起。 数据库的用户连接，锁定冲突与死锁是数据服务器上需要监测的主要几个候选参数。定期对数据库控制台中的进程信息进行检查（例如SQL Enterprise Manager中的Current Activity），查找受到阻滞的服务器进程ID，这是一个引起数据查询没有响应的常见原因。它是一个冲突问题，通常要对数据库设计或程序逻辑做很大的调整才能解决。 死锁问题可以用很多方法认定。最常用的是在Performance Monitor里通过Number of Deadlocks/sec的数值来认定。程序的死锁问题必须经过检查，而且要做到能够正常响应才行，因为如果由数据服务器来确定死锁的承受者（即为了解决死锁而被取消的用户或对话）将使程序有很大的毛病。在出现死锁时，程序应能自行能检测到，并做出相应的对策来解决问题，通用的方法是等待几毫秒后再次进行操作，一般来说，死锁都是对时间敏感的错误，重试就能够消除问题。 评估强度测试结果 强度测试结束后，对目标值与测试中获取的数据进行比较，可以找到为了满足用户的需要而应当做的一些修正。下列是为性能修正而要检查与评估的各个项目， 硬件 数据库的设计 ActiveX组件 客户端游标 ASP的执行 IIS负荷 硬件 硬件升级大概是提高程序能力的一个最简单最低廉的解决方案。硬件升级比聘用一组开发员对程序进行重写要经济的多，比如只要增加内存就可以很方便地将程序的吞吐能力提高一倍。但是如果测试结果表明CPU使用是系统的瓶颈，那么升级的费用会相当昂贵，因为几乎整台机器都要升级，才能达到CPU数量和速度增加。 其它一些与硬件升级包括提高硬盘和控制器的速度，以及加上更快或额外的网卡。 数据库设计 如果评估出的结果与数据库的设计有关，则先寻找热点。分析死锁的数据，确认程序已经做了最大程度的优化避免死锁。必要时要考虑改变数据访问逻辑来解决冲突。试验不同的索引方法。检查数据服务器的查询执行方案，确认查询使用了正确的索引，等等。 ActiveX组件 优化引用了ActiveX Data Objects类型库的ActiveX组件必须小心地进行分析。不要使用ADO的默认属性。始终都指定属性以防止偶然情况的发生，例如Cursor Type和 Cursor Location 属性。 客户游标 如果Web应用程序占用了异常大量的内存，这个问题可能是由游标位置的不正确造成的。当使用客户游标时(recordset.cursorlocation = adUseClient)，先了解客户端确实是Internet Information Server而不是浏览器。（这种情况的特例是Remote Data Services，不在本文讨论范围）。开发员常犯的错误是假定客户游标在浏览器而不是IIS的整个数据组中移动。因此，牢记数据组实际上是存储在运行IIS的机器上将让你有意识地注意对资源的合理利用。 比如，程序要存取一张有效的州或国家代码，而这些信息都存储在数据服务器上，利用客户游标生成一个数据组并驻留在IIS上，然后在当地访问这些代码的效率会更高，这样可以避免程序对这些信息访问时，数据服务器上额外的信息往返。 ASP的执行 如果有数据存取过程的ASP页面需要很长时间来运行，就有必要将这些数据存取的代码转移到ActiveX组件中去，更可行的办法是放在Microsoft Transaction Server (Windows NT) 或 Component Services (Windows 2000)所带的软件包里，这取决于你使用的系统。这些编译过的代码的运行效率要比Active Server Pages所包含的解释脚本的代码快很多。 Internet Information Server负荷 监测使用Internet Information Server的程序数量与类型。你可能需要增加更多的服务器，将程序转移到另一台服务器上运行或执行Windows Load Balancing Service 成功执行强度测试的技巧 应当 将所有的商用逻辑放在ActiveX组件里，用ASP页面将它们联系起来，把可以再使用的代码封装到库内。 使用MTS(Windows NT 用户)。这是一个强大的为服务器端COM对象提供额外线程和资源合并，并轻松对这些对象进行管理的工具。另外MTS还提供了事件处理能力。 使用资源/连接合并。MDAC的这一特性是默认的，但是应当对其进行监测以保证运行正常。 调试数据存储。在合适的位置调用存储程序。 用输入、输出和数据转换的缓存来最小化数据访问的操作量。 只要有机会就使用进程内程序和ActiveX组件 确保实际工作时是不允许进行调试的。调试程序会强制转移线程。 在intranet环境里，如果可能的话可以将一些工作量转移到客户浏览器上。 升级到Windows 2000。对程序进行强度测试时，新发布的Windows 2000性能与可伸缩性的增强立刻就能感觉出来。 如果你一时之间无法升级到Windows 2000，至少升级到Microsoft Visual Basic® Scripting Edition (VBScript) 5.0也是一个不错的办法，新版本的性能与功能也得到了明显的增加。 考虑使用Microsoft Message Queue Server (MSMQ)。合理地使用异步信息传递可以显著增大能处理用户响应的次数。 不要: 在Active Server Pages内使用程序或对话层对象 在Active Server Pages放置数据访问代码。用脚本代码来和ActiveX组件内的数据访问函数与商用逻辑进行通信。 在不是绝对必须的时候使用HTTPS/Secure Sockets Layer。这一认证协议执行时的代价是非常昂贵的。 不必要的使用程序或对话状态。 总结 Internet使你的程序比传统的客户-服务器方式程序有更多的潜在用户。越来越多的组织意识到网络是他们商业战略的一个重要组成部分，所以他们选择的技术要能够应付巨大的需求。这些组织不光要有易于使用的工具，还要有能满足他们用户负荷的基础设施。因此较之以往，强度测试更应该成为一个很重要的步骤，尤其是当你在程序中包含了MDAC的时候。 注意  在开发环节中用最优法，是使系统在高强度下成功运行的一个基本要求。这就是说，在开发过程中，有负荷下的性能测试和为达到性能要求而进行的调试都要排进日程表。 进行强度测试和在有负荷下对程序反复调试的好处是显而易见的； 可以获得所需的确保程序有足够吞吐能力的信息。 可以精确了解程序的可伸缩性信息，从而调试程序达到所需的性能要求。 可以在实际推广前，及早发现降低性能的吞吐能力的设计问题并做出修正。 由于程序的高性能，可以在用户和商业伙伴中赢得良好的声誉。 Send feedback on this article.  Find support options.