性能实战之需求分析阶段

目前正在做性能项目，加上之前在极客时间的课程学习，准备把实施的过程记录并提炼下。

性能工程

第一次见“性能工程”这词是在高楼老师的课程里，老师把一个性能项目从“测试”引到“工程”的级别，因为性能工程比性能测试多了一个性能环比的环节。

性能环比：把线上的性能数据拿回来，和性能测试过程中的数据做环比，看之前做的是否满足真实的业务场景

并提出了RESAR性能工程方法论，其中过程如下：

看着过程比较多，其中性能测试我大致分为四个阶段：

需求分析阶段——测试准备阶段——测试执行阶段——报告结论阶段

需求分析阶段

字面上理解需求分析阶段包括需求阶段，分析阶段。

需求阶段：业务需求——〉性能需求——〉性能指标

分析阶段：业务分析——〉业务模型；架构分析——〉环境模型

咋一看，怎么越来越复杂了，其实上面关系链是指前后过程，这个过程我们只要记住三个重点：性能指标，业务模型，环境模型。

性能指标

说到性能指标，这里得提一下性能场景。

高老师把性能场景分为四个：1，基准场景；2，容量场景；3，稳定性场景；4，异常场景，而性能指标具体对应到各个场景中。

这里先有个概念，我们来看看实际情况。

你也许一上来就被业务方或者老板说要系统支持xxx并发，而我刚开始听到的就是1w。

这么高，先不管什么业务，肯定是业务非常好！但我知道这是个初创项目，真实业务嘛大家可以自行想象。

虽然心里嘀咕，但嘴上还是应付着好的好的，毕竟我们是专业的，先一步一步来。

首先，了解业务需求：

• 当前系统的新版本业务简单，目前实现主要是下单业务
• 我们的下单业务就是类似电商的售卖场景，只不过是虚拟物品
• 下单业务流：首页—产品列表——产品详情——确认下单（需要登录）——订单支付——我的购买

接着，了解性能需求：

• 因为之前另外的版本线上做过售卖（注册了三四千用户），出现了高并发服务器卡死无响应的性能问题
• 而新版本上线后会做售卖活动，库存有限，类似秒杀活动，预计比之前有更大的流量
• 为了保证业务活动的高并发下的正常售卖，需要系统支持1w的并发

所以，至于老板怎么得出1w结论的，已经不重要了。因此我们自己要得出一个合理的性能指标

合理的性能指标怎么来：

凡事都讲缘由，既然是高并发问题引起的，那我们就从这里提问：

1. 当时的负载程度多大？答：有个基础监控，大概峰值每秒几十的rps，区间的数据也不大。
2. 问题出在那？答：未知，只知道当时服务器配置为2核4G。
3. 区间数据有吗？答：当时活动用户注册量为三千多，下单约为六百，转化率为20%

因为我们当下是新版本，业务场景也不一样，再提问下。

1. 那么新版本的预计流量是多少？答：5W的用户
2. 新版本的环境配置是多少？答：未知，需要性能测试后给出。
3. 活动的运营策略和之前有区别吗？答：没有

从上面基本可以看出：我们的用户数为5W，假如1分钟内进入5w的在线用户（每秒833），30秒内1W用户登录（每秒333），10秒内2千用户下单（每秒200），预计会达到5千到1w的总下单量，于是我打算先按照这个目标来。

高楼老师把它分为了业务指标与技术指标，并建议用TPS来承载并发，即单位时间内完成事务的个数，所以按照上面每秒并发，再稍微拔高下，我们可以得出技术指标。

接口级的TPS：首页各接口800TPS，登录共两接口500TPS，下单接口300TPS。

业务级的TPS：首页业务800TPS，登录接口500TPS，下单业务300TPS。

上面两个也就对应性能场景中的基准场景，即我们至少得执行两种级别场景，而每级别场景根据对应的接口及业务来分。

那我们怎么回答老板的1w并发呢？其实老板的并发就是指用户级的下单并交易成功的事务，也就是容量场景。

用户级的TPS：也就是容量场景中的TPS，1w，但容量场景的TPS需要考虑到业务模型，所以这里的1w只是参考值。

业务模型

什么叫业务模型？我理解：

统计区间内用户的事务分配比例     ——这个统计区间来自于峰值业务的时间段或特定并发场景

用户级TPS中可以根据业务模型，从在线用户数推算出并发用户数，即得出来老板的业务指标。

首先进行业务分析，常见两个方法：

• 业务监控日志分析：但我们新版本没有运营数据
• 业务运营人员分析：我们运营也不敢说分析准确

看来，只能等上线试运行后得到监控日志，并分析出业务模型，才能得到业务指标的下单并发。

没有日志监控系统（比如ELK），可以用nginx访问日志来统计各接口的比例，并在容量场景脚本中做好比例分配，比如使用jmeter的吞吐量控制器。

这里先暂且不做，后面上线试运行后再做。

环境模型

所谓环境模型？我定义：

生产环境模型：指目前生产环境部署架构，包括网络拓扑，部署架构（单台还是集群），系统架构（如spring cloud）。

压测环境模型：指压测环境部署架构，可以复制生产环境或等比缩小，包括网络拓扑，部署架构，系统架构。

我解释下这3个名词：

• 网络拓扑：主要指应用的网络环境，比如使用阿里云ECS，那么是否走内网VPC？出入带宽是否限制？是流量计费还是固定带宽？带宽是否有上限？等等。
• 部署架构：目前后端一般是集群部署以及容器化部署，这里就是指用了多少个机器，多少个节点。
• 系统架构：也就是大家经常见到的架构图，主要是描绘出业务链路，包括CDN、负载均衡、各应用服务、数据库、各种中间件等等。

画出上面3个图就得到了当前的生产环境模型，当然画图也是为了增加脑中的概念，方便后面性能分析。

生产环境模型可以指导压测环境的搭建部署，而经过性能测试后压测环境模型可以为生产环境的搭建部署提供依据。

首先架构分析：

生产环境的架构分析

对生产环境的架构分析，就是画出上面的图。

很尴尬，新版本未上线，即没有生产环境架构，只好跳过这一步😂

压测环境的架构分析

考虑到业务简单，并且时间资源紧张，越简单快速越好，就进行单机架构部署，购买了3台8C，16G的ECS，系统及网络拓扑如下：

因为使用的Spring Cloud，考虑到核心服务应该占有资源较大，所以最好分开单独一台，部署架构如下

按照上面的图，就可以让开发运维搭建压测环境了。

总结

需求分析阶段需要关注三个要点：

1. 性能指标：根据历史与未来业务场景，分析出性能需求，最后得出接口与业务级性能指标，为基准场景提供依据，这里使用TPS承载即可（技术指标）。
2. 业务模型：根据历史日志或者运营业务分析，得出特定区间业务比例分布，为容量场景提供依据，服务于业务指标（老板口中的并发）。
3. 环境模型：根据生产或实际情况，画出生产对应架构图，并分析出压测环境架构图，这样就可以指导压测环境的部署了。

自此，需求分析阶段结束，把这些内容摘写进测试方案，并做好记录，就可以走下一个测试准备阶段了。

注：这里我没有提到性能测试的计划，压测肯定有多个时间节点的计划，这个时间尺度可以根据性能会议讨论得出，可以用表格或自己的方式做需求跟踪，这里就不细说了。