约 12 分钟8 张卡

性能测试

性能测试是在明确的环境和负载下，测量系统完成任务的速度、容量、资源消耗和稳定性。一个“每秒 1000 次”的结果，只有同时说明请求内容、成功标准、延迟、错误率和运行条件，才有判断价值。

性能面试需要解释实验如何支持结论：流量是不是预期业务，发出的压力是否达到目标，服务在哪个环节等待，以及增加负载后会怎样变化。工具线程数只是方案的一项配置。

1. 面试核心

先记住这几条，再读正文

先定义业务操作、数据分布、负载变化和验收条件，容量结论必须带环境与质量约束。卡 · 目标、负载与环境
并发表示同时存在的活动，吞吐表示单位时间完成的工作；虚拟用户数不等于每秒请求数。卡 · 并发、吞吐与事务
高连接数测试要分别记录建连速率、稳定存活连接数和连接上的业务负载，空闲连接能保持不代表消息处理也达标。卡 · 综合题
RPS 统计请求，TPS 统计定义好的事务；一个业务事务可以包含多个请求，比较前必须统一计数口径。卡 · 并发、吞吐与事务
固定用户等待响应后再发下一次，会在服务变慢时减少新请求；固定到达速率与固定并发模拟的是不同条件。卡 · 开放与封闭负载模型
平均值会隐藏慢请求，延迟分布、错误率与吞吐应一起看，超时和失败不能从报告中消失。卡 · 延迟分布与错误
瓶颈需要客户端、服务端和依赖的对应证据，CPU 不高也可能因锁、连接池或外部依赖而受限。卡 · 执行过程与瓶颈证据
长时间稳定性关注资源、队列和错误随时间的变化，短时峰值通过不能证明长期可持续。卡 · 目标、负载与环境

2. 目标、负载与环境

卡 · 怎样设计并说明一次接口性能测试？卡 · 短时压测通过后，稳定性测试还需要观察什么？

性能方案从要回答的问题出发。验证预计业务量、寻找失效点、观察突发恢复和寻找资源泄漏，需要不同的负载过程。

测试目标	负载安排	主要观察
预期负载下的性能	在目标业务量保持足够的观察窗口	成功率、延迟、资源和积压
容量与压力边界	分阶段增加负载，观察接近或超过限制的行为	拐点、限流、排队、错误和恢复
突发变化	明确幅度地快速升降负载	扩容延迟、瞬时积压和恢复时间
长时间稳定性	在有代表性的持续负载下运行	内存、连接、磁盘、队列及错误趋势

这些名称不决定一套固定参数。具体时长、阶梯和阈值要由业务周期、风险和资源约束确定。例如寻找连接泄漏，需要观察连接数是否随着重复业务持续增长，几秒钟成功请求不足以支持结论。

负载至少要描述操作比例、请求数据、账号与热点、读写关系、思考时间和重试行为。所有请求都访问一个缓存键，和访问大量不同记录，可能得到完全不同的结果。只用新建空库也可能遗漏真实查询成本。

环境记录包括实际版本、实例数、资源限制、数据规模和依赖拓扑，具体范围见测试环境。先确认脚本的功能结果和清理正确，再放大负载；否则可能高效地测量一条错误路径。

验收条件应能被测量，例如“目标操作比例和数据分布下，在稳态窗口内成功事务吞吐达到某值，p95 延迟及业务错误率不超过规定上限”。这里的数值来自产品目标或容量假设，不能从工具默认配置反推。

3. 并发、吞吐与事务

卡 · 并发用户数、并发请求数和吞吐量有什么区别？卡 · TPS 与 RPS 有什么区别？卡 · 怎样测试十万以上并发连接？

并发数描述某个时刻同时存在的活动数量。报告必须说清是在线用户、活跃虚拟用户、未完成请求还是服务端执行中的任务，它们不相等。

吞吐量描述单位时间完成的工作量。HTTP 请求可以用 RPS（requests per second）计数；业务事务可以用 TPS（transactions per second）计数。这里的事务指测试约定的一组业务操作，不必是数据库事务。

例如一次“提交订单”包含查询商品、提交订单和读取结果 3 个请求。如果 60 秒内有 600 个业务事务成功完成，并恰好产生 1800 个完成请求，则平均为 10 个成功事务每秒、30 个完成请求每秒。若包含失败、重试或提前退出，两者就不一定保持三倍关系。

工具中的采样吞吐还可能把事务父样本和子请求分开统计，因此应明确统计对象。不能把任意采样总数都命名成业务 TPS。

固定 50 个虚拟用户，各自等待一个请求完成后才继续发送，在不含思考时间且平均响应约 0.1 秒的简化稳态下，大约能产生 50 / 0.1 = 500 次请求每秒。响应变为 0.5 秒时，同样 50 个用户约为 100 次每秒。这个估算解释了线程数为什么不能直接作为 RPS。

4. 开放与封闭负载模型

卡 · 目标每秒进入 200 个请求，为什么固定线程数可能测不出这个条件？

封闭负载模型由固定数量的用户反复执行任务，下一轮开始依赖上一轮结束，可能还包括思考时间。它适合表达“这些用户每做完一轮才继续”的行为。

开放负载模型按独立的到达计划开始新任务，不以先前任务完成为前提。它适合表达外部请求持续进入的情况；系统变慢时，未完成任务可能累积。

假设目标是每秒有 200 个新请求到达。用少量线程同步等待响应，在服务变慢时可能只能发出每秒 80 个请求。如果报告仍说“200 RPS 下通过”，就把配置目标当成了实际负载。

必须同时记录计划到达、实际启动、完成、失败和未能启动的数量。负载发生器资源不足、线程不足或调度延迟，同样会让实际压力偏离目标。时间测量还要说明从计划开始、实际发送还是服务接收时起算，避免漏掉排队等待。

没有一种模型对所有产品都正确。根据真实用户或上游行为选择模型，再确认工具怎样实现这个模型。限速计时器只能推迟请求，不能凭空增加执行资源，也不能保证服务器一定达到目标吞吐。

5. 延迟分布与错误

卡 · 平均响应时间正常，能否认定性能达标？

响应时间通常是客户端从发送操作到完成接收所经历的时间；服务端处理时间只覆盖内部一部分。连接建立、网络、连接池排队和客户端等待都可能使二者不同，工具中 latency 等字段的具体含义也要核对。

分位数描述排好序的样本中某个位置的值。p95 帮助观察较慢的一端，但不同统计实现可能使用不同插值规则；比较数据时应保持口径一致。

下面用明确的“向上取整排名”规则展示平均值的局限，单位为毫秒：

from math import ceil
from statistics import mean

samples = [20] * 95 + [2000] * 5


def percentile(values, fraction):
    ordered = sorted(values)
    return ordered[ceil(len(ordered) * fraction) - 1]


print(mean(samples))
print(percentile(samples, 0.95))
print(percentile(samples, 0.99))

输出依次为 119、20、2000。平均 119 毫秒不能让读者看出其中 5 次等待了 2 秒；单独看 p95 也会遗漏更尾部的慢请求。本函数只用于非空样本和 0 < fraction <= 1 的演示，不是完整统计库。

错误也需要单独解释。服务过载后立即拒绝请求，平均响应时间可能反而下降，但这并不代表业务性能提高。应区分成功与失败请求的延迟，报告超时、协议错误和业务断言失败，并保留各自数量。

超时样本只能说明等待至少达到超时阈值后仍未完成，不能把超时阈值当作真实完成时间，也不能悄悄丢弃。按时间窗口观察趋势，并按接口、数据范围或实例分层，可以避免汇总值掩盖局部问题。

6. 执行过程与瓶颈证据

卡 · 怎样设计并说明一次接口性能测试？卡 · 吞吐不再增加但 CPU 不高，应怎样定位性能瓶颈？卡 · 短时压测通过后，稳定性测试还需要观察什么？卡 · 怎样测试十万以上并发连接？

先以小流量核对正确性，再按方案预热、增加负载、保持观察窗口，最后降低或停止负载并检查恢复。预热可能改变缓存和运行时状态，报告应明确哪些窗口用于最终统计，不能只挑表现最好的一段。

停止条件同样属于方案，例如错误超过上限、依赖积压持续增加或测试端资源耗尽。触发后保留证据，确认负载已经撤除、队列被处理、测试数据得到回收。

观察	可能的方向	继续需要的证据
吞吐不再增长、延迟上涨	排队或共享资源接近上限	各阶段等待、队列长度与资源利用
CPU 不高、请求很慢	锁、连接池、I/O 或依赖等待	线程状态、池指标、链路与慢查询
服务端很空闲、实际请求不足	负载端资源或调度受限	压测机 CPU、网络、线程和实际发出率
错误增加但平均延迟下降	快速拒绝或提前失败	状态码、业务断言及成功请求延迟
测试越久内存或连接越多	泄漏、缓存增长或积压	回收后趋势、对象或连接归属

这些只是排查方向，不是看到一个指标就能下的结论。要把同一时间窗口的负载、客户端结果、服务指标和依赖证据联系起来，再用可控变更验证原因。

优化对比应保持环境、数据、负载和统计窗口可比，说明只改变了什么，并重复观察是否稳定。若同时扩容、换数据、改脚本，无法把全部提升归因于某一段代码。

6.1 高连接数测试

验证“支持十万以上并发连接”，要先定义连接指什么：传输连接、已完成协议握手的连接，还是完成认证且仍能交换业务消息的会话。协议、握手、保活、断开判断和代理拓扑都应按实际系统记录，不能把客户端创建了多少对象当成连接数。

建连能力、连接保持能力和业务处理能力要分开测量：

维度	需要记录的量	不能据此推出的结论
建立连接	计划与实际建连速率、握手成功率和耗时	累计成功十万次不等于同时存活十万条
保持连接	同一窗口内的存活连接数、心跳或探测结果、断开数量	空闲连接保持成功不等于业务消息处理成功
传递消息	每连接的消息频率、大小与收发方向，成功率和延迟	配置消息频率不等于实际完成吞吐

先确认负载发生器能制造所需压力。核对客户端和服务端的文件描述符限额、内存、CPU、网络及连接状态；Linux 的 RLIMIT_NOFILE 会限制进程可打开的描述符范围，提高配置值也不会增加内存或处理能力。若使用 TCP，还要检查压测端的源地址与可用源端口、连接关闭后的状态，以及 NAT 等中间设备的限制。不能因为服务端只监听一个端口，就认为客户端也不存在端口资源约束。

单个压测端接近资源上限时，可按连接分片分配到多个负载发生器，并分别记录实际负载和资源。增加压测机、源地址或调整限额，都要结合实际受限环节；不能只乘机器数量，就把理论总数当成已经达到的规模。

执行时先以少量连接核对握手、业务断言和清理，再阶梯建连，在每一阶保持观察窗口。到达目标后，分别观察保活负载和约定消息负载；有突发断连或重连需求时，再单独安排该阶段，避免把重连速率与稳定存活数混在一起。出现约定的错误、延迟、资源或积压上限就停止增加压力，保留失败阶段的证据。

客户端与服务端的计数要按时间窗口和连接口径对齐。存在代理、连接池或多路复用时，两端物理连接数不一定一一对应，应分别检查入口连接、后端连接和业务会话；数量不同先解释拓扑与采样时刻，不能直接判定丢连接。稳定存活还要结合协议允许的心跳、探测或业务响应确认，服务端保留了一个连接记录并不充分。

最后停止新增连接，按协议释放已有连接，等待并检查会话、描述符、内存和后台任务的回收趋势。短暂关闭状态或有界缓存不一定是泄漏，应和测试前基线及合理清理窗口比较。报告保留各阶段的实际存活数、业务结果、资源曲线和恢复证据；小规模试跑只能验证方案与脚本，不能据此声称已通过十万连接。