文章目录
注意，受到本地主机的带宽，cpu核心数，磁盘空间影响，建议服务器压测
配置线程数
设置http请求
设置请求头信息
设置断言
察看结果树
每个线程300ms后执行
配置计数器变量引用
https://wjqwsp.github.io/2016/08/29/jmeter%E5%8E%8B%E5%8A%9B%E6%B5%8B%E8%AF%95%E5%9F%BA%E7%A1%80/
汇总报告
压测结果
qps限制器
Constant Throughput Timer 的主要属性介绍：
名称 ：定时器的名称
Target throughput（in samples per minute）：目标吞吐量。注意这里是每分钟发送的请求数，因此，对应测试需求中所要求的20 QPS ，这里的值应该是1200 。
Calculate Throughput based on ：有5个选项，分别是：
This thread only ：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的 target Throughput 乘以矣线程的数量。
All active threads ： 设置的target Throughput 将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
All active threads in current thread group ：设置的target Throughput将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和All active threads选项的效果完全相同。
All active threads （shared ）：与All active threads 的选项基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
All cative threads in current thread group （shared ）：与All active threads in current thread group 基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。
如上图，该元件仅作用于fnng.cnblogs.com ，设置定时器的Target throughput为1200/分钟（20 QPS），设置Calculate Throughput based on 的值为All active threads 。
当然，Constant Throughput Timer只有在线程组中的线程产生足够多的request 的情况下才有意义，因此，即使设置了Constant Throughput Timer的值，也可能由于线程组中的线程数量不够，或是定时器设置不合理等原因导致总体的QPS不能达到预期目标。
设置常数吞吐量定时器
java.net.BindException: Address already in use: connect
问题描述：在window环境下使用JMeter进行高并发压测时，会出现在压测一段时间后，忽然JMeter僵死出现大量的java.net.BindException Address already in use报错
问题原因：window本地的连接数不够用（相当于tcpip连接配置没有调优）
问题解决：
1.cmd中，用regedit命令打开
表
2.在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下，
1）右击parameters，添加一个新的DWORD，名字为MaxUserPort
2）然后双击MaxUserPort，输入数值数据为65534，基数选择十进制
3.同时建议也修改Time_Wait参数
添加名为TcpTimedWaitDelay的DWORD键,设置为30,以缩短TIME_WAIT的等待时间
4.一定要记得重启电脑（修改完成的后，单台服务器可以支持1.5-2K的并发/TPS压测）
https://blog.csdn.net/wxlbrxhb/article/details/38817089
https://www.cnblogs.com/dwdw/p/10818524.html
https://www.cnblogs.com/imyalost/p/6004678.html
mysql sleep线程数过多
原因
造成睡眠连接过多的原因？
1. 使用了太多持久连接（个人觉得，在高并发系统中，不适合使用持久连接）
2. 程序中，没有及时关闭mysql连接
3. 数据库查询不够优化，过度耗时。
show global variables like’wait_timeout’;
SHOW VARIABLES LIKE “%wait_timeout%”;
set global wait_timeout=30;
SHOW FULL PROCESSLIST;
SHOW PROCESSLIST;
SHOW global VARIABLES LIKE “interactive_timeout”;
SHOW VARIABLES LIKE “interactive_timeout”;
set global interactive_timeout=30;
mysqladmin -h10.0.0.1 -pxxx processlist | grep xxxx | awk ‘{print $2}’ | egrep ‘[0-9]’ | xargs -i mysqladmin -h10.0.0.1 -udev -p’xxx’ kill {}
配置websocket
下载插件管理器
lib/ext 插件放置地方
https://jmeter-plugins.org/install/Install/
1、Streaming Connection 勾选与否的影响
线程组设置 1 个并发，循环 2 次。
2 个 websocket sample 请求都不勾选 Streaming Connection
发现每次请求都会 opening new connection。
](https://testerhome.com/uploads/photo/2018/ee3d0370-ef38-4376-9d2c-9f8b18cd21b9.jpeg!large)
都勾选
发现 4 个请求都在同一个 connection 中
1、WebServer
（1）Server Name or IP：WebSocket 发送的目标服务器的地址或者名称
（2）Port Number：WebSocker 服务器监听的端口号。
2、Timeout:
（1）Connection 发送一个连接请求后，Jmeter 等待连接完成的最长时间，单位是毫秒。
（2）Response 对响应消息的最大等待时间。
3、WebSocket Request
（1）Implementation：只支持 RFC6455(v13) ，WebSocket 协议标准的最新版。
（2）Protocol：有 ws 与 wss 之分， ws 前缀是 WebSocket 连接的辨别标识，wss 前缀是 WebSocket 安全连接的辨别标识。根据自己的实际情况填写
（3）Streaming Connection ：TCP session 要不要保持，如果勾上标识连接会一直存在，如果没有勾上，那么得到第一次响应后该链接就会被关闭。
（4）connection id：会话的 id 标志。
（5）Request data：填入将要发送的请求，要跟开发沟通好，这个是什么格式的消息。
4.WebSocket Response
（1）Response Pattern – 采样器将等待含有该标识的消息并继续通信（或者直到 timeout，该连接关闭）
（2）Close Connection Pattern – 如果服务器返回的消息含有这样的字符，就结束会话。
（3）Message Backlog – 定义服务器返回消息保留的最大长度。
因此，当勾选了 streaming connection 时，不仅会在结束会话后保留连接，而且勾选了的 sampler 会在有可用连接是直接使用，而没有勾选的 sampler 即使存在可用连接也会重新打开一个新的连接。因此，如果是要在一个会话中发送多条消息，请勾选这个 streaming connection。
https://bitbucket.org/pjtr/jmeter-websocket-samplers/downloads/
下载websocket插件
websocket连接直接断开
netstat -ano 发现大量线程
分别查看2个pid
netstat -ano|findstr 46888
ARMS接入
找到耗时接口
点击traceId
点击详情
点击方法栈，找到耗时方法
发现数据库地响应很快，分析堆栈信息
数据库情况
找到原因
主要是争抢jdbc连接资源，造成大量线程阻塞睡眠
解决方法
- 加机器，分摊压力（治标不治本）
- 优化项目线程数(需要知道数据库最大线程数配置多少，以及数据库对多少个服务进行提供，否则线程数配置过多，造成数据库线程不够，其它服务可能就线程资源没有了)
压力主要集中在mysql
方案一：引入redis，减少数据库读的压力，但是影响范围比较广。
方案二：目前读写都在同一个数据库，造成单库压力过大。加库。但是影响面比较广，比如还要考虑读库同步问题。
方案三：提升数据库性能。
配置数据库连接数
查看HikariConfig 数据库连接池
com.zaxxer.hikari.HikariConfig#validateNumerics
可以看到默认10个
重新压测，发现吞吐没变。但是响应时间缩短一半。90%线程898响应。这个结果好了很多。
查看链路可知是因为线程过多，造成数据库争抢，所以相对应的数据库反而延迟了。
仔细思考为什么线程数修改了，吞吐没变。主要是tomcat只能同时处理200线程数。
优化tomcat
优化JVM
堆4G，采用cms吞吐回收器
解决方案：
压测
使用长连接，多机器压测
原因分析：tomcat连接数不够
jmeter卡住不动
压测机不行，处理不了。造成大量阻塞连接超时。tomcat平均响应20ms，能处理过来。
找到一个没调用数据库的接口去压测，发现无法突破1400瓶颈，是网关问题。直接访问tomcat，单机并发3000+。但是无法在继续上去，原因是带宽问题造成的。为验证猜想，于是本地启动。拿三台机器压测，并发6000+。
问题：k8s网关。
1.修改jmeter.bat并重启，将其中的set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m进行更改。这个是最常见的解决方法。原理是线程卡死的原因是堆溢出导致，因此降低最小内存Xms，提升最大内存Xmx，注意Xmx>=Xms，Xms可修改范围256m，512m，1g等，对应的Xmx可修改范围为256m，512m，1g等。
2.在HTTP请求默认值中，设置响应超时(Response)以及连接超时(Connect)，单位是毫秒。原理是，当http请求的连接时间以及响应时间超过了所设置的响应超时(Response)以及连接超时(Connect)时，将该请求标记为err以处理线程卡死并处理下一条http请求。
3.减少后台应用，节省内存用于jmeter接口压力测试。关闭jemerGUI，仅仅保留cmd命令行以及goland服务端，重复上述步骤。结果依然无效。
4.关闭goland启用服务端，使用git bash开启服务端；关闭jemerGUI，仅仅保留cmd命令行；重装jmeter，保留原始设置**(不设置最小内存以及最大内存，不设置超时)**；桌面仅保留cmd命令行，其余窗口全部最小化。
优化参数
tomcat
server.tomcat.max-threads 400
server.tomcat.min-spare-threads 100
.datasource.primary.maximumPoolSize 200
数据库
set global wait_timeout=30;
set global interactive_timeout=30;
压测机
提升端口限制
提升销毁空闲tcp时间
其它
max-connections: 200 # 默认值 max-connections-per-route: 50 # 默认值
feign.httpclient.max-connections = 2000
feign.httpclient.max-connections-per-route = 50
hystrix.threadpool.default.maxQueueSize =
hystrix.threadpool.default.coreSize =
解决方案
硬件层面
- 提升tomcat连接数
- 提升mysql连接数
- 提升ebean连接数
- jvm不需要调优
- 提升数据库性能，加资源，加库。
- 提升网络带宽
server.tomcat.max-threads 400
server.tomcat.min-spare-threads 100
xxx.datasource.primary.maximumPoolSize 200
代码层面
- 引入redis，减少数据库读的压力，但是影响范围比较广。(过期时间设置短点)
- 数据库读写分离。缺点需要维护同步状态。另外需要注意，在同步数据期间，会存在redis缓存不一致情况。
- 异步任务解耦
其它
提高gateway并发量
LB和k8s也要看看是不是这块限制了(感觉还是带宽受限)
生成报告
jmeter -n -t D:\apache-jmeter-3.2\bin\test1.jmx -l result.jtl -e -o D:\abc\HttpReport
# -n：以非GUI形式运行Jmeter
# -t：source.jmx 脚本路径
# -l：result.jtl 运行结果保存路径（.jtl）,此文件必须不存在
# -e：在脚本运行结束后生成html报告
# -o：用于存放html报告的目录
dashboard
charts
Over Time
①、Response Times Over Time（脚本运行期间的响应时间变化趋势图）
说明：可以根据响应时间和变化和TPS以及模拟的并发数变化，判断性能拐点的范围。
②、 Response Time Percentiles Over Time (successful responses)
说明：脚本运行期间成功的请求响应时间百分比分布图，可以理解为聚合报告里面不同%的数据，图形化展示的结果。
③、Bytes Throughput Over Time（脚本运行期间的吞吐量变化趋势图）
说明：在容量规划、可用性测试和大文件上传下载场景中，吞吐量是很重要的一个监控和分析指标。
④、 Latencies Over Time（脚本运行期间的响应延时变化趋势图）
说明：在高并发场景或者强业务强数据一致性场景，延时是个很严重的影响因素。
Throughput
①、Transactions Per Second（每秒事务数）
说明：每秒事务数，即TPS，是性能测试中很重要的一个指标，它是用来衡量系统处理能力的一个重要指标。
Response Times
①、 Response Time Percentiles（响应时间百分比分布曲线图）
说明：即响应时间在某个范围内的请求在所有请求数中所占的比率，相比于平均响应时间，这个值更适合用来衡量系统的稳定性。
②、Time Vs Threads（平均响应时间和线程数的对应变化曲线）
说明：可以通过这个对应的变化曲线来作为确定性能拐点的一个参考值。
压测结果
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8IRRtahz-1623236549384)(C:\Users\GIGA25\AppData\Roaming\Typora\typora-user-images\image-20210608125457413.png)]
12台机器压测
lb问题
发现加机器后，吞吐也上不去。怀疑lb问题。找了腾讯客服，
可能是源ip问题。于是分别从张家口阿里云机房和上海腾讯云机房找到了4台机器，进行压测。直接飙升吞吐。
1799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
