参考文章

服务器压力测试实现步骤,测试web性能时 做一个压力测试的四大步骤

https://www.baidu.com/s?wd=%E6%B5%8B%E8%AF%95%E6%9C%8D%E5%8A%A1%E5%99%A8qps%EF%BC%8C%E5%8E%8B%E6%B5%8B%E5%A4%9A%E9%95%BF%E6%97%B6%E9%97%B4%E6%AF%94%E8%BE%83%E5%90%88%E9%80%82&rsv_spt=1&rsv_iqid=0x8d45486e00a0e702&issp=1&f=8&rsv_bp=1&rsv_idx=2&ie=utf-8&rqlang=cn&tn=baiduhome_pg&rsv_dl=tb&rsv_enter=1&rsv_btype=t&inputT=14721&rsv_t=3e29ilIUiNg8sXqW7h7quA1kixontpG8uFB1OFt6ZEfLhlN%2BapAkgwmRp2SDp26d33Wl&oq=Quartz%2520demo&rsv_pq=ffab7fe10095f517&rsv_sug3=156&rsv_sug1=78&rsv_sug7=100&rsv_sug2=0&rsv_sug4=14721

jmeter接口验签

Jmeter——使用JSR223元件实现RSA登录加密
https://www.cnblogs.com/hong-fithing/p/12175501.html

Jmeter之BeanShell脚本(如何看到脚本执行过程)
https://www.cnblogs.com/wangyi0419/p/12183407.html

tomcat最大连接数

当一个进程有 500 个线程在跑的话，那性能已经是很低很低了。Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发，当然了，也可以将其改大。当某个应用拥有 250 个以上并发的时候，应考虑应用服务器的集群。具体能承载多少并发，需要看硬件的配置，CPU 越多性能越高，分配给 JVM 的内存越多性能也就越高，但也会加重 GC 的负担。操作系统对于进程中的线程数有一定的限制：Windows 每个进程中的线程数不允许超过 2000Linux 每个进程中的线程数不允许超过 1000另外，在 Java 中每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用。Tomcat的最大并发数是可以配置的，实际运用中，最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件，更多的处理器都会使Tomcat支持更多的并发。

jmeter参数

响应时间一般是以95%的请求的平均响应时间为准

彻底理解jmeter的ramp-up参数

1. 线程数20，启动时间（ramp-up）10，循环次数1
   
   
2. 线程数10，启动时间（ramp-up）20，循环次数1
   
3. 线程数10，启动时间（ramp-up）20，循环次数2
   
4. 线程数20，启动时间（ramp-up）10，循环次数2
   
5. 线程数10，启动时间（ramp-up）20，循环次数永远，持续时间10秒，启动延迟5秒
   结果分析：10秒内发送了12个请求，启动了5个线程.过大的ramp-up也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。(该例子就是ramp up过大导致请求阶段已经结束，但仍有部分线程没有启动起来)
   
   
   参考文章：如何合理设置jmeter的ramp up参数

• 如何合理设置ramp up呢
  确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率

总结说明

线程1-1启动时间：21:45:18.095（第18秒时线程1投入了战斗）
线程1-2启动时间：21:45:19.205（第19秒时线程2也投入了战斗）
线程1-3启动时间：21:45:20.316（第20秒时线程2也投入了战斗）
线程1-4启动时间：21:45:21…（第21秒时线程2也投入了战斗）
…
线程1-10启动时间：21:45:28.094（第28秒时10个线程终于全部投入了战斗）

持续时间的使用场景

比如说，现在有一个场景，50用户同时的点击率相当于200用户的在线率，这时候需要观察200用户在线时，服务器的一个性能情况，这时候就可以设置循环周期为永远，然后设置持续时间为10分钟或更多，使用top命令，查看cpu的一个占用情况
　　

彻底理解ramp up

2

ab是apachebench命令的缩写，压力测试/性能测试

循环次数+ramp-up+线程数

我设置的参数是10个线程，ramp-up=10，循环次数2，显示结果是10秒内发了20个请求，每个线程在一秒内会发2次请求，该场景下的并发数肯定是102/10=2个请求/秒，每个请求间隔时间是10/（210）=0.5秒


循环次数不是永远，ramp-up才有意义。

以上可以理解成：【模拟的是并发数为2的场景】
设置一个固定循环次数，这种设置可以让一定量的用户，进行多次循环，从而构成一种并发

循环次数（永远）+持续时间

模拟的场景是：
不设置次数仅控制循环时间，这种设置模式是为了观察服务器在一个时间段内，维持某种并发的运行情况

• 循环次数永远，ramp-up为1秒-----1毫秒内差不多发送10个请求，60秒内发了差不多58万个请求
  

• 循环次数永远，ramp-up为1000秒-----平均1毫秒内发了20个请求，60秒内发了差不多50万个请求
  

参考：Jmeter之线程组循环次数

同步器里面的Timeout in milliseconds参数

模拟用户组的数量：定义有多少用户触发同步块的释放（默认为0即所有用户），假设为3000
超时时间（以毫秒为单位）：默认为0（即到所有用户到达集合点才触发，否则永不触发），假设为3000，就是最长等待3秒，3秒内一旦集齐3000用户就出发，3秒过后假设只集齐了2500，那么这2500就同时发车，然后剩下的500再发车。

线程组参数

线程数：a
Ramp-Up时间:b
循环次数：c

说明：
（1）每个线程可以看做是一个用户
（2）循环次数指每个用户的循环次数
（3）Ramp-Up时间指的是所有线程启动的耗时，和循环次数没关，也就是说a/b才是每秒并发数

版本缺陷记录

1. fillder和jmeter捕捉app请求失败
2. 测试的时候遇到了网站有csrf防御http://47.107.116.139/phpwind/index.php?m=u&c=login&a=dorun【第一啥是csrf，第二如何破解，第三我如何也做csrf防御，第四什么场景需要用这个东西】

jmeter文件上传载压测过程详解记录

真正并发测试是设置集合点

真的理解Jmeter线程数、Ramp-Up、循环次数真的理解？

注：线程数抽象实例化后就是用户数，Ramp-up time是规定所有用户在时间段内把请求发送完（前提条件循环次数是1），而且请求的时间间隔是固定的=Ramp-Up time/线程数。
疑问二： 循环是在哪个时间点开始执行的？与线程组的关系是怎样的？
解答：循环开始时间几乎与启动时间并行，
如下图解释：a循环数为1的解释是1个/s请求发5次请求。
b循环数为2时解释是（1个/s请求发5次）执行2遍（循环数），循环开始执行时间几乎与第一遍执行时间并行。（仔细观察Thread Name的时间点）
疑问三：配置10/s个并发如何实现？是否可以通过（线程数，Ramp-Up time、循环数）配合来实现？
方法一： 通过（线程数，Ramp-Up time、循环数）配合来实现
组合有很多种，我列了几个
————————————————
版权声明：本文为CSDN博主「弘毅密令」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u013908944/article/details/97383303

取样器是记录请求过程中的信息【url，请求参数…】
监听器是将信息进行分析输入结果并展示【压测的结果】

nacos性能测试报告

https://nacos.io/zh-cn/docs/nacos2-naming-benchmark.html

jmeter压测结果分析

Jmeter的Throughput和平均响应时间计算方法整理

Throughput为吞吐率（请求数/秒）它可以有多个指标来衡量，但通常我们用tps或者qps（qps是tps的一种情况，类似正方形是特殊的长方形一样，但我们通常将qps来替代tps）来衡量吞吐率。在加了事务控制器后，TPS=Throughput
宏观上：TPS=并发数/响应时间，jmeter的Throughput = (number of requests) / (total time) ，即
Throughput =(sample样本数)/(最后一个线程启动的时间+最后一个线程持续的时间-第一个线程启动的时间)
可以这样理解这个公式：绝对的并发是不存在的，请求发出的时间总有先后，绝对的TPS也是无法计算的，统计的角度看，服务器处理请求总数/花费的时间即是TPS，这也是
为什么需要不断增大用户数来寻找服务器的最大TPS的原因

Jmeter如何分析压测结果

学习视频推荐

https://www.bilibili.com/video/BV1zi4y187H8?p=24&spm_id_from=pageDriver

jmeter安装

1. 安装
   jmeter下载地址
   
   解压后（解压路径不要有中文名称）进入到bin目录下点击jmeter.bat即可运行

配置

bin目录下修改

language=zh_CN

sampleresult.default.encoding=UTF-8

2. 设置语言
   
   
   
   
   添加查看结果树（记录请求结果的）
   
   点击运行可查看到结果
   
   线程组相当于业务流程
   
   jmeter安装插件查看QPS和响应时间随着时间的变化曲线

取样器是记录请求过程中的信息
监听器是将信息进行分析输入结果并展示

jmeter原理

就是通过多线程去模拟用户并发请求


安装badboy脚本录制工具

测试网站
http://47.107.116.139/phpwind/

比如我们测试一个登陆功能

保存之后就可以到jmeter中打开了

app端脚本录制

中文乱码的解决方案

添加请求头

http默认80，https默认443

jmeter默认发送的格式是www-form-urlencode

jmeter参数化

导入csv参数

创建csv文件（进行文件转码）



设置请求头

添加请求体【${username}表示变量的意思】

{"username":"${username}","password":"${password}"
}

查看结果如下：

用户参数

哪个请求就到对应请求下添加用户参数

用户定义的变量

相当于全局变量的意思

使用

jmeter连接数据库

1. 测试计划中导入jdbc链接的jar包
   我本地的jar包在这里
   
   测试计划中导入包：
   

2. 添加jdbc配置
   

3. 添加jdbc取样器
   

下面是一些具体的配置

jdbc:mysql://localhost:3306/test_db?characterEncoding=utf8&serverTimezone=Asia/Shanghai&allowMultiQueries=true&nullCatalogMeansCurrent=true&zeroDateTimeBehavior=CONVERT_TO_NULL

bug调试

变量的使用

html网页中，xpath提取器

查看到的结果如下：

json提取


“data”:"(.*?)"提取花括号中的所有内容
$ 1 $ 返回匹配到的第一组

我的返回结果是

断言

判断结果是否符合预期，符合则正常往下走，不符合则抛出异常

集合点

比如线程组为100，用户组为20，50都可以，最好不要是30，99这些不能整除的
ramp-up线程组启动时间要小于timeout in milles（聚合时间）【以便准确把线程集合起来】

点击运行后可以查看到

命令行使用

jmeter -n -t E:\查询用户-并发测试.jmx -l E:\日志文件.csv -e -o E:\测试报表文件夹

Jmeter命令行参数介绍

元件和组件

性能测试

性能测试

性能测试专业术语
PV=page view
TPS=transactions per second
QPS=queries per second
RPS=requests per second

RPS=并发数/平均响应时间

pv 是指页面被浏览的次数，比如你打开一网页，那么这个网站的pv就算加了一次；
tps是每秒内的事务数，比如执行了dml操作，那么相应的tps会增加；
qps是指每秒内查询次数，比如执行了select操作，相应的qps会增加。

公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。

单台服务器一般是50-70QPS

公司服务器qps是多大（回答的值应该是50-70QPS）（这是单台机器），这不是在问并发（多台机器）。

QPS（TPS）= 并发数/平均响应时间

    一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

事务：从登陆开始到登陆结束【这里面可能包含了验证码请求，用户查询请求，退出登陆请求】

qps也可以说是最大吞吐能力
吞吐量：衡量的指标可以 有多个方面，请求数/秒，页面数/秒—单位时间网络成功传输的数据量

地铁模型【转载自：https://blog.csdn.net/baidu_37964071/article/details/82192792】
假设：
某地铁站进站只有3个刷卡机。
人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。
乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。

场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。

场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。

场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。
那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。

场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s）， 还有3名的“响应时间”为3s（等待2s+进站1s）。

场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时 间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽）。

场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增 加进站的人流与速度（提升TPS、增大连接数）。

场景八：到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、 拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是 在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生

固定吞吐量测试

需求描述：一个用户以20qps的频率来访问服务器，持续10秒钟，查看服务器平均响应时间

线程组循环次数： 20*10=200

目标吞吐量（每分钟吞吐量）：20*（10*60）=1200次

理发店模型