jmeter与压测基础知识

1 压力测试中的指标
1.1 TPS
TPS 即Transactions Per Second的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程**(完整处理，即客户端发起请求到得到响应)**。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。一个事务可能对应多个请求，可以参考下数据库的事务操作。

1.2 QPS
QPS 即Queries Per Second的缩写，每秒能处理查询数目(完整处理，即客户端发起请求到得到响应)。是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
我们从它的英文全名可以得出它是查询意思，原来在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数。 虽然名义上是查询的意思，但实际上，现在习惯于对单一接口服务的处理能力用QPS进行表述（即使它并不是查询操作）。

1.3 平均处理时间（RT）
RT：响应时间，处理一次请求所需要的平均处理时间。
我们一般还会关注90%请求的的平均处理时间，因为可能因网络情况出现极端情况。

1.4 并发用户数(并发量)
每秒对待测试接口发起请求的用户数量。

1.5 换算关系
QPS = 并发数/平均响应时间
并发量 = QPS * 平均响应时间

比如3000个用户(并发量)同时访问待测试接口，在用户端统计，3000个用户平均得到响应的时间为1188.538ms。所以QPS=3000/1.188538s= 2524.11 q/s。
我们就可以这样描述本次测试，在3000个并发量的情况下，QPS为2524.11，平均响应事件为1188.538ms

1.5 TPS和QPS的区别
这个问题开始，我认为这两者应该是同一个东西,但在知乎上看到他们的英文名，现在我认为：
QPS 每秒能处理查询数目，但现在一般也用于单服务接口每秒能处理请求数。
TPS 每秒处理的事务数目，如果完成该事务仅为单个服务接口，我们也可以认为它就是QPS。

PS:还有一个RPS的的概念 request per second 。每秒请求数，在一定条件下和QPS 和TPS类似。
 

关于这里的Ramp-Up Period(in seconds): 设置线程需要多长时间全部启动。如果线程数为200 ，准备时长为10 ，那么需要1秒钟启动20个线程。也就是每秒钟启动20个线程。如果有100个线程、Ramp-Up Period=1s，那就表示100个线程在1s时间内创建起来，也就是说每隔0.01s会增加一个线程，直到100个线程全部建立，之后所有的线程就分别独立地向系统发送请求了，它们之间互不影响

1、误区

在JMeter压测过程中，我们通常认为1s内100的并发量（即：QPS为100）的设置如上图，没有再添加额外的控制器；
我们用上述的设置，对某个接口进行压测，运行后用表格查看结果，会看到starttime没有重复的，说明没有并发的请求：

压测任务需求的确认

压测前要明确压测功能和压测指标，一般需要确定的几个问题：

1. 1. 固定接口参数进行压测还是进行接口参数随机化压测？
   2. 要求支持多少并发数？
   3. TPS（每秒钟处理事务数）目标多少？响应时间要达到多少

压测方案： 

1.如果想通过设置Ramp-Up Period(in seconds)、线程数、循环数的方法来压测，

 RPS

RPS 就是每秒请求数（Request Per Second），它描述了施压引擎向服务器实际发出的压力大小。
从用户角度来说，rps 是每秒钟点击的次数
从客户端角度来说，rps 是每秒向服务端发出的请求数
使用工具的最终目的就是为了利用线程数和迭代次数模拟出和用户每秒点击相匹配的压力值，施压服务端，得到性能数据

Rps 由并发数，和服务器响应时间决定。并发数过低时可能达不到预期的 RPS，并发数过高时可能压力过大直接就压垮了服务器。

jmeter 怎么调节压力

从前面的描述中我们知道压力就是每秒发出的请求数。现在再来理解一个 jmeter 的名词Ramp-up-period（in seconds）

Ramp-up-period

jmeter 在线程组中有一个可调节的数值：Ramp-up-period，它表示启动所有线程需要的时间，单位是秒

图 1-1 设置了 100 个线程，迭代次数=1，Ramp-up-period=25，那么它表示我将在 25 秒内启动 100 个线程，也就是每秒钟启动 4 个线程。

每个线程启动之间的间隔时间是 25/100=0.25s,也就是 250ms。

换个理解方式，它表示了我们给服务器的压力在第一秒内是每秒钟 4 次请求。也就是说，RPS 在第一秒内是 4/s，后续 25s 内呈现递增的趋势。如下：
4/s
8/s
12/s
16/s
.......

​

1-1

图 1-2 设置了 100 个线程，迭代次数=10，Ramp-up-period=25，那么它表示我将在 25 秒内启动 100 个线程，每个线程迭代 10 次。也就是说，RPS 在第一秒内是 40/s，后续 25s 呈现递增趋势。如下：
40/s
80/s
120/s
.........
我们来思考一个问题：迭代设置了 10 次，真的每秒就能迭代 10 次吗？
这就涉及到一个很核心的知识点，我们设计的迭代次数其实是总迭代次数，为什么这么说呢？因为线程的迭代是顺序进行的，也就是说响应时间决定了每秒能迭代多少次。如果我们设计的迭代数超出了线程每秒最大迭代次数，那么一定是时间顺延。

由此可见，基础线程组中我们设置的 rps 仅仅是一个预期值！最终能达到多少 rps，由我们的线程数或者每秒迭代次数来决定。反过来说，为了达到预期的 rps 值，需要先设计并发数或者每秒迭代数。

​

1-2

Throughput Shaping Timer（rps 定时器）

现在我们再来看一下 Throughput Shaping Timer（rps 定时器）
这个定时器是在我们线程已经固定的基础上来逐渐增加每秒迭代次数的

start=1 end=200，持续时间是 60。表示我们需要在 60s 内将 RPS（每秒请求数）均匀的从 1 提升到 200
并发数 = 预期 RPS * 响应时间

2.添加同步定时器

如果是有要求需要支持多少并发数，可以通过添加同步定时器来实现 

​

 打开同步定时器，设置模拟用户组的数量为5，也就是5个并发，超时先设置为0

​

再次运行，就可以看到在同一时间会发出5个请求（这里不是绝对的，会更接近5个并发）,那么这里设置的并发数，会等线程数达到这个数量后一起发出去，起到并发的作用.

​

 超时时间：

 前面设置线程数100，并发5，刚好每凑齐5个请求一起发出去。如果线程数100，并发为3，最后还有1个请求凑不齐会怎样？

​

 可以看到右上角时间一直在运行，不会自动结束，因为前面超时时间为0，就一直等待。​

 为了避免这种一直等待的情况，可以设置同步定时器的超时时间，比如我设置500毫秒，如果500毫秒还没凑齐3个请求，那就先发出去，不用一直等了。

3. 添加常数吞吐量定时器

常数吞吐量定时器可以让JMeter以指定数字的吞吐量（即指定TPS，只是这里要求指定每分钟的执行数，而不是每秒）执行。吞吐量计算的范围可以为指定为当前线程、当前线程组、所有线程组，并且计算吞吐量的依据可以是最近一次线程的执行时延。这个定时器引入了变量暂停，通过计算使总吞吐量，尽可能接近给定的数字。当然，如果服务器不能处理它，或者如果其他定时器或耗时的测试原件阻止它，那么吞吐量将更低。

​

 名词解释：

第一： 只有此线程：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的目标吞吐量乘以该线程的数量

第二： 所有活动线程：设置的目标吞吐量将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。

第三：所有活动线程(共享)：与所有活动线程的选项基本相同。唯一区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。

第四： 当前线程组中的所有活动线程：设置的目标吞吐量将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和所有活动线程选项的效果完全相同。

第五：当前线程组中的所有活动线程(共享)：与当前线程组中的所有活动线程基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。

 运行后结果可由jp@gc - Transactions per Second插件查看效果，

 ​

4、压测结果查看

  运行完后，聚合报告会显示压测的结果。主要观察Samples、Average、error、Throughput。

Samples:表示一共发出的请求数
Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）
Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
4.4、Throughput:简称tps,吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps越高说明服务器处理能力越好。

5、压测结果的分析

有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；

5.1、Throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；

若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；压测结束，登陆相应的web服务器查看CPU等性能指标，进行数据的分析;

5.2、最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。

5.3、最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。

5.4、压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。

5.5、影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。