为了获得有效的可扩充性，你首先必须鉴别限制处理能力的瓶颈，并着手消除此瓶颈。例如，如果瓶颈为处理器，就要进行试验来评估增加其它处理器的效果。虽然很少有人期望资源成倍增长，处理能力也成倍增长，但如果不存在其它瓶颈，处理能力增加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中十分高效，因此用不了多少时间。
针对改善许多中型与大型机构的系统性能的应用程序不在少数。但意识到性能的重要性，因而浪费资源，反而会造成性能问题。这些情况大多与编写可靠的代码有关，而不在于应用哪种技巧。
低廉的硬件
有可能进行性能测试并将其做好吗？一般来说，性能测试昂贵、麻烦而又费时，而且很少会产生投资回报。对大多数机构来说，要提高性能，增加更大的内存、添置另一台处理器或服务器可能是更为方便低廉的方式。
同样，如果集中于影响总体性能（应用）的次要项目，我们可能会错误地以设计理念为中心，花费了大量的开发时间，但性能却没有多大改善。硬件也不贵，那就应用它吧！说这样的话真是让人痛苦！
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
