监控工具主流还是用 grafana

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

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

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

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

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

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

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

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

一般 10-30 左右。

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

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

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

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

光呆是什么

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

你的 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 分布式压测吗？我测了一下，分布式压测时，管控机的控制台只能显示单个客户端的测试结果，而不是汇总起来。两者之差就只有聚合报告中的总样本数不同