性能需求分析

性能测试点的选取

 

*  发生频率非常高的(例如:某邮箱核心业务系统中的登录、收发邮件等业务,它们在每天的业务总量中占到90%以上)

*  关键程度非常高的(产品经理认为绝对不能出现问题的,如登录等)

*  资源占用非常严重的(导致磁盘I/O非常大的,例如某个业务进行结果提交时需要向数十个表存取数据,或者一个查询提交请求时会检索出大量的数据记录)

 

对性能需求点的描述

 

准确

如系统必须在不超过 10 秒的响应时间内,处理 20 起登录任务。再如发邮件时间最大不超过5秒以及平均时间在2秒以内。

一致

用户和性能测试工程师对有关术语的理解要一致,如:并发用户数、在线用户数、注册用户数: 

特定

性能测试的需求一定是有条件的。

检查系统后台关键业务数据10G、操作数据量为20K, 1500 个用户、500 个并发用户运行的负载下,连续运行12小时过程中,业务操作是否满足性能需求。

 

常见性能需求

 

1、响应速度-比如:API请求的平均响应时间应低于1s, WEB首页打开速度5s以下,web登陆速度 15s以下。

2、服务支持50万个在线用户

3、某接口支持200个用户同时调用(平均3秒调用一次)

3、计费请求成功率达到99.999%以上。

4、在100个并发用户的高峰期,邮箱的基本功能,处理能力至少达到10TPS

5、系统能在高于实际系统运行压力1倍的情况下,稳定的运行12小时 

6、这个系统能否支撑200万的vu(每天登录系统的人次)          vu----Virtual user(虚拟用户) 

 

"不成文"的性能需求指标:  

 

响应时间:根据国外的一些资料,一般操作的响应时间为2,5,8秒,2秒内优秀,5秒内良好,8秒内可接受,其它一些特殊的操作,如上传,下载可以依据用户体验的情况,延长响应时间。

  Peter bickford 在调查用户反应时发现:在连续27次即使反馈之后,第28次操作进,计算机让用户等待2分钟,结果半数人在第8.5秒左右就走开或者按下种启键。使用了鼠标指针变成漏斗提示的界面会把用户的等待时间延长到20秒左右,使用动画的鼠标指针漏斗提示界面则会让用户的等待时间超过1分钟,而进度条则可以让用户等待到最后。Peter bickford的调查结果被广泛用到web软件系统的性能需求的响应时间定义中。

  第三方研究表明,如果网页是逐步加载的,先出现横幅,再出现文字,最后出现图像。在这样的条件下,用户会忍受更长的等待时间,用户会把延迟在39秒内的也标识为“good”,超过56秒的才认为是“poor”的。

80/20原则:又称帕累托效应,比如,某一些系统一天中80%的访问量集中在20%的时间内。

 

如何根据性能需求进行测试

 

其实我们上面得到的需求指标仍然是不明确的:

是验证当前硬件和软件配置能否支撑200万vu?

是测试当前的硬件和软件配置最多能支撑多少vu?

是帮助开发寻找性能瓶颈?

 

根据需求进行性能测试的过程:

  首先,请你们当前软件和硬件配置下验证能否支撑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

 

 

----------------------

  上面的小案例算是抛出的一块砖,需求开发难度要远远大于需求管理,在实际工作中常常需要我们为客户开发这部分性能需求。所以,在追求技术的基础上,请更多的了解分析你的项目及行业指标。

猜你喜欢

转载自www.cnblogs.com/yaoyao9446/p/9242243.html