JMeter高并发负载测试

并发通常用于定义负载测试的工作负载，例如并发用户。通常，它是唯一定义的输入。实际上，有许多因素会增加工作量并影响并发性。星辉小编将在本文中探讨其中的一些。

如何计算目标并发用户

一种常见的方法是将唯一用户数除以给定时间段的平均访问持续时间。

例如，每小时 12,000 个唯一身份访问者/(每次访问 60 分钟/15 分钟)将等于 3,000 个并发用户。

这种方法的问题包括：

假设访问者均匀分布在采样的 1 小时内。访问者更有可能遵循某种形式的泊松过程。

唯一身份访问者的数量可能计算错误。根据用于对唯一性进行抽样的方法，这通常会产生误导，尤其是在使用源 IP 之类的东西时，这些东西通常可以由真实用户共享或代理。

并发有助于但不定义整体工作负载。这些用户实际上在做什么?空闲还是忙碌?更多的计算方法可能是分析或跟踪不同时期的真实用户，或者使用除上述平均值之外的描述性统计数据来显示频率分布或箱线图，以便您可以更好地模拟并发使用。

获得正确的并发性很重要，因为最终，工作负载很可能由某种形式的排队系统处理，并且并发性会影响这些队列的到达时间。

在现实生活中的计算机系统中，分布很少是均匀的，因此最好在被测系统中尝试观察、理解和建模并发性。

如何启动并发用户

假设您已经创建了一个模型(好或坏)，现在是时候使用您最喜欢的负载测试工具并在负载下模拟该模型了。

JMeter 的核心是一个JMeter线程组，它允许您定义有多少用户、一个加速期以及执行测试的次数或测试的固定持续时间。从本质上讲，加速会延迟单个线程的启动。

例如，3,000 名并发用户的启动时间为 300 秒，将在每个用户启动之间施加 10 秒的延迟。

这为启动线程提供了线性、均匀的分布，因此除非您的目标是在所有用户启动后测量性能(并忽略启动本身)，否则此方法不太可能模拟真实的负载配置文件。

流行的JMeter 插件库提供了一个名为 Ultimate Thread Group 的替代方案，顾名思义，它为您提供了更多启动并发用户的选项。这包括可变数量的线程、加速时间和持续时间。通过耐心和一点点RSI将信息插入 UI，您可以创建更真实的并发负载配置文件。

FWIW，我经常在加速阶段发现许多与性能相关的缺陷，特别是对于初学者来说更现实的模型。这是您测试中监控和衡量性能的重要时期。很多时候，这段时间会从测试结果中被忽略。

如何运行并发用户

既然您的用户已经开始并且测试正在进行中，许多测试人员将专注于这段测试，并将其作为进一步观察和结果的基础。一些测试人员可能将其称为“峰值并发负载”或“稳态负载”。

除了并发性之外，影响这一时期的一个关键因素是吞吐量。

吞吐量可以通过许多不同的方式来衡量，例如网络吞吐量或每秒的请求数。但最终，吞吐量是由用户在被测系统上执行某些操作来创建的。正如我之前提到的，如果大多数用户只是空闲，那么高并发用户测试可能没有多大意义，因此吞吐量对于建模和有效模拟同样重要。

吞吐量最常受到思考时间(用户事务之间)或步调(每次迭代之间的时间)等因素的影响，但它也受到任何系统队列中的服务时间的影响，例如 Web 应用程序响应时间或网络延迟和带宽。

泊松过程或每对连续事件之间的时间具有指数分布，并且这些到达间隔时间中的每一个都被假定为独立于其他到达间隔时间。

那么我们如何模拟呢?

JMeter 有一套不错的计时器，可用于帮助随机化用户操作的到达间隔时间。我喜欢使用Gaussian Random Timer将每个请求随机延迟在一个恒定的延迟偏移附近(根据高斯曲线分布)。

JMeter 还有一个Test Action控制器，我喜欢用它在每次迭代结束时添加一个变量 pause 。这可以帮助确定节奏，或每个用户通过交易列表的速率。尽管如此，迭代之间的节奏可能很难正确，尤其是如果您的目标是模拟平均访问持续时间，例如。

我认为最好的方法是使用单个用户和多次迭代手动修改脚本，这样您就可以了解迭代之间的时间安排。

可以使用吞吐量控制器控制特定代码块的执行频率。我更喜欢使用百分比执行，以便我可以通过测试计划“加权”一定百分比的迭代。

吞吐量计时器也很有用，因为它引入了可变暂停，计算以保持总吞吐量(以每分钟样本数计)尽可能接近给定数字，该数字本身可以是随机的。

将每分钟的样本(当 JMeter 执行它们时)转换为模型的吞吐量目标可能很困难。

需要一定的努力/理解才能准确地建模。

了解结果!

假设您已经独立地摆脱了 JMeter 脚本，您还可以使用免费节点在 Flood IO 上运行它们以了解可用报告。

Flood IO中的并发是测试计划中所有线程组的活动线程数。但是，在您对使用 JMeter 或任何其他流行的负载测试工具生成的大量并发数感到兴奋之前，必须考虑一下测试计划中并发的实际含义。

可能有 100K 用户处于完全空闲状态，或者 1K 用户的迭代速度比一千只受惊的瞪羚还快，从而有效地将相同的工作负载应用到被测系统上。因此，作为单一度量的并发性缺乏上下文。

您应该查看的其他重要指标包括吞吐量和错误。有几种方法可以查看吞吐量、网络或请求，我通常更喜欢后者，因为它与外部监控工具很好地结合在一起。

从客户端监视错误对于帮助跟踪服务器端的潜在瓶颈非常重要。例如，响应代码图将帮助您显示非 HTTP 200 响应代码。您还可以在事务响应时间图中查看失败的事务计数。

结论

并发本身不足以定义系统工作负载。可以结合使用其他指标(例如吞吐量)来帮助描述工作负载。

当心平均值和均匀分布。大多数商业和开源测试工具中的默认设置通常不足以模拟真实的工作负载模型。

在您的测试计划中启动或增加用户与“稳态”负载一样重要。不要丢弃结果!

始终寻找不同指标之间的关系，例如并发、吞吐量和响应时间。永远不要忽视错误!

以上就是关于“JMeter高并发负载测试”的介绍，大家如果想了解更多相关知识，不妨来关注一下星辉的JMeter教程，里面的课程内容更加详细，由浅到深，适合没有基础的小伙伴学习，希望对大家能够有所帮助。