性能压测：模拟真实用户，还是数字魔术？

性能压测做久了，你会发现一个特别分裂的现象：报告里TPS（每秒事务数）三万、响应时间几十毫秒，数字漂亮得像广告片里的样板间；可系统一上线，真实用户一进来，首页转圈、下单超时、支付回调堆积，运维群立刻炸锅。这时候大家就会问一句：之前的性能压测到底压了个什么？是不是只做了一场数字魔术，模拟了个寂寞？

我很少用“建议”这个词，但这条我得先说：性能压测的价值，不在于跑出几个能写进汇报PPT里的漂亮数字，而在于你能不能提前复现真实用户会遇到的卡顿、超时和雪崩。把模拟真实用户这件事做扎实，比换多贵的压测工具、堆多少台施压机都重要。这篇文章我就围绕“性能压测到底是模拟真实用户，还是数字魔术”这个话题，聊聊这些年踩过的坑、总结出的方法，以及怎么让你的压测结果经得起上线的检验。

1. 数字魔术：那些漂亮但不可信的压测数据从哪来

1.1 为什么压测报告会和线上体验“两张皮”

先说个常见场景。测试环境压测报告显示下单接口平均响应时间只有80毫秒，结果双十一大促当天，真实用户实测下单平均要三秒。差在哪？差在压测时你测的是一个“被保护得好好的接口”，而上线后用户走的是完整的链条：DNS解析、CDN回源、网关鉴权、WAF拦截、限流判断、业务逻辑、缓存穿透、数据库查询、分布式事务、第三方支付回调、日志异步写入……每一环都可能成为瓶颈。

很多团队做压测有个惯性思维：把压测理解成“用工具打接口”，只要并发数上去了、吞吐量出来了、响应时间达标了，就认为系统稳了。但真实用户不是这么访问系统的。真实用户有思考时间，会在页面上停留、会滚动、会犹豫要不要点结算；真实用户有操作路径，不会只盯着一个接口猛刷；真实用户有数据状态，有人是新客、有人购物车里有一百件商品、有人已经登录了两个月没掉过线；真实用户分布在五花八门的网络中，有人用5G、有人连着公司WiFi、有人在地铁里信号一格一格跳。

如果你把这些因素全部忽略，压测结果当然只是一个理想状态下的数字。问题是，传统压测工具的默认行为恰恰就是“忽略”——因为它天生擅长并发、擅长循环、擅长忽略一切跟“人性”有关的东西。于是压测就变成了数字魔术：数字确实是从真实系统上采到的，但模型是假造的，路径是简化的，场景是脱敏的，数据是预热的。数字没骗你，模型骗了你。

1.2 “数字魔术”的几种常见手法

结合我见过的大大小小团队，压测变魔术基本就这几种套路，团队完全可以自查：

第一种，同一机房内网压测。压测机跟应用服务器放在同一个交换机下面，走的是千兆内网，跳过了公网入口、带宽限制、NAT转换、链路抖动。测出来的网络耗时几乎为零，但真实用户每次请求都要经过复杂的公网环境，那个网络延迟加进来，响应时间直接翻倍都不奇怪。更隐蔽的是，很多系统在入口处有按IP或区域的限流策略，压测机IP一旦被识别，结果就更失真了。

第二种，压测脚本里没有思考时间，也没有业务停顿。工具默认一个线程跑完一个请求立刻跑下一个，CPU都不带喘气的。真实用户不可能这么操作，正常人看到一个页面最少停留几秒，填个表单更是要十几秒。没有思考时间等于把真实用户的密度放大十倍甚至几十倍，最终测出的TPS对应的是“极端灌入”，而不是“真实到达”。这种压测结果如果直接拿去做容量预估，容量规划会偏得离谱。

第三种，只挑性能最好的接口打。有些项目给某个读接口加了Redis缓存，命中率98%，压测时自然又稳又快。但线上真实流量里，用户一进来打的是首页聚合接口，要调十几个下游服务；下单要写订单、扣库存、清购物车、走支付，一堆写操作才是瓶颈所在。单测一个性能最好的接口，就像体检只量身高不查血，当然没问题，但也当然说明不了问题。

第四种，压测数据全是“热数据”，缓存一打一个准。压测前把数据库里所有关键记录都预热到缓存里，然后用几千并发去刷同一批ID，缓存永远命中，数据库几乎不参与。可真实用户访问的数据是有倾斜的，头部商品确实热，但总有长尾请求会穿透到数据库；更怕的是缓存刚过期的那一瞬间，几千个请求一起打到数据库。

这些手法单独拎出来，每一条都算不上什么秘密，但组合在一起，就足够做出一份特别好看的压测报告。我也不是说团队故意造假，很多人是因为不了解真实用户模型该怎么建，最后被工具带的默认参数牵着走，压着压着就失真了。

2. 模拟真实用户：到底要模拟什么

2.1 真实用户不是“匀速打接口的机器人”

想搞明白什么是“模拟真实用户”，先得打破一个思维定式：真实用户不是一组并发连接，而是一个一个具体的人，带着具体的目的、状态和网络环境在访问你的系统。

我举个例子。一个电商App，假设日活50万。这50万人不是半小时内均匀触发请求的，而是有明显的潮汐效应：早上七八点通勤路上刷一刷、中午十二点午休时间逛一逛、晚上八点到十一点是绝对高峰。在这个高峰窗口里，流量也不是平滑上升的，而是突然涌进来的——很多人同时收到推送、同时点开直播间、同时去抢限量款。这种“突发性”对系统造成的冲击，远比用固定并发数匀速打接口要大得多。

真实用户还有“有状态的连续操作”。一个人不是单纯地GET一个商品详情页，而是可能这样走：搜索“蓝牙耳机”→ 翻了三页 → 点进A商品看评价 → 又退出来看B商品 → B加入购物车 → 去结算页看了一眼运费 → 犹豫了一下没付款 → 关了App。整个过程涉及个请求，有GET有POST，有少量并发、有前后依赖、有中间停顿。如果压测时把这一整个用户旅程抽象成N个互相独立的请求，分别压测再求和，等于把一个多幕剧拆成了无数个没有关联的静帧，那么“用户角度”的体验自然测不出来。

所以“模拟真实用户”的核心，不是把用户数量复制出来，而是把用户的“行为模式”和“到达规律”复制出来。行为模式决定单个用户的请求序列和接口覆盖，到达规律决定系统在任意一秒内的真实压力形状。这两件事做到了，压测模型才站得住。

2.2 用户画像与场景矩阵怎么拆

要把行为模式和到达规律变成可执行的压测脚本，建议先做两件事：拉日志和定场景矩阵。

登录日志最简单也最有效。把线上网关或接入层的access log拉出来，分析30分钟或1小时的代表性时段，统计每个接口的请求占比、各业务模块的调用比例、平均每个会话触发多少个请求、相邻请求的平均间隔是多少。别拍脑袋“我觉得首页应该最多”，要用数据说话。日志会告诉你真相：有时候占了50%流量的其实是个听都没听说过的轮询接口，而不是你想当然的核心下单接口。

拿到这些数据之后，按业务重要性、资源消耗、用户覆盖度三个维度筛选，把接口分成几个场景。典型做法是可以设置这样几个场景模板：

场景矩阵里还要明确一个关键参数：用户思考时间。很多人讨厌思考时间，因为一旦加上，压测时间会变长、并发效率会降低，辛苦设计的脚本跑半天也就几千个请求。但思考时间恰恰是模拟真实用户最重要的一环。通过日志里相邻请求的间隔时间来计算P50/P95思考时间，再加到脚本里，这样做出来的流量曲线才接近线上到达率。

2.3 数据分布：压测数据比并发数更容易被忽略

脚本和场景只是模型的一半，数据是另一半。有些压测做得再认真，如果数据分布不对，结果一样会骗人。

真实系统的数据分布基本都遵循二八定律甚至一九定律：少数商品贡献大部分浏览量，少数用户的订单量远高于普通人。压测时如果所有请求都打在同一批商品ID上，那么缓存命中率会高得离谱、数据库行锁主要集中在几个热点行上、连接池的占用形态也跟真实情况完全不同，最终测到的其实是“缓存系统有多能扛”，而不是“整个系统在真实数据分布下能不能扛”。

模拟数据分布至少要覆盖这几类状态：用户状态（登录/游客/新注册/黑名单/不同等级）、商品状态（有库存/无库存/已下架/限购/秒杀中）、缓存状态（热数据/冷数据/已过期/永不过期）、数据体量（空购物车/10件商品/100件商品）。特别是“大多数压测对象是冷数据”这一点，很多人没有意识到，如果压测数据全都是预热好的热数据，系统中的数据库查询优化器、连接池、缓存淘汰策略根本得不到有效考验。

我自己的做法是，在压测数据库中造一份按线上统计分布生成的数据集，表空间大小跟生产数据量级持平，关键索引分布、数据倾斜程度尽量贴合线上。然后留一小部分请求不打缓存，或者故意让缓存每过几分钟自然过期一批，模拟缓存穿透的局部场景。只有数据状态接近真实，压力测试才算真正意义上“摸着石头过河”，而不是在池子里原地转圈。

3. 把压测从“数字”拉回“真实”：一套可落地的实操步骤

3.1 第一步：用日志和监控先“画像”

要想让压测贴近真实用户，第一步并不是打开压测工具，而是先花半天时间分析系统现状。具体可以做这么几件事：

从网关或Nginx的access log里提取最近一周的高峰期数据，按小时粒度统计QPS曲线，找到系统真实的“尖峰形态”。然后解析出请求路径，找出TOP20接口和它们的占比，把接口之间的上下游依赖关系理清楚。再结合APM（应用性能监控）工具，看每个接口的平均耗时、P95耗时、依赖了哪些外部服务、哪些调用最容易成为瓶颈。最后把业务侧的转化漏斗拉出来，看看从浏览到下单整体有多少步、每一步的流失率是多少。

这些数据汇总起来，你就有了一张上线系统的“用户画像”：什么时间段压力最大、尖峰流量是平缓还是陡峭、流量集中在哪些接口、用户的操作链路过长还是短、响应时间主要在哪个环节消耗。这个画像才是压测场景设计的灵魂。要是连这一步都省了，脚本写得再花哨都是空中楼阁。

3.2 第二步：压测环境尽可能“像素级”贴近生产

环境问题往往是压测结果和线上差距巨大的主要原因。最理想的做法是直接用一套独立的压测环境，配置跟生产一致：同等规格的应用服务器数量、同版本数据库、同样的缓存集群大小、内存CPU配额不缩水。现实中大部分团队没有这个条件，那就至少要保证几个关键点。

网络路径要尽量模拟真实链路，压测机不要跟应用服务器放在同一台交换机下，最好能经过统一的接入层和网关。如果实在只能内网压测，要在结果分析时手动加上公网延迟的偏移量，把基线打高。数据库数据不能是“干净得只有几十条记录”的demo库，数据量、索引区分度、热点分布要跟生产成比例。依赖的下游服务如果有条件，用影子系统或mock平台做隔离，但要记录哪些依赖是被mock掉的，避免把mock的超快响应当成真实结果。

如果团队有条件做全链路压测，那就更好了，直接把生产的流量复制一份，打到一个灰度分组上。这样网络、数据、依赖全部是真实的，唯一要处理的是测试流量标记和防脏数据。全链路压测是相对最接近真实用户的压测方式，但投入成本也高，适合大促前或核心系统上线前。

3.3 第三步：编写带“人味”的压测脚本

脚本是压测模型落地的最小单元，最容易犯的错就是写得像“打桩”，完全没有人味。下面以Locust为例写一个简单示意，它本质上是把用户行为定义成独立进程中的任务序列，每个用户虚拟实例独立循环运行。

from locust import HttpUser, task, between import random class RealisticEcommerceUser(HttpUser): # 每个用户请求间的思考时间，用日志P50和P95拟合 wait_time = between(1, 5) def on_start(self): # 模拟用户登录，拿到会话 self.token = self.login() def login(self): resp = self.client.post("/api/login", json={"user": f"u{random.randint(1, 100000)}", "pwd": "test"}) return resp.json().get("token") @task(30) def browse_home_and_search(self): # 首页聚合接口 self.client.get("/api/home?channel=feed") # 有概率发起搜索 if random.random() < 0.4: keyword = random.choice(["蓝牙耳机", "运动鞋", "手机壳"]) self.client.get("/api/search", params={"q": keyword, "page": random.randint(1, 3)}) @task(10) def detail_and_add_cart(self): # 从热品池和长尾池分别取值，模拟数据冷热分布 item_id = random.choice(HOT_ITEMS if random.random() < 0.7 else COLD_ITEMS) self.client.get(f"/api/item/{item_id}") if random.random() < 0.3: self.client.post("/api/cart/add", json={"item_id": item_id, "num": 1}) @task(3) def check_out(self): # 下单操作，依赖前置购物车数据 self.client.post("/api/order/create", json={"address_id": 1})

这段脚本想说明三个重点：第一，wait_time定义了思考区间，模拟人的停顿而不是机器连发；第二，按比例控制不同任务的执行概率，让压力分布接近线上真实接口占比；第三，冷热数据池分离，随机选择，让缓存的命中率不总是100%。你不需要一定用Locust，JMeter同样可以做到，核心思路是这套“人味逻辑”，而不是工具本身。

写脚本时还有一些细节值得单独强调：不使用全局共享的无状态Cookie池，每个虚拟用户要用独立会话，避免把登录态的并发开销漏掉；不要给所有请求都加同样的Header，每个用户应该带不同的UA、设备类型、地区信息，因为网关和风控模块对这类参数敏感；如果是写操作，不要只压“成功路径”，要有一定比例的参数不合法、库存不足、重复提交，这些异常分支在真实用户中说得直白一点非常常见，却恰恰会消耗系统资源并且暴露问题。

3.4 第四步：监控指标不能只看RT和成功率

压测跑起来之后，很多人盯着压测工具面板上的平均响应时间和成功率看，这两个指标达标就宣布“压测通过”。这其实是最危险的认知。压测工具输出的RT和成功率只是“果”，真正决定系统会不会挂的“因”都在服务器和中间件指标里。

每一轮压测，我建议至少同步采集这几维指标：应用服务器的CPU、内存、磁盘I/O、线程池活跃线程数、JVM的GC频率和STW时间（如果是Java应用）、各接口的P50/P95/P99响应时间；数据库侧的活跃连接数、慢查询数量、锁等待时间、缓冲池命中率；中间件侧Redis的命中率与内存碎片率、消息队列的积压数量和消费Lag（消费滞后量）、网关的连接数。

这些指标要用一套看板集中展示，跟压测工具的执行时间轴对齐。为什么要这么强调？因为“响应时间变慢”往往只是表象，真正的瓶颈在链路深处：比如数据库连接池被打满、Redis缓存雪崩后请求直击数据库、Java应用Full GC频发导致线程卡死。如果只看施加压力那端的RT，你只能看到“慢”，却看不到“为什么慢”，排查效率会低不少。

压测执行最好采用梯度加压的方式，不要一上来就5000并发冲到底。建议从100并发起步，每3到5分钟升一级，200、400、800、1500……每升一级观察5分钟，记录当前级的各指标表现。目的是找到系统的“拐点”——随着并发上升，哪个组件最先开始恶化？它的瓶颈是单点资源耗尽，还是某个依赖服务和线程池先到了天花板？找到这个拐点，就等于找到了扩容和优化的依据。

4. 常见问题与排查技巧实录

4.1 容易翻车的6个典型坑

4.2 排查思路：先分“谁慢”再谈“优化”

有一次压测一个订单服务，TPS卡在800上不去，CPU还不到40%。刚开始所有人都认为是性能瓶颈，准备扩容，但我去看了线程栈，发现大量线程阻塞在数据库连接获取上。顺着查下去，连接池参数配置的是50，但压测场景里每个请求经过网关、业务服务、订单服务，一个事务要占用好几个连接，加上慢SQL把连接长时间持有，连接池直接耗尽。问题根本不在服务CPU，而在连接池容量和SQL执行效率。

那次之后我给自己定了一条排查规矩：压测结果不达标，不要急着调代码、加机器，先按“应用→数据库→外部依赖→基础设施”的层次逐一排除，判断瓶颈在哪一层。判断的方法是逐层看指标和线程状态：应用层CPU高不高？不高说明可能阻塞在I/O或锁等待上。数据库有没有慢SQL和锁等待？有就优先处理SQL和索引。Redis和MQ有没有异常？拉长消费积压数。最后才看系统层面的CPU、内存、磁盘、带宽。压测排查跟生活里看病是一个逻辑，得先分科，才知道病根在哪。

4.3 怎么证明你的压测不是“数字魔术”

整篇文章反复在说“不要做数字魔术”，那到底怎么证明自己的压测结果可信？我这几年沉淀了几个自我验证的检查项，称之为“真实性的三问”。

第一问：压测时的流量模型跟线上真实的访问比例是不是一致？如果线上搜不到多少SEO爬虫流量，而压测时一堆请求在打爬虫接口，说明模型偏了。

第二问：系统在压测过程中的核心指标是否在合理健康区间？数据库慢查询比例是否在正常范围？Redis命中率是否跟平时差不多？应用线程池是否稳定？如果这些指标异常，哪怕接口RT合格，也是压测环境自己的失真状态。

第三问：有没有做过回归性验证？找一个已经上线的历史版本，用同一套场景去压测，跟线上的历史监控数据对比，误差如果控制在较小范围内，就能反向证明压测模型是可信的。这个方法算是经过反复校验的，如果一套压测场景压旧版本的结果和线上历史表现大差不差，那用它压新版本得出的结论就有很高的参考价值。

压测这行干久了，我最大的体会是：压测工具本身就是把双刃剑，它给出的数字越精确，越容易让人忽略它背后模型的粗糙程度。模拟真实用户这件事没有完美答案，因为真实用户的行为永远在变化，但我们必须不断逼近，把每个已知的失真项逐一修掉。别让性能压测变成一场自娱自乐的数字魔术，也别让“真实性”成为一句漂亮的口号——它应该落实到每一次日志分析、每一个思考时间、每一行脚本、每一个监控指标里。毕竟，用户不会对着你的压测报告用系统，他们只会用自己的真实体验投票。