JMeter - 利用 Ultimate Thread Group 的 Threads Schedule 配置压测场景计划

性能测试最关键的一个方面是可以模拟应用程序的实际负载。可是，肯定目标负载的并发用户数是不够的。在测试阶段使用的相同目标负载下，通过测试的应用程序可能会失败。或者当问题是系统中的瓶颈时，应用程序可能会在测试负载下失败。发生这些事情是由于除了目标负载以外，开发人员和性能测试人员还应该关心在测试执行期间如何分配负载也就是模拟各类负载压力场景。

JMeter的Ramping-Up

虽然有不少JMeter的参数负责负载分配（好比Number of threads'线程数'，Loop Count'循环次数'或Duration'持续时间'），但其中一个参数可能不是那么容易理解，而且它的适当值参数可能并不老是很明显。 此参数称为ramp-up斜坡上升。

Ramp-up是JMeter将全部users (threads)"测试用户（线程)"添加到测试执行所需的时间。 或者换句话说， JMeter开始执行全部线程须要多长时间。

例如：

• 1000个目标线程，加速1000秒：JMeter将每秒添加一个用户
• 1000个目标线程，持续100秒：JMeter每秒将增长10个用户
• 1000个目标线程，50秒加速：JMeter每秒将增长20个用户

在本文中，咱们将重点介绍如何应用JMeter的Rame-up斜坡上升来模拟咱们应用程序的不一样负载状况也就是相似Loadrunner中的压测场景配置。

配置JMeter压测场景

咱们将测试某一web网站。 咱们将应用具备相同目标线程值的各类负载，但具备不一样的上升周期组合。

1.建立一个具备目标线程数的线程组（假设为100）。
右键单击 - >添加 - >线程 - >线程组
将线程数的值更改成100.如今让咱们假设您要运行咱们的测试5分钟。 所以，您须要在Duration“持续时间”字段中指定值300。 如今，让咱们将线程组中的“Ramp-Up Period”字段保持为空。

 

2.添加一个访问Web主页的HTTP Request Sampler "Http请求采样器"。 
右键单击Thread Group - > Add-> Sampler - > HTTP Request
我将其名称更改成“BlazeDemo home page”。 添加“blazedemo.com”做为服务器名称，并确保将该方法设置为GET。

 

3.查看包含用户分布的图表。 
这样的图表能够帮助咱们可视化负载模式并检查咱们要测试的内容。 JMeter不提供开箱即用的这些选项，但您能够轻松安装“自定义插件包”，其中包含许多有用的侦听器（可经过Jmeter-GraphsGeneratorListener此连接找到安装说明）。 其中一个插件被称为"Active Threads Over Time"。 添加该侦听器：
添加 - >监听器 - > jp@gc - Active Threads Over Time

 

请记住 ，若是您有大量目标线程，则加速期不该为0。 Ramp-up 0意味着性能脚本将在测试执行开始时当即添加全部线程，所以它会当即给您的应用程序带来很是严重的负载。

固然，有时您可能但愿模拟此类负载，例如在Spike performane test "峰值测试"期间，但这是一个单独的案例，具备单独的最佳实践方法（在下面介绍）。 但即便使用峰值测试，咱们一般也不但愿全部用户都在测试的第一秒当即执行。

 

这种状况看起来并不符合实际状况，一般这种负载加压没有任何意义。 若是您有一个Web应用程序，用户一般会或多或少地逐渐访问您的站点，而且您的服务器有足够的时间进行适当的调整和扩展。

加速分配应根据您的需求而定。 所以，首先须要作的是了解您的测试目标。 最好的方法是从生产环境中学习并找出当前网站的负载模式。 但与此同时，在许多状况下，它足以建立一个线性加速，显示用户逐渐进入您的网站或应用程序。

建立线性负载加速

1.返回线程组并将Ramp-Up周期更改成120。

由于测试持续时间是300秒，因此在2分钟内加速，咱们有3分钟的保持时间。 重要的是，在加速结束而且全部用户都启动并运行以后，有足够的保持时间。 保持时间确认系统能够处理负载而且性能保持稳定且不会恶化。

在这个测试中，咱们肯定了3分钟的保持时间，但在您的状况下，全部这些值都将基于您的特定需求和您要模拟的场景。

 

2.运行测试，查看活动用户数量如何逐渐增加2分钟。

 

这种负载称为Linear“线性”。 这种方法适用于主要关注目标负载的许多用户。 可是,这种方法不是最佳实践。 为何？ 由于若是服务器在线性加速期间在某个负载下表现不佳，一般很难隔离并肯定哪一个负载。 咱们不清楚咱们的服务器能够处理哪些负载以及哪些负载不能处理。

这就是为何按步骤执行加载要好得多。 因此让咱们将测试持续时间分红几个阶段。

建立步进负载加速

咱们仍然想测试100个用户，但咱们会逐步逐步提高他们。 咱们将从25个持有一段时间负载的用户开始，看看服务器如何处理它。 以后咱们将增长25个到50个，另外25个到75个，最后25个到100个用户。 这种方法效果更好，更可靠。

不幸的是，JMeter不支持开箱即用的步进加载步骤。 可是您能够轻松安装名为Ultimate Thread Group终极线程组的相应插件。 此插件为您提供了很是强大的控制线程组加压负载能力和灵活性，能够为您的测试应用程序模拟各类负载场景。

1. Ultimate Thead Group 相似于默认的'Thread Group'JMeter元素，能够经过如下方式找到：

右键单击左侧的元素选项卡 - >添加 - >线程（用户） - >jp@gc - Ultimate Thread Group

 

2.在建立'Ultimate Thread Group'元素以后，咱们能够从最初的'Thread Group'复制咱们的'BlazeDemo home page'请求采样器和'Active Threads Over Time'监听器。

 

3.Ultimate Thread Group提供了一个'Threads Schedule' 线程计划表，您能够在其中配置不一样的线程组。 您能够决定线程数量（'Start Threads Count'），每组开始添加到测试执行以前的延迟（'Initial Delay，sec'），线程组的加速期（'Startup Time'） ，sec'），在减速前线程组的持续时间（'Hold Load For，sec'）以及指定全部线程组应该关闭的速度（'Shutdown Time'）。 全部线程组同时启动，但每一个线程组都有本身的Intial Delay“初始延迟”值，这有助于分别从每一个组中分离用户。

Ultimate Thread Group“终极线程组”插件的另外一个重要功能是，您能够在下图中看到预期的负载分布，并根据您的须要调整分配值，甚至在运行脚本以前而且没有考虑到棘手的计算。

让咱们将测试分为4个步骤，每分钟增长25个用户。 在这种状况下，咱们的'Threads Schedule' 线程计划表将以下所示。

 

Spike Testing峰值测试

这种负载灵活性可能有用的另外一个很好的例子是峰值测试。 基本上，峰值测试是一种性能测试，其中应用程序在乎外的增量和负载减小下进行测试，以查看它在这种状况下的行为以及是否可以处理这种峰值。 让咱们调整咱们的'Threads Schedule'来模拟某种峰值测试。 要模拟该模式，咱们须要使用Shutdown Time“关闭时间”列来负责线程减速。

 

总结

这样利用Ultimate Thread Group的Threads Schedule配置压测场景计划,就能够作到和Loadrunner 同样的负载加压策略了

跟你们推荐一个学习资料分享群：747981058，里面大牛已经为咱们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！人生是一个逆水行舟的过程，不进则退，我们一块儿加油吧！