性能常识 JMeter 性能测试相关疑惑,欢迎大家一起讨论~

拉拉肥👧 · 2022年05月10日 · 最后由 Hao123 回复于 2022年11月08日 · 8679 次阅读

1.在实际工作中,使用哪一个线程组做性能呢?一般使用 JMeter 自带得基础线程组:Thread Group,还是用 JMeter 插件里面的:jp@gc - Ultimate Thread Group 呢?
我的理解:
基础线程组-Thread Group:模拟不了现实中用户使用软件的场景,如果在线程组里面设置:1000 个线程数,那么在启动的时候,直接就启动 1000 个线程。在现实生活中,我们的 app 或者网站不可能一直很稳定的有 1000 个用户一直在访问。
jp@gc - Ultimate Thread Group,也称之为最终(尖峰)线程组,这个线程就比较难以理解,但是功能也比较强大。它可以对负载中的线程组进行复杂的管理。通过在线程计划中具有无限数量的行来完成此操作,这可以为线程组的不同部分启用不同的配置。该插件跟 Stepping Thread Group 线程组有些类似,不过这个是多个线程组设置的结合。执行的时候,每个线程组是同时按照自己的规则开始执行的,每一时刻,得到的结果都是两个线程组的叠加。

总结:在工作中使用 Ultimate Thread Group 进行压测性能测试,相对应更符合实际情况,更有说服力。

2.在实际工作中,如何设置线程数,是由谁来定 tps 和 qps 的值是否符合预期?
我的理解:
线程数、tps、qps 的值是由 pm、rd 来定的。
你们工作中都是如何设置以上值得呢,有没有值得参考得方案呢?欢迎分享、共同学习

3.工作中,一般一台压测服务器进行压测多少线程数?如何分析我们压测需要几台压测服务器?

4.工作中,监控工具使用 grafana 和 netdata,哪一种工具比较多?

5.工作中,使用 JMeter 录制得方式,然后在进行压测靠谱吗?
欢迎大家一起讨论 JMeter 进行压测、性能测试的工作经验~

共收到 18 条回复 时间 点赞

1、我用 Stepping Thread Group 多一些,jmeter 自带的那个很少用。

2、线程数一般就自己定,这个属于执行层面的东西,只要线程数能发出足够的压力达到性能瓶颈即可,具体数量一般不纠结。tps 和 qps 我们这边不怎么区分(大部分情况下两个值差异不大),不过性能标准我们是 tps + rt(响应时间),具体值要达到多少这个,会先由性能测试负责人基于产品/开发提出的高压力场景进行分析转换,然后再项目组一起沟通确认转换过程是否合理,进而定下最终的目标值

3、这个要看压测机配置,没有很固定的数量。

4、我们运维用 grafana(服务器监控这些直接用运维提供的工具)

5、录制用得比较少,因为很多时候都需要多账号做参数化。

光呆是什么😂

拉拉肥👧 回复

一般 10-30 左右。

陈恒捷 回复

太赞了,我们怎么知道压力达到了瓶颈呀

拉拉肥👧 回复

增大压力(线程组数量)后,TPS 不再上升,只有 RT 增加,说明达到处理能力的瓶颈了。

陈恒捷 回复

明白了,咱们线程组数量一般按多少一次类推向上加

3.工作中,一般一台压测服务器进行压测多少线程数?如何分析我们压测需要几台压测服务器?

这个 jmeter 官方说一台机器不宜超过 2000 线程,jvm 可能处理不好,一般就是一千左右,具体需要几台压测服务器,需要结合响应时间

1、Stepping Thread Group 使用频率最高 官方自带基础线程组一般仅用来调试压测脚本
2、压力模型选并发还是 QPS 取决于业务场景,例如秒杀 一般选并发类加压模型,而评估系统性能选 QPS 类模型居多 线上服务或接口 根据上下游的调用量来确定 或历史同期或历史峰值 来确定较为合适 一般多给出 20% 的 BUFF
3、涉及到施压机节点的发压能力 建议按照 1 核 2G 2 核 4G 对试压机节点做基准测试 优化 JVM 参数 保证单台最优 压力不够进行横向扩展 发压稳定 & 成本最低为原则
4、基于 Prometheus 做监控的较多,上层用 Grafana 进行数据可视化展示。建议统一用运维侧提供的监控平台
5、压测脚本一般还是自己编写为主,里面的脚本参数化,断言设置及压测数据准备。流量录制更多线上流量回放 作为压测的补充来使用

线程组策略可能还要看实际场景,大部分情况下都会选用梯度递增。像秒杀活动可能就要瞬间的高压,此时服务器也需要做一些数据预热之类的操作,不然响应时间很感人。(题外话,你也是光呆?)

拉拉肥👧 回复

你的 name 叫拉拉肥,还以为是 ff14 里的拉拉菲尔

1、我们工作中主要使用的是 Stepping Thread Group 线程组,Thread Group 也是用来调试的。
2、我们在测试前没有定 tps 和 qps,一般会先拍一次脑袋,然后测出一个结果之后再根据这个结果拍第二次脑袋😂
3、我们根据 4C8G 的压测机配置给了一个预期的并发量,但是实际测试工作中能够支撑的并发量会根据场景以及脚本复杂度发生变化,没办法一概而论。
4、对于监控工具,现在市面上主流的基本都用过,主要是每个客户的环境架构都不一样,有的开通端口要走的审批很麻烦,所以会灵活调整性能测试时使用的监控工具。
5、自己开发了一个工具,录制后,能够自动对接口中的请求响应进行解析,参数化后生成 jmeter 脚本。

拉拉肥👧 回复

历史脚本 除非引擎版本已经不支持 所以线程组未做替换仍然使用 Stepping Thread Group 新的脚本默认使用 Concurrency Thread Group



基础线程组设置 ramp up 就行了,其他的几个阶梯线程组都有缺陷

各有优点吧,基准的 ramp up 不能达到某个线程进行持续,而梯级的可以保持持续时间,找拐点和分析都是比较合适的

请问各位大佬在进行性能测试时,是测出性能瓶颈或其他指标性结果即可,还是需要根据测试结果给出对应的性能优化方案

各位大佬,我想问下这两种阶梯加压的插件:Concurrency Thread Group 和 Stepping Thread Group 适用于 jmeter 分布式压测吗?我测了一下,分布式压测时,管控机的控制台只能显示单个客户端的测试结果,而不是汇总起来。两者之差就只有聚合报告中的总样本数不同

imath60 回复

官网不是说 Stepping Thread Group 已经被 Concurrency Thread Group 代替了吗

监控工具主流还是用 grafana

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册