快速瓶颈识别—更好的负载

《快速瓶颈识别—更好的负载》由会员分享，可在线阅读，更多相关《快速瓶颈识别—更好的负载（12页珍藏版）》请在金锄头文库上搜索。

1、快速瓶颈识别 更好的负载 测试方法 Oracle 白皮书 2008 年 6 月 快速瓶颈识别 更好的负载测试方法 第 2 页 快速瓶颈识别 更好的负载 测试方法 . RBI 兼具对瓶颈的全面了解以及精细的负载测试方法，使企业能够创建高度可扩展的兼具对瓶颈的全面了解以及精细的负载测试方法，使企业能够创建高度可扩展的 Web 应用程序。应用程序。 引言引言 您准备启动关键的 Web 应用程序。确保良好的应用程序性能至关重要，但时间短暂。如何能够以最佳方式测试应用程序，同时还要满足最后期限？ 快速瓶颈识别 (RBI) 是一种新的测试方法，可允许质量保证 (QA) 专业人员非常快速地发现 Web 应用

2、程序性能限制，并确定这些限制对最终用户体验的影响。RBI 方法的开发历经数年涵盖所有类型平台的测试，可显著缩短负载测试周期，同时允许进行更加彻底的测试。使用此方法，企业可以提升应用程序质量、增强客户体验以及降低部署新系统的成本。 定义的性能测试定义的性能测试 性能测试可以粗略定义为“为评估系统或组件是否符合指定性能要求而进行的测试”。但是，每个应用程序都至少有一个瓶颈，因此很少有系统在任何时候都能达到初始的性能要求。为了反映这一现实，让我们将性能测试重新定义为“为隔离和识别阻止应用程序扩展导致无法满足其性能要求的系统和应用程序问题（瓶颈）而进行的测试”。 这种观点上的哲学转变，即从作为评估的测

3、试到作为主动研究以隔离和解决问题的测试，是创建 RBI 方法的驱动力。RBI 兼具对瓶颈的全面了解以及精细的测试方法，使企业能够创建高度可扩展的 Web 应用程序。 了解瓶颈、吞吐量和并发性了解瓶颈、吞吐量和并发性 在深入研究 RBI 方法的细节之前，我们必须首先大致了解一下瓶颈以及发现瓶颈的位置，并对吞吐量和并发性测试加以区分。 瓶颈瓶颈 主要的性能障碍主要的性能障碍 任何对数据流或处理速度予以定义限制的系统资源（如硬件、软件或带宽）都会产生瓶颈。在 Web 应用程序中，瓶颈可限制数据吞吐量或限制应用程序连接数，从而直接影响性能和可扩展性。这些问题在系统体系结构的所有级别出现，包括网络层、W

4、eb 服务器、应用服务器以及数据库服务器。根据我们对实际客户应用程序的测试经验，瓶颈跨这些组件分布，如图 1 中所示。 在在 Web 应用程序中，瓶颈可限制数据应用程序中，瓶颈可限制数据 吞吐量或限制应用程序连接数，吞吐量或限制应用程序连接数， 从而直接影响性能和可扩展性。从而直接影响性能和可扩展性。 图图 1. 瓶颈在系统基础架构中的分布估计。瓶颈在系统基础架构中的分布估计。 测试复杂性的复合影响测试复杂性的复合影响 您所选择的测试方法直接影响隔离和解决瓶颈的难度。遗憾的是，过多的测试过程都从复杂的使用情形开始，测试人员试图完全模拟如何在生产环境中使用应用程序。这可能涉及运行几个不同的事务，

5、以模拟以不同方式与应用程序交互的不同类型的用户。遗憾的是，这会产生明显的测试障碍，因为复杂性较高并且涉及多个不同事务的情形会在测试中引起更多的瓶颈，从而难以确定根本原因。 例如，图 2 中的图形显示了标准电子商务应用程序的测试结果，在大约 2,000 个并发用户时出现瓶颈。在此示例测试中，使用情形涉及浏览、搜索项目以及将其添加到购物车中以完成采购。虽然只有三个事务被测试， 快速瓶颈识别 更好的负载测试方法 第 3 页 但是每个事务都与应用程序体系结构的所有级别交互，并且其中任何一个级别都可能导致瓶颈。对于更复杂的情况，瓶颈还可能由系统问题导致。最后，测试中涉及的变量越多，确定问题原因的难度就越

6、大。 图图 2. 电子商务应用程序测试的图形化结果。电子商务应用程序测试的图形化结果。 如果问题可能出现在体系结构的任何层中，并且出现在任一层中的可能性实际并不大于出现在任何其他层中的可能性，那么您还可以到哪里寻求指导呢？ 所有系统和应用程序性能问题大多由吞吐量限制所引起。所有系统和应用程序性能问题大多由吞吐量限制所引起。 两个主要问题：吞吐量和并发性两个主要问题：吞吐量和并发性 吞吐量是指系统可以支持的数据流数量，衡量单位为每秒点击数、每秒页数以及每秒数据兆位数。并发性是指同时连接并使用一个应用程序的独立用户数。根据我们的经验，所有系统和应用程序性能问题大多由吞吐量限制所引起。但是，并发性问

7、题对应用程序性能也是至关重要的，甚至可能更难以隔离。 吞吐量测试吞吐量测试 吞吐量测试涉及最小化到系统的用户连接数以及最大化这些用户执行的工作量。这迫使系统和应用程序满负荷运行以发现所有问题。 对于系统级别的吞吐量测试，可以将基本文件添加到 Web 服务器和应用服务器中以进行测试。然后，可以设置负载测试以请求这些测试文件，评估每层的最大系统吞吐量。通常，测试人员使用大的图像文件进行带宽测试，使用小的文本文件或图像进行点击率测试， 快速瓶颈识别 更好的负载测试方法 第 4 页 而使用非常简单的应用程序页面（例如“Hello World”页面）进行页面速率测试。如果系统并未满足基本的应用程序性能要

8、求 仅请求这些简单的测试页面，则测试应该停止，直到系统本身通过调整设置、增加硬件容量或增加允许的带宽而得到改进。 然而，实际应用程序的吞吐量测试涉及在应用程序本身中点击关键页面和用户事务（请求之间具有有限的延迟），以找出各种功能组件的每秒页面容量限制。显然，页面吞吐量最差的页面或事务需要进行最大程度的调整。 并发性测试并发性测试 在系统和应用程序级别，会话和套接字连接可限制并发性。代码缺陷和不正确的服务器配置设置也会限制并发性。并发性测试涉及在系统上增加多个用户，并使用实际页面延迟时间以足够慢的增加速度收集各级别负载测试过程中的有用数据。与吞吐量测试一样，测试被测试应用程序中的关键页面和用户事

9、务至关重要。 快速瓶颈识别 更好的负载测试方法 第 5 页 使用场景使用场景 吞吐量吞吐量 并发并发 Bottleneck Point 100 Users 1 Second/Page Pages/Second = (100VU x 1 Page/VU) 1 Second = 100 100 连接 50 Pages/Second1,000 Users 10 Seconds/PagePages/Second = (1000VU x 1 Page/VU) 10 Seconds = 100 1,000 连接 25 Pages/Second虽然大多数瓶颈在吞吐量测试中发现，但是为了正确地测试应用程序，您

10、必须对吞吐量和并发性都进行测试。虽然大多数瓶颈在吞吐量测试中发现，但是为了正确地测试应用程序，您必须对吞吐量和并发性都进行测试。 吞吐量和并发性测试之间的区别吞吐量和并发性测试之间的区别 包含 100 个虚拟用户的负载测试（判断时间为 1 秒）生成的负载与包含 1,000 个虚拟用户的负载测试（判断时间为 10 秒）生成的负载不等同。如图 3 所示，这两个测试的吞吐量完全相同，但并发性截然不同。 图图 3. 包含包含 100 个虚拟用户的负载测试与包含个虚拟用户的负载测试与包含 1,000 个虚拟用户的负载测试。个虚拟用户的负载测试。 在第一种情形（吞吐量测试）中，应用程序在每秒 50 页时出

11、现瓶颈。但是，在第二种情形（相同事务的并发性测试）中，应用程序在每秒 25 页时出现瓶颈。这两个测试之间的唯一区别是系统上的用户数以及这些用户在页面上停留的时间长度。在用户较少并且页面查看延迟较短的吞吐量测试中，应用程序具有更大的吞吐量；第二个测试显示了应用程序的并发性受限。如果测试人员仅检查吞吐量，则在将应用程序用于生产环境之前不会发现并发性问题。 以下页面上的图 4 和图 5 显示了每个测试的结果，并突出了对吞吐量和并发性都进行测试的重要性。 这两个测试之间的唯一区别是系统上的这两个测试之间的唯一区别是系统上的 用户数以及这些用户在页面上停留的用户数以及这些用户在页面上停留的 时间长度。时

12、间长度。 图图 4. 100 个用户的吞吐量测试（页面查看时间为个用户的吞吐量测试（页面查看时间为 1 秒）在每秒秒）在每秒 50 页时显示瓶颈。页时显示瓶颈。 图图 5. 1,000 个用户的并发性测试（页面查看时间为个用户的并发性测试（页面查看时间为 10 秒）在每秒秒）在每秒 25 页时显示瓶颈。页时显示瓶颈。 快速瓶颈识别 更好的负载测试方法 第 6 页 快速瓶颈识别 更好的负载测试方法 第 7 页 RBI 测试方法测试方法 过去，性能测试人员着重将并发用户数作为应用程序可扩展性的关键量度。但是，如果在吞吐量测试中发现大量应用程序和系统级问题，则需要一种新的方法。 以下三个原则构成了

13、RBI 方法的基础。 ? 所有 Web 应用程序都具有瓶颈。 ? 每次只能发现其中一个瓶颈。 ? 应该将重点放在哪里最可能出现瓶颈。 虽然认识到并发性测试的重要性，但是 RBI 方法首先着重于吞吐量测试以发现最常见的瓶颈，然后进行并发性测试以在反映应用程序预期实际用户数的负载条件下评估性能。RBI 测试也从简单的测试开始，然后增加复杂性，这样当出现问题时，所有其他可能的原因均被排除。着重于吞吐量测试，然后进行并发性测试，并使用结构化流程测试方法，这样可确保快速隔离瓶颈，从而提高效率并降低成本。 RBI 测试的优势测试的优势 通过 RBI 方法，可以进行快速而彻底的测试从而系统地发现所有系统和应

14、用程序问题 简单问题和复杂问题均可发现。 通过使用分层方法发现瓶颈，您可以快速识别并隔离了解有限的组件中的问题。通过使用分层方法发现瓶颈，您可以快速识别并隔离了解有限的组件中的问题。 缩短测试时间缩短测试时间 如果最初着重于吞吐量测试，您可以节省多少时间呢？举例来说，系统预期处理 5,000 个并发用户，并且用户在每个页面上平均花费 45 秒的时间。如果应用程序具有一个将其可扩展性限制为每秒 25 页的瓶颈，则并发性测试将在大约 1,125 个用户（每秒 25 页，每页 45 秒）时发现此瓶颈。 为了不使数据出现偏差，应该缓慢加速典型的并发性测试。例如，您可以考虑每五秒增加一个用户。在此示例中

15、，测试进行 5,625 秒或 94 分钟（1,125 个用户，每个用户 5 秒）时出现瓶颈。但是，为了验证瓶颈，测试必须继续到此点以后以证明吞吐量没有随用户的增加而增大。吞吐量测试可能已在不到 60 秒内发现此问题。 快速瓶颈识别 更好的负载测试方法 第 8 页 消除初始测试复杂性消除初始测试复杂性 性能通常测试从过于复杂的情形开始，同时运行过多的组件，从而容易隐藏瓶颈。RBI 方法从系统级测试开始，该测试甚至可以在部署应用程序之前执行。 提高提高 QA 效率效率 RBI 方法首先测试最简单的测试案例，然后进行复杂性增加的测试案例。如果最简单的测试案例运行正常，而当复杂性增加时失败，则瓶颈在于

16、新增加的复杂性。通过使用分层方法发现瓶颈，您可以快速识别并隔离了解有限的组件中的问题。 通过知识聚合提高测试效率通过知识聚合提高测试效率 此方法的模块化和迭代特性意味着出现瓶颈时，所有先前测试的组件均已被排除。例如，如果点击主页显示没有瓶颈，但点击主页并执行搜索显示非常差的性能，则瓶颈的原因在于搜索功能。 常见系统瓶颈的常见系统瓶颈的 RBI 测试测试 任何性能测试都应该首先评估支持应用程序的基本网络基础架构。如果此基本系统无法支持系统上的预期用户负载，则即使无限可扩展的应用程序代码也会出现瓶颈。应该运行基本的系统级测试以验证带宽、点击率和连接数。此外，应该运行简单的测试应用程序页面，例如简单的“hello world”页面。 应用程序应用程序 验证系统基础架构满足最终用户的最基本需求之后，验证应用程序本身。再次从可能的最简单测试情形开始。 如果测试进行到此尚未发现系统级问题（或这些问题已得到解决），则所有的其余问题均由应用程序本身导致。例如，如果测试应用程序页面达到每秒