需求|5000字详解性能需求( 二 )

文章插图
当响应时间＞5秒后，74%的PC端用户、50%以上的App用户会选择放弃操作，30%的用户会选择卸载应用，33%以上的用户会转身使用竞品。
吓人不？
我们接着看下响应时间的定义：提交请求和返回该请求的响应之间使用的时间。主要由网络传输时间和业务处理、数据处理时间组成。

文章插图
而对于产品来说，需要关注的是页面响应时间，就算接口处理完成，数据传到客户端上了，在前端也需要解析出来，也会消耗一定时间。
响应时间多长才能满足要求呢？
之前有个2-5-10原则，而现在随着技术、硬件的更新换代，响应时间也有了1-3-5标准。

文章插图
即1s内用户完全可以接受，3s内用户觉得还可以，5s用户就会开始焦躁不安。
当然这只是个通用标准，不是个固定标准。我们在提出需求时，可以结合业务重要性、数据量大小、使用频次来做综合考虑。
举个例子：导出excel报表。对于很多B端产品，这是个刚需、高频的功能。
我们可以这样提出性能要求：

1万条数据，导出完成用时3s。
3万条数据，导出完成用时5s。
10万条数据，导出完成用时8s。

我从网上找到一些响应时间参考指标，大家可以看下：

互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
金融企业：1秒以下为佳，部分复杂业务3秒以下。
保险企业：3秒以下为佳。
制造业：5秒以下为佳。

2. 并发用户数——笼统也直观的指标并发用户数的定义是每秒同时向服务器提交请求的用户总数量。
关于并发用户数有2个理解：

多个用户同一时间做不同操作，比如多个用户有发动态的，有刷动态的。
多个用户同一时间做同一个操作，比如多个用户一起发动态。

对于这2个理解，在性能需求上可以分开提，比如：

系统支持并发用户数500
发布动态：支持300人并发发布动态。

有几种并发用户数评估方法，大家可以看下：
1）公式1：
n：平均每天的访问用户数。App可以直接用日活代替。
L：一天内用户从登录到退出的平均时间，可以理解为平均用户使用时长。
T：考察时间长度，一天内多长时间有用户在使用系统。
举个例子:
App日活是10w，用户平均使用时长是10min，用户每天活跃时间大约是从早上10点到晚上10点。
公式里的n=10w，L=10min，T=12h
C=（10w×10min）/12h，时间单位统一成秒
C=（10w×10×60）/（12×3600）≈1388人/秒
峰值C’=1388×3×根号1388≈1500人/秒
提需求时可以以峰值并发用户数为准
2）公式2：
C=（用户总量/统计时间）*影响因子
影响因子一般为3
比如App的每天晚上8点-10点用户最活跃，且活跃用户有8w。
8w/2h×3≈33人/秒
3）公式3：
根据80~20原则：80%的请求在20%的时间内产生。然后结合PV一起算（注意不是UV，因为一个用UV产生多个PV）
比如1天的PV有100w
先算80%的PV：100w×80%=80w
20%的时间：24h×20%=4.8，换算出秒，就是4.8×3600=17280秒
并发数就是：80w/17280=46人/秒
如果是B端私有化部署的产品，一般使用人数比较固定，我们可以从企业人员数量做评估：用户数量×比例，比例可以视具体情况而定，一般取8%-20%。
当然这些都是评估方法，得出的具体数据量只是做个参考。