本节书摘来自异步社区《应用程序性能测试的艺术（第2版）》一书中的第1章，第1.2节为什么性能问题如此常见，作者【新西兰】Ian Molyneaux（莫得尼克斯），更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 为什么性能问题如此常见
上文为什么是好的性能、什么是差的性能做了一个基本的定义。应用的性能孰优孰劣，似乎也很好判断，那为什么还有那么多的应用无法满足高性能这样一个关键需求呢？下文给出了一些常见的原因。
1.2.1 IT商业价值曲线
性能问题之所以让人头疼，有一个很重要的原因就是它通常在应用生命周期的后期才会凸显出来，越晚发现问题，就要花费越多的精力去解决问题。图1-1所示的IT商业价值曲线很好地描述了这个观点。
图1-1所示中，实线（预期）表示在经过一段时间的IT投入（应用开发过程）后，应用按期发布成功，上线之后运行良好，几乎没有任何性能问题，并立即开始带来营收（黑色方块）。
图1-1所示中，虚线（实际）描绘了在现实世界经常发生的真实情况：开发延迟、发布延期（虚线方块）。应用发布上线之后，为了应对层出不穷的线上性能问题，大量的时间和金钱被消耗。最终开发出来的应用不能为企业带来预期的收益，这对谁都不是一个好消息。
类似这样的问题，在公司董事执行层得到越来越多的重视。很多公司都引入了IT服务管理（Information Technology Service Management，ITSM）和IT资产管理（Information Technology Portfolio Management，ITPM），希望由此走上拥抱IT基础架构库（Information Technology Infrastructure Library，ITIL）这个行业标准的道路。在当今很多公司里，IT部门再也不是一个“独立王国”，可以享受不受限制的资金和资源投入。它也成为公司众多部门当中的一个（重要的）业务单元，同样需要在一定的预算控制下运作。
1.2.2 性能测试成熟度
图1-2所示是弗雷斯特研究公司在2006年针对一次应用部署的产品中性能缺陷的修复率监控得到的数据。在本次再版中，我本想用一些更新的数据来代替这张图，但是很遗憾，这些数据从2009年以来似乎并没有发生太大变化。
图1-2中描述了3个性能测试成熟度等级。第一级称为“救火式”，也就是说在应用正式发布之前几乎没有任何性能测试，因此基本上所有的性能问题都需要在线上发现并解决。这是最低效的一种方式，但让人诧异的是，这种做法在业界还相当普遍。采用救火式对待应用性能的公司面临着巨大的风险。
第二级称为“性能验证（或者叫检验）”。采用这种模式的公司在对待应用性能时，会做一些性能测试，但是这通常只会发生在应用生命周期的靠后阶段；因此，仍然会有相当一部分性能缺陷会遗漏到线上（30%）。这是目前大多数公司采用的方式。
最后一级称为“性能驱动”。这意味着在应用生命周期的每一个阶段，性能都会被纳入考虑。采用这种方式的公司，通常只会有很小一部分性能缺陷遗漏到线上（5%）。这才是所有公司应该努力采用的一种性能测试模式。
1.2.3 在应用设计阶段缺少性能考虑
回到关于导致性能问题的常见原因的讨论上来：如果在应用设计阶段没有充分考虑性能，麻烦会接踵而至。“性能驱动设计”本身对于应用性能就是一个很好的保证，或者至少在出现意料之外的性能问题时，提供了一种便捷修复的可能性。由于设计导致的性能问题如果在应用生命周期的早期阶段没有发现，那么到后期很难彻底消除，而且这种性能纠正如果不耗费巨大返工几乎是不可能的。
1.2.4 最后一刻才想起性能测试
上文提到，有很多公司在研发过程中采用了“性能验证/检验”模式。使用这种模式，性能测试往往是在应用即将发布之前才开始的，他们几乎没有考虑性能测试本身所需要的时间，也没有考虑如果发现问题所需要的修复时间。虽然这种方式比性能“救火”要好，但这种方式的缺点也显而易见：一些非常严重的性能缺陷仍有可能被遗漏到线上；另一种情况是虽然发现了问题，但是却没有足够的时间在应用发布以前修复这些问题。
性能测试被延迟到最后一刻带来的常见场景就是为了修复临近发布才发现的性能问题，应用发布不得不一拖再拖。一个带着性能问题上线的应用在发布之后仍需要不断的投入来修复问题，最坏的情况是应用彻底下线直到问题解决。
所有这些问题都会对业务以及等着使用应用的客户信心造成极大的负面影响。所以性能测试必须尽早开始，而不是等到应用即将发布的最后一刻。
1.2.5 可扩展性
对应用容量需求或者应用的可扩展性评估不足也是导致性能问题常见的一个原因。应用的设计和预期的发布模式很容易忽视潜在的用户社区体量和地理分布。许多应用在开发和测试过程中都容易忽略下面一些问题。
有多少终端用户会使用这个应用？
这些用户会分布在什么地方？
有多少用户会并发使用这个应用？
终端用户如何接入这个应用？
随着时间发展，应用的用户增长模式是怎样的？
最终的应用拓扑是怎样的，会有多少台服务器，它们地理位置分布在哪里？
应用对于网络容量的需求会是怎样的？
如果忽视上面提到的这些问题，我们就无法真实评估应用到底需要支持多少线上并发用户。同样，应用终端用户的网络情况，比如低带宽、高延迟的广域网连接，也是容易被忽视的一个考量因素。本书第2章将会讨论关于连接性问题的更多细节。
1.2.6 低估受欢迎程度
很多公司会低估他们网站的受欢迎程度，这听起来有点奇怪，但是事实确实如此。公司在发布网站时容易忽视“追新效应”。每当有什么新奇的东西出现，人们都会对此非常好奇，然后蜂拥而至。有的时候为了发布效果，公司也会通过媒体来做一些推广，这就更加重了这种群集效应：本来预期网站在发布之后第一天会有10000的点击量，结果等着你的却是1000000的点击量，这样预期之外的压力足以将你的系统彻底击溃。
换句话说，当我们考虑性能时，我们需要考虑的是峰值流量而不是平峰流量。
重大故障：一个真实案例
几年前，英国政府决定在互联网上公开1901年的人口普查数据。这项工程浩大，需要将大量的纸质文档电子化，然后开发一个应用供用户来访问。
我本人也非常期待这个项目的实施，因为我当时正在追溯自己的家族历史，而政府即将公开的这部分数据应该可以提供很多有用的信息。当这个网站上线之后，我便马上登录使用。虽然我发现网站有点慢，但我还是能够用它进行一些简单的搜索。然后仅仅过了一天，当我再来使用这个网站时，呈现在我面前的已经是一则道歉信息，表明网站暂时不可用。这个网站在最终修复重新发布之前连续好几个星期不可用。
这是一个低估应用受欢迎程度的典型案例。大家对这个网站的关注程度远远超出了预期，因此网站的性能支撑不了如此大体量的访问点击。这并不意味着这个网站在推出之前没有做过性能测试。但这个案例至少说明，对于这样一个网站，评估的性能和容量需求太保守了。
一个好的应用必须能够支撑那些突发的需求高峰。
1.2.7 性能测试还是一门非正式学科
正如上文提到的那样，性能测试计划和实施通常还是非常不正式的。其中的原因很难考究，因为功能测试在很多年前就已经成为一门非常正式的学科。关于功能测试，行业内有许多沉淀和专家意见，甚至还有很多咨询公司专门提供测试类的咨询服务。
回到2009年看性能测试，情况却和功能测试恰恰相反，至少从参考资料的层面上说是这样。当时测试行业内几乎没有任何关于性能测试的系统性文档，所以我决定为性能测试写些东西。我们一直不缺关于如何进行应用性能调优的书籍和文档，但是阐述如何有效地进行性能测试的书籍实在是太少了。
到了2014年，我很高兴地看到情况有所改观。当我们在谷歌上搜索“性能测试”的时候，我们能够搜到大量公司，他们提供性能测试服务、工具和一些培训，当然这些公司更多的出发点还是性能测试工具。
1.2.8 没有使用自动化测试工具
如果不使用自动化工具，就没有办法有效开展性能测试。人肉战术（周末叫上100个心怀怨恨的员工，掐着秒表测试性能）显然不是一个好主意。首先，这种人肉测试没法复用，然后为了测试稳定性，让员工连续24小时使用/测试系统，这恐怕已经侵犯员工权利了。
还有，你如何对来自100个不同员工的响应时间数据进行关联分析呢？更别提还有那么多监控指标（网络、服务器）需要关注。如果你的应用的目标用户数小于5个，这种人肉性能测试方法或许还可行，但是如果真是这样，恐怕你现在也不需要阅读这本书了。
业界有不少非常棒的性能测试工具，而且这样的工具还会越来越多。需要进行多大规模的性能测试，很大程度上决定了你使用工具的成本。好消息是，性能测试工具市场是一个充满竞争的市场，最大的不一定是最好的。因此在选择工具之前，最好多做点功课，帮助公司IT预算负责人更好地决策。附录C的列表包含了当今业内领先的性能测试工具供应商。第2章会详细讲述如何根据需求，选择最合适的性能测试工具。
1.2.9 应用技术的影响
应用开发中使用到的一些技术，可能无法使用第一代，甚至第二代自动化工具来进行压测。这样的借口已经越来越勉强了，因为如今绝大多数的应用都在一定程度上Web化了。而如今大部分自动化测试方案都能够很好地支持Web技术。
Web软件开发过程中的技术栈都慢慢开始标准化了，形成了一些核心的技术。大多数自动化工具供应商都会跟随这个节奏，推出对应支持功能。在本书第9章，我会探讨一下现在（以及老旧）的应用技术如何影响了性能测试的发展。
