目前，对软件性能最普遍的理解就是软件处理的及时性。但其实，从不同的系统类型，以及不同的视角去讨论软件性能，都会有所区别。
软件性能的关注点对于不同类型的系统，软件性能的关注点各不相同
- Web 类应用和手机端应用，一般以终端用户感受到的端到端的响应时间来描述系统的性能；
- 非交互式的应用，比如典型的电信和银行后台处理系统，响应时间关注更多的是事件处理的速度，以及单位时间的事件吞吐量。
总结为，交互式–注重响应时间；非交互式–注重吞吐量，处理事件速度。
同样的，对于同一系统，不同对象群体对软件性能和关注点也不完全相同，甚至有些时候是对立的。
关注软件性能的对象群体
终端用户是软件系统的最终使用者，他们对软件性能的反馈直接决定了这个系统的应用前景；而，软件开发人员、运维人员、性能测试人员，对性能测试的关注点则直接决定了一个系统交付到用户手中的性能。
从终端用户（也就是软件系统使用者）的维度来讲，软件性能表现为用户进行业务操作时的主观响应时间。对终端用户来讲，这个时间也短也好。
这个响应时间包含系统响应时间和前端展示时间：
- 系统响应时间，反应的是系统能力，又可以进一步细分为应用系统处理时间、数据库处理时间和网络传输时间等；
- 前端展现时间，取决于用户端的处理能力。
从这个角度来看，软件性能测试需要进行后端（服务器端）的性能测试和前端（浏览器端）的性能测试。
二、软件设计开发人员眼中的软件性能从软件系统开发（也就是软件设计开发人员）的角度来讲，软件性能关注的是性能相关的设计和实现细节，这几乎涵盖了软件设计和开发的全过程。
在软件设计开发人员眼中，软件性能通常会包含算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面。
- 核心算法的设计与实现是否高效；
- 必要时，设计上是否采用 buffer 机制以提高性能，降低 I/O；
- 是否存在潜在的内存泄露；
- 是否存在并发环境下的线程安全问题；
- 是否存在不合理的线程同步方式；
- 是否存在不合理的资源竞争。
- 站在整体系统的角度，是否可以方便地进行系统容量和性能扩展；
- 应用集群的可扩展性是否经过测试和验证；
- 缓存集群的可扩展性是否经过测试和验证；
- 数据库的可扩展性是否经过测试和验证。
- 代码实现是否遵守开发语言的性能最佳实践；
- 关键代码是否在白盒级别进行性能测试；
- 是否考虑前端性能的优化；
- 必要的时候是否采用数据压缩传输；
- 对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序。
- 数据库表设计是否高效；
- 是否引入必要的索引；
- SQL 语句的执行计划是否合理；
- SQL 语句除了功能是否要考虑性能要求；
- 数据库是否需要引入读写分离机制；
- 系统冷启动后，缓存大量不命中的时候，数据库承载的压力是否超负荷。
- 是否为性能分析（Profiler）提供必要的接口支持；
- 是否支持高并发场景下的性能打点；
- 是否支持全链路的性能分析。
需要注意的是，软件开发人员一般不会关注系统部署级别的性能，比如软件运行目标操作系统的调优、应用服务器的参数调优、数据库的参数调优、网络环境的调优等。
系统部署级别的性能测试，目前一般是在系统性能测试阶段或者系统容量规划阶段，由性能测试人员、系统架构师，以及数据库管理员（DBA）协作完成。
三、系统运维人员眼中的软件性能从软件系统运维（也就是系统运维人员）的角度，软件性能除了包括单个用户的响应时间外，更要关注大量用户并发访问时的负载，以及可能的更大负载情况下的系统健康状态、并发处理能力、当前部署的系统容量、可能的系统瓶颈、系统配置层面的调优、数据库的调优，以及长时间运行稳定性和可扩展性。
终端用户最关心的是响应时间，这也是系统运维人员关心的，但是系统运维人员必须在最大并发用户数和系统响应时间之间进行权衡取舍。比如，当有两套系统配置方案可以提供以下系统能力的时：
- 配置方案 A 可以提供 100 万并发访问用户的能力，此时用户的登录响应时间是 3 秒；
- 配置方案 B 可以提供 500万并发访问用户的能力，此时用户的登录响应时间是 8 秒。
这时，从全局利益最大化角度来看，系统具有更大并发用户承载能力的价值会更大，所以运维人员一般都会选择方案 B。
目前，有些系统为了能够承载更多的并发用户，往往会牺牲等待时间而引入预期的等待机制。 比如火车票购票系统
从这个角度来看，软件性能测试需要进行并发测试、压力测试等。
从性能工程的角度看，性能测试工程师关注的是算法设计、架构设计、性能最佳实践、数据库相关、软件性能的可测试性这五大方面。
在系统架构师、DBA，以及开发人员的协助下，性能测试人员既要能够准确把握软件的性能需求，又要能够准确定位引起“不好”性能表现的制约因素和根源，并提出相应的解决方案。
一个优秀的性能测试工程师需要具备的技能- 性能需求的总结和抽象能力；
- 根据性能测试目标，精准的性能测试场景设计和计算能力；
- 性能测试场景和性能测试脚本的开发和执行能力；
- 测试性能报告的分析解读能力；
- 性能瓶颈的快速排查和定位能力；
- 性能测试数据的设计和实现能力；
- 面对互联网产品，全链路压测的设计与执行能力，能够和系统架构师一起处理流量标记、影子数据库等的技术设计能力；
- 深入理解性能测试工具的内部实现原理，当性能测试工具有限制时，可以进行扩展二次开发；
- 极其宽广的知识面，既要有“面”的知识，比如系统架构、存储架构、网络架构等全局的知识，还要有大量“点”的知识积累，比如数据库 SQL 语句的执行计划调优、JVM 垃圾回收（GC）机制、多线程常见问题等等。
并发用户数、响应时间、系统吞吐量
并发用户数并发用户数，是性能需求与测试最常用，也是最重要的指标之一。
它包含了业务层面和后端服务器层面的两层含义：
- 业务层面的并发用户数，指的是实际使用系统的用户总数。但是，单靠这个指标并不能反映系统实际承载的压力，我们还要结合用户行为模型才能得到系统实际承载的压力。
- 后端服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。
在系统运行期间的某个时间点上，有一个指标叫作“同时向服务器发送请求的数量”，这个“同时向服务器发送请求的数量”就是服务器层面的并发用户数，这个指标同时取决于业务并发用户数和用户行为模式，而且用户行为模式占的比重较大。
分析得到准确的用户行为模式，是性能测试中的关键一环，也是除获取性能需求外最难的工作。
- 对于已经上线的系统来说，往往采用系统日志分析法获取用户行为统计和峰值并发量等重要信息；
- 而对于未上线的全新系统来说，通常的做法是参考行业中类似系统的统计信息来建模，然后分析。
通俗来讲，响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”，是用户视角软件性能的主要体现。
响应时间，分为前端展现时间和系统响应时间两部分- 前端时间，又称呈现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间；
- 而系统响应时间，又可以进一步划分为 Web 服务器时间、应用服务器时间、数据库时间，以及各服务器间通信的网络时间。
系统吞吐量，是最能直接体现软件系统负载承受能力的指标。所有对吞吐量的讨论都必须以“单位时间”作为基本前提。
我认为把“Throughput”翻译成吞吐率更贴切，因为我们可以这样理解：吞吐率 = 吞吐量 / 单位时间。但既然国内很多资料已经翻译为了“吞吐量”，所以通常情况下我们不会刻意去区分吞吐量和吞吐率，统称为吞吐量。
对性能测试而言，通常用 “Requests/Second”“Pages/Second”“Bytes/Second” 来衡量吞吐量。当然，从业务的角度来讲，吞吐量也可以用单位时间的业务处理数量来衡量。
- “Bytes/Second”和“Pages/Second”表示的吞吐量，主要受网络设置、服务器架构、应用服务器制约；
- “Requests/Second”表示的吞吐量，主要受应用服务器和应用本身实现的制约。
性能测试场景的指标，必然不是单个，需要根据实际情况组合并发用户数、响应时间这两个指标。
并发用户数、响应时间、系统吞吐量之间的关系- 当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段称为 “空闲区间”。
- 当系统整体负载并不是很大时，随着系统并发用户数的增长，系统的吞吐量也会随之呈线性增长，我们往往把这个阶段称为 “线性增长区间”。
- 随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长。相应地，系统的整体吞吐量并不会随着并发用户数的增长而继续呈线性增长。我们往往把这个阶段称为系统的“拐点”。
- 随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。
