首先,请你们当前软件和硬件配置下验证能否支撑200万vu。如果可以支撑200万,再增加到300万看是否可以支撑。如果不能达到200万,那么就需要寻找一下是否有性能瓶颈,将主要的性能瓶颈解决后,再看一下是否可以支撑200万,如果可以支撑,输出测试结果。仍然不能,请评估需要添加多少硬件设备。
通过上面流程的分析,那么我们对于需求实施过程就非常明确了。
下面看来分析某邮箱系统的需求:
按照 某某 邮箱20000万注册用户,其中日活跃用户数为1.5%的规模计算:
日活跃用户=20000*1.5%=300万
日活跃用户人均每天发6封邮件,用户使用客户端收发邮件比例20%,则:
每天发邮件投递量=300万*6*20%=360万封
如何得到每秒的邮件数?
方式一: 严格的根据2/8原则 ,80%的邮件集中在20%的时间发送。
集中发邮件数: 3600000*80%=28800000封
集中发送的时间:24*20%=4.8小时=17280秒
每秒发送邮件数:2880000/17280=166.7封/秒
方式二,根据 某某邮箱业务模型表,每天忙时集中邮件系数0.15,邮件平均峰值系数2,则:
峰值邮件量=3600000*0.15*2/3600=300封/秒
注:忙时集中系数=忙时业务量/全天业务量
在两种方式的分析中,方法二得出的结果是方法一的将近一倍,我们不要根据经验理所当然的去分析,要深入的了解系统,我们要对行业指标及计算方式。如果按照第一种方式,性能测试达标了,但系统真正上线后可能远远超出了我们的评估。2008年北京奥运运门票系统就是一个典型的案例。
再来分析系统的登录:
去年全年处理“WEB登录”交易约 100 万笔,考虑到 3 年后交易量递增到每年 200万笔。
假设每年交易量集中在 8 个月,每个月 20 个工作日,每个工作日 8 小时,试采用 80~20 原理估算系统服务器高峰期“WEB登录”的交易吞吐量应达到怎样的一个处理能力
200万/8=25万/月
25万/20=1.25万/日
1.25万*80%/(8*20%*3600)=1.74TPS
----------------------
上面的小案例算是抛出的一块砖,需求开发难度要远远大于需求管理,在实际工作中常常需要我们为客户开发这部分性能需求。所以,在追求技术的基础上,请更多的了解分析你的项目及行业指标。
相关链接: