标题: 发布 Web 应用程序时避免瓶颈的实际负载测试技巧 [打印本页] 作者: 阿七 时间: 2008-8-31 00:41 标题: 发布 Web 应用程序时避免瓶颈的实际负载测试技巧 发布 Web 应用程序时避免瓶颈的实际负载测试技巧
摘要 负载测试应该是每项 Web 开发工作的一部分,并且应在开发过程的早期进行。然而,如果您认为可以利用开发环境进行负载测试,那么当您发布应用程序时多少会感到惊讶。在本文中,作者将对规划负载测试工作、考虑使用哪些计算机、模拟用户的数量、适用的工具以及如何解释结果这一过程进行概述。
让我们设想以下场景。您即将结束为期 6 个月的对某项复杂的 Internet 应用程序或 Web 服务的开发工作,并且已准备对其进行部署。开发团队小心翼翼地就松散耦合的 n 层 Web 应用程序进行了设计。从工作的第一天开始,所有可伸缩、稳定的和高性能的应用程序所必需的要素就已悉数构建到系统的体系结构之中。质量保证团队已对系统进行了彻底地测试、解决掉了大部分的严重错误并仔细考虑了那些待发现的剩余错误。因此,您的开发工作应该进行得相当顺利,对吗?请再想一下。
您已将负载测试作为开发工作的一部分进行实施了吗?如果没有,那么您应接受这样的事实:即,在复杂的设计当中,您将需要就某些地方的性能、可伸缩性和可靠性方面予以关注。瓶颈是系统中阻碍正常通信量流量的元素。尽管良好的设计对于构建成功的 Web 应用程序而言至关重要,但是经验告诉我们,大部分这些种类的错误只能在系统处于较大负载的情况下才会被发现。这些是您作为单个用户在开发过程期间,通过测试系统无法发现的问题。尽早地实施负载测试计划有助于确保将在开发时出现的意外情况降至最低限度。
在本文中,我们将介绍基于实际经验的测试方法,但这并非抛开传统的负载测试策略。由于带领过众多的负载测试团队,我们汲取了一些教训,它们可能会对您有所帮助。
我们将讨论较早开始测试工作的优点,并概述设置测试环境的注意事项。我们将帮助您确定适于自己的实现的度量标准,并介绍一些实施这些度量标准的工具。此外,我们将向您说明,为什么“我的站点能同时处理 x 名用户吗?”这样的问题太过含糊而无法精确回答。最后,我们将讨论一些针对您的特定需要选择适当的负载测试工具的重要注意事项,并对跟踪测试结果提出一些建议。
我们将使用术语“负载测试”来描述性能、可伸缩性和可靠性测试。人们往往过于频繁地使用术语“可伸缩性测试”来描述上述这三项,而您的团队所做的很可能不仅限于此。图 1 描述了这些目标。
尽早开始
您应在设计阶段就开始规划负载测试工作。根据我们的经验,建议您采取“无惊讶”方法来进行开发工作。工作时始终抱着会发现问题的想法。分布式 Web 应用程序和 Web 服务的体系结构日趋复杂,使得潜在问题成为应用程序设计中的固有现象。
最近,我们在复杂的 n 层 Web 体系结构的开发阶段中,进行的负载测试效果不错。但我们对其中的两个问题估计不足。第一,我们低估了测试开始后将会发现的问题数量。我们的第一次测试运行在只处理了 2 名用户和 100 份定单后就告失败了。第二,我们低估了设置测试环境所需要的时间。幸运的是,由于我们开始规划测试足够早,从而有时间解决在部署日期之前发现的问题,或将问题降到最少。通过密切关注设计,成功地解决最初的几个问题后,系统的可伸缩性很快就得到了提高。
通过定义测试环境,您就可以开始规划测试工作。根据测试工作的规模,这可能是很重要的任务。
返回页首
定义环境
在定义测试环境的过程中,第一个任务就是估计需要何种工作。我们用于资源成本的一条通用指南是,将实现时间的 15% 至 20% 用于测试,其中的大约三分之一用于负载测试。
重要的是创建单独的测试环境,该环境应与生产环境类似。如果计算机的配置、速度和设置均不相同,那么要推断出生产环境中的性能几乎是不可能。换言之,对于诸如“向系统添加更多硬件是否能提高可伸缩性”这样的问题,您能给出确定回答,但是对于“在生产环境中一台 Web 服务器能处理多少用户?”之类的问题,您却无法准确回答。您的主要任务之一就是降低不确定性,并通过结论性的证据来回答问题。如果没有类似的硬件,在迫不得已的情况下,您充其量也只能根据经验进行猜测。
面对将生产用计算机用于负载测试环境的成本,您可能会畏缩不前。但请您考虑考虑在生产环境中查找与硬件相关的问题所需的成本,以及精确预测单台 Web 服务器能处理的负载的价值。诸如处理器速度和可用的 RAM 之类的变量会影响可用系统资源,并随之可能更改可伸缩性问题表明它们自身的方式。在实验室中,环境变量是不可抗拒的因素。该种变量数量太多,而您无法确定问题的根源。如果不可能使用单独的环境,那么请考虑加速生产硬件购买以用于负载测试实验室中。一旦部署了系统,实验室设备就还可以用作生产设备的备用品。另一个好处是,用不着等到发布之日前,您就能消除系统缺陷。
关于为何您不应使用开发环境进行测试,有几点原因。有关详细信息,请参阅提要栏“Don't Use Your Dev Environment for Load Testing”。对于质量保证团队所使用的系统测试环境,情况亦是如此。这适用于想要跟踪似乎与系统负载无关的功能错误的单个用户测试。这种测试对系统测试环境中使用的硬件类型放宽了限制。它从开发团队接收的软件更新也更频繁。在负载测试中,应只安装影响系统性能的版本,以将修改负载脚本的耗时缩至最短。
除了可伸缩性实验室运转所必需的资源以外,负载测试工作是否能成功还取决于组织中的其他角色。图 2 角色摘要。
实验室以外最重要的角色是具有很大权限的数据库管理员 (DBA),这个事实无需我们过分强调。可伸缩性问题最可能的根源就在于数据库、数据访问策略(例如,存储过程、预处理语句或内联 SQL)或数据访问技术(例如,ADO、ODBC 等等)。DBA 能够帮助识别和解决与数据库相关的问题,例如建立索引成本过高、过度锁定以及事务超时。理想情况是,您应有一位专门的称职的 DBA 来作为负载测试工作中关键点的全职资源。
我们还建议您让开发团队中的成员轮流负责测试实验室,以便每名团队成员都能参与到这项测试工作中。如果这样做,您将取得极佳的交叉培训的效果,并持续地向实验室提供最新的理念。
返回页首
定义测试策略
下一步是清楚地定义度量标准。度量标准的例子包括:每分钟处理的定单数,或者执行对 ASP 页面的请求所需要的毫秒数。度量标准允许您量化每次测试运行之间进行更改的结果。它们提供了与为您的 Web 应用程序定义的标准之间的一种比较。
为了确定需要跟踪的度量标准,需要采取一系列步骤。您需要定义待回答的问题,为每个问题定义质量条,然后确定将测试结果与质量条进行比较所必需的度量标准。
第一步很直接。例如,您可能想要了解签出响应时间。请记住列出那些与测试策略相关的问题,而避免组织您无法测试的模糊问题。
下一步是为每个问题定义质量条。让我们以典型的定单提交流程为例。我们可能决定站点在峰值负载期间每分钟必须处理 10 份定单,一名用户等到请求执行的时间不应超过 30 秒。为了建立这样一个标准,您可能会注意许多不同的源。首先咨询业界人士,了解系统性能的可接受级别。将历史数据带到这些会议上将有助于讨论,并常常可用来管理预期情况。如果在生产环境中已存在某个版本,则可以从当前站点活动和增加的通信量的短期投影收集数据,或通过查询现有数据库的活动趋势来收集数据。
有了一份问题列表和每个问题的质量标准后,您现在就需要确定使用哪个度量标准。根据上一个例子,每分钟定单数和给定测试中的定单数将是良好的高级度量标准,这些标准可作为站点是否满足质量条要求的指示器。当您想要在测试过程中更新这些度量标准时,应报告给管理层。
较低级的度量标准衡量性能并帮助您解决系统瓶颈和稳定性问题,或将这类瓶颈和问题减到最少。增加性能也许会对高级度量标准产生直接影响。例如,减少特定活动的事务时间可能导致每分钟定单数的增加。
大多数测试工具允许您在个别页上或一组页上设置定时器,并提供运行测试用例的平均时间。两种度量标准均允许您将高级度量标准用于一次又一次测试运行,但它们均不能帮助您深入了解到底是什么需要改进。
对此 Windows 性能计数器很有用。例如,您可以监视 dllhost 进程的 Processrivate Bytes,以检测服务器软件包中的内存泄漏。有关各个Microsoft Internet 信息服务 (IIS) 计数器的适合且详细的描述,可从 The Art and Science of Web Server Tuning with Internet Information Services 5.0 获取,而图 3 描述了用于负载测试的主要计数器以及要注意的趋势。
但是,性能计数器只在识别问题症状时有用,对识别问题原因无用。如果您的系统在 20 名并发用户时中断,则 Active Server Pages:Requests Timed Out 计数器可以真正确认,至少一名用户已超时,但要确定超时的原因却如同大海捞针。这是因为性能计数器数据主要提供操作系统和网络级别的信息。要成功找到问题的原因,需要访问应用层的数据。此任务的关键是,构建分布式日志记录系统,以检索并集中存储来自应用程序中的错误和性能数据。这允许您立刻了解系统是否正在工作。如果系统没有工作,则您就拥有了找到问题领域所必需的信息。
返回页首
解释度量标准
配置完所有这些度量标准之后,现在您就可以访问大量数据。因此,您将如何以有效率的方式来理解数据?我们将针对解释性能计数器数据讨论三个选项:性能监视器、Perfcol 以及与负载测试工具集成的性能数据。
Windows 2000 中的性能监视器允许您以图形的方式显示各个计数器的进度。一个有用的功能是能够在日志文件中捕获读数,从而允许您在测试运行一完成就以可视的方式检查整个测试运行。图 4 说明了在线订购应用程序上的站点活动如何能在性能监视器中得到解释。
沿着与性能监视器同一条线,Windows DNA Performance Kit Beta 包含一个称为 Perfcol 的工具。此工具的用途与性能监视器类似,不同之处在于该工具将取样数据存储在数据库中,而不是写入文件。
一些负载测试工具,例如 Microsoft Application Center Test (ACT) 和来自 Empirix 的 e-TEST 套件,均包含内置的性能计数器功能,它们能在测试的运行持续期间记录度量值。然后计数器数据会写入数据库以供以后访问。ACT 包含在 Visual Studio .NET 中,它集成了性能监视器计数器,允许所有数据均存储在单个资源库中。
不管负载测试工具是否集成某种形式的性能计数器监视,您也许均会发现仍需要诸如性能监视器之类的工具的支持,尤其是如果产生负载的服务器没有适当的安全访问权来监视应用程序服务器时,这种情况在环境包含防火墙时会频繁发生。
无论选择何种监视工具,关键在于存储每次测试运行的度量标准以供将来评估。转回到过去的数据对于理解系统如何响应所作的更改很关键。
对于日志记录系统生成的应用级数据,我们建议构建一个查看器,该查看器使您能够立即访问一个位置内的错误和性能信息。考虑到它所代替的操作是每次要求反馈时在命令行生成 SQL 查询,因此这项工作还是值得的。
返回页首
选择适当的负载测试工具