标签：场景 50tps 性能 并发 线程 测试 tps

负载测试

阶梯线程组-stepping threads group

通过逐步增加并发用户数来进行压测，增加并发的数量不一定是相同的

• 增加的量(或者叫做步长)，可以相同，也可以不相同。
• 增加的量相同，只是一种特殊情况：stepping threads group。
• 不相同的增量，不能用 stepping threads group，需要使用另外一个组件

在阶梯线程组的执行过程中，我们的并发用户数是时刻发生变化的。

阶梯线程组设计的规律：缓起步，快结束。

快结束：并不是指瞬间结束，若在1秒钟停止20个以内的并发用户，不会出问题，但是大于220，就出问题了。太慢，会把整体的请求的人数以及tps值拉低了。太快，不能中断的请求被你强制中断了，导致报错，这个人为导致的报错被当作服务器的报错了

压力测试场景

压力测试定义：运行比较长的时间，看稳定性。

---

压力测试并发数计算，根据负载的最大并发数：

上篇文章得知我们的最大用户并发数是18，可以使用20% 或者80%，作为压力测试的并发人数

18* 20% = 4

18* 80% = 14

1- 使用普通线程组进行压力测试 

压力测试6分钟

在做压力测试的过程中，一直关注响应时间、tps值，看下运行过程中有没有报错。

2- 使用阶梯线程组进行压力测试

用15个并发持续3600s压力测试 tps展示了压力测试失败的场景

性能测试报告

性能测试时，能不启用监听器，则不启用，监听会占用性能

真正做性能测试的是通过命令行 CLI-mode 的方式进行的

---

没有监听器，我们怎么知道性能测试结果？

使用 jmeter的html报告，与是否启用添加监听器无关

操作步骤如下：

选择生成文件地址勾选仅错误日志 选择文件 执行压力测试 生成的jtl文件 5.1.1 版本以上使用此功能生成报告 报告目录 html报告

面向目标性能场景1  Arrivals Thread Group （面向 tps）

Arrivals Thread ： 达到多少率 tps

需求 1：期望我的项目的接口，都要能满足50tps？ 50tps 满足大部分中小微企业的要求

50 tps 

• 1分钟可以处理： 50\*60s = 3000 事务
• 1小时 可以处理：3000 \* 60 = 180000 事务
• 1小时可以处理18w个请求  24h 432w个请求

若产品，日均访问量约为千万， 50tps基本已经能满足要求了

---

设计场景验证接口时候满足50tps

10s内分5次达到50tps，并持续60s

下图两表结合观察发现，线程数在150个线程左右可以达到50tps

活动线程响应图 tps响应图

响应时间却 远远大于1.5s，显然是不能接受的

得出结果  此接口不能满足50tps的要求

设置为18tps后

线程数150个 响应时间约等于2s 平均事务18

---

需求 2：设计能支持1000个人同时秒杀，我们的系统不能崩溃

场景分析：

• 秒杀业务不会是 单纯的 1000个人在1s内启动运行，需要保证1000个人访问系统，持续运行不是只运行1s，系统不能崩溃
• 用户故事角度： 我要在1s内收到响应结果，这种场景属于 1000tps 请求接口，并得到正常响应

面向目标性能场景2 Concurrency Thread Group  （目标：并发数）

Concurrency Thread： 达到多少人 并发数

校验 接口是否能够达到100 的并发用户

并发数到100后

响应tps大约11

平均响应时间为9s 不满足 100个并发数

响应时间

 Ultimate Thread Group 终极线程组

用于有时间规律的压测，应用于如：美团，饿了么外卖点单时间 大约集中于饭点 的业余场景

使用Ultimate Thread Group 设置阶梯线程 增加的量(非步长)

 

标签：场景,50tps,性能,并发,线程,测试,tps
From： https://www.cnblogs.com/orangezhangzz/p/16887678.html