性能测试实战：并发量与TPS计算公式及压测设计指南

做性能测试这么多年我经常被问到两个问题你这个压测并发数是怎么定的这个TPS指标又是怎么算出来的很多刚入行的同学拿着JMeter就开压线程数随手填个5005000问为什么用这个数答不上来。也有不少测了几年的人一直停留在“用工具跑脚本”的层面对并发量公式和TPS计算背后的逻辑没有系统梳理过一旦场景换成就不知道怎么下手了。这篇文章我打算把这两块掰开了讲透包括并发量怎么从业务指标推导、TPS怎么估算和验证以及我踩过的一些坑希望能给正在做性能测试的同学一个能直接用的参考框架。本文适合刚接触性能测试的新手也适合正在带团队做压测方案的老手作为参考。我不会堆理论尽量用实际压测场景里经常遇到的情况来讲解最后附上我实操中的经验教训以及常见问题的排查思路。1. 先搞清楚并发量和TPS究竟在测什么1.1 并发量不是“同时在线人数”这是新手最容易混淆的一个概念。很多人一上来就说“我们系统有5万用户在线所以并发要模拟5万”这个理解是有问题的。在性能测试场景里并发量指的是同一时刻真正向服务器发起请求的用户数量不是系统里有5万在线用户而是这5万人里有多少人此刻正在“按下按钮”或者正在等待响应。举个例子一个视频App有100万日活但用户大部分时间在浏览视频流、阅读文案真正触发后端接口的频率很低。假设平均每个用户每小时只触发10次接口请求那么算下来每秒的请求数就很有限并发模型完全不是100万这个量级。如果直接拿日活当并发数去压压测机先被自己压垮了数据也没参考价值。在线用户数Online Users和并发用户数Concurrent Users是两个完全不同的统计口径。我们在压测工具里填的线程数其实更接近“同时在发请求的用户数”线程越多同时发给服务器的请求数就越多。这里还有一个容易混乱的概念叫“并发连接数”比如TCP连接数比并发请求数大不少因为很多连接是Keep-Alive挂着的并不代表有业务请求在跑这也要区分开。1.2 TPS才是衡量系统能力的“硬指标”TPS全称是Transactions Per Second每秒事务数在性能测试领域可以粗略理解为每秒完成的业务请求数。它不像并发量那样“看起来很大”但它直接反映系统处理能力。你并发设计得再漂亮最终服务器能不能扛住看的是TPS曲线能撑到多少、稳定在哪、什么时候开始下跌。举一个日常生活的例子一个银行柜台排队人数很多不等于柜员办理业务很快真正衡量柜员能力的指标是他每分钟办完几笔业务。并发用户数就是“排队窗口人数”TPS就是“每分钟办完的业务笔数”。所以你看到系统并发用户数高不代表它处理能力一定强如果每笔业务都要十几秒哪怕堆了一大堆并发请求TPS也上不去。1.3 两者之间的换算关系Littles Law并发量和TPS不是割裂的它们之间有一个非常实用的关系式叫Littles Law公式很简洁[ C TPS \times RT ]其中C是并发用户数并发请求数TPS是每秒事务数RT是平均响应时间单位秒。这个公式在性能测试里非常常用它的意思是系统里同时存在的请求数量等于每秒新到的请求数乘以每个请求在系统里逗留的时间。举个例子如果TPS是100平均响应时间是0.5秒那系统里任意时刻在处理的请求数就是50。如果响应时间涨到2秒TPS还是100并发数就要到200。这从直觉上也说得通请求处理得慢单位时间内堆在系统里的请求就越多。反过来给定目标并发数C和期望RT也能够推算出需要达到的TPS目标。这个公式在我们设计场景时非常好用下文会反复用到。1.4 常见认知误区速查结合我带团队的经验下面这些观点经常在评审会上出现容易把方案带偏常见说法实际情况在线人数就是并发数在线用户只有一部分会同时产生请求并发数越高系统越强并发只是“压力形态”TPS才是处理能力TPS和并发数一定成正比过载后TPS会下降呈倒U型曲线压测工具填多少线程就是多少并发只是模拟压力真实并发受脚本、网络环境、响应时间影响只测一个接口就够了业务模型完整的混合场景才有实际意义记住一个表象成千上万的在线用户只是“池子”并发量和TPS是从池子里“舀水”的节奏和速度。理解了这一点后文的公式才不会用错。2. 并发量计算公式从业务需求反推压力2.1 核心公式的推导并发量不是一个拍脑袋的数字它可以从业务指标一步步推导出来。我的做法一般是这样先明确目标业务场景和时间窗口再估算这个窗口内的请求总量最后除以时间得到平均请求速率再乘平均响应时间得到并发数。最常见的一个基础公式是这样的[ C n \times p \times r \times t ]C目标并发用户数n系统活跃用户总数日活、月活或特定业务用户数p用户活跃比例也就是在某个时间段内实际会操作用户的占比r单个活跃用户在单位时间内的平均请求频率次/秒t平均事务响应时间秒这个公式的本质是任何时刻正在服务器上处理的那批请求数等于总请求到达速率乘以每个请求平均耗时。它和Littles Law是同一个道理的另一种写法。举个例子。某电商系统日活80万人在晚上8点到10点属于访问高峰假设这个时间段会有30%的用户访问p0.3每个活跃用户平均每10分钟触发一个核心业务请求比如加购、下单、支付相当于r1/600次/秒系统平均响应时间目标是0.8秒。那么[ C 800000 \times 0.3 \times (1/600) \times 0.8 320 ]算下来并发用户数大约是320。这个数字远小于80万但逻辑是对的日活80万的系统真正的并发压力可能只有几百。很多刚做压测的同学会觉得这个数太小了但压测时你用320线程跑出来的效果往往比随便填2000线程更接近真实生产压力。2.2 不同场景下的并发估算变体上面的基础公式适用于一般业务系统但现实中的业务形态差异很大不同场景需要调整参数。我把常遇到的几类列一下。有明确业务流程的场景比如用户平均每次访问会依次打开首页、搜索、详情页、加购、下单共5个步骤每个步骤耗时不同。此时应该先算出每个步骤的请求速率再分别计算并发数取各步骤中最大的作为压测目标。因为瓶颈往往出现在某一个接口上而不是所有接口平均分配。轮询类场景比如消息推送、订单状态刷新App端每3秒轮询一次。这种场景的并发模型是周期性脉冲而不是均匀到达。轮询用户越多对服务器的瞬间冲击越明显。估算时要把轮询周期考虑进去例如10万在线用户每3秒轮询一次平均每秒约3.3万个轮询请求按0.2秒响应时间估算并发约6600这个量级比普通业务接口大得多设计时要注意接口的RT预算。秒杀类场景这类场景的特点是瞬时流量远大于日常不能用日活和平均频率来算。常用的简化思路是根据“放量数量”和“预计抢完时间”反推。假设秒杀10万件商品预计1分钟内抢完那么TPS至少需要1667如果单次请求RT是0.5秒根据Littles Law对应的并发数约为834。这个并发数适用于压测中模拟秒杀接口的线程组。更严谨的做法用排队论M/M/c模型计算但工程上没那么复杂按峰值流量给一个1.5到2倍冗余就够。高并发消息推送场景如果系统向大量用户推送消息用户会集中打开App产生“羊群效应”。这种场景的峰值往往出现在推送发出后的前几分钟估算时要抓住“瞬间到达率”而不是全天平均值。可以按推送触达用户数乘以预期打开比例再除以高峰窗口时间来计算。2.3 参数取值的一些经验值公式里最让人犹豫的就是p和r到底该取多少。参数取错了整个估算也就失真了。根据我多年项目经验给一个参考区间活跃比例p一般业务系统取10%到20%对特定活动页可以到30%甚至更高对后台管理类系统通常取全部在线人员的80%以上因为后台用户操作反而更密集。请求频率r普通浏览类业务一个人平均每1到3分钟一个操作强交互类业务比如在线编辑、交易系统可能每10到30秒一个操作纯轮询类按周期直接换算。响应时间t可以先取目标响应时间比如要求RT小于1秒就把t取为1预留一定余量。如果已经有线上监控数据最好取P95而不是平均值。参数设定不可能一步到位。我的习惯是先按经验值估算第一版然后用压测实测数据反过来校验看按公式算出来的并发数能不能撑住预期TPS。如果实测和预期差得比较远说明p或r的取值偏离实际再去查线上日志做校准。这套“先估算再校准”的闭环比任何公式都管用。2.4 计算示例以某电商订单系统为例我把一个完整案例走一遍这样大家可以直接套用步骤。假设某电商平台要做大促前的容量评估已知数据日活300万、大促当天预计有60%用户会访问、核心下单接口单用户日均调用1.5次、大促主要集中在上午10点到12点的2小时高峰。首先算高峰窗口内的总请求量300万x60%180万人会访问其中假设有40%的人会下单尝试那就是72万人会触发下单请求再考虑部分用户会取消重试乘以1.2的冗余系数大约是86.4万次下单请求。这2小时内平均每秒请求速率是864000/7200120次/秒。如果我期望下单接口的RT不超过1.5秒根据Littles Law并发数大约为120x1.5180。如果目标压测场景只测下单接口用180线程就够了。但要加上其他接口混合比例比如查询、加购流量更大并发数要重新按各环节比例加权计算。有一个容易被忽视的点真实压测下如果服务端开始出现排队RT可能会从1.5秒涨到5秒此时即使TPS不变并发线程里堆积的请求也会暴涨压测工具的活跃线程数会远高于180这个数。这就是为什么压测时不光要设目标并发还要关注RT在过载点之后的变化形态。3. TPS计算需求推导、日志统计、实测反推3.1 TPS的定义与统计口径和并发量不同TPS更直观但统计口径容易出问题。一个“事务”在不同系统里定义差别很大可能是整个下单流程从提交订单到返回成功也可能是单次数据库查询。定义不清楚后面的所有计算都没有意义。我在做方案时会先把“事务”的定义在评审会上敲定。一般推荐把“用户可感知的业务操作”作为一个事务例如“登录事务”“下单事务”“支付事务”。如果是技术层面的一个连接或者一次内部调用可以用单独的名字如QPS每秒查询数去统计避免和TPS混在一起。TPS指标还可以拆成很多角度数据库TPS、中间件TPS、应用服务器TPS但业务侧最关注的通常是“端到端TPS”即从负载机发起请求到完整收到响应的每秒事务完成数。在做瓶颈定位时再逐层拆到组件TPS这是后话。3.2 路径一从业务需求倒推TPS在没有线上日志的情况下只能从业务指标倒推。公式很简单[ TPS \frac{总请求量}{时间窗口(秒)} ]沿用电商大促案例下单业务高峰2小时请求量是86.4万平均TPS就是864000/7200120。但这是“平均”TPS大促的流量不是均匀的往往在整点附近出现尖峰例如10点开始的前10分钟流量可能是平均值的2到3倍。因此不能只用平均值定目标要按峰值系数放大。若峰值系数为2.5则设计目标TPS为300。有人会提出“二八原则”说80%的请求集中在20%的时间段里。这是一个统计经验不适用于精确容量规划。我看到不少方案直接套用2/8最后压测目标定得太高或太低原因就是没有结合实际业务的流量分布。更可靠的做法是直接看线上监控的分钟级请求量曲线取高峰期的最高分钟值来算目标TPS。没有监控数据时再退一步用2/8原则做粗估。3.3 路径二从生产日志统计修正如果你的系统已经上线并有日志系统那么生产日志是最好的数据源比任何估算都准。具体做法是导出高峰时段某一天的Nginx或者应用访问日志按接口聚合统计每秒请求数取P95或者最大值作为压测TPS基线。举个例子从日志统计出某下单接口在高峰期最大分钟请求量是24000次/分钟也就是400 TPS一天的平均TPS是80。压测目标就可以设为400再乘以1.2到1.3的冗余系数得到500。这里要注意的是生产日志统计出来的是“实际到达量”如果系统已经出现过限流或拒绝请求统计结果偏低直接拿去做目标会导致压测强度不够。所以最好选一个没有明显丢弃请求的正常日作为基准。另外强烈建议按接口维度拆分统计而不是只看总TPS。下单接口和查询接口的处理逻辑完全不一样资源消耗也不同混合在一起就只能得到一个总盘子无法指导后续的容量规划。3.4 路径三从容量测试反推单机限额还有一种场景是系统还没上线或者业务指标本身不可靠这时候可以用“压测反推”的方式先测出单机单个应用实例能支撑多少TPS再乘以节点数得到整体容量。比如压测发现单实例在RT达标的情况下最高稳定TPS是800线上有10个实例理论上集群容量8000 TPS。但实际应用要打个折扣因为负载均衡不均、服务依赖瓶颈、单点故障等因素我一般按0.7到0.8的容量系数来估算也就是5600到6400 TPS比较稳妥。这种方式非常适合做容量规划的初步摸底。很多性能测试项目的第一阶段我都喜欢先做单机基准测试把每个核心接口的单实例TPS跑出来再推算集群整体这样后面的全链路压测有据可依。3.5 长事务场景的TPS处理上面讲的都是短事务场景但在实际业务中总会混入一些长事务。典型的是报表导出、批量接口、文件生成这类事务单次耗时可能达到10秒甚至几十秒。如果用统一的TPS和并发数去设计会非常别扭。我遇到过这样一个案例一个管理系统有日常查询接口RT大约0.3秒也有一个数据导出接口RT大约40秒。如果把两个接口放在同一个线程组里线程被长事务长时间占住日常接口的TPS就会被拖累压测结果失真。最终做法是拆成两个线程组分别按各自的目标并发和TPS来压测或者单独写一个独立场景。长事务的TPS目标不一定要很高它的核心指标是“并发完成率”和“时长内最大处理笔数”比如要求1小时内完成10万笔导出平均TPS只需要28但并发线程数因为RT太长可能要被设为几百才跑得起来。这种情况下并发数和TPS的差异就体现得非常明显。你算出来的TPS可能只有30但只要平均RT是40秒Littles Law告诉你并发数要求高达1200。这也是为什么我会建议场景设计时先按目标TPS估算线程数实际压测再通过逐步加压来校准不要只看单一指标。4. 实操中的压测设计经验与排查指南4.1 到底先定并发数还是先定TPS这是很多团队在压测方案评审时经常争论的问题。我的建议是目标先定TPS线程数作为手段去调整。因为TPS是业务可以直接感知的指标每秒能处理多少订单、多少人支付而并发数是实现这个目标的一种手段不具备业务可比性。举个例子某支付渠道要求峰值支持2000 TPS平均响应时间小于1秒。压测时先用少量线程跑起来然后逐步增加线程观察TPS是否线性增长RT是否还在目标范围内。如果线程加到400TPS达到2000但RT已经上涨到1.8秒那这个并发数是不合格的如果线程加到800TPS稳定在2000RT还在0.8秒左右那说明系统的处理能力在并发800这一档能达到指标。此时的“并发数”更多是压测结果而不是预先设定的输入。真正业务上关注的是能不能稳定支撑2000 TPS以及这个能力能持续多久。4.2 压力递增策略我见过不少压测方案直接设置3000线程持续压30分钟结果一上来系统就狂报错日志刷屏最后连瓶颈在哪都没看清。正确的做法是阶梯式加压例如每30秒增加10%的线程数同时记录每个梯度的TPS、平均RT、错误率。这样你能清楚看到系统在哪个并发点开始“拐弯”——TPS不再增长、RT突然上扬、错误率开始抬头这个点就是系统的性能拐点。从拐点往后再增加并发已经没有意义系统的处理能力已经耗尽。真正有价值的性能测试不只是“扛住目标压力”更重要的是找到这个拐点并分析拐点背后的原因是数据库连接池满了还是应用线程池耗尽又或者是下游第三方接口成为瓶颈。出了问题之后还要了解问题影响的范围方便确定优先修复的方向。这里有一个我常用的压测脚本设计原则并发线程数从一个低值起步比如10到20个然后按固定梯度增加不要一上去就压满。尤其是第一次压测的任务更多是为了摸清底数而不是为了证明系统能扛多少。4.3 常见问题与排查速查表下面的表格整理了我实际排查中遇到的高频问题压测出现问题不要慌先按表里思路过一遍现象优先排查方向说明并发数上去了TPS却不涨应用线程池、数据库连接池、中间件队列处理能力到达上限出现排队或线程阻塞TPS保持RT持续升高CPU负载、垃圾回收、锁竞争请求在排队或等待资源响应时间被拉长错误率突增超时设置、连接池耗尽、后端服务拒绝可能是超时时间过短也可能是资源耗尽触发保护个别接口TPS极低数据库慢查询、外部依赖接口耗时单接口瓶颈需要针对该接口做隔离排查结果波动大压测机性能不足、网络带宽限制排除压测环境本身的影响保证压测数据可信长时间压测后TPS下降内存泄漏、缓存失效、临时文件堆积稳定性和资源回收问题需要更长时间验证除了这些方向还有几个容易踩的坑。一是压测机的性能受限尤其是用笔记本跑高并发线程数一高CPU先满了压测结果失真这种情况下建议分布到多台压测机去跑。第二是没用独立的网络带宽压测流量和办公流量混在一起网络延迟忽高忽低数据根本没法看。第三是忽略“思考时间”真实的用户操作之间有停顿如果压测脚本完全不设思考时间压力会比实际大好几倍做出来的报告往往偏保守。大部分压测工具都支持调度器延迟或者固定定时器要根据业务操作习惯合理设置。4.4 关于全链路压测与实际容量评估如果条件允许我会建议做一次“全链路压测”即模拟真实用户访问完整业务链路的压测。传统的接口级压测侧重于单点容量但实际生产环境里的瓶颈往往在多个服务之间的依赖关系上。比如下单接口本身没问题但支付回调服务或消息队列消费能力跟不上最终业务照样受损。全链路压测能暴露这一类服务间协作的瓶颈。全链路压测的实施门槛比接口级压测高很多。它需要独立的压测环境或完整的流量标记方案流程上要改造中间件确保压测数据不会污染生产数据。对于没有改造条件的团队退一步做“核心链路压测”也可以把下单链路涉及的核心服务串起来用Mock替代非关键依赖重点验证依赖顺序和超时表现。这类压测能帮团队提前发现架构上的单点比单纯测接口容量更有价值。4.5 报告撰写与分析要点压测做完之后数据整理和报告其实也很考验水平。一份好的报告不应该是把图表粘贴进去就结束。我一般会包含几个核心部分测试环境拓扑、压测模型与指标口径、目标指标与实际结果对比、性能拐点截图、瓶颈分析与调优建议、后续复测计划。最关键的是“结论对业务可读”运维、开发负责人、业务方都能从自己的角度获得信息而不只是一堆技术参数。在报告里还要明确“影响范围”。这个点经常被忽略但其实很重要在测试中发现的性能缺陷要说明影响范围比如影响特定地区用户、特定接口、特定时间段的业务还是全链路问题。只有充分说明影响范围业务领导才能判断需要多高的处理优先级这也是性能测试结果能真正推动业务决策的关键。有条件的话我还会附带容量预估结论当前架构能支撑多少日常用户增长多少以后需要扩容让报告从“测试结果汇报”变成“容量规划输入”。5. 最后分享一点这十几年攒下来的体会5.1 公式是起点不是终点从入行到现在我很长一段时间都在追求“更精确的并发量公式”后来发现方向有点偏。再精确的公式也只是建立在业务假设的基础上假设错了公式再严谨也没意义。真正靠得住的是估算加实测的循环用公式拿到初始值用压测校准假设再用校准后的数据指导下一次估算。这个循环跑得越多次估算的准确度就越高团队的经验也会沉淀下来。5.2 数据造假是压测的大忌这个问题我必须拿出来说因为它直接毁掉性能测试的价值。有些团队为了汇报好看压测时报喜不报忧或者把目标定得很低测试结果“轻松通过”。这样的压测不仅浪费人力更可怕的是给业务带来虚假的安全感上线后真正遇到故障时反而没有准备。我个人的原则是压测数据要经得起复看怎么测的、什么环境、用什么参数每一步都可以追溯。数据是脏的比没有数据更糟。5.3 性能测试的最终价值是容量规划做了十几年性能测试我自己的体会是高性能测试做得好不好不看你能跑多高的TPS而是看你能不能回答“系统还能撑多久、什么时候需要扩容、哪些业务增长会先压垮系统”这些问题。并发量和TPS的计算只是工具透过数据看懂系统的容量边界帮助业务提前做规划才是这项工作的价值所在。希望这篇文章的公式、案例和踩坑经验能让大家在实际项目中少走一些弯路。