东莞企业建站平台,专业做婚庆的网站有哪些,哈尔滨服务好的建站方案,wordpress洛米主题一、前言
性能测试之于软件系统#xff0c;是保障其业务承载能力及稳定性的关键措施。以软件系统的能力建设为主线#xff0c;系统能力设计工作与性能测试工作#xff0c;既有先后之顺序#xff0c;亦有相互之影响。以上#xff0c;在性能测试的场景决策#xff0c;架构…一、前言
性能测试之于软件系统是保障其业务承载能力及稳定性的关键措施。以软件系统的能力建设为主线系统能力设计工作与性能测试工作既有先后之顺序亦有相互之影响。以上在性能测试的场景决策架构分析、流量分析、压测实施和剖解调优等主要环节中引发对于系统能力底盘夯实和测试策略改进的诸多思考。
在性能测试阶段剖析系统能力实现及调优方案探索更优解及性能测试策略的提升空间。
二、热点数据存储模型压测实战及思考
通过性能测试推测SKU库存预占场景在不同存储模式下的性能瓶颈及风险。
数据架构升级后SKU库存预占效率TPS提升2300%↑。
测试驱动结合系统实现论证缓存预热的必要性并借助大数据分析探索科学的缓存预热及保温策略。
结合新业务模式思考更加科学的测试数据构建思路和测试过程提效方案。
1、压测场景
库存预占是指在订单接单环节为单据提供SKU库存短暂预留。物流仓配订单接单环节会发起SKU维度的库存预占行为。
库存中心通过“库存预占主应用”中的预占接口对外提供SKU库存预占标准能力。主要通过“库存扣减逻辑管控及数据库层交互”、“缓存层交互”以及“任务调度”三个关键应用承载库存逻辑计算及存储层交互能力。
数据模型视角对预占能力实现分为两种
▪事业部维度库存预占主要通过Redis缓存层承载。
▪批次库存预占直接由数据库承载。
当大促仓配单量进入爆发期热点SKU预占请求快速增长且库存预占请求直达数据库系统TP99会出现跳点甚至持续升高严重情况下造成接单超时。
以上计划针对性构造压测场景及数据模型确认系统的峰值承载能力及调优策略的有效性。
2、首压及分析
◦压测目标“库存预占主应用”下的“预占接口”在数据库承载热点SKU预占请求模式下探索目标TP99≤3000ms可承载的峰值流量并验证调优后的峰值承载能力目标 TP99≤500ms。
◦压测方案单个热点SKU持续发压预占发压起始QPS10并以QPS10递增探索可承载请求的性能上限。
◦压测过程及结论
▪在QPS50时系统可稳定支撑库存预占业务TP99≈100ms。
▪“库存预占”主应用CPU使用率≤15%内存使用率≤35%
▪“库存扣减逻辑管控及数据库层交互”应用CPU使用率≤18%内存使用率≤65%
▪数据库CPU使用率≤7.8%无慢SQL
▪基于当前的系统性能体现具备持续加压的条件。
▪以QPS10递增加压至60时TP99在2分钟左右快速增长至7000ms“库存预占”主应用TPS≤60预判系统能力达到瓶颈停止加压。
“库存预占”主应用 TP99TPS趋势 “库存预占”主应用 硬件资源趋势 数据库 关键指标CPU 数据库 关键指标慢SQL 数据库 关键指标内存 ◦瓶颈预判单据维度的库存预占是以先查可用库存后写预占库存的方式进行在对热点SKU高频次下单过程中数据库会对该行记录长时间持续读写数据库层面会通过行锁机制保证单笔交易的原子性行级锁引发的锁竞争大概率会导致系统处理能力达到瓶颈制约系统的执行效率。同时从应用层到存储层未出现硬件资源瓶颈排除硬件资源不足的影响。
3、调优及复压
◦存储层改造见 库存中心-库存预占场景 系统架构简图经首轮压测及分析为解决已知性能瓶颈从数据架构层面将批次库存预占由数据库直接承载请求压力升级为由Redis缓存主要承载请求压力。利用Redis高性能吞吐能力解决并发场景下的数据读写效率问题由Redis前置承载热点商品的主要流量。
◦一致性保障见 库存中心-库存变化监控机制简图
▪为确保缓存层与数据库层数据一致性在缓存命中的情况下通过建立调度任务或MQ方式异步回写数据库。
▪在缓存击穿时通过先读数据库后写Redis再反馈API预占结果之后异步回写数据库确保数据一致性。
库存中心-库存预占场景 系统架构简图 库存中心-库存变化监控机制简图 ◦复压结论
▪完成数据架构升级及热点SKU缓存预热后初始QPS1100并以100递增TPS上探至1200时TP99≈130ms系统可稳定支撑批次库存预占业务。
▪当TPS上探至1300时TP99出现明显波动毛刺≈420ms且“缓存层交互”应用CPU占用率飙升至90%核心链路稳定性劣化停止加压。
▪相较数据库承载模式缓存化升级后TP99满足预期≤500msTPS承载能力大幅提升2300%(1200-50)/50。
“库存预占”主应用 TP99TPS趋势 “库存预占”主应用 硬件资源趋势 数据库 关键指标(CPU) 数据库 关键指标慢SQL 数据库 关键指标内存 Redis集群 关键指标 4、系统健壮性思考
◦**全量缓存的弊端**供应链模式中的不同行业SKU品类生命周期存在较大差异如服饰行业≈3个月全量缓存模式会导致Redis中存在大量无效品类资源消耗膨胀不可控增加资源成本有必要设计更有效的缓存方案。
◦**缓存预热及保温的必要性**缓存命中率与预热机制和保温策略紧密相关。
▪必要性常规大促节奏起售期会触发首次缓存初始化促销品类与日常销售品类的重合度决定了首次缓存击穿的概率。目前的Key有效期7天大促起售期→开门红→高峰期间隔均大于7天缺少必要的保温策略会增加下个促销节点前缓存失效的可能性。
大促开门红至11.11 缓存命中率趋势
系统整体可平稳承载流量__同时缓存命中率曲线有一定的提升空间 ▪预热思路如何尽可能保持在大促等特定时段的缓存有效性提升缓存命中率降低击穿概率可通过前置的多维度分析调研包括但不限于基于大数据的大促前集中采购品类分布分析、历次大促及关键节点促销品类密度及分布分析 以及 关键客户促销计划调研等方式结合技术手段前置预判、预热及保温。
◦**缓存预热实践**通过对某客户大促前集中采购期及大促节点SKU品类重合度分析发现以下规律
▪集采入视角大促集采期SKU品类相对开门红品类重合度≈69%相对11.11品类重合度≈75%。
▪销售出视角起售期SKU品类相对开门红重合度≈94%开门红相对11.11品类重合度≈75%。
▪以上数据证明通过在开门红以及11.11大促等关键促销节点前将集采期及前一促销期的SKU可用库存数据进行缓存预热有助于提升预占请求的缓存命中率。
大促主要环节 SKU品类重合度分析 ◦**异常场景识别**库存场景对数据三性准确性、及时性、完整性要求较高在数据库与缓存的双向同步过程中需避免因一致性问题引发的业务异常。
▪超卖异常识别大促单量峰值期为保护主数据库安全通过缓存同步限流减缓主库压力造成缓存至数据库同步延迟同一SKU在数据库层未及时扣减如此时叠加缓存Key到期情况接口直接返回MySQL数据可能会引发超卖业务异常。
▪系统优化思路
▪静态方案单量高峰期期间延长Key效期覆盖大促关键环节间隔。
▪动态方案增加热点SKU缓存效期延时策略Key到期T-1天日均预占请求量大于1的SKU自动延长Key有效期。
5、测试策略改进思考
◦场景拓展
▪直播电商模式主流化趋势强劲2023年前三季度全国直播电商销售额达1.98万亿元增长60.6%占网络零售额的18.3%直播电商拉动网零增速7.7个百分点相较传统电商其限时促销模式叠加社交传播扩散属性单品瞬时流量大不同促销场次品类重合度更低促销频次高对系统性能提出了不同的要求。
▪反推性能测试策略从平台视角出发需要尽可能提升选用SKU的多样性同时降低压测单次请求SKU的品类重合度识别真实复杂场景下的性能隐患。
◦效率提升复杂场景的仓配订单性能测试工作需要前置基础数据的大量储备商品、库存以及高复杂度接口请求数据准备。如何确保商品和库存等基础数据快速就绪同时下单请求的报文体根据SKU密度和复杂度需要自动化快速构建组装需要在现有压测框架基础上开发扩展功能以支撑从基础数据到复杂单据的一键快速初始化构造能力降低复杂场景构建难度提升测试工作效率。
三、无效调用量分析、识别及调优实战
在性能测试的流量分析阶段结合业务场景调研前置识别性能瓶颈疑点。
推动排查及调整核心链路调用逻辑后在标定的业务窗口期核心接口调用总量降低60%↓。
深入细分业务场景推演潜在的调优空间。
1、背景
物流系统在订单出库后由 订单明细查询应用提供订单及其关联包裹明细信息的对外查询能力。主要由外部系统Top2量级调用方接入回传67%、履约回传11%调用在单据出库后输出出库货品的数量和包裹详情等订单基础信息。
关键Top2调用方拓扑 2、场景调研及疑点识别
◦场景调研及风险预判生产流量分析
▪对“订单包裹明细查询接口”进行调用量趋势分析取样23年10.12 06:30~23:00流量分析期环比最近一次促销同时段最近一次大促请求高峰期Top2调用方峰值调用总量激增305%。
▪基于前期调研从调用量看常规情况下仓库出库能力均值≈400000单/分钟仓库出库高峰时段为每日08:00~18:00仓出库次数:“订单包裹明细查询接口”峰值调用量≈1:10为“常规比例”。
▪通过对10月12日线上数据观测仓出库次数:“订单包裹明细查询接口”调用峰值400000/6532200≈1:16相较“常规比例”偏差较大。
▪以上通过生产流量分析工作识别出在仓库出库高峰时段“订单包裹明细查询接口” 调用量存在疑点并进一步深入分析。
最近一次促销期 关键应用调用量 2023年10.12 关键应用调用量 ◦调用链粗筛
▪仓配出库单据维度履约回传应用向订单系统推送出库明细时会调用仓明细查询接口。
▪接入回传应用在回传订单信息时会调用仓明细查询接口。
▪履约状态回传调用峰值 / 接入回传调用峰值 ≈ 1:9接入回传调用峰值明显偏大逐步锁定疑点系统接入回传应用。
◦疑点深剖
▪经深入排查首先确认前期对异常流量和疑点系统的判断基本准确。
▪技术架构层面接入回传应用在未判断订单状态情况下调用目标接口。导致单据在未出库且没有出库明细时发生大量无效调用。
▪同时发现因AB测试环境别名配置错误导致生产流量误叠加。
3、调优策略
◦调用逻辑调整
▪“I” 业务场景订单回传阶段如单据状态为出库前不发起“订单包裹明细查询接口”调用剔除无效查询。
▪根据最终的回传内容是否需要明细信息判断调用的必要性剔除非必要查询。
◦调整AB测试环境别名配置避免测试流量对生产环境产生非必要压力。
优化前接入回传应用逻辑 优化后接入回传应用逻辑 4、调优效果
◦相对调优前10.12“接入回传应用” 调用总量降低60%↓前2397252500 后925890100峰值调用量降低64%↓前5921500 后2121800。
下图分别为调整前、后调用量分布用以对比 5、性能风险前置识别
◦压测实施阶段不是发现性能隐患的唯一阶段如果有能力在流量分析阶段识别性能风险并推动论证问题发现越早风控代价资源越小质量风险越低。
6、OpsReview常态化
◦流量异动观测流量分析及性能风险识别需要结合实际的生产运营特征以及接口的关键调用链定义系统调用量的普遍规律。被调用方有必要不断积累识别调用来源和常规量级盘点外部调用策略在调用量出现异动时排查风险。
◦编码规范对于接口调用逻辑有必要抽象为标准方法避免团队协同开发过程中出现因人而异的Coding差异降低无效查询发生概率。
◦定制化逻辑排查系统内非标业务存在较多的定制化逻辑有必要针对特殊逻辑排查无效查询风险。
7、潜在调优空间推演
◦基于测试经验经过业务场景梳理发现 “I场景” 下存在细分的非标定制化流程以及与 “I场景” 并列的 “P场景” 标准流程。
◦联动研发深入分析 “I场景” 中的非标定制化流程 以及 “P场景” 中的标准流程已确认存在进一步优化空间并明确优化方案如下图。 四、总结
性能测试作为系统能力巩固升级的关键措施通过对典型案例的陈述和思考探索系统能力和性能测试策略的提升空间。确保核心系统链路稳定高效承载业务峰值流量同时从容应对极端场景。
作者京东物流 刘锐等
来源京东云开发者社区 自猿其说 Tech 转载请注明来源
