JMeter之集合点

1、计算公式：

线程数 =  QPS * time

注意：QPS--每秒完成请求的个数；time--每个请求响应完成平均需要时间

故QPS * time 就是所有请求完成响应所需要的总时间，如果需要在一秒内完成所有请求，所以线程数需要等于总时间值

 

压力测试线程数确定：

比如一个活动，大概一个小时内有60W人的流量，算应该压测的线程数是多少

一个小时 = 60分钟 = 3600 s

 

算法：

二八定律，20%的时间跑了80%的流量            --- 换算就是12分钟跑了48W流量

48W/12/60 = 667

就是设置集合点，每秒应跑的线程数是667（不是绝对，线程数需要一点点往上压，主要看测试之前指定的指标）

 

指标

每秒事物数、接口error率、响应时间、内存、CPU、网络、资源、JVM查看fgc情况和阻塞点

 

压力测试：

　　压力测试分两种场景：一种是单场景，压一个接口的；第二种压混合场景，多个关联的接口。压测时间，一般场景都运行10～15分钟。如果疲劳测试，可以压一天或一周，根据实际情况而定。

压测任务需求的确认：

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

　　1⃣️固定接口参数进行压测还是进行接口参数随机化压测

　　2⃣️要求支持多少并发数
　　3⃣️TPS（每秒钟处理事物数）  目标多少？响应时间达到多少？

　　4⃣️压服务器名称还是压服务器IP，一般搜是压测指定的服务器

压测设置：

线程数：并发数量，能跑多少量。具体说是一次存在多少用户的访问

Ramp-Up Period(in seconds)：表示JMeter每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是20，准备时长为10，那么需要10秒启动20个用户，也就是每秒启动2个线程。

循环次数：这个设置不会改变并发数，可以延长并发数。总请求数 = 线程数 * 循环次数

调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。

 

 

 

集合点：简单理解下，虽然我们的性能测试理解为多用户并发测试，但真正的并发是不存在的，为了更真实的实现并发这概念，我们可以在需要压力的地方设置集合点

 

我们这里拿获取天气的例子说明一下，用户每次到达获取天气的接口时，所有的虚拟用户都互相之间等一等。然后，一起访问。

 

1、接着前面创建的脚本，右键点击 线程组---->定时器---->Synchronizing Timer（同步定时器）

 

 

 

 

 

这样，我们就添加了一个“集合点”。因为在发送获取城市天气的请求集合，所以需要将“集合点”拖到“获取城市天气”前面的位置（也可以作为获取城市天气请求的子节点），如上图

 

这里设置模拟5个用户集合并发，超时时间设置为5000毫秒(5秒，当设置为0时，表示无超时时间，会一直等下去，直到有5个用户才出发)，点击运行

  

查看压测结果：

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

Samples:表示一共发出的请求数

Average：平均响应时间，默认情况下是单个Request的平均响应时间（ms）

Error%:测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因

Throughput:简称TPS，吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，TPS越高说明服务器处理能力越好。

 

压测结果的分析

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

Throughput：吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数

压测结束，登陆相应的web服务器查看CPU等性能指标，进行数据的分析

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

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

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

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