性能测试的概念

什么是性能测试？性能测试的目的是什么？

常见的性能问题有哪些？

以购物软件为例：
1）购物过程中页面突然无法打开，刷新后可以重新打开
2）双十一期间无法进入商品页面
3）页面加载时间过长，需要消耗用户大量的等待时间
……

常见性能测试指标

并发数

并发数，就是服务器在某一时刻接收到的请求数量

1. 从业务层面看，并发数指的是同一时刻实际使用系统的用户总数。
2. 从后端服务器层面看，并发数指的是web服务器在一段时间内处理浏览器请求而建立的http连接数或生成的处理线程数

吞吐量

这个也很简单，指的就是服务器在单位时间1s内一共处理了多少请求

下面介绍工作中常见的用来描述吞吐量的数据

TPS

全称是Transactions Per Second，表示服务器每秒钟能处理多少条事务。计算的方法也很简单，我们只需要测量一段时间内服务器处理的事务总数，拿这个总数除以这段时间，就可以得到1s内处理的事务数量了

我们在实际计算TPS时，时间段的选取也是有讲究的，请看下面的例子

某平台统计出了双十一那天用户在平台上达成的总交易数量——10万次，程序员想要根据这个来算TPS，此时TPS = 10w次 / 24*60*60s

但是根据二八定律，很有可能双十一当天80%的交易都是发生在20%的时间内，笼统地按照上面的算法计算，就无法精准定位平台的TPS峰值。因此我们可以采用下面的算法：TPS = 0.8*10w次 / 0.2*24*60*60s，这样的算法一定是更加精准的

当然如果我们知道更具体的数据，比如统计的交易数据可以精确到小时，那我们肯定就能更精准地计算了

QPS

全称是Queries Per Second，表示服务器每秒钟能处理多少条查询请求

读到这里肯定有人会问，TPS与QPS的关系是什么呢？

• 解释TPS与QPS的关系，就等价于解释一条事务和一条请求之间的关系:
  • 通常一个事务包含多个查询请求
  • 比如一个下单操作 (Transactions ) 包含用户查询、库存查询、价格查询、创建订单等多个查询 (Query)

RPS

RPS（Requests Per Second，每秒请求数），用于表示服务器每秒处理的 HTTP 请求数量，常用于 Web 服务、API 接口的吞吐量衡量。很好理解所以不再赘述

s/KB

有时候还会用发送1KB所需的时间来表示吞吐量，这个不太常用，认识就行

响应时间

响应时间主要用来验证系统处理速度快不快

对于用户而言，软件的响应时间指的就是从用户发出请求开始，到用户看到前端页面的响应信息所需要的时间

具体到web系统，web系统的响应时间主要包含前端展现时间和系统响应时间。

• 前端展现时间：页面渲染时间。
• 系统响应时间：包含服务器、数据库、通讯网络等响应时间

下面这张图展示了从用户发出请求开始，到用户看到前端页面的响应信息的更具体的过程

并发用户、系统吞吐量、与系统响应时间的关系

可以看下下面这张图，图中横坐标表示的是并发用户数，并发用户数越多，表示系统并发量越高。图中纵坐标是用TPS表示的系统吞吐量

从上面我们可能非常直观的看出，在到达拐点之前，系统吞吐量会随着并发量的提高而提高，到达拐点之后，并发量继续提高，吞吐量却不增反降，这是为什么呢？

• 这个关键就在于饱和这个词的理解，在到达拐点之前，系统一直处于未饱和的状态，这意味着系统的各种资源还有很多是空闲的，未被利用的，这时候增加并发数，就可以让一些空闲的资源被利用起来，这样系统的吞吐量就更高了
• 到达拐点之后，系统处于饱和状态，这意味着系统的各种资源基本上都分配给各个线程了，没有处于空闲状态的资源了，此时再增加并发数，资源的利用率也不会提高了，然后随着并发数的不断提高， “线程调度、资源等待、请求排队” 等额外开销却一直不断地在提高，因此到达拐点之后并发量继续提高，吞吐量却不增反降

到这里可能有人又会问了，你这目前为止只说了并发用户与系统吞吐量的关系，还没说系统响应时间呢呀？这个其实也很简单，在到达拐点之前，系统响应时间一直都是随着并发数缓慢增加，到达拐点之后，系统响应时间迅速增加。其大致的曲线如下图绿线所示。

为什么响应时间会随着并发数的增加而增加呢？

随着并发数的提高，系统用于“线程调度、资源等待、请求排队” 上的额外时间开销也会随着提高，响应时间自然会越来越长

为什么响应时间在拐点之前缓慢增长，在拐点之后迅速增长呢？

1. 拐点之前，系统处于未饱和状态。虽然随着响应时间的增加，额外开销也在一直增加，但与此同时资源的利用率也在一直增加，
2. 服务器通常会用一个请求队列来管理 “请求队列” 机制来缓冲并发压力。当并发数超过系统的 “处理能力上限” 时，新请求会进入队列等待处理，队列长度越长，请求的整体响应时间也就越长

在上面的关系图中，拐点的含义是什么？
拐点表示的就是系统运行状态最好的点，因为这种状态下系统的吞吐量很高，并发量也很高，同时系统响应时间还很低。我们对系统做性能测试的一大目标，就是要去测定在什么条件下可以达到这个系统的拐点

资源利用率

前面响应时间就刚刚提到过资源利用率，现在我们的问题是，这个资源具体指的是什么？

• 对于一台电脑而言，它的资源可以是CPU资源、存储器资源
• 对于系统而言，它的资源还需要加上网络资源

测试性能关注点

不同人员对于系统性能的关注点是不一样的

终端用户

对于终端用户来说，用户关注的是从提交请求到收到响应所需要的时间，这包括系统响应时间和前端展现时间。

系统运维人员

系统运维人员对系统性能的关注点主要集中在系统负载和稳定性上

关注点	关注的目的
关注系统的并发与负载能力	评估系统容量上限和抗压力能力，明确系统在大量用户并发访问时的性能边界
关注系统健康与稳定性	保障系统长时间运行或高负载下的稳定，避免因资源耗尽、组件故障导致服务中断
关注系统长期运行表现	确保系统在长时间运行后仍能保持稳定性能，避免因性能衰减影响业务连续性

系统运维人员的重要职责

职责	目的
全局权衡与容量规划	实现最大并发用户数与响应时间的平衡，为系统扩容、升级等容量规划提供依据，确保资源投入的性价比
数据库与组件调优	提升数据库、中间件、缓存等关键组件的性能，通过针对性调优减少性能瓶颈，优化系统整体处理效率

组件调优的例子不好举，但是全局权衡的例子还是能举的
例如：当有以下两种方案时

• A方案：100万并发访问用户，登陆响应时间3秒
• B方案：500万并发访问用户，登陆响应时间8秒

这种情况下运维人员往往更倾向于第二种，因为B方案支持的并发量更大，并发量这一属性在全局权衡中更加重要

软件设计开发人员

软件开发人员对性能的关注点主要集中在操作设计层面，即从原理上如何提高系统的性能。比如采用更适合的数据结构与算法，降低系统操作的时间复杂度，或者采用索引的方法使得查找更快捷，还有通过高效的回收机制来防止内存泄露等等。更详细的关注点可以参考下表

关注点	关注的目的
算法设计与效率	确保算法高效无冗余，避免因算法复杂度高导致性能瓶颈，如时间复杂度、空间复杂度的优化
架构设计与可扩展性	验证架构的合理性，确保系统容量和性能可扩展，如分布式架构的负载均衡、服务拆分是否合理
数据库性能（SQL、索引等）	优化数据库查询效率，避免慢SQL、无效索引等问题，提升数据读写性能，减少数据库成为性能瓶颈的可能
代码级性能（内存、线程等）	排查内存泄漏、线程死锁等代码缺陷，确保代码在高负载下的稳定性，如JVM垃圾回收、多线程并发控制
性能最佳实践落地	确保代码符合性能最佳实践，如缓存策略的有效利用、异步处理的合理应用等，提升系统整体性能
软件性能可测试性	保障性能测试能有效开展，如代码中是否预留性能监控埋点、是否支持性能测试环境的快速搭建等

性能测试人员

测试人员的工作重点在于性能测试场景的设计、脚本的开发和执行，以及性能缺陷的排查和定位。
测试人员除了需要具有极其宽广的知识面，如系统架构，存储架构，网络架构等全局的知识，还要有大量知识积累，比如数据库SQL语句的执行计划调优、JVM垃圾回收、多线程常用问题等。这样才能做出更好的性能测试。 测试人员对性能具体的关注点如下

关注点	关注的目的
性能测试场景设计	确保测试场景能真实模拟生产环境的业务模型和负载模式，使测试结果具有参考价值
脚本开发与执行	保证性能测试脚本的正确性、可复用性和稳定性，确保测试过程顺利进行并产生可靠数据
性能指标监控与收集	实时监控关键性能指标（响应时间、吞吐量、资源利用率等），为后续分析提供数据支持
性能瓶颈定位与分析	发现系统的性能瓶颈（如CPU、内存、网络、数据库等），分析其产生原因并提出优化建议
测试结果的可复现性	确保测试结果可重复验证，避免因环境或测试过程差异导致结果失真，提高测试结论的可信度
性能测试报告撰写	清晰、全面地呈现测试过程、结果和建议，帮助开发、运维人员理解性能问题并推动优化

下面就是四种不同人员对性能的关注点对比

角色	关注点	关注目的
终端用户	业务操作的响应时间、页面加载速度、操作流畅度、稳定性	快速完成业务需求，获得流畅、无卡顿的使用体验，减少等待和操作失败的情况
系统运维人员	并发与负载能力、系统健康与稳定性、全局权衡与容量规划、数据库与组件调优、长期运行表现	评估系统容量上限和抗压力能力；保障高负载下的稳定性；平衡并发与响应时间；为扩容和优化提供依据；确保长期稳定运行
软件开发人员	算法设计与效率、架构设计与可扩展性、数据库性能（SQL、索引等）、代码级性能（内存、线程等）、性能最佳实践落地、性能可测试性	避免算法和代码导致的性能瓶颈；确保架构可扩展；优化数据库操作；防止内存泄漏/死锁等问题；提升整体性能；保障性能测试顺利进行
性能测试人员	性能测试场景设计、脚本开发与执行、性能指标监控与收集、瓶颈定位与分析、结果可复现性、报告撰写	模拟真实业务负载；确保测试过程稳定可靠；提供分析所需数据；找出并分析性能瓶颈；保证测试结论可信；为优化提供依据和推动改进

性能测试分类

基准测试

基准测试又叫单用户测试，主要就是测试系统在单用户运行情况下的各项性能指标，为多用户并发测试和混合场景测试等提供参考依据

并发测试

所谓的并发测试，就是多用户测试。并发测试的目的，不止是为了获得被测系统在多用户并发操作时的性能指标，还是为了排查系统在并发条件下会不会发生内存泄漏、线程锁、资源争用这样的问题

负载测试

负载测试的目的主要是为了测量系统的安全临界值。

这个就有点像是奥运会里面的举重比赛，举重比赛测的其实就是运动员举重的极限值，规则要求运动员要成功将杠铃举过头顶，并维持三秒钟。运动员先从比较轻的杠铃开始举重，成功之后就给这个杠铃增加重量，然后运动员接着举，一直加重到举起来不能维持三秒为止

负载测试也有一个类似的要求，比如要求系统的响应时间必须要在两秒以内，基于这个标准，我们开始先将这个系统的并发数设置为1000，测试此时系统响应时间是否符合标准，如果是，我们再将这个系统的并发数设置为2000，然后再测，如果依然符合标准，那就接着加并发数，一直加到某个值，使得此时系统的响应时间刚刚好是2s，那我们就说，我们找到了这个系统的安全临界值

压力测试

这个就比负载测试做的更绝一些，接着我们刚刚说的举重那个例子，负载测试是检测运动员能成功举起并维持3s的重量临界值，而性能测试则是测试运动员举不起来的重量临界值

正经一点儿的说法，压力测试就是一直给系统增加负载（增加并发数），一直加到系统崩了为止。因此压力测试测的是系统的崩溃临界值，而负载测试测的是系统的安全临界值

稳定性测试

测试系统在长时间运行的状态下能不能稳定于运行，这个很好理解，不再多说