一、压测计划:见压测计划图片
二、压测步骤:
压测步骤:
uat环境调试数据准备:
压测商品数据:
http://richemont-bs-dunhill-web-uat.cloud.bz/product?id=DU21RPP9011&code=DU21RPP9011_0
dunhill压测用户:
11000000000~11000001000
密码: a12345678
压测前准备工作:
准备10个sku压测商品,编写jmx压测脚本
准备1000个用户,如果用分布式压测,需要将用户文件进行切割分配,这样才能保持真实的用户登录场景
1、打开unex 针对 dunhill 租户的限流。-- @敬磊
2、压测期间,订单不能下发 给下游系统。-- @敬磊
3、关闭 发送邮件,短信功能-- @李守群
4、商品检查,确保能下单,库存足够-- @王鹏飞
jmeter脚本编写done
1. 中文字符参数化 已修改(发送请求时写好内容编码格式为utf-8)
2. 录制时不要使用GraphQL HTTP REQUEST 已修改
3. 使用简单控制器分好模块 已修改
4. 模块下用例加上编号和名称 已修改
5. 后端监听器 influxdbUrl修改为influxdb url地址和数据库 http://10.11.14.100:8086/write?db=gap measurement
influxdbUrl http://host_to_change:8086/write?db=jmeter 已修改
measurement jmeter 已修改
6. 放压测平台上 用户文件 需要修改 #将脚本jmx文件和参数化csv文件放在同一目录下
7. 修改压测商品数据,商品库存为100w
8. 全局断言 已修改 断言使用response code
如果grafana配置了jmeter dashboard 全局断言加上${__groovy(if(prev.getResponseCode()!="200"){prev.getResponseCode()+" "+prev.getResponseMessage()}else{prev.getResponseDataAsString()})}
9. 关键接口断言 已修改 断言使用唯一值断言 实在不行,使用字符串包含
如果grafana配置了jmeter dashboard 全局断言加上${__groovy(if(prev.getResponseCode()!="200"){prev.getResponseCode()+" "+prev.getResponseMessage()}else{prev.getResponseDataAsString()})}
10.jmx脚本压测并发时碰到错误 ,在取样器错误后要执行的动作 ->选择启动下一进程循环。
比如登录接口放在仅一次控制器,如果登录出错,下面的token失效时,所有接口都会报错,此时勾选【启动下一进程循环】下面的请求就不会再次执行 #注意啦注意啦注意啦
11.针对录制含有http graphql requests请求时 jmeter5.0版本及一下,请求参数参数化后,数据会和转义的数据穿插不兼容,此时需要修改请求参数,将请求参数\\\全局替换为\\\\\
12.jmeter各版本之间的区别可能会产生不同的现象
1.jmx在低版本能打开,高版本打不开
2.http graphql requests 高版本有http graphql requests,如果录制的时候不想抓取http graphql requests请求,可以在录制页面取消勾选detect graphql request
#第11条案例
{"operationName":"orderCreate","variables":{},"query":"mutation orderCreate {\n orderCreate(\n input: {terminal: PC, platformSource: OFFICIAL_SITE, orderLines: [{skuCode: \"${skuCode}\", name: \"测试数据\", quantity: 1, lineType: SALABLE_PRODUCT, image: \"https://scm-dam.oss-cn-shanghai.aliyuncs.com/scm-dam/2021-07-25/2w1125_be4e4e4_420449f0-e87f-47c4-a474-b22fd82dc76a.jpg\", skuProperties: \"{\\\\\"size\\\\\":\\\\\"XXXL\\\\\",\\\\\"color\\\\\":\\\\\"墨色\\\\\"}\"}], additionalServices: [], receiptInfo: {country: \"中国\", countryId: \"1\", province: \"江苏省\", provinceId: \"320000\", city: \"南京市\", cityId: \"320100\", district: \"市辖区\", districtId: \"320101\", address: \"马陆测试数据23333\", mobile: \"${mobile}\", name: \"张凯\", distributionType: EXPRESS, logisticsCompanyCode: \"SF\"}, distributionType: EXPRESS, extInfos: \"{\\\\\"payType\\\\\":\\\\\"ALIPAY\\\\\",buyInfoMobile: \\\\\"11000000008\\\\\",}\", productAmount: {amount: 1, currencyCode: CNY}, amount: {amount: 1, currencyCode: CNY}, coupon: {amount: 0, currencyCode: CNY}, discount: {amount: 0, currencyCode: CNY}, tax: {amount: 0, currencyCode: CNY}, giftCard: {amount: 0, currencyCode: CNY}, freight: {amount: 0, currencyCode: CNY}, additionalServiceFee: {amount: 0, currencyCode: CNY}}\n ) {\n order {\n code\n orderCode\n __typename\n }\n __typename\n }\n}\n"}
该案例脚本见文件:
dunhill_ordersimple_test.jmx
dunhill_order_2.jmx (该脚本未应用于实际压测)
dunhill_mix .jmx
三、性能测试报告:
性能测试报告:
#除了JMeter dashboard监控、richemont官网资源dashboard监控 监控数据之外,还需要关注数据流向,那么久需要关注中间件,是否有中间件监控,监控数据是否正常
#用户页面访问发送请求经历了哪些步骤:
1,前端请求->建立连接->官网前端Pod
2, 后端请求->建立连接->官网后端Pod ->Open网关Pod(判断环境,比如判断是否是灰度环境)
1, 后端请求->建立连接->(通过graphql传递信息)官网后端Pod ->Service(BFF)->消息分发->队列->UNEX ->DB 等一系列步骤,我们就需要把已有安装监控的情况进行查看
1.压测场景:
JMeter阶梯式压测
场景设置:1台控制机(负载生成系统:Linux version 3.10.0-693.11.1.e17.x86_64)2台施压机
一、最简创单流程
(控制机1台,压力机2台,所以脚本写的并发数*2)每1分钟增加20*2=40虚拟用户,到达200虚拟用户后持续5分钟
压测时间:2021-10-25 18:52~19:02;
JMeter dashboard监控: 用户名/密码:user/123456
https://optimize.monitor.baozun.com/d/IT_jVc8mz/test?orgId=1&from=1635159120000&to=1635159720000&var-data_source=udpDatabase&var-application=All&var-transaction=$%7Brname%7D189%20%2Fproduct%2FCHC21AS605F01&var-measurement_name=jmeter&var-send_interval=5&var-aggregation=30s
JMETER监控关注:[All]
截图1 【请求接口90%响应时间、TPS、错误率】 =======>聚合报告
截图2 【Transactions Response Times (avg) & Thread】 =======>大部分用户响应时间,根据曲线图得出结论
截图3 【Total Throughput】 =======>查看TPS是否整体比较平稳,查看整体平稳TPS最高值
richemont官网资源dashboard监控: 用户名/密码:dev/dev123 http://grafana-bz-openshift-monitoring-sit.app.cloud.bz/d/hzGk-9qmkjkhx/ocp-project-deployment-pod-summary?orgId=1&from=1635159120000&to=1635159720000&refresh=1m&var-Namespace=uat&var-Project=richemont&var-App=richemont-dunhill-bff-api
Desired Replicas:容器化的,服务器俩个节点 4C4G
切换APP查看关注对象:
[App(richemont-bs-dunhill-web)] 前端CPU使用率 [APP pods使用CPU核心数(每pod)]
[App(richemont-dunhill-bff-api)] 后端CPU使用率 [APP pods使用CPU核心数(每pod)]
服务器节点监控关注:
截图1 【App pods使用CPU使用率】 =======>查看服务器节点使用CPU占比
持续压测10min
场景设置:1台控制机(负载生成系统:Linux version 3.10.0-693.11.1.e17.x86_64)2台施压机
二、混合场景:创单流程(登录->加购->结算->创单->订单查询) 页面压力占比
创单 10%Vuser
PDP页面访问 30%Vuser
PLP页面访问 30%Vuser
Homepage访问 30%Vuser
(控制机1台,压力机2台,所以脚本写的并发数*2)200*2=400虚拟用户,(Rame-Up时间1S)1S内启动,(调度器配置-持续时间600s)持续压测时间10min
压测时间:2021-10-25 19:58~20:08 & 2021-10-25 20:21~20:31;
JMeter dashboard监控: 用户名/密码:user/123456
https://optimize.monitor.baozun.com/d/IT_jVc8mz/test?orgId=1&from=1635163080000&to=1635163680000&var-data_source=udpDatabase&var-application=All&var-transaction=$%7Brname%7D189%20%2Fproduct%2FCHC21AS605F01&var-measurement_name=jmeter&var-send_interval=5&var-aggregation=30s
JMETER监控关注:[All]
截图1 【请求接口90%响应时间、TPS、错误率】 =======>聚合报告
截图2 【Transactions Response Times (avg) & Thread】 =======>大部分用户响应时间,根据曲线图得出结论
截图3 【Total Throughput】 =======>查看TPS是否整体比较平稳,查看整体平稳TPS最高值
richemont官网资源dashboard监控: 用户名/密码:dev/dev123 http://grafana-bz-openshift-monitoring-sit.app.cloud.bz/d/hzGk-9qmkjkhx/ocp-project-deployment-pod-summary?orgId=1&from=1635163080000&to=1635163680000&var-Namespace=uat&var-Project=richemont&var-App=richemont-dunhill-bff-api
Desired Replicas:容器化的,服务器俩个节点 4C4G
切换APP查看关注对象:
[App(richemont-bs-dunhill-web)] 前端CPU使用率 [APP pods使用CPU核心数(每pod)]
[App(richemont-dunhill-bff-api)] 后端CPU使用率 [APP pods使用CPU核心数(每pod)]
服务器节点监控关注:
截图1 【App pods使用CPU使用率】 =======>查看服务器节点使用CPU占比
2.压测分析总结:
2.1 UAT环境中最简创单流程下,创单性能为每秒87单,大约每小时能创建31W单
2.2 混合场景中,总TPS大约在370(JMETER dashboard监控 截图3获取)左右,大约每小时能处理130W左右的请求,大部分请求90%平均响应时间在3-5S左右
2.3 混合场景中,大约能处理 8W UV/小时 #Page View(PV) Unique Visitor(UV)
2.4 压测过程中2台BFF SERVER 的CPU占用在90%左右,DB&UNEX相关server的CPU和内存占用均在50%以下( 1, 后端请求->建立连接->(通过graphql传递信息)官网后端Pod ->Service(BFF)->消息分发->队列->UNEX ->DB 等一系列步骤,我们就需要把已有安装监控的情况进行查看)
PS:由于正式上线后负载的情况可能会有差异,相应的处理能力数据也会有所浮动
四、压测邮件
Hi all:
网关问题已经解决,以下为本次dunhill 3个场景压测的结果和分析:
压测时间:2021-10-25 18:52~19:02;
压测环境:UAT环境;
压测场景:最简创单流程(Login-加购-创单)持续10分钟
线程数:200;
压测结果:
1. 最简创单场景在200vuser下,每秒创单的数量为87单,每小时大约能够创建31W单;
2. orderCreate请求90%的平均响应时间为2.39秒
3. 压测过程中2台dunhill bff server的CPU占用均在90%左右,JVM的CPU LOAD在15左右;
richemont-JVM资源监控:dunhill:
http://10.90.81.183:3000/d/LWRt_usGk5/ric-dunhill-jvmjian-kong-zhi-biao?orgId=1&refresh=30s&from=now-15m&to=now&var-Namespace=uat&var-application=dunhill-bff-api&var-instance=10.102.160.148:9091&var-jvm_memory_pool_heap=All&var-jvm_memory_pool_nonheap=All
#richemont-JVM资源监控关注:JVM Misc->CPU Usage - CPU 使用率(根据曲线图查看系统CPU使用率)
分析排查:通过对jstack初步分析 可能和log4j相关的配置优化有关;
解决方案:待开发进一步对jstack文件分析排查(jstack见附件);
-----------------------------------------------------------------------------------------------
压测时间:2021-10-25 19:58~20:08 & 2021-10-25 20:21~20:31;
压测环境:UAT环境;
压测场景:混合场景(创单10%;PDP 30%;PLP 30%;HOMEPAGE 30%)持续10分钟
线程数:400 & 600;
压测结果:
1. 400vuse和600vuser两个场景下,总TPS平均都在370左右,大约能够处理130W请求/小时;
2. 大部分请求的90%平均响应时间在3-5秒左右;
3. 压测过程中2台dunhill bff server的CPU占用均在90%左右,JVM的CPU LOAD在20左右;
richemont-JVM资源监控:dunhill:
http://10.90.81.183:3000/d/LWRt_usGk5/ric-dunhill-jvmjian-kong-zhi-biao?orgId=1&refresh=30s&from=now-15m&to=now&var-Namespace=uat&var-application=dunhill-bff-api&var-instance=10.102.160.148:9091&var-jvm_memory_pool_heap=All&var-jvm_memory_pool_nonheap=All
richemont-JVM资源监控关注:JVM Misc->CPU Usage - CPU 使用率(根据曲线图查看系统CPU使用率)
分析排查:通过对jstack初步分析 可能和log4j相关的配置优化有关;
解决方案:待开发进一步对jstack文件分析排查(jstack见附件);
PS:附件为本次压测的详细数据记录和jstack分析日志。
该案例附件见文件:
压测邮件附件内容.rar(1.dunhill_record.xlsx
2.jstack_2021.10.25.202840
3.jstack_2021.10.25.202852)
PS:Jstack文件是在小蜜蜂->应用服务->压测环境API节点先生成Jstack文件,进行下载