51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2578|回复: 0

[讨论] 这篇文章我也比较反感,但请大家说说自己看法!不要拍我,说说自己的理由。

[复制链接]

该用户从未签到

发表于 2010-9-8 17:22:19 | 显示全部楼层 |阅读模式
<P>这篇文章我也比较反感,但请大家说说自己看法!不要拍我,说说自己的理由。</P>
<P>&nbsp;</P>
<P>通过本文你会了解到:系统性能与可扩张性测试重要性的下滑与其带来的有限回报,为何会降低你安排这些活动的优先级。通过本文你会了解到:系统性能与可扩张性测试重要性的下滑与其带来的有限回报,为何会降低你安排这些活动的优先级。 </P>
<P>&nbsp;</P>
<P>如今,高速服务器几乎可以处理任何单独的工作负担。仅用几千美元,凑个整数可能为5 000美元,你就足以配置一套几乎可以执行任何工作负担的系统。因为这一点,性能测试已成为很少有人能负担得起的奢侈之物。 当然,也有一些机构的应用程序不能在单独一台或少数几台服务器上运行。所要执行的任务极为庞大复杂,没有单独的服务器能满足这一需求。但是,有这类需求的机构已显著地减少。 通过本文你会了解到:系统性能与可扩张性测试重要性的下滑与其带来的有限回报,为何会降低你安排这些活动的优先级。 </P>
<P>&nbsp;</P>
<P>个人性能记录 我还清楚地记得我编写的一个性能测试应用程序。这是一个旨在同时阅读八台电话交换机的输入信号的程序。每部交换机以9 600波特的速率与应用程序进行数据通信。 应用程序必须验证记录格式,将有效记录与无效记录分别写入两个文件。它的另一任务是在网络发生故障时,将记录上述文件的网络共享文件转移到本地驱动器上,并在网络恢复时将文件返回过去。 此系统在一台安装DOS操作系统的25兆赫80486SX计算机上运行。如果不发生故障,它可以全速处理所有八台交换机。在网络故障期,它的最大负荷也达到五台。这一能力已超出它能够全速支持3到4台交换机的设计目标。那样,公司处理数据流的能力会在当前基础上增加数倍。 由于错误引起的额外处理负担会产生连锁反应,使系统迅速退化。丧失一个特性就会产生额外的处理负担,这样又会使其它的特性丧失。 如果系统不能正常运行,收入就会降低,因此有必要测试系统的性能。但是,即使那样,硬件的性能也会偏离普通公司的性能目标。 </P>
<P>&nbsp;</P>
<P>为何要做性能测试? 进行性能测试有两个原因:一是为了保证系统能够满足公司当前或短期的计划需求。也就是说,要确定能够从当前的系统中获得最大的性能。 第二个原因是:为了支持更大的负载,要就何时对系统进行改造做出规划。这包括重新编写解决方案片断、重建解决方案或添置更多的硬件。这样,进行性能测试就有助于了解:要想超越现有的系统性能,我们该做出哪些努力。 何为性能测试? 谈论性能测试时,我们并不仅仅是谈论性能测试本身。相反,我们谈论的是响应速度、处理能力与可扩充性。这三项指标之间关系密切,每一项都不能孤立起来进行评估。 响应速度很容易量化。任何人用一块秒表就可以迅速地测量出某一程序的响应速度。当然,甚至简单的自动化测试方法还更为精确。不过,事实上,某一程序的响应速度是性能测试的最基本的组成部分,即使在处理能力最低的情况下,也可以进行直接观测。发出请求到产生响应,这一过程所耗费的时间即为系统的响应速度。 处理能力是指系统在同一时间内所能处理的业务量大小。不同的业务类型对处理能力有特别的限制。某一系统每秒可能只能完成20宗业务。不管你给系统多少业务,在指定的时间内,它只能完成其最大处理能力内的业务量。 响应速度测量完成一宗业务所需的时间(秒)。例如,假定测量的响应速度为每宗业务3秒。处理能力则正好相反,它测量每秒处理的业务量。结合起来说,如果系统每秒最多可完成20宗业务,而每宗业务的响应速度为3秒,那么在任何时间,系统都同时在处理60宗业务。 响应速度与处理能力关系密切的一个原因是:系统处理的业务数量增加,则系统的响应速度就会降低。过去只花不到一秒就可完成的业务现在要花两到三秒,甚至更长时间。更让人沮丧的是,一般如果系统所接受的业务量超过某一速率,总体的处理能力就会下降。如果系统每秒能够处理20宗业务,而业务以每秒25宗的速率进入系统,则系统的总体业务处理能力可能会下降到17宗每秒。正因为这样,当我所编写的交换机阅读程序开始失去更多的特性时,也发生了这种情况。由额外业务引发的额外处理负担开始引发超时、重发及其它降低总体处理能力的后果。 可扩充性测量应用程序所能扩张的程度。一旦决定了最大处理能力,下一步就要决定:在环境发生变化的情况下,处理能力可进行多大程序的扩展。可扩充性与瓶颈直接相关。瓶颈是已达到最大处理能力的系统的一部分,它制约系统达到更好的性能。在直接与瓶颈相关时,可扩充性选项一般十分有效。瓶颈一般分为以下几类:处理器、内存、磁盘或网络速度。 为了获得有效的可扩充性,你首先必须鉴别限制处理能力的瓶颈,并着手消除此瓶颈。例如,如果瓶颈为处理器,就要进行试验来评估增加其它处理器的效果。虽然很少有人期望资源成倍增长,处理能力也成倍增长,但如果不存在其它瓶颈,处理能力增加80%应该是合理的。 只有当瓶颈限制系统的性能时,它们才会变得明显起来。如果处理器限制了系统的处理能力,就很难觉察到其实所安装的内存也只能支持另外10%的业务处理能力。实际情况是,发现一个瓶颈并不一定能完成鉴别可扩充性选项的目的。一般来说,我们有必要真实展示提议的可扩充性选项的性能,以证明取得的实际改善。 这就是性能测试的主要矛盾之处。要正确进行性能测试,你得需要你所测试的硬件,在那种情况下,你实际已经购买了它。 评估性能 如今,大多数的应用程序并不需要超出一台单独系统处理能力的性能。例如,微软估计,一台运行ISA的双处理器2.4GHz英特尔奔4服务器每秒能够对30至42兆的SSL流量进行加密。假如大多数机构连接互联网所使用的只是每秒1.544兆的标准T1(D1,如果你喜欢)线路,那么系统处理能力与平均需求之间就存在巨大的差距。然而,多数机构只专注于让计算机执行SSL加密与其它一些大家熟知的困难任务,很少有人意识到系统处理能力与他们所讨论的工作负载之间的差距。 讨论主要集中于一种或一组要消耗更多时间的技巧。例如,在.NET中应用反射(reflection)来处理对象比直接调用对象要花费更多的时间。(反射是在运行时间访问元数据的一种机制。)这是事实。但是,尽管反射要比直接调用方法多花几倍的时间,它仍然没有触及许多应用程序的有效处理时间的表层。 同样,由于要耗费大量的处理器能力,我们也放弃了处理异常的包装与重扔(wrap and rethrow)方法。因为要经过很长时间才能找到合适的处理器,一般来说异常处理十分昂贵。针对直接由错误引起的底层异常,包装与重扔(wrap and rethrow)技巧可能会潜在产生一些或更多异常。对处理器来说,这可能要比单独的异常要昂贵数百倍。但是,这种认识忽略了这样一个事实:即异常其实(或至少应该)极少发生,而且通过包装与重扔(wrap and rethrow)技巧获得的信息对解决问题相当有益。 另一个提到性能,且性能在这里有一定价值的地方是存储过程(微软SQL服务器数据库中)。一些机构要求为每个表格访问建立存储过程,但并不是因为存储过程所带来的安全利益,而是专注于它所获得的性能改善。然而,在大多数情况下,应用存储过程对性能并没有多大的改善。此过程中省略的部分(编辑与查询优化)在SQL中十分高效,因此用不了多少时间。 针对改善许多中型与大型机构的系统性能的应用程序不在少数。但意识到性能的重要性,因而浪费资源,反而会造成性能问题。这些情况大多与编写可靠的代码有关,而不在于应用哪种技巧。 低廉的硬件 有可能进行性能测试并将其做好吗?一般来说,性能测试昂贵、麻烦而又费时,而且很少会产生投资回报。对大多数机构来说,要提高性能,增加更大的内存、添置另一台处理器或服务器可能是更为方便低廉的方式。 同样,如果集中于影响总体性能(应用)的次要项目,我们可能会错误地以设计理念为中心,花费了大量的开发时间,但性能却没有多大改善。硬件也不贵,那就应用它吧!说这样的话真是让人痛苦!</P>
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-3-29 17:38 , Processed in 0.064511 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表