性能压测时，并发压力增加，系统响应时间和吞吐量如何变化

性能测试



性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准，也有不同的优化手段。



• 主观视角：用户感受到的性能

• 加载页（先文字后图片）

• 客观视角：性能指标衡量的性能



做性能优化的时候，一方面提高性能指标，另一方面要考虑到提高用户的主观感受（可以利用异步操作）。架构师训练营不介绍主观视角



性能测试指标



• 相应时间 RT, Response Time：用户感受到的时间（客户端视角）。应用系统从发出请求开始到收到最后响应数据所需要的时间。直观的反映了系统的快慢

• 并发数：系统能够同时处理请求的数目，系统的负载特性。对于网站而言，并发数即系统并发用户数，指同时提交请求的用户数目。注意与在线用户数（当前登录系统的用户数）和系统用户数（可能访问系统的总用户数）的区别。一般来说，并发数不会太大，淘宝双十一高峰并发数可能是百万级别，可能同时在线数达到亿级，用户数可能超过十亿。

• 吞吐量：单位时间内系统处理的请求数量，系统的处理能力。对于网站，请求数/秒，页面数/秒，访问人数/天，处理的业务数/小时

• TPS, Transactions Per Second 每秒事务数

• 性能计数器：描述服务器或操作系统性能的数据指标，包括 System Load、对象与线程数、内存使用、CPU 使用、磁盘与网络 I/O 等指标。



其他常用指标：



• RPS, Request Per Second：每秒请求数

• CPS, Codes Per Second：HTTP 返回码每秒

• PV, Page View：页面浏览量

• UV, Unique Vistor：独立访问者

• IP, Internet Protocal：独立 IP 数

• IOPS, Input/Output Operations Per Second 磁盘



吞吐量 = ( 1000 / 响应时间 ms) × 并发数



吞吐量 Throughput 的讨论需要有时间单位，一般采用 Bytes/Second、Pages/Second 和 Request/Second 等单位。



• Bytes/Second 和 Pages/Second 表示的吞吐量，受网络设置、服务器架构、应用服务制约

• Request/Second 表示的吞吐量，受应用服务器和应用本身的制约



不同并发用户数场景下，即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也不一样。



比如 100 个并发用户，每用户每隔 1 秒发出一个 Request 和 1000 个并发用户，每隔 10 秒发出一个 Request，两个场景有相同的吞吐量 100 Request/Second，但是两个场景所占用的资源不一样，性能拐点也肯定不一样。





性能测试方法





• 性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期

• 负载测试：对系统不断增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时候继续对系统施加压力，系统的处理能力不但不能提高，反而会下降。

• 压力测试：超过安全负载的情况下，对系统继续施加压力，知道系统崩溃或不能再处理任何请求，一次获得系统最大压力承受能力。

• 稳定性测试：在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，是系统运行较长一段时间，以此检测系统是否稳定。在生产环境，请求压力是不均匀的，呈波浪特性，因此为了更好的模拟生产环境，稳定性测试也应不均匀的对系统施加压力。





究竟部署多少台服务器（资源）比较合适？是架构师需要考虑的一个决策，找到性能、价格的平衡点。架构师要清醒的知道，决策的依据到底是什么，可能的代价是什么，是否能够承担这个责任……



• 空闲区间：系统并发用户数比较少，吞吐量也低，系统处于空闲状态

• 线性增长区间：系统整体负载不大，随着并发用户数增长，吞吐量也会随之线性增长

• 拐点：系统并发用户数进一步增长，系统处理能力趋于饱和，每个用户的响应时间逐渐变长；系统整体吞吐量不会随着并发用户数增长而继续线性增长。

• 过饱和区间：系统并发用户数继续增长，系统处理能力达到过饱和状态；如果继续增加并发用户数，最终所有用户的响应时间会变得无限长；系统整体吞吐量会降为零，系统处于被压垮的状态。



Performance Testing Methodology, Quest Soft, 2005





在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。最后，响应时间过长，达到了超时的程度。



——《02丨性能综述：TPS和响应时间之间是什么关系？》 性能测试实战30讲



通常从两个层面定义性能场景的需求指标：业务指标和技术指标。



所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。