产品经理提性能需求时，最容易写出的一句话是：

页面打开要快一点，系统要稳定，用户多的时候也不能卡。

这句话方向没错，但没法开发，也没法验收。

“快一点”到底是 1 秒还是 5 秒？“用户多”是 100 人同时在线，还是 100 人同一秒提交订单？“稳定”是全年不宕机，还是请求成功率达到 99.9%？如果这些问题没有说清楚，开发只能凭经验实现，测试也只能凭感觉验收。

一份可执行的性能需求，至少要说清楚四件事：

在什么场景下，用多大的数据量和访问压力，要求哪个指标达到什么数值。

下面是产品经理需要掌握的 9 类性能指标。

这 9 类指标可以先分成三个问题：用户等多久、系统扛多少、能否稳定运行。 产品不需要把自己变成运维工程师，但要知道每个指标看什么参数、解决什么问题。

1. 响应时间：用户要等多久

响应时间，是从用户发起操作，到用户看到结果所经历的时间。

它不是一个单独的“后端接口耗时”，而是一整条请求链路的总和：

用户操作
  ↓
客户端处理
  ↓
网络传输
  ↓
网关、鉴权与排队
  ↓
服务端业务处理
  ↓
数据库、缓存及外部服务调用
  ↓
结果返回
  ↓
客户端解析、渲染与展示

可以简单理解为：

用户感知响应时间
= 客户端发送耗时
+ 上行网络耗时
+ 网关与排队耗时
+ 服务端处理耗时
+ 数据库/缓存/外部依赖耗时
+ 下行网络耗时
+ 客户端渲染耗时

因此，用户说“页面打开用了 3 秒”，不等于“接口响应用了 3 秒”。接口可能只用了 300 毫秒，其余时间消耗在网络、多个接口串行请求、图片下载或页面渲染上。

不要只写平均响应时间

平均值很容易掩盖慢请求。比如 100 次请求中，95 次耗时 200 毫秒，5 次耗时 8 秒，平均值看起来还可以，但那 5 个用户已经认为系统坏了。

性能需求通常应关注分位值：

• P50：50% 的请求不超过这个时间，代表普通用户体验。
• P95：95% 的请求不超过这个时间，适合多数业务验收。
• P99：99% 的请求不超过这个时间，用于关注尾部慢请求。
• Max：最慢请求耗时，可辅助排查，但一般不建议单独作为承诺指标。

用户体验可以参考“1—3—5”，但不能机械套用

• 1 秒内：用户通常感觉操作流畅。
• 1～3 秒：用户能感知到等待，但多数情况下可以接受。
• 3～5 秒：应显示明确的加载状态或处理进度。
• 超过 5 秒：用户更容易重复点击、离开页面，或者认为系统异常。

这只是体验参考，不是所有业务的统一标准。支付结果查询、登录、搜索和十万条数据导出的合理等待时间完全不同。

合格的需求写法

在 1,000 名并发用户、商品列表包含 10 万条数据、筛选结果不超过 1 万条的条件下：
- 搜索接口响应时间 P95 ≤ 800ms，P99 ≤ 1.5s；
- 首屏可见时间 P95 ≤ 2s；
- 超过 1s 时页面显示加载状态；
- 请求超过 5s 未完成时提示用户稍后重试，不允许无反馈。

2. 并发用户数：同一时刻有多少人在操作

并发用户数不是“注册用户数”，也不是“日活用户数”。它描述的是同一时间段内，正在向系统发起操作的用户数量。

并发场景至少分两种：

• 混合并发：不同用户同时浏览、搜索、提交、刷新，更接近真实流量。
• 单场景并发：大量用户同时执行同一个操作，例如抢购、开票、提交订单或考试交卷，更容易形成流量尖峰。

“支持 10 万用户”没有实际意义。产品需要说明：10 万是注册量、同时在线人数，还是同一秒发起请求的人数。

用日活和使用时长估算平均并发，只适合早期没有监控数据时做容量起点。上线后的需求应优先使用真实小时分布和历史峰值，并额外考虑营销活动、开盘、抢购等集中流量。

合格的需求写法

活动开始后的前 5 分钟，预计有 20,000 人在线；峰值时有 3,000 名用户同时进入活动页，其中约 500 名用户会在同一秒提交领取请求。系统在该压力下仍需满足既定响应时间和成功率。

3. 吞吐量：系统每秒能处理多少业务

吞吐量表示系统在单位时间内完成的工作量。常见口径包括：

• QPS：每秒处理的请求数。
• TPS：每秒完成的事务数。
• 每秒订单数、每分钟导入行数、每小时生成报表数：更贴近业务的吞吐口径。

QPS 和 TPS 不能直接画等号。一次“提交订单”可能包含查询商品、校验库存、计算优惠、创建订单和扣减库存等多个请求，但从业务角度只完成了一笔交易。

产品经理更应该优先描述业务吞吐量，再由技术团队换算接口和系统压力。

合格的需求写法

秒杀开始后的峰值 10 秒内，系统每秒需接收 5,000 次下单尝试，并成功处理至少 1,000 笔有效订单；重复提交不得生成重复订单。

4. 成功率与错误率：快，但不能错

如果系统响应很快，但大量请求失败，这种“性能好”没有业务价值。

常见指标包括：

• 请求成功率；
• 超时率；
• 系统错误率；
• 业务失败率；
• 重试成功率。

这里必须区分两类失败：

• 系统失败：超时、服务异常、数据库错误、网络错误等。
• 业务拒绝：余额不足、库存不足、验证码错误、无操作权限等。

业务拒绝通常不应该算作系统错误，否则指标会失真；但产品需要确认每一种结果是否符合预期。

合格的需求写法

在峰值压力下，系统请求成功率 ≥ 99.95%，系统错误率 ≤ 0.05%，超时率 ≤ 0.1%。因库存不足导致的正常业务拒绝单独统计，不计入系统错误率。

5. 可用性：系统有多少时间真正可用

可用性回答的是：用户需要系统时，系统能否正常提供服务。

常见表达是 99.9%、99.95% 或 99.99%。以 30 天计算，大致对应：

但只写一个百分比还不够，还要定义：

• 哪些核心功能纳入计算；
• 计划维护是否排除；
• 部分用户失败是否算不可用；
• 统计周期是月、季度还是年；
• 由哪个监控口径判定开始和恢复时间。

状态可见性也是可用性的一部分。当系统正在处理、降级或发生异常时，应让用户知道发生了什么，并在合适的时间给出反馈，而不是一直转圈。

合格的需求写法

登录、查询余额和提交订单三个核心功能的月度可用性均需达到 99.95%。若连续 1 分钟内超过 20% 的请求失败，则该功能记为不可用；计划维护窗口不计入，但需提前通知。

6. 资源利用率：系统有没有余量

CPU、内存、磁盘和网络是技术资源指标。产品不一定要规定具体实现，但需要知道：系统如果长期跑满，就没有能力应对下一次流量上涨。

常见观察项包括：

• CPU 利用率：计算资源是否接近饱和；
• 内存使用率：是否持续增长、是否存在泄漏风险；
• 磁盘吞吐和 I/O 等待：读写是否成为瓶颈；
• 网络吞吐和连接数：是否接近带宽或连接上限。

“CPU 必须低于 75%”“内存必须低于 70%”可以作为初步参考，但不能脱离部署方式和业务特点直接套用。更重要的是明确峰值持续时间、扩容策略和安全余量。

合格的需求写法

在目标峰值流量持续 30 分钟的压测中，系统不得因资源耗尽发生错误；核心服务应保留至少 30% 的容量余量，并能够在流量达到目标值 120% 时触发扩容或限流保护。

7. 数据规模与批处理时长：一万条和十万条不是同一个需求

查询、导入、导出、统计和报表类需求，必须把数据规模与完成时间一起写。

例如：

1 万条数据导出完成时间 ≤ 3s；
3 万条数据导出完成时间 ≤ 5s；
10 万条数据导出完成时间 ≤ 8s。

这种写法比“导出要快”清楚，但还缺少几个关键条件：

• 每条数据包含多少字段；
• 是否包含图片、附件或复杂计算结果；
• 导出格式是什么；
• 是同步下载还是后台生成；
• 多人同时导出时是否仍满足要求；
• 超过上限后系统如何处理。

合格的需求写法

导出范围最多 10 万条，每条包含 20 个文本字段，文件格式为 XLSX。在 50 个导出任务同时执行时，95% 的任务应在 30 秒内生成。超过 3 秒的任务转为后台处理，完成后通知用户下载；文件保留 24 小时。

8. 客户端流畅度：不只看接口快不快

移动端和 Web 页面即使接口很快，也可能因为渲染、长列表、图片或动画处理不当而卡顿。

常见指标包括：

• FPS：每秒显示帧数；
• 卡顿帧或慢帧占比；
• 页面滚动是否掉帧；
• 点击后多久出现可见反馈；
• 页面首屏和关键内容何时可操作。

60 FPS 通常意味着每帧只有约 16.7 毫秒的处理预算；30 FPS 对应约 33.3 毫秒。单写“FPS 达到 60”仍然不够，还需要指定机型、系统版本、页面和操作路径。

合格的需求写法

在指定的中端测试机型上，打开包含 200 条数据的行情列表并连续滚动 30 秒，平均 FPS ≥ 55，严重卡顿次数为 0；点击筛选后 100ms 内必须出现可见反馈。

9. 启动、耗电与流量：移动端长期体验

移动端性能不只是“页面快”，还包括启动速度、耗电量和网络流量。

启动时间

• 冷启动：应用进程不存在，从点击图标到首页可操作；
• 热启动：应用仍在内存中，从后台回到前台；
• 首次启动：可能还包含初始化、资源解压和用户授权。

三种启动场景不能混用一个数字。

耗电量

耗电与机型、电池健康度、屏幕亮度、网络环境和测试时长有关。只写“耗电不能太高”无法验收，直接与竞品对比也要保证测试条件一致。

网络流量

需要关注首装后的资源下载、图片和视频流量、后台刷新频率，以及弱网下的重复请求。

合格的需求写法

在指定测试机型、相同亮度和 Wi-Fi 环境下：
- 冷启动至首页可操作 P95 ≤ 2.5s；
- 热启动至页面可操作 P95 ≤ 1s；
- 前台连续浏览行情 30 分钟，耗电量不超过电池总量的 5%；
- 浏览 100 个普通图文条目产生的下行流量不超过 50MB。

性能需求应该怎么提

写性能需求时，可以直接套下面这个公式：

业务场景 + 环境条件 + 数据规模 + 访问压力 + 指标阈值 + 统计口径 + 持续时间 + 异常处理

一个错误示例

系统需要支持高并发，页面响应要快，不能出现卡顿。

问题在于：并发是多少、哪个页面、什么操作、什么设备、快到什么程度、允许多少失败，全都没有定义。

一个可执行示例

在生产同等配置、10 万条商品数据、2,000 名用户混合并发持续 30 分钟的条件下：

1. 商品搜索接口响应时间 P95 ≤ 800ms、P99 ≤ 1.5s；
2. 搜索页面首屏可见时间 P95 ≤ 2s；
3. 请求成功率 ≥ 99.95%，系统错误率 ≤ 0.05%；
4. 搜索结果滚动平均 FPS ≥ 55；
5. 核心服务不得因资源耗尽发生重启；
6. 超过 1s 的操作显示加载状态，超过 5s 仍未完成时给出明确提示；
7. 压测结束后系统应在 5 分钟内恢复到正常资源水位。

产品提性能需求前，要确认的 10 个问题

1. 测的是哪个业务场景和哪条用户操作路径？
2. 测试环境与生产环境的配置差异是什么？
3. 数据量是多少，数据分布是否接近真实业务？
4. 在线用户、并发用户、QPS 和 TPS 分别是多少？
5. 压力是瞬时尖峰，还是持续半小时的稳定流量？
6. 响应时间看平均值，还是 P95、P99？
7. 成功、失败、超时和正常业务拒绝分别怎么定义？
8. 达到极限后，是排队、限流、降级，还是直接失败？
9. 哪些指标必须达标，哪些只是观察项？
10. 谁提供数据、谁执行测试、谁确认最终结果？

最后一句

性能需求不是一句“要快”，也不是随手填一个 500 毫秒。

产品经理真正要定义的是：用户在什么情况下需要等多久，系统在多大压力下必须完成多少业务，失败时又该给用户什么反馈。

数值不是越小越好，而是要与业务价值、用户预期、技术成本和风险等级相匹配。写清场景、口径和验收方式，性能才会从“感觉问题”变成一项真正可管理的产品需求。