一、JMeter 中的高级线程组概述
最近群里的测试小伙伴在问在 JMeter 中,“jp@gc - Ultimate Thread Group”和“jp@gc - Stepping Thread Group 阶梯加压”有哪些区别和实际应用场景有哪些?所以这里也跟大家分享一下
JMeter 作为一款强大的性能测试工具,拥有众多实用的插件,其中 jp@gc - Ultimate Thread Group 和 jp@gc - Stepping Thread Group 这两个高级线程组在性能测试中发挥着至关重要的作用。
jp@gc - Ultimate Thread Group 功能强大且灵活度高,相当于把多个不同基础线程组进行组合。它可以用于创建线性负载、阶梯负载、尖峰负载和波浪形负载等多种测试场景。例如,在创建线性负载测试场景中,可在 60s 内启动 100 个线程,持续运行 60s,再花 10s 的时间结束脚本。同时,添加监听器 jp@gc - Active Threads Over Time 后,能方便地查看线程运行情况。在创建阶梯负载测试场景时,比如测试 100 个用户,可以逐步提升用户数量,先从 25 个用户开始,在一定时间内保持该负载,观察服务器的处理情况,然后再依次增加用户数量,通过这种方式能更可靠地了解系统在不同负载下的运行状态。
jp@gc - Stepping Thread Group 则主要用于模拟从某个值开始不断增加压力,直至达到某个值,然后持续运行一段时间的测试场景。例如,设置总共要启动的线程数为 100,从运行之后 0 秒开始启动线程,初次启动 0 个线程,之后每次启动 10 个线程,每运行 30 秒启动一次,启动线程时间为 5 秒,全部启动完之后持续运行 60 秒,最后每 1 秒钟释放 5 个线程。结合监听器 jp@gc - Active Threads Over Time,可以清晰地观察线程运行情况,还能设置比较陡峭的并发。
二、jp@gc - Stepping Thread Group 的特点与应用
(一)独特的参数设置
- This group will start:表示总共要启动的线程数,它确定了整个测试过程中的最大线程数量,比如设置为 100 个,表示最终会加载 100 个线程,用于模拟特定场景下的最大并发用户数。
- First,wait for:这是第一阶段等待时间,如果设置为 0,就不需要等待,它可以用于控制测试的起始时间点,以便更好地模拟实际场景中的用户行为。
- Then start:初始加载的线程数,比如设置为 20 个,表示初始启动 20 个线程,为后续的逐步加压提供了起始点。
- Next add:每梯次加载的线程数,比如设置为 5 个,表示每个梯次加载 5 个线程,结合后面的参数可以控制线程增加的速度和节奏。
- threads every:当前运行多长时间后再次加载线程或每一次加载完成之后的持续时间,比如设置为 1 秒,每梯次加载完线程之后运行 1 秒,这个参数可以调整测试的动态性。
- using ramp-up:每梯次加载线程的时间,比如设置为 0 秒,表示每一次加载立刻完成,它与前面的参数共同决定了线程增加的速度。
- Then hold load for:线程全部加载完之后运行多长时间,比如设置为 30 秒,表示 100 个线程加载完之后再持续 30 秒,用于模拟系统在高负载下的持续运行情况。
- Finally,stop/threads every:每多长时间释放多少个线程,比如设置为 5 个和 1 秒,表示所有持续负载结束之后每 1 秒钟释放 5 个线程,用于控制测试的结束过程。
(二)应用场景广泛
- 容量测试:在容量测试中,jp@gc - Stepping Thread Group 可以评估系统在用户逐渐增加情况下的性能极限。通过逐步增加线程数,观察系统的响应时间、吞吐量等指标的变化,确定系统能够承受的最大负载。例如,在模拟网站上线初期访问量逐渐增长的过程中,可以使用该插件来测试系统的容量,以便及时发现潜在的性能问题并进行优化。
- 稳定性测试:验证系统在用户访问量逐步增长过程中的稳定性和响应时间。通过长时间运行测试,观察系统在不同负载下的稳定性,确保系统在持续高负载下不会出现崩溃或性能严重下降的情况。例如,在电商平台大促活动前,可以使用该插件进行稳定性测试,以保证系统在高流量下的稳定运行。
- 发布前压力测试:模拟新服务或产品发布后,用户逐渐发现并访问的场景,以评估系统的准备情况。通过设置合理的参数,模拟真实用户的增长趋势,提前发现系统可能存在的性能瓶颈,为发布做好充分准备。
(三)使用注意事项
确保配置的用户增长速度和系统处理能力相匹配,避免因过快增加负载导致测试环境崩溃。在设置参数时,需要充分了解系统的性能特点和处理能力,根据实际情况合理调整线程增加的速度和数量。
监控资源使用情况,结合监听器结果分析性能瓶颈。在测试过程中,要密切关注系统的资源使用情况,如 CPU、内存、网络带宽等,结合监听器收集到的响应时间、吞吐量等数据,分析系统的性能瓶颈所在,以便进行针对性的优化。
根据实际需求调整参数,合理设置测试持续时间和用户行为模式,以获得最接近真实的测试结果。不同的应用场景可能需要不同的参数设置,要根据具体情况进行调整,确保测试结果能够真实反映系统在实际使用中的性能表现。
三、jp@gc - Ultimate Thread Group 的特点与应用
(一)丰富的控制参数
- Start Time:该阶段开始的时间点,相对于测试启动的时间(单位:秒)。它决定了线程组开始执行的时间,可以精确控制测试的启动时机,以便更好地模拟实际场景中的用户行为。例如,如果设置为 10 秒,表示在测试启动后的第 10 秒开始执行该线程组。
- Initial Delay, sec:线程开始增加前的延迟时间。这个参数可以用于模拟用户在进入系统前的等待时间,或者在某些特定场景下,为了避免瞬间高并发而设置的延迟。比如设置为 5 秒,那么在 Start Time 之后,会再等待 5 秒才开始增加线程。
- Startup Time, sec:线程从零增加到目标数量所需的时间。它控制了线程数量的增长速度,可以模拟用户逐渐进入系统的过程。例如,如果要在 30 秒内启动 100 个线程,那么 Startup Time 可以设置为 30 秒。
- Hold Load For, sec:达到目标线程数后保持该负载的时间。这个参数用于模拟用户在系统中的持续活动时间,以便测试系统在高负载下的稳定性。例如,设置为 60 秒,表示在达到目标线程数后,保持该负载状态 60 秒。
- Shutdown Time:线程从当前数量减少到零所需的时间。它可以控制测试的结束过程,避免突然停止测试对系统造成的冲击。比如设置为 10 秒,表示在测试结束时,用 10 秒的时间逐渐减少线程数量至零。
(二)多样的应用场景
- 创建线性负载:例如在 60s 内启动 100 个线程,持续运行 60s,花 10s 的时间结束脚本。这种场景可以模拟用户数量逐渐增加,然后在一定时间内保持稳定,最后逐渐减少的过程,适用于测试系统在稳定负载下的性能表现。
- 创建阶梯负载:先从 25 个用户开始在一定时间内保持一个负载,查看服务器如何处理它。之后再依次增加 25 个用户,直到达到 100 个用户。这种方式可以更细致地观察系统在不同负载阶段的性能变化,找出系统的性能瓶颈。
- 创建尖峰负载:可以模拟突然出现的高并发情况,如促销活动、突发事件等场景下用户的瞬间涌入。通过设置合适的参数,可以快速启动大量线程,然后在短时间内达到峰值,再逐渐减少线程数量,测试系统在应对突发高负载时的性能。
- 创建波浪形负载:以 12306 抢票为例,每次开放抢票时,有大量用户涌入,等到下次开放时,又有大量用户涌入,像波浪一样不断敲击服务器。通过设置合适的 Initial Delay、Startup Time、Hold Load For 和 Shutdown Time 参数,可以模拟这种波浪形的负载模式,考验服务器的性能。
(三)优势与不足
- 优势:提供了丰富的控制选项,能够满足复杂测试需求。可以根据不同的测试场景精确调整线程的行为,模拟出各种真实世界中的用户行为模式。例如,在模拟用户登录高峰期、持续使用期以及用户活动的逐渐减少等场景时,能够更加贴近实际情况,获得更准确的性能评估结果。
- 不足:配置较为复杂,需要了解更多线程组控制参数的概念和作用。对于初学者来说,可能需要花费一定的时间来学习和理解这些参数的含义和用法。而且在设置参数时,需要充分考虑系统的性能特点和测试需求,否则可能会导致测试结果不准确或者测试过程出现问题。
四、两者区别与实际应用对比
(一)参数设置方面的区别
- 启动方式:
- jp@gc - Stepping Thread Group 从一个初始值开始,通过逐步增加线程数的方式启动。例如设置总共要启动的线程数为 100,从运行之后 0 秒开始启动线程,初次启动 0 个线程,之后每次启动一定数量的线程,逐步达到最大值。
- jp@gc - Ultimate Thread Group 可以设置初始延迟时间,然后在特定的启动时间内将线程从零增加到目标数量。比如设置初始延迟为 5 秒,在 Start Time 之后,会再等待 5 秒才开始增加线程,然后在规定的 Startup Time 内启动到目标线程数。
- 运行过程控制:
- jp@gc - Stepping Thread Group 通过设置每梯次加载的线程数、加载时间和持续时间等参数来控制运行过程。例如每梯次加载 5 个线程,每运行一段时间再次加载,加载时间为特定值,加载完成后持续运行一段时间。
- jp@gc - Ultimate Thread Group 则通过 Startup Time、Hold Load For 等参数来控制线程从启动到达到峰值以及在峰值持续运行的时间。例如在 30 秒内启动到目标线程数,然后保持该负载状态一定时间。
- 结束方式:
- jp@gc - Stepping Thread Group 通常是每多长时间释放一定数量的线程,逐步减少线程数直到为零。比如每 1 秒钟释放 5 个线程。
- jp@gc - Ultimate Thread Group 可以设置一个线程从当前数量减少到零所需的时间,逐渐结束测试。比如设置为 10 秒,表示在测试结束时,用 10 秒的时间逐渐减少线程数量至零。
(二)应用场景的不同
- 容量测试:
- jp@gc - Stepping Thread Group 在容量测试中适合逐步增加负载,观察系统在不同负载阶段的性能变化,找出系统的容量极限。例如在模拟电商平台用户访问量逐渐增长的过程中,可以更好地了解系统在各个阶段的处理能力。
- jp@gc - Ultimate Thread Group 则可以通过创建不同的负载模式,如线性负载、阶梯负载等,全面测试系统在不同负载情况下的性能表现。比如在测试一个新上线的应用时,可以通过创建线性负载来模拟用户数量的逐渐增加,观察系统的响应时间和吞吐量的变化。
- 稳定性测试:
- jp@gc - Stepping Thread Group 可以通过设置较为平缓的线程增加速度,长时间运行测试,观察系统在不同负载下的稳定性。例如在进行银行系统的稳定性测试时,可以逐步增加用户数量,观察系统在处理大量交易时的稳定性。
- jp@gc - Ultimate Thread Group 可以通过设置尖峰负载或波浪形负载来测试系统在突发高负载和间歇性高负载情况下的稳定性。比如在测试在线游戏服务器时,可以模拟玩家数量的突然增加和波动,观察服务器的性能表现。
- 发布前压力测试:
- jp@gc - Stepping Thread Group 可以根据实际情况逐步增加负载,模拟新服务或产品发布后用户逐渐发现并访问的场景,提前发现系统可能存在的性能问题。例如在发布一个新的移动应用时,可以通过设置逐步增加的线程数来模拟用户的增长趋势,确保系统在发布后能够稳定运行。
- jp@gc - Ultimate Thread Group 可以通过创建多种负载模式,全面测试系统在不同用户行为模式下的性能表现,为发布做好充分准备。比如在发布一个新的电商平台时,可以通过创建阶梯负载和波浪形负载来模拟用户在促销活动和日常使用中的行为,确保系统能够应对各种情况。
总之,jp@gc - Stepping Thread Group 和 jp@gc - Ultimate Thread Group 在参数设置和应用场景上各有特点,性能测试人员可以根据实际需求选择合适的线程组进行测试,以获得更准确的性能评估结果。