项目分为:
联机组,负责与各交易来源的交易,进行接口开发,信息交互;
批量组,对联机组做出的数据,进行处理,已经日志、等相关业务、技术api等调用;
管理台,对数据库表的整理查询,以及相关技术的便捷开发等;
就拿这次参与的项目来说,甲方对项目重要程度、项目类型震荡型等因素考虑下,选择抽取了不同的指标进行项目非功能技术压测,分为:
1:脚本组:脚本开发老师,和项目开发老师沟通,讨论,各压测交易,怎么样合理的以脚本的方式,对每支交易做出参数话数据,之后以jmter发出交易,之后提交压测组进行压测性能,jmter不能支持太大的性能,以另一个工具进行性能接口压测;
2:联机性能压测组:对联机交易的整理功能压测,压测整个交易链路下的各配置,是否正确,符合指标规范;同时负责对管理台交易的压测(接口少);
3:批量性能压测组:对批量组交易的整体功能压测,压测数据处理、等相关业务;
4:环境组:负责整个非功能环境的服务维护、服务资源监控、压测出现问题,,提供工具进行分析问题,
例如出现位置响应时间突刺问题、内存12小时稳定增长问题,搭建监控探针项目,监控服务器整体资源、线程栈、堆内存、网络、等资源情况,
也负责非功能环境服务f5IP资源等;
5:公共执行组:对项目整体的测试,例如、超时时间、日志、启动时间等测试;
也负责数据库相关指标测试;
6:其余各组,等各dbs、系统管理员等人员提供帮助;
下面展示一些常用的命令、和优化方式:
-- 数据库最大连接数:
select value from v$parameter where name = 'processes';
或服务器查询:
show parameter process'
其中,process 10000(最大连接数)
-- 查询当前连接数
select count(*) from v$pocess
-- 查看阻塞进程,关闭
select * from v$session t1,v$locked_object t2 where t1.sid = t2.session_id;
alter system kill session '38,2023';
压测过程中,出现无法解决的问题时、或者响应时间波动难以排查问题时等,可能会用到线程栈、堆内存、tcp网络等dump来排查问题:
-- 1.当前服务器tcp查看到下一服务器之间的tcp握手、数据处理、挥手等操作dump分析
注:需要到各服务器去执行,一个服务器节点执行一次
-- 1.1 时刻打印tcpdump信息
tcpdump -i eth0 host 110.110.110.110
-- 1.2tcpdump信息输出到日志文件中
nohup tcpdump -i eth0 -nn 'host 10.200.11.11' > /bsts/xsf/log/tcpdump/tcpdump_2022030801.log 2>&1 &
nohup tcpdump -i eth0 -nn 'port 22601' > /bsts/xsf/log/tcpdump/tcpdump_2022030801.log 2>&1 &
-- 2.查询目标IP服务器,和我服务器的连接数
注:服务端会多一条监听线程(以ip监控或者以端口好监控)
netstat -n |grep "1.1.1.1" |awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}';
netstat -nat|grep -i "22601" |wc -1
-- 3.最后一种,查询先出dump,
-- 3.1 项目配置javaopts,配置jdk jvm访问登录
--3.2 服务器实时打印
每5秒生成一个先出栈
while true;do echo "hello"$system_date;
jstack -1 1 > /bsts/log/stackdump/xiangmuming_123_$system_date;sleep 5;
system_date=$(date '+%Y%m%d%H%M%S');done
压测相关注意点
银行部分交易来源用的深证通封装消息传递;类似之前保险行业封装的mq一样,作为消息的传递;
1.需要了解消息在深证通mr里面的停留时间(配置文件配置,默认40秒)
2.压测时,需要了解,:(稍后补充mr13个异常案例,作为了解)
2.1 压测时,如果你不能及时从mr或者mq中接收消息,怎么办,交易难道要让他自己销毁吗?
解决方案:起多个线程的方式,来尽可能多的来接收mr或者mq里面的亲亲贵;
获取交易后,以okhttp连接池异步消费请求;
优化交易,响应时间尽量500ms以内;
2.2 在接收mr或者mq里面交易里,应该时调用一个api来手动获取请求报文;
这时候需要考虑到,高并发时,可以1ms接收一次请求,没有高并发的场景时,1s或者100ms接收一次请求;
3.压测时,毕竟时多个线程进行交易,
理想情况下,一个cpu独赢一个线程(或者cpu大于线程),这样可以保证请求不会过于竞争;
一般情况下,肯定线程数远大于cpu数据,竞争使用资源,最完美的线程数,就是从jvm里看,每一个线程碎片时间、空闲时间很少,没有大量的浪费,那就是完美的,如果线程数据设置过大,浪费内存资源(一个线程1M空间)或者浪费cpu资源(切换线程也浪费上下文资源);
5.脚本开发过程中,发现部分交易因第三方api问题,windows环境发压不高,要用linux环境相关api包,
6.注意fegin线程池数量,(其他文章补充配置)
使用httpclient作为feign的实现,默认线程时10,是否需要增加,看业务进行判断
7.mr作为类似mq的消息传递工具,测试负载策略,(其他文章补充)
8.联机组个服务,线程池配置(随tps不同,可进行占比分配)
server.undertow.io-threads=3
server.undertow.work-thread=64
9.各服务跳转,都可以配置线程池
注意连接数、连接超时时间、响应超时时间;
10.交易整体容量测试,无错误问题,但是cpu不达标,(不考虑增加负载的服务个数,例如仓4台扩到8台)
a.