一、压测计划：见压测计划图片
二、压测步骤：
压测步骤：
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文件，进行下载
316
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
