【转】如何定义性能需求

标签: 定义 性能 需求 | 发表时间:2015-02-03 23:55 | 作者:小熊座
出处:http://www.iteye.com

转自: http://www.infoq.com/cn/news/2015/02/define-performance-requirements

 

JVM监控解决方案提供商 Plumbr的官方博客上发表了一篇题为《 如何定义性能需求》的文章。文章指出,随着企业信息化程度的提高,业务人员对软件功能性需求的描述越来越好。但涉及到易用性、兼容性或性能等非功能性需求的时候,他们经常会不得要领。比如,他们可能会提出“它的运行速度要快”这样的性能需求。在更好的情况下,他们可能会提出下面这样的性能需求:

  • 在系统中执行的操作,95%的都必须在5秒针内响应;
  • 系统必须支持100并发用户。

初看上去,这样的需求已经好了很多了。但实际上,它们甚至比只用一个“快”字描述更差。虽然它们包含了一些数字,看上去似乎可以作为开发人员的终极目标。但实际上,这两个需求最多只能为关于性能需求的讨论开一个头。

文章接下来对上述两个需求进行了剖析。

第一个需求没有提出针对其它5%的操作的性能需求。而且,不同的功能对性能的需求也不尽相同。比如,对于功能“显示当前账户余额”和“显示2013年所有的交易”,前者5秒响应可能都略显慢,而后者响应时间再长一些也可以接受。因此,性能需求描述应该:

  • 针对不同的操作类型指定可接受的时间延迟;
  • 将时间延迟相关的需求与负载/吞吐量相关的需求联系起来;
  • 明确时间延迟的测量位置,比如,延迟时间是以客户端为标准,还是以服务器端发送出最后一个字节为标准;
  • 哪些操作的时间延迟不太要紧。

第二个需求看上去很准确,实际上很笼统。比如,将“100个并发用户”理解成“100个线程处理100个并发操作”。如果每个操作用时1秒,那么系统吞吐量为100 ops/sec;但如果每个操作用时10秒,那么系统吞吐量则只有10 ops/sec。对于后一种情况,我们不能认为它满足“100个并发用户”的需求。因此,需求应该更清楚地描述特定用户的行为,而不是用“并发用户”这样的术语。当然,这里并不是说建议测量吞吐量,因为现实世界的应用程序往往是多功能的,很难使用吞吐量来衡量其性能。

本文还提到了容量规划,即在什么样的前提条件下实现上述性能需求,包括如下三个方面:

  • 系统的数据量;
  • 系统的基础设施限制,比如,CPU、内存等;
  • 系统的部署环境,比如,网络带宽是多少,是否需要离线操作等。

总之,应该与业务人员紧密合作,制定出可测量的、具体的性能需求。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [定义 性能 需求] 推荐:

【转】如何定义性能需求

- - 操作系统 - ITeye博客
转自: http://www.infoq.com/cn/news/2015/02/define-performance-requirements. JVM监控解决方案提供商 Plumbr的官方博客上发表了一篇题为《 如何定义性能需求》的文章. 文章指出,随着企业信息化程度的提高,业务人员对软件功能性需求的描述越来越好.

微信自定义机器人的最初需求样本

- - 白鸦,Blog
前不久给微信提了几个未来可以通用的接口需求,我认为可以作为很多企业的智能客服去使用,也可以配套上他们的CRM. 虽然到目前为止 Guang.com的一个兼职工程师还没有完全实现这些设计,但依然还是挺好玩的~. 最近有不少新的微信账户在使用这些接口(可以添加如下好友来测试:订酒店、下厨房、逛),也有人在讨论这些接口可以怎么用.

2012.5.23微博热报:需求分析、性能调优

- - InfoQ cn
@阿里巴巴中国在 微博中举了一个对设计花瓶的需求分析示例,引起了大家对需求分析技巧的讨论; @左耳朵耗子在 微博中表示性能调优不一定要自己使用缓存,因为许多层面已经设计了缓存机制. @阿里巴巴中国在 微博中举了一个例子:“需求方说:帮我设计一个花瓶. 小A肯定做出了花瓶,但是未必是顾客想要的.

ASP.NET性能优化之构建自定义文件缓存

- Pei - 博客园-首页原创精华区
ASP.NET的输出缓存(即静态HTML)在.NET4.0前一直是基于内存的. 这意味着如果我们的站点含有大量的缓存,则很容易消耗掉本机内存. 现在,借助于.NET4.0中的OutputCacheProvider,我们可以有多种选择创建自己的缓存. 如,我们可以把HTML输出缓存存储到memcached分布式集群服务器,或者MongoDB中(一种常用的面向文档数据库,不妨阅读本篇http://msdn.microsoft.com/zh-cn/magazine/gg650661.aspx).

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.