下载掌阅APP，畅读海量书库
立即打开
在计算机领域，performance被翻译为“性能”。但是在生活中，performance一词包含了许多含义，例如，职场人的performance指的是绩效，而performance review则是每年都会进行的绩效考核。
如果在互联网上搜索一下，那么大多数与“性能”有关的热门文章都与计算机软件执行任务所需的时间有关。响应时间是任务执行的持续时间，以每个任务的时间为单位。例如，在百度上搜索“性能”，响应时间约为200ms。在浏览器中可以通过某些方式查看这个结果，这就是网页搜索的性能证据。因此，对于计算机用户来说，性能通常被等同于软件执行某项任务所需的时间。
然而，当我们在个人笔记本计算机上编译Android操作系统源代码时，往往需要漫长的等待，有时可能会面临无法成功编译的尴尬。这通常被归咎于笔记本计算机的系统性能不足。这时的性能又与软件执行的环境密切相关。那么，什么是软件的性能呢？
本章先从宏观上介绍与软件性能相关的因素；然后从宏观和微观两个层面讨论软件性能的定义；接着从时间和空间的角度来探讨软件的性能指标，了解其描述方式和相关工具；最后通过性能测试和监控来感知并保障软件系统的性能。
从宏观上讲，软件性能指的是软件在运行时完成某一功能的响应特性，以及在增加软件功能时保持这些响应特性的能力。
从控制论的角度看，软件一般包括4个要素：系统边界、内部结构、外部效应（输出）和连接输入。
· 系统边界：管理系统可以启用有用的入口（可扩展性）并拒绝有害的入口（安全性）。
· 内部结构：控制和维护系统以适应外部变化（灵活性）和内部变化（可靠性）。
· 外部效应：管理环境的直接变更，以最大化提高外部效果（功能性）降低内部工作量（可用性）。
· 连接输入：管理对环境的感知，以支持数据交换（联通性）和限制数据交换（隐私性）。
每个人都有自己的皮肤边界，内部有大脑、器官和循环系统等，还有骨骼和肌肉等的行动输出以及感觉输入。与之类似，计算机有物理外壳、主板结构、屏幕这样的输出效应器，以及键盘、鼠标这样的“接收器”；而软件则有内存边界、内部程序的结构以及专门的输入/输出模块或子系统。
每个元素在软件性能中都扮演着各自的角色，它们必须与环境成功地进行交互。如果成功交互，则可以最大化系统的受益机会，并使系统受损风险最小化，将4个一般要素与2个一般环境交互类型（机会行动和风险行动）相结合，就可以得出软件性能的8个一般性能目标，如图2-1所示。
图2-1 软件性能的宏观多维模型
软件性能的宏观多维模型也可以用图2-1所示的网络来表示，其中，一个点到中心的距离表示该维度的性能指标的高低程度。这个网络中呈现的区域由一个形状和目标之间的张力组成。形状描述了系统的性能，它会随着环境的变化而变化，例如，威胁环境可能需要更多的安全性。连接线表示目标之间的相互作用，也就是张力。可以将连接线想象成具有不同张力的橡皮筋，它们连接着性能的各个维度，因此，增加一个维度的性能指标可能会突然改变另一个维度的性能指标。
一个系统的边界决定了什么可以进入和离开，可以被设计用来抵御外部威胁（安全性）和接收外部数据的机会（可扩展性）。
可扩展性表示一个系统利用外部元素的能力（例如，软件可以拥有扩展插件）。程序可以使用第三方插件，这相当于一只开放的人工手使用工具。然而，要实现扩展性，必须有一个已知的链接形式，这就如同一辆汽车要通过拖车来延伸自己，它的拖钩必须与拖车的拖链相匹配。开放标准就具有这种优点，它代表了开放源码的价值。可扩展性是影响软件性能的关键因素。
安全性是软件性能的关键部分，是软件防止未经授权而进入、滥用或接管的能力。软件拥有登录账号和密码，就是一种常见的确保安全性的方法。安全硬件是密封且防篡改的，进入-拒绝原则适用于硬件和软件两种环境。病毒和黑客的威胁使边界防火墙和登录检查系统显得至关重要。安全缺陷是系统故障，也是性能故障。
软件的内部结构可以用于管理内部变化（可靠性）或外部变化（灵活性）。
灵活性是指软件在新环境中工作的能力。就像履带协助车辆在复杂地形中工作一样，移动设备可以在复杂的网络区域接收信号。CSMA/CD协议的性能优于更可靠但不灵活的轮询协议。灵活的关系型数据库取代了更有效但不灵活的数据模型。大多数现代软件都有一个参数设置模块（如Windows控制面板）来为硬件、软件或用户环境提供配置服务。灵活性是软件性能的另一个关键。
高可靠性意味着一个软件在内部发生变化（如部分故障）的情况下仍然能够正常运行。可靠的系统几乎总是可用的，无论多大的压力或负载，都能够生存，即便由于受到影响不能提供全量服务，也可以优雅地退化降级，而不是灾难性地崩溃。在软件中，与可靠性相关的指标主要有两个：平均故障间隔时间，表征的是随着时间的推移系统无故障运行的概率；快速恢复，常通过代码修复或状态回滚实现。可靠性是至关重要的软件性能。
系统效应器可以改变外部环境（外部效应），设计系统效应器的目标是让效应（功能性）最大，让产生这种效应的成本（可用性）最小。
功能性是指系统直接作用于其环境以产生预期变化的能力。关注功能性需求可以生成功能性很强的软件。因为人们都有为获得新能力而升级软件的需求，因此功能性在软件性能中非常重要，甚至是系统存在的根本。
可用性是指软件以最小化成本提供对应功能的能力。在工作中使用更少的代码实现相同的功能往往意味着可用性更高，因为常规来说，精简指令集的可用性都会优于复杂指令集。轻量级软件在后台运行会更为良好，本质原因也是这个，因为它使用的CPU或内存资源更少。
连接输入部分既可以支持信息交换（联通性），又可以限制信息交换（隐私性）。
联通性表征系统与其他系统通信的能力。有时我们会将行为与效应器联系起来，即让行为发生在以感觉为引导的反馈回路中。有时我们会将信息和受体联系起来，因为只有经过受体处理的信息才有意义，即使是交流行为，也需要效应器的参与。信息交流的最终结果来自受体以及随后产生的加工行为。对于现代软件来说，联通性几乎是必需的。
隐私性表征软件控制自身信息发布的能力。隐私性有时用保密性来代替，保密性是工程师从软件的角度给出的名称，而隐私性则是从用户的角度给出的名称。在技术环境中，隐私性是软件性能的关键组成部分。
软件性能的多维模型在概念上是模块化的，彼此并不重叠。理论上，任何维度上的性能都可以与其他维度相结合。在设计实践中，软件必须满足所有需求，其中各维度之间可能没有必然的关系。
虽然性能可以被认为是绝对的，但软件性能的多维模型将性能视为相对于环境的性能，因此性能没有一个“完美”的形式。在图2-1所示的8个指标中，4个是成功指标——功能性、灵活性、可扩展性和联通性，4个是避免失败的指标——安全性、可靠性、隐私性和可用性。
我们要知道，环境可能会发生变化，无论是机会还是风险，都会为环境带来影响。机会行动可以给对应的软件带来好处，风险行动可能损害软件，所以机会行动和风险行动都可能为环境带来影响，迅速改变收益和损失关系。
因为环境可以变化，所以环境类型多样。如果性能有一个形状和一个区域，那么就可以用不同的形状去适合不同的环境。软件性能的多维模型通过为性能的各个维度分配权重，帮助开发人员确定适合环境的性能形状。
软件性能的多维模型给了我们宏观上的理论方向。在系统层面和更小的粒度上，它还可以提供更多实际指导。
性能是软件的一种非功能特性，可以定义为“ 软件与其环境交互以获得价值和避免损失的程度 ”。它不仅关注软件是否能够完成特定的功能，还关注软件在完成该功能时展示出来的时空属性。换句话说，性能就是在空间资源和时间资源有限的条件下，表征软件是否能够正常工作的指标。软件的性能是建立在软件所实现的功能基础之上的，软件的功能关注的是软件做了什么，软件的性能关注的是软件做得如何。因此，性能是对综合资源和速度的考量，对“空间”和“时间”都具有高敏感度。
狭义上，软件性能指的是在尽可能少地占用系统资源的前提下，尽可能提高运行速度；广义上，软件性能指的是软件的质量属性，包括正确性、可靠性、易用性、安全性、可扩展性、兼容性和可移植性等。软件的性能是对整个软件的整体考量，既包括所有的硬件组件和整个软件栈，也包括所有数据在流动路径上和软硬件上所发生的事情。软件性能取决于各种资源的平衡，这类似于木桶理论，某种资源的耗尽会严重阻碍软件的性能。
软件的性能可以通过客观指标与主观感受来描述和评价。从客观的角度来看，可以用性能指标来描述软件的性能。而从主观的角度来看，由于软件的性能是由人来感受的，不同的人对于同样的软件可能会有不同的主观感受，这与软件的用户体验相关。
ISO 9241-210:2019中这样描述用户体验：人们对使用或期望使用的产品、系统或者服务的认知、印象和回应。用户体验是主观的，所以会更注重实际应用效果。ISO在定义的补充说明中有如下解释：用户体验是指用户在使用一个产品或系统之前、使用期间和使用之后的全部感受，包括情感、信仰、喜好、认知印象、生理和心理反应、行为、成就等各个方面。因此，许多因素都可以影响用户体验，这些因素被分为三大类：使用者的状态、系统性能及环境。其中，系统性能被认为是软件产品自身影响用户体验的关键因素。不同的人关注软件性能的视角也不同。对使用软件的用户而言，更关注及时性；对软件服务或软件产品提供者而言，既关注时间因素，又关注空间使用率，是多种因素的权衡。
因此，软件的性能是指软件在运行过程中表现出来的时间效率、空间效率与用户需求之间的吻合程度。如果时间效率、空间效率与用户的心理期待一致，或者能够达到用户的具体要求，那么用户就会认为这款软件的性能符合要求；反之，用户会认为这款软件的性能有问题，或者难以接受。
从时空的视角来看，性能是指在完成某项任务时所展示出来的及时性和空间资源的有效性。
性能指标是衡量性能的尺度。从时间的维度来看，性能指标包括响应时间、延时时间等；从空间的维度来看，性能指标包括吞吐量、并发用户数和资源利用率等，此外，还有故障响应时间指标。故障响应时间是指软件从出现故障到确认修复前的时间，该指标通常用于反映服务水平。显然，平均故障响应时间越短，故障对用户系统的影响越小。
响应时间指系统对用户请求做出响应的时间，与人对软件性能的主观感受一致。它完整地记录了软件处理请求的时间。由于一款软件通常会提供许多功能，不同功能的处理逻辑也千差万别，因此不同功能的响应时间也不尽相同，甚至同一功能在不同环境（如输入的数据不同）下的响应时间也不相同。因此，响应时间通常是指该软件所有功能的平均响应时间或者所有功能中的最大响应时间。当然，有时候也需要针对每个或每组功能讨论其平均响应时间和最大响应时间。
软件的响应时间是我们所关注的关键性能指标，而影响响应时间的主要因素涉及各种各样的延时，下面介绍两种延时的抽象模型。
1.排队延时
负载和响应时间之间的数学关系是众所周知的。一个称为M/M/m的排队模型将响应时间与满足一组特定需求的系统负载联系了起来。M/M/m有一个假设，即系统具有“理论上的完美可伸缩性”。尽管这个假设有些过分，但M/M/m在性能方面还是有很多值得我们学习的地方。在低负载时，响应时间基本上与空负载时的响应时间相同。随着负载的增加，响应时间会逐渐缩短。这种逐渐的退化并没有造成太大的危害，但是随着负载持续上升，响应时间开始以一种不再轻微的渐变方式退化。这种退化令人不爽，而且是呈现双曲线趋势的。
在M/M/m中，响应时间（r）由两个部分组成：服务时间（s）和排队延时（q）。服务时间是任务消耗给定资源的时间，以每个任务执行的时间为单位。排队延时是指任务排队等待使用给定资源的时间。排队延时也可以用每个任务执行的时间来度量，此时指给定任务的响应时间与卸载系统上同一任务的响应时间之间的差异（不要忘记“理论上完美可伸缩性”的假设）。
2.相干延时
相干延时是由于任务的有序性执行造成的时间延迟，无法使用M/M/m排队模型。这是因为M/M/m假设所有 m 个服务通道都是并行、同构且独立的，这意味着M/M/m假设当某用户在先进先出队列中等待足够长的时间，并且前面排队的所有请求都已经退出服务队列后，才会轮到该用户接收服务。然而，相干延时并不遵循这种工作方式。
假设有一个HTML数据输入表单，其中，Update（更新）按钮用于执行SQL Update语句，Save（保存）按钮用于执行SQL commit（提交）语句，用这种方式构建的软件几乎可以直接看到性能的糟糕程度。这对于希望更新同一行数据的其他任务来说，带来的影响可能是毁灭性的。每个任务都必须等待该行的锁定（在某些系统上，可能是更糟糕的页锁定），直到锁定用户决定继续下面的工作并单击Save按钮，或者直到数据库管理员终止用户的会话。
在这种情况下，任务等待释放锁的时间与系统的繁忙程度无关，而是取决于系统各种资源利用以外的随机因素。这就是为什么永远不能假设在单元测试环境中执行的性能测试能够决定是否将新代码插入生产系统。
软件性能的空间指标包括吞吐量、系统所支持的用户总数、并发用户数和资源利用率等。吞吐量是指系统在单位时间内处理请求的数量。对于无并发功能的软件而言，吞吐量与响应时间呈严格的反比关系，实际上，此时的吞吐量就是响应时间的倒数。无并发的软件都是单机应用的。对于互联网或者移动互联网上的产品而言，并发用户数是指系统可以同时承载的正常使用软件功能的用户数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。资源利用率反映的是在一段时间内资源平均被占用的情况，一个主要的度量指标就是负载，另一个是数据倾斜。
1.负载
许多人不明白，为什么让一个程序变得更有效率会给系统中的其他程序带来性能改进，而这些程序与正在修复的程序没有明显的关系。其实，这是由于负载对系统的影响。
负载是指由并发任务执行引起的资源竞争，这就是性能测试难以捕捉到生产后期出现的所有性能问题的原因。负载的一个度量指标是利用率。
利用率=使用的资源/指定时间间隔内的资源容量
随着资源利用率的提高，用户从该资源请求服务时的响应时间也会增加。这就如同交通非常拥挤时，必然会导致等红绿灯的时间变长。
软件运行环境中的CPU在每个时钟周期内都有固定的指令数量，这就会让软件总是以同样的速度运行，但是响应时间肯定会随着系统资源使用的增加而受到影响。在分布式系统中，数据在不同空间的存储位置同样会对软件的性能产生影响。
2.数据倾斜
假设有 x 个数据库调用，调用操作占用了 y 秒的响应时间。如果能消除一半的调用量，那么能消除多少不必要的响应时间呢？答案往往出人意料，几乎从来不是“一半的响应时间”，能消除的响应时间取决于我们可以消除的单个调用的响应时间。不能假设每个调用平均的持续时间为 y / x 秒，因为语句没有告诉我们调用的持续时间是一致的。
数据倾斜用于表征具体调用中的不一致性。因为存在数据出现倾斜的可能性，所以无法对软件的响应时间提供准确预估。在不了解任何有关数据倾斜信息的情况下，可以提供的答案可能是“响应时间在0～ y 秒之间”。但是，假设有具体的附加信息，就可以对最佳情况和最差情况进行估算。在数据库应用中，读写分离也只是大粒度分隔数据倾斜的一种方式。
由于时空的内在联系，系统性能的时空指标往往具有较强的相关性。以吞吐量和响应时间这两个重要的指标为例，吞吐量和响应时间通常相互关联，但并不完全相同，真正的关系是微妙而复杂的。
1.并发通信中的吞吐量与响应时间
假设某个基准测试以每秒1000个任务的速度测量了吞吐量，那么用户的平均响应时间是多少呢？人们很容易认为每个任务的平均响应时间是0.001s，但事实并非如此。如果处理这个吞吐量的系统有1000个并行、独立且同质的服务通道，那么每个请求可能正好消耗1s。
现在我们知道每个任务的平均响应时间在0～1s之间。然而，不能仅从吞吐量测量中推导出响应时间，必须单独测量它。当然，有些数学模型可以计算给定吞吐量下的响应时间，但是模型需要更多的输入，而不仅是吞吐量。
2.计算环境中的吞吐量与响应时间
计算环境展示了吞吐量和响应时间之间的微妙关系。如果需要在单个CPU的计算机上编程以实现每秒100个新任务的吞吐量，假设编写的新任务在计算机系统上的执行仅需0.001s，那么是否能够达到所需的吞吐量？如果能够在0.001s内运行一次任务，那么肯定可以在1s内至少运行100次。例如，如果任务请求被很好地序列化，就可以在一个循环中依次处理这100个任务。
然而，如果每秒100个任务随机出现在系统上，即100个不同的用户登录到单个CPU计算机上，那么会发生什么呢？CPU调度器和序列化资源可能会将吞吐量限制在远低于每秒100个任务的范围内，因此不能仅凭对响应时间的度量来推导出吞吐量，还需要进行单独的测量。
响应时间和吞吐量并不一定相反。要了解这两者之间的关系，需要同时测量它们。哪一个更重要呢？对于给定的情况，可以从两个方向上合理地寻找答案。在许多情况下，两者都需要管理的核心性能指标。例如，系统可能有一个业务需求，要求在99%以上的系统响应，给定任务的响应时间必须小于1s，同时系统必须支持在1s的间隔内持续执行1000个任务。
软件的时空架构决定了软件性能的时空约束。而软件时空属性自身的复杂性与多样性也导致了软件性能指标的丰富性。不同的业务系统、子系统乃至功能模型之间都存在着共同的性能指标，如延时、资源利用率等。同时也存在着各自的差异性指标，如前端系统的最大绘制内容（LCP）、累积布局偏移（CLS）等。常见的部分性能指标及其介绍如表2-1所示。
表2-1 常见的部分性能指标及其介绍
表2-1中涉及的性能指标是一些关键指标，寻找各种软件性能指标的完备集是非常困难的。根据软件业务需求的多样性，会产生许多复合指标。有些性能指标可以直接度量，而有些则只能通过度量指标以间接计算的方式得到。很多时候，大家也把度量指标当作性能指标进行讨论。
“在99%以上的系统响应”是对响应时间的期望限定，有些人更倾向于使用“平均响应时间必须是×秒”来描述响应时间。想象一下，对每天在计算机上执行的某项任务来说，我们可能容忍的响应时间是1s。假设，a系统90%的平均响应时间是1s，b系统60%的平均响应时间是1s，那么对于a系统，会有10%的用户不满意，而对于b系统，会有40%的用户不满意吗？如果在a系统中，90%的响应时间是0.91s；在b系统中，90%的响应时间是1.07s，那么仅说1.00s的平均响应时间可能更有意义。
在统计学中，我们尝试用两个可能的数值来描述世界，一个是均值，另一个是方差。客户感受到的可能是方差，而不是均值。将响应时间表示为百分数，可以产生与最终用户期望相符的性能描述，并且令人信服。例如，“动态库加载”任务必须在至少99.99%的执行中在0.5s以内完成。
一切抽象都可以归结为数学，一切结果都可以归结为概率。所以，我们可以用概率来描述软件的性能，例如，“在许多情况下，系统的响应时间不超过2s，然而至少有95%的关键任务响应时间在1s以内”，这才是我们应该追求的性能描述方式。
时序图是UML指定的一种图形，用于按照交互发生的顺序显示对象之间的交互。在可视化响应时间方面，时序图是一个非常有用的工具。
在时序图中，每个进入的“请求”箭头和相应的“响应”箭头之间的距离与服务请求所花费的时间成正比。这样的时序图可以表示组件如何花费时间。
时序图不仅可以帮助人们概念化给定系统中的响应时间是如何被消耗的，还可以很好地显示同步处理线程是如何并行工作的。
除了分析业务外，时序图还可以分析性能，但需要系统性思考性能，还需要其他内容。假设修复任务的响应时间为2048s，在这段时间内，运行该任务将导致软件服务器执行320000个数据库调用。在软件和数据库层之间有太多的请求和响应，以至于看不到任何细节。也就是说，在一个很长的滚动条上打印时序图并不是一个好的解决方案。
时序图可以概念化控制流和相应的时间流，可以作为时间上的“利刃”，那么有空间上的“利刃”吗？
直方图一般可以确切地显示慢速任务在哪里消耗了时间。例如，可以推导出概要描述中标识的每个函数，以及函数调用响应时间所占的百分比，还可以推导出任务期间调用每种类型函数的平均响应时间。简单描述是响应时间的表格分解，通常按组件响应时间贡献降序列出。
如果可以深入聚合为单个调用的持续时间的维度，就可以知道有多少调用对应于某个函数的其他调用，并且可以知道每个调用消耗了多少响应时间。针对“这个任务应该运行多长时间”的问题，可以使用组件描述的直方图给出答案。
没有任何模型是完美的，因此性能测试是不可或缺的。在模型计算和性能测试中，很可能预见实际生产中会遇到的问题。除了进行性能测试外，还需要对线上系统进行监控，以感知软件的性能拐点，并通过容量规划以及其他技术手段对系统进行性能优化。
如何对一个新软件进行足够的测试，以确保不会因为性能问题而破坏生产环境？有些人认为性能测试是徒劳的，因此完全有理由不进行性能测试。千万不要有这种心态，因为只要在生产环境上线之前进行测试，就有很大可能发现许多问题。一旦抱有尝试甚至抵触的情绪，测试就可能变得敷衍。
在性能测试中，虽然永远不可能发现所有问题，但这正是需要一个可靠而高效的方法来解决上线前测试过程中遗漏问题的原因。不要跳过性能测试。至少，在解决上线操作过程中不可避免地出现的性能问题时，性能测试计划会使我们成为更有能力的问题诊断专家和更清晰的思考者。
回归到对吞吐量和响应时间的测量。吞吐量通常容易测量，而测量响应时间要困难得多。用秒表计算终端用户操作所需的时间可能并不困难，但要获得真正需要的数据可能非常困难，这就是要深入研究响应时间细节的原因。不幸的是，人们更倾向于测量容易测量的东西，而不一定是他们应该测量的东西。在评估真实系统的细节时，需要充分考虑系统允许获得的测量数据的质量。
再次回归到有关性能的两个非常重要的指标——最佳响应时间和最佳吞吐量，这两个目标是矛盾的。优化第一个目标需要最小化系统的负载，而优化第二个目标则需要最大化系统负载。在两者之间找到一个负载级别，得到的平衡点就是系统的最佳状态。这个最佳平衡点是资源利用的性能拐点。在拐点处，吞吐量是最大化的，对响应时间的负面影响最小化。在数学上，拐点是响应时间除以利用率的值达到最小的点。拐点的最佳位置是通过原点的一条直线相切于响应时间曲线的点。
为什么拐点如此重要？对于具有随机服务请求的系统来说，允许持续资源负载超过拐点负载，会导致响应时间和吞吐量在负载微小变化时剧烈波动。因此，对于随机请求到达的系统，管理负载以使其不超过拐点负载是至关重要的。即使系统可以完美地伸缩，一旦平均负载超过拐点负载，就会遇到大量的性能问题。而且，实际系统性能往往达不到模型中假设的性能。因此，性能拐点的利用率更具约束性。
总而言之，系统中的每个资源都有一个拐点。在一个随机请求的系统中，如果任何资源的持续利用率超过拐点值，就会遇到性能问题。因此，负载管理至关重要，管理的目标是确保资源利用率不超过系统的拐点。
有些系统可能没有完全确定的作业计划。如果访问者可以完全确定进入系统，这意味着可以准确地知道下一个服务请求什么时候到达，那么就可以提前规划，让系统临时超过阈值利用资源，而这可能不会造成性能问题。在一个确定到达的系统上，负载管理的目标是达到100%的资源利用率，而不是让如此多的工作负载排队等待。
容量规划是一项复杂的技术，其目标约束有以下几点：在高峰时间内，对于给定资源的目标容量，可以顺畅地完成任务而不超过拐点。
如果利用率低于拐点，那么系统性能大致呈线性。如果系统中的任何资源超过了它们的拐点，就会出现性能问题。当出现性能问题时，不需要花时间进行数学建模，而应通过重新安排负载、减少负载或增加容量来尽快修复这些问题。
拐点在随机访问的系统中非常重要，因为它们倾向于聚集并导致短暂的利用率峰值。这些峰值需要足够的空闲容量来处理，这样用户就不必忍受每次峰值发生时明显的队列延迟（这会导致明显的响应时间波动）。
对于给定的资源，只要持续时间不超过几秒，暂时超过拐点的利用率都是可以接受的。那么，具体多少秒算是太长呢？如果无法满足基于百分比的响应时间承诺或吞吐量承诺，那么峰值持续时间就太长了。根据经验，应至少确保峰值持续时间不超过8s。
如果可能，我们希望将性能视为软件应用的一个功能，就像在Bug（缺陷）跟踪系统中展示的那样。然而，类似于许多其他的软件特性，在编写、学习、设计和创建软件时，我们无法确切地知道软件性能如何。对于许多软件来说，直到进入生产阶段，性能仍然是完全未知的。既然我们不知道软件在生产环境中的性能如何，那么在编写程序时，就应该考虑怎么做才能轻松地修复性能问题。编写在生产环境中容易修复的软件，通常是以在生产环境中容易测量的软件为起点的。
在谈到生产环境性能度量时，人们通常会担心性能度量的影响。具有额外代码路径来进行计时的软件会比没有额外代码路径的软件运行速度慢吗？过早优化是一切罪恶的根源吗？将性能度量整合到产品中更有可能创建一个可快速运行的软件，更重要的是更可能打造一个随着时间推移运行变得更快的软件。
性能就像任何其他特性一样，不会自然而然地发生，而是需要经过设计和构建。要做好性能，必须考虑它，研究它，为它编写额外的代码，测试它，并最终获得它。