阿里中间件团队 + 关注
手机版

PTS 有奖征稿活动官方示例

  1. 云栖社区>
  2. 阿里中间件团队>
  3. 博客>
  4. 正文

PTS 有奖征稿活动官方示例

中间件小哥 2019-01-17 14:24:28 浏览1128 评论2

摘要: 示例一:新业务上线 【业务场景】公司新作了一个电商服务,近期需要上线,需要提前预估下系统性能表现。 【业务指标】上线后一段时间内(如1个月)预计秒级 浏览:加购:生成订单:支付的比例为10000:8000:6000:5500 的比例。

示例一:新业务上线

【业务场景】
公司新作了一个电商服务,近期需要上线,需要提前预估下系统性能表现。

【业务指标】
上线后一段时间内(如1个月)预计秒级 浏览:加购:生成订单:支付的比例为10000:8000:6000:5500 的比例。能够正常走通流程,下单不出现异常情况。

【业务流程】

  • 登录—登录信息来源于文件参数
  • 浏览商品—商品信息随机数生成
  • 加购—添加到购物车,添加的商品由上一个接口输出
  • 生成订单---购物车中部分商品合并结算,商品id,随机生成
  • 支付订单—支付订单,订单由上一个接口输出

【压测配置信息概要】
资源包购买:因目标是各api的rps 之和为29500,故购买最大4wrps的包。
业务上是一个流式过程,故放在一个串联链路中,按照业务模型进行API配置:

接口:login,输入参数:username、password,来源文件参数
接口:viewProduct,输入参数:productId(系统函数生成),输出参数:productId
接口:addToCart,输入参数:productId
接口:createOrder,输入参数:productId1,productId2,出参:orderId
接口:payOrder,输入参数:orderId,出参:result

压力配置:RPS模式,每个API按照10000:8000:6000:5500的最大RPS配置,起步设为5%
监控信息:云监控集成(服务部署在阿里云上,使用了ECS/RDS/SLB都进行了监控),因服务不是java的无法使用ARMS监控

【压测过程及结论】
首次压测的时候,全局调速30%的时候,发现RT不高但是失败率特别高,根据云监控发现SLB中拒绝链接的请求很多,发现是SLB的规格限制,扩大slb的容量后继续压测。第二次压测在,调速到50%的时候,发现RT比较高,特别是加购、订单生成的API上,根据RDS监控发现CPU内存使用率比较高,到RDS控制台的CloudDba上看到有慢SQL,排查之后再进行压测调速到80%时,发现整体系统负载水位较高,偶尔会出现rt很高的请求,需要进行一次扩容再继续压测,按照比例扩容后,调速到100%压测,并持续运行10分钟,无异常,系统表现良好。



示例二:活动前容量评估

【业务场景】
春节期间会在微信小程序上做一次抽奖活动(手动点击抽样按钮抽奖),提前预估压力

【业务指标】

  1. 预计有5w名用户参与活动,同时抽奖的预计达到5000。
  2. 抽奖活动不可出现异常和数据错乱的问题。

【业务流程】

  • 获取微信个人信息(如头像、昵称等),登录小程序;
  • 打开活动页面;
  • 用户输入要求的个人信息(如商家要求的信息),提交信息;
  • 点击抽奖按钮进行抽奖;
  • 确认保存中奖信息;

【压测配置信息概要】
资源包购买:因目标是5000 并发用户,为了给系统留一些buffer,购买了1w并发资源包,技术上预计系统承载6k-7k的并发位置。
业务上是一个流式过程,故放在一个串联链路中,按照业务模型进行API配置:

接口:getConfig,输入参数:uid,出参:nick_name
接口:activity_page
接口:post_info,输入参数:nick_name/interest_info
接口:lottery,输入参数:nick_name,出参:lottery_result
接口:check_result,输入参数:is_get_prize,出参:result

压力配置:并发模式,自动递增,场景并发5000,起步5%
监控信息:ARMS监控集成(因自身服务不部署在阿里云上,故无法使用云监控)

【压测过程及结论】
首次压测的时候,在并发2000时,出现了比较大的失败率,RT也达到了1000+ms,根据Timing瀑布流及业务信息排查发现,是入口队列较小,排队情况较多导致的。进行了扩容处理,第二次压测在3000并发时,在抽奖API上RT很大,结合Timing和ARMS监控,看到是在数据库操作上比较慢,并且有慢SQL,优化表、和SQL之后,再进行压测。优化后并发在4000时,发现系统压力较大,cpu 和内存使用比例较高,进行扩容之后,再继续压测。扩容后再压测5000并发时,发现API平均RT在800ms左右,CPU消耗在40% 左右。为了留足系统buffer,进行适量扩容之后,压测到6000,发现系统稳定,即压测结束。



【云栖快讯】一站式开发者服务,海量学习资源免费学  详情请点击

网友评论