A_60_压力测试
2021-04-14 17:07:35 0 举报AI智能生成
全面、高效的知识图谱：A_60_压力测试!! 全面又深度的提升认知，达到实际应用的目的! 建议先纵观全局，掌握好大方向。 再根据自己的需要，针对性的学习某一个点，最后做到逐步由点及面。
作者其他创作
大纲/内容
数据收集
tomcat status 状态监控
实时监测会话
jvm消耗
CPU
top 实时
内存
nginx
历史时间的请求
具体请求过滤,统计
时间信息提取
制作图表
分支主题
业务数据库
参加人数
每分钟业务情况
异常数据检查(并发,作弊等)
图表制作
图表制作
案例
浙广6套 跨年摇金币
设备结构
阿里云
SLB
ESC -Cent OS
tomcat
ESC -Cent OS
tomcat
ESC -Cent OS.. 5台
tomcat
RDS
规则
19点档
实际人数
1185
总请求数
5665
由于后端请求休息时间差异,此数量没有太大的参考意义
1分钟最高处理请求数
454
20点档
实际人数
834
总请求数
4105
1分钟最高处理请求数
461
21点档
实际人数
473
总请求数
2355
1分钟最高处理请求数
248
22点档
实际人数
302
总请求数
1509
1分钟最高处理请求数
148
23点档
实际人数
213
总请求数
1105
1分钟最高处理请求数
92
24点档
实际人数
85
总请求数
228
1分钟最高处理请求数
81
压测
待收集
实际运营
估算:每s请求数均值
小于总人数(在单人请求间隔>1s情况下)
1185
约等于 总人数/请求休息间隔时间
1185/N
大于 1s最高数据库处理业务数
50
网络受理间隔秒数
总人数/网络队列每s受理数(其实很大,远超过并发人数)
够快的情况下是能超过总人数的. 即此不耗时
子主题 3
依据经验比例估算
wasu 元宵摇红包
实际人数2119
1分钟最高数据库处理业务数 1623
3s请求一次后端
1s最高数据库处理业务数 40
实际峰值每s请求数
500
浙广6套 跨年摇金币
实际人数1185
1分钟最高数据库处理业务数 454
比wasu业务数少,是因为间隔时间长导致(30s请求一次后端)
1s最高数据库处理业务数 50
实际峰值每s请求数
估算出: 500*(50/40)=645
wasu元宵摇红包
设备结构
linux
nginx
tomcat
tomcat
mysql
调优
放大 http连接数
调整JVM 内存至10G (不一定要用这么多,只是机器本身有32G,冗余设计)
应用程序与数据库的连接数 调大
mysql maxThread放大
负载均衡 nginx + 2tomcat
规则
12点档
实际人数1600
1分钟最高数据库处理业务数(接近并发数) 668
1s最高数据库处理业务数 25
20点档
实际人数2119
1分钟最高数据库处理业务数 1623
1s最高数据库处理业务数 40
猜测/预算
压测
分支主题
实际运营
分支主题
图表制作
瓶颈
硬件
CPU
top
内存
free
网络
客户端出口带宽(下载)
宽带下行
服务端入口带宽(上传)
宽带上行
软件
jvm
Catalina.sh -> 4G内存为例
JAVA_OPTS="$JAVA_OPTS -Xms2560m"
JAVA_OPTS="$JAVA_OPTS -Xmx3000m"
JAVA_OPTS="$JAVA_OPTS -XX:PermSize=256m"
JAVA_OPTS="$JAVA_OPTS -XX:MaxPermSize=512m"
应用服务器
tomcat
http连接数
server.xml
maxThreads="2000"
maxProcessors="3000"
acceptCount="3000"
应用连接数据库连接数
工程数据库连接池配置 如:config.properties
maxActivity 连接池的最大数据库连接数
maxIdea 最大空闲数，数据库连接的最大空闲时间。
数据库连接数
mysql
max_connections
1000~5000 并行连接
负载(软件tomcat/硬件CPU,内存)
nginx 软件层均衡
pcre 前置条件
安装
配置
启停
均衡策略#ip hash
gzip压缩
F5 硬件层均衡
分布式可能出现的问题
内存对象不可同步
引入消息同步机制(menmcach等)
上传到服务器本地目录资源(图片等),其它服务不可见
用图片服务器解决
session不可共享
负载策略用 ip hash
分析手段
LoadRunner 11 压测
策略
无休息时间,测试服务器最大极限可受理的请求数
设休息时间,模拟实际用户场景
并发Vuser
模拟实际用户数量
慢慢增长Vuser
观察场景状态中错误情况
分支主题
服务器 500
连接耗尽
应用服务器连接耗尽
数据库连接耗尽
[10060] 连接已超时
具体错误
优先解决,因为此可能影响到其它的参考数值
观察每秒点击次数
300~400 上不去
或
一定程度停止增长
数据库连接数不够
mysql线程数 maxThread
客户端硬件资源不够用了-CPU
服务端硬件资源不够用了-CPU,内存,JVM
下降,服务挂掉
响应时间边长,导致
服务超时
硬件资源上限
tomcat挂掉
办法:单机增加多个tomcat服务,通过nginx配置负载均衡
JVM挂掉
依据原因增加JVM配置内存等
观察tomcat在线用户session数
Max threads: 2000
配合Vuser新增
超过一定数值服务可能会挂掉
Current thread count: 100
上不去了
Vuser只添加了这么多
Vuser数超过当前thread数,说明未同时连接,可能是休息时间或其它原因导致
观察观察吞吐量
压力客户机网上是否100%上线(常见于页面资源加载测试)
服务端带宽上限(上传带宽,宽带上行)
观察-事务响应时间(含自定义的休息时间)
单次请求消耗时间
理想:1s内响应,图表稳定(直线)
分支主题
此图测试设置了2s休息时间.可见响应时间稳定且响应时间0.5s内
Vuser同时进入
监控目标
Vuser上升曲线
事务响应时间(含自定义的休息时间)
每秒点击次数
可结合同时刻Vuser数量,比较每秒点击数,可分析出1s成功请求用数量
无休息时间
每个用户1s内可能有多次连接
每秒点击次数可能超过同时在线人数
设休息时间
因设休息时间(如:2s),同时请求的用户在1s内只有1/2的人在请求服务器
此时每秒点击数为同时刻最大Vuser的一半
吞吐量
网络资源消耗 如:每秒100MB
单页面消耗网络资源,流量 会在录制脚本时,编译后日志中体现
用户并发打开网页,加载大量资源时观察
依据压测
评估服务器可支撑的并发数
设定Vuser人数,预测的请求休息时间
观察事务响应时间正常 即可支撑
仅设定参考Vuser人数,不设置休息时间
观察事务响应时间是否正常
不正常,响应太慢,则调整Vuser参考人数
正常,再放大Vuser人数
最大的Vuser人数和最大的每s请求数,都可转换为平台可支撑的 实际并发人数
LoadRunner 11 参考配图
压测.愿望接口,两个tomcat,3000
linux服务器 状态检查
CPU
内存
磁盘
网络
tomcat 状态检查
最大并发,当前并发
JVM内存
jvisualvm JVM监控
预测: 每s请求数
准备数据
预计参加人数
预计并发人数
每次请求休息时间s
最大值(在单人请求间隔>1s情况下)
预计并发人数
约等于值
预计并发人数/每次请求休息时间s
扩展
已知每s请求数/并发人数
估算请求间隔时间
小于等于
并发人数/每s请求数=平均每人每s请求数
预算硬件
=目标并发人数/单服务器并发数
解释词
每次请求休息时间s[操作间隔时间+请求处理时间]
1分钟最高数据库处理业务人数 (接近并发人数)
并发数 = 每s请求数 = 没s点击数
0 条评论
下一页
