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

xujian1001

<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>