衡量软件性能三大常用指标：并发用户数、响应时间、系统吞吐量

并发用户数，是性能需求与测试最常用，也是最重要的指标之一。它包含了业务层面和后端服务器层面 的两层含义。

• 业务层面的并发用户数，指的是实际使用系统的用户总数。但是，单靠这个指标并不能反映系统实 际承载的压力，我们还要结合用户行为模型才能得到系统实际承载的压力。
• 后端服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。

响应时间

通俗来讲，响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到 客户端接收到最后一个字节数据所消耗的时间”，是用户视角软件性能的主要体现。

响应时间，分为前端展现时间和系统响应时间两部分。其中，前端时间，又称呈现时间，取决于客户端 收到服务器返回的数据后渲染页面所消耗的时间；而系统响应时间，又可以进一步划分为Web服务器时 间、应用服务器时间、数据库时间，以及各服务器间通信的网络时间。

严格来讲，响应时间应该包含两层含义：技术层面的标准定义和基于用户主观感受时间的定义。 而在性能测试过程中，我们应该使用哪个层面的含义将取决于性能测试的类型。显然，对于软件服务器端的性能测试肯定要采用标准定义，而对于前端性能评估，则应该采用用户主观感受时间的定义。

系统吞吐量

系统吞吐量，是最能直接体现软件系统负载承受能力的指标。

这里需要注意的是，所有对吞吐量的讨论都必须以“单位时间”作为基本前提。其实，我认为 把“Throughput”翻译成吞吐率更贴切，因为我们可以这样理解：吞吐率=吞吐量/单位时间。但既然国内很多资料已经翻译为了“吞吐量”，所以通常情况下我们不会刻意去区分吞吐量和吞吐率，统称为吞吐 量。

对性能测试而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”来衡量吞吐量。当然，从 业务的角度来讲，吞吐量也可以用单位时间的业务处理数量来衡量。

以不同方式表达的吞吐量可以说明不同层次的问题。比如：

“Bytes/Second”和“Pages/Second”表示的吞吐量，主要受网络设置、服务器架构、应用服务器制 约； “Requests/Second”表示的吞吐量，主要受应用服务器和应用本身实现的制约。

这里需要特别注意的是：虽说吞吐量可以反映服务器承受负载的情况，但在不同并发用户数的场景下， 即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也会相差甚远。

并发用户数、响应时间、系统吞吐量之间关系

• 当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段 称为 “空闲区间”。

• 当系统整体负载并不是很大时，随着系统并发用户数的增长，系统的吞吐量也会随之呈线 性增长，我们往往把这个阶段称为 “线性增长区间”。

• 随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应 时间会逐渐变长。相应地，系统的整体吞吐量并不会随着并发用户数的增长而继续呈线性 增长。我们往往把这个阶段称为系统的“拐点”。
• 随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用 户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系 统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。