针对此次库内作业性能测试,梳理一下期间的工作流程
第一步:梳理脚本
梳理已有的接口脚本,确认需要做性能测试的几个接口,即使用率高,对性能有要求的几个主要接口。
第二步:熟悉业务
结合页面的操作,和确认的接口,梳理具体的业务逻辑
第三步:环境部署
同时,请开发人员部署了测试环境。
测试环境的服务器指标,尽量和生产环境一致。
部署的时候,负载均衡等情况也尽量和生产环境一致。
由于服务器成本问题,此次只做到了指标一样,但部署情况做了调整,各个服务各一台,webapi部署了两台。
施压机器的确定:此次的施压机和部署的服务都是在云上,不存在带宽限制。
如果施压机在本地windows上,部署服务在云上,就会有带宽问题。
第四步:基础配置
部署测试环境后,要做基础配置。有分两个部分。
开发人员做一部分基础配置。
测试人员做一部分,仓库的,货品的,库区的,等基础数据的配置。
第五步:造数
造基础数据
造了6个不同类型的商品,通过新建入库单和出库单的操作,各自库存有1千万
造了100万个出库单,每个出库单有6个商品
造了几千个波次,每个波次有100个出库单
其中,造数也是通过跑脚本的方法进行。
所以,最终的结果:1个波次,100个出库单,其中1个出库单包含6个不同的商品。
第六步:调试脚本
对于请求中,明细条数比较多的情况,脚本的处理。
然后测试数据的处理。
先是 select 出库单 from 出库表 limit 1,10000
然后使用下面这个公式分100列
=INDIRECT("A"&100*ROW(A1)-99+COLUMN(A1))&""
从C1开始,直到CX,是100列,再把分好列的数据重新粘贴到新的excel里
然后,另存为
备注:到AF 30列,AP 40列,HZ 50列,BJ 60列,BT 70列,CD 80列,CN 90列,CX 100列
第七步:执行脚本&&分析
依次执行脚本,通过并发数的增加,查看 tps,cpu,io的情况
第八步:监控指标&&做记录
使用命令:
top: cpu,内存的情况,wa值等
iftop: 查看流量的进出情况
iostat 2 100: 网络进出情况,每2秒一次,记录100次
在每次跑脚本之前,可以先使用nmon ,记录10分钟内的服务器性能情况
nmon -s10 -c100 -f -m /home/
之后根据grafana上的结果查看信息
第九步:慢sql配置&&记录
慢查询的配置
vi /etc/my.cnf
分别表示:打开,存储的位置,阈值,没有建立索引的也不记录
每次执行脚本前,可以先清空慢查询记录
这样得到的就是此次执行job,所导致的慢查询了。
第十步:报告
重要指标要单独发到邮件中。
服务器处理能力:TPS结果集中
响应时间:多数业务的平均响应时间都超过
并发能力:多数业务场景的并发数为1时,数据库都存在明显的读写等待。并发处理能力差。
第十一步:性能优化策略
先是,慢sql的优化
再是,问题最严重的服务器,指标提升
最后,梳理业务,业务层面做优化