示例一：新业务上线
【业务场景】
公司新作了一个电商服务，近期需要上线，需要提前预估下系统性能表现。
【业务指标】
上线后一段时间内（如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分钟，无异常，系统表现良好。
示例二：活动前容量评估
【业务场景】
春节期间会在微信小程序上做一次抽奖活动（手动点击抽样按钮抽奖），提前预估压力
【业务指标】
- 预计有5w名用户参与活动，同时抽奖的预计达到5000。
- 抽奖活动不可出现异常和数据错乱的问题。
【业务流程】
- 获取微信个人信息（如头像、昵称等），登录小程序；
- 打开活动页面；
- 用户输入要求的个人信息（如商家要求的信息），提交信息；
- 点击抽奖按钮进行抽奖；
- 确认保存中奖信息；
【压测配置信息概要】
资源包购买：因目标是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，发现系统稳定，即压测结束。
