论“性能需求分析”系列专题(二)之 常用的性能需求获取方法

简介:

实际过程中常常对性能需求该如何获取而纠结,本博文进行详细的介绍,理论与案例一并附上,希望大家多多讨论拍砖。

常用的性能需求获取方法

下面就跟大家一起讨论几种常用的获取性能需求的方法。

1.依据用户明确要求

依据用户明确给出的测试相关数据和指标是分析系统性能需求最直接、最简便的方法。对于前面提到的专业型客户,如银行、军事、医疗、政府机关等以及国外客户大多都会给出较明确的性能需求(响应时间、并发量、服务器资源指标等),作为开发方,只需进行整理后参照明确指标进行测试即可。

2.依据用户提供的已有数据整理分析得出

所谓客户提供的已有数据指客户业务交易的纸质数据、客户旧版本系统中的历史数据(服务器日志、数据库记录等)。例如,一个未曾使用过电子系统的保险公司,获取需求时可以通过汇总已有投保纸质单据进行分析,得出各地域及每年某个时间段的投保、理赔数量、主要投保及理赔的险种业务等来进行性能测试。若该公司已有旧版本的电子投保系统,则旧版本的运行系统中存在了大量有价值的数据。比如:Web服务器(IISApacheJboss等)的日志中记录了系统访问情况以及出错信息等,我们可依据日志信息分析客户的业务量,以及每年、每月、每周、每天的峰值业务量等(通过服务器日志获取性能需求的方法参见1.6.3节)。此时,以充分的真实业务数据做参考得出的性能需求显得更加真实有效。

3.依据同行业中类似项目或类似行业中的数据

方法包含了两种情况,一种为“依据同行业种类似项目的数据”,另一种为“依据类似行业的数据”。这两种情况所表达的含义是一致的:当自己没有某些资源时,要学会借助外界力量帮助自己实现性能目标的获取。比如,有读者可能会这样问:需求中没有说明性能需求,只说要做一个网站的性能测试。此时,如何开展性能测试呢?回答是:先分析用户群特征,然后参考其他同行企业的公布出来的数据进行测试。

下面给出几个依据同行业中类似项目的数据或类似行业的数据得出性能需求的几个实例

1-1. 在某企业网站的成功解决方案中介绍该方案的优势为:“实现了7*24稳定运行要求,系统可承载3000用户同时访问,1秒快速响应您的请求等”,其中的数据可作为性能需要的参考。

1-2. 有一些网站首页本身就提供了点击量、文章浏览量等统计信息,尽管在许多时候,不能完全照搬这些数据,但这些信息仍然具有很强的参考价值。

1-3. 在开发一个保险类软件时,除了可从客户发布的一些成功解决方案中获取数据,还能主动去索取一些数据,比如,可以咨询某保险公司:“我想购买贵公司的保险,但首先要了解一下投保情况和理赔的数据或比例等,好让自己更确信公司的诚信……”。不过,这种方式不被推荐,因为对方的回答很可能存在水分以提高业务量。

1-4. 可以借助一般的B/S架构的项目性能目标来套,比如:2/5/10原则,即2秒的响应是愉快的,5秒是可接受的,10秒是最大可忍受的。

4.80/20原则分析计算得出

在性能测试需求获取中,经典的80/20原则可理解为:每个工作日中80%的业务在20%的时间内完成;80%的功能只会有20%的用户访问,或者说80%的用户只使用20%的功能。

1-5. 每年业务量集中在8个月内,每个月有20个工作日,每个工作日为8小时工作制根据80/20原则,可得出,每天80%的业务在1.6小时(8小时*20%)内完成。去年,全年处理业务约100万笔,其中15%的业务处理中每笔业务需对应用服务器提交7次请求;70%的业务处理中每笔业务需对应用服务器提交5次请求;其余15%的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后3年业务发展的需要,测试需按现有业务量的2倍进行。请根据上述数据进行测试强度的估算

v每年总的请求数:

(100万笔*15%*7/+100*70%*5/+100*15%*3/)*2=1000万次/年。

v每天请求数:

171929689.jpg

v每秒请求数:

(62500/*80%)/(8小时*20%*3600/小时) = 8.68/秒(约为9/秒)。

可见,服务器处理能力应达9/秒。

5.任务分布图

若利用上面的某种方法获取到了客户业务相关的某些数据,则可借助任务分布图作进一步分析。任务分布图能够直观地展现客户业务在24小时内的交易情况,能协助读者整理出交易频繁的业务种类及相应的时间段。如:表中是某在线购物网站的任务分布图,从中可见:12:00-14:0020:00-22:00点之间的交易混合程度较高,“查询”任务的并发用户在14:00达到最大。任务分布图也支持对全年或某个月的任务分布情况作统计分析,在此不再赘述。

某在线购物网站的任务分布图

典型业务

并发用户数(单位:百人)

登录




2

5

30

35

6


70

75

3

注册





2

20

10

3


30

25


查询




3

8

50

40

8





放入购物车




2

3

30

30

6





支付





1

25

20

5





时间

2

4

6

8

10

12

14

16

18

20

22

24























本文转自hblxp32151CTO博客,原文链接:http://blog.51cto.com/starpoint/1314059,如需转载请自行联系原作者

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
1月前
|
测试技术
性能场景之压测策略设计
【2月更文挑战第19天】性能场景之压测策略设计
289 4
性能场景之压测策略设计
|
3月前
|
缓存 运维 前端开发
【分布式】衡量网站的性能指标
【1月更文挑战第25天】【分布式】衡量网站的性能指标
|
7月前
|
负载均衡 测试技术 应用服务中间件
性能测试常见瓶颈分析及调优方法总结
性能测试常见瓶颈分析及调优方法总结
261 0
|
1月前
|
SQL 运维 监控
性能场景之稳定性场景方案设计
今天想说说稳定性场景设计。经常在一些场合被问到性能场景的设计问题,但是大部分都是和容量相关的。为什么稳定性问的人少呢?稳定性是不是说在容量场景做好了之后就水到渠成了呢?首先稳定性场景的设计应该说比容量场景设计要简单一点。毕竟容量如果测试结果非常好的话,稳定性场景只要有一时间变长的动作就可以了。但是不要小看这个时间变长的动作,它会让你要准备和思考的内容多出不少。下面来庖丁解牛地细化一下
44 6
性能场景之稳定性场景方案设计
|
3月前
|
测试技术
影响性能测试的因素有哪些?
影响性能测试的因素有哪些?
|
3月前
|
SQL 缓存 数据库
后端开发中的数据库优化策略——提高性能和可靠性
在后端开发中,数据库是至关重要的一环。如何优化数据库,提高系统性能和可靠性,一直是后端开发者需要面对的问题。本文将介绍几个常用的数据库优化策略,包括数据结构设计、索引优化、SQL语句优化、缓存优化等方面,希望对后端开发者有所帮助。
26 2
|
10月前
|
数据采集 测试技术
性能测试(2)——性能策略
压力测试是在强负载(大数据量、大量并发用户等)下的测试,查看应用系统在峰值使用情况下操作行为,从而 有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。 通俗理解:压力是逐步增加的,直到系统不能接受用户请求的性能点,去发现系统在什么情况下,应用程序的性能会变得不可接受。
114 0
|
11月前
|
存储 人工智能 缓存
系统设计:快速粗略计算系统容量和性能需求
系统设计:快速粗略计算系统容量和性能需求 虽然在处理分布式系统时,数据量可能会变得非常大,但所有的计算都归结为基本的计算。为了得到正确的计算结果,知道以二的幂来表示的数据量单位至关重要。
 系统设计:快速粗略计算系统容量和性能需求
|
SQL 运维 监控
性能测试常见瓶颈分析及调优方法
事务成功率在某些时候也可以视为请求成功率,在断言判断时以code/status等内容来作为请求是否成功的衡量依据;
性能测试常见瓶颈分析及调优方法
|
机器学习/深度学习 存储 数据可视化
开发者效率的几个瓶颈点
开发者效率的几个瓶颈点
开发者效率的几个瓶颈点