搞性能压测这几年我最怕听到的一句话是业务方问“这系统到底能扛多少并发”问的人觉得这是个常识问题答的人心里却清楚如果不把口径定清楚这个问题根本没法回答。之前我们做活动页容量评估测试同学说单接口QPS能到800开发说核心链路TPS撑死500架构的兄弟说并发2000不在话下三个人都对但数字摆到一张PPT上就是互相打架。根子在于QPS、TPS、RT、并发数、吞吐量这几个词看着是常识实际口径差得十万八千里。这篇文章不绕弯子把这几个指标的定义、相互之间的数学关系以及最实际的“并发量到底怎么估算”一次讲透适合刚接手性能测试、或者正在准备容量评估但还没把指标关系理顺的同学。1. QPS和TPS先搞清楚你在数请求还是事务1.1 QPS是每秒查询数但“查询”的范围早就变了QPS全称Queries Per Second直译是每秒查询数。这个词最早流行于数据库领域衡量的是数据库每秒能执行多少次查询。后来HTTP接口普及大家发现接口的GET、POST本质上也是在“查”和“写”干脆把所有请求都笼统称为“查询”于是QPS慢慢演变成了“每秒请求数”的代名词。现在的技术讨论里你说QPS是每秒请求数完全没问题只要听的人知道你统计的是请求维度的数量就行。但这里有个值得注意的口径问题。一个HTTP接口被调用一次到后端可能会继续拆出多次内部调用比如查缓存、查数据库、调下游服务。如果你压测的是网关入口QPS统计的是外部进来的请求数如果你直接压测某个内部服务QPS可能就是内部实际处理的请求数。两个数差几倍很正常写报告前必须先标注清楚统计位置否则后面做容量规划时照着网关QPS去给下游服务配资源一定会出问题。1.2 TPS是每秒事务数事务边界才是关键TPS全称Transactions Per Second每秒事务数。它和QPS最大的区别在于“事务”是一个完整的业务操作而不是单个请求。比如“用户下单”是一个事务但一次下单在后端可能要经历商品校验、库存查询、库存扣减、订单生成、支付单创建这一串动作。如果拆成接口级别可能是四五个甚至更多的请求。所以同一个系统里TPS和QPS通常是两个不同的数字而且TPS一定小于等于QPS。两者的比值约等于平均每个事务包含的请求数。我之前压过一个交易链路前端每下一次单后端会发出6个内部HTTP请求压测结果显示QPS大约1200TPS大约2001200/2006恰好吻合。如果发现TPS和QPS的比值对不上事务内的请求数你反而要警惕了——要么统计数据有遗漏要么链路里存在大量异步请求或重试逻辑这类问题往往就藏在数字对不上的地方。1.3 做容量评估前先把指标口径统一起来我的建议很简单接口级压测看QPS链路级压测看TPS。如果业务方问“每秒能承受多少笔交易”你要答TPS不要拿QPS数据去顶替如果业务方问“这个接口能扛多少访问量”你要答QPS。很多团队在容量估算时数字对不上根子就在把这两个概念混着用。另外在做需求评审或写压测报告时最好统一注明“本报告中的QPS指入口请求数TPS指完整业务事务数”避免后面扯皮。这个习惯花不了几秒钟但能省掉大量沟通成本。2. RT、并发数、吞吐量从用户视角和服务视角看完全是两种东西2.1 RT不是“一个数”至少要看TP95和TP99RTResponse Time是响应时间字面意思是一个请求从发出到收到完整响应的时间。但实际压测和监控里RT从来不是单一数值它有平均值、中位数、TP90、TP95、TP99等一堆分位值。为啥要分这么细因为平均值太容易被长尾拖累。举个例子某个接口1秒内处理了100个请求其中99个都是100毫秒返回剩下1个慢请求耗时10秒平均值算下来大约是199毫秒。光看平均值你可能会觉得性能还不错但真实情况是这1秒内有个用户等了10秒体验已经是灾难级别了。我的习惯是容量评估、监控告警都以TP95或TP99为准平均值只作为参考。TP95的意义是95%的请求RT不超过这个值它比平均值稳定得多也更能反映大多数用户的真实体验。如果你的压测报告里只写一个平均RT说实话参考价值很有限。还有一个非常容易踩的坑RT要区分是哪一层的RT。压测工具测到的是端到端RT它包括了网络传输、网关处理、应用排队、数据库访问、响应传输的全过程。但应用日志里记录的RT往往只是应用内处理时间。两者可以差很多倍。分析问题时如果只盯着端到端RT你会以为应用慢了如果只盯着应用RT你又会漏掉网络和网关的瓶颈。两个数据要对照着看。顺带提醒一句这里的RT是响应时间Response Time别和网络设备里的路由目标RTRoute Target搞混完全是两个世界的概念。2.2 并发数不是“同时点了多少下”而是“同时有多少请求在处理中”并发数Concurrency的定义是同一时刻系统内正在处理中的请求数量。很多人听到“并发”第一反应是“有多少用户同时操作”但这其实是个很模糊的理解。一个用户可以在1秒内连续发起10个请求如果每个请求只要100毫秒那这10个请求是串行完成的系统里任意时刻只有1个请求在处理并发数就是1。反过来如果每个请求耗时2秒哪怕只有5个人同时点由于每个请求都占着服务资源长达2秒系统里某一时刻可能有5个请求同时在处理并发数就是5。说白了并发数关心的是请求占着资源的时间窗口而不是用户按下了多少次按钮。这也决定了并发数不能独立看必须和RT联动。你拿到一个“并发数500”的监控数字时一定要追问一句当时的QPS是多少、RT是多少如果QPS只有50、RT是10秒那说明系统已经严重排队过载了如果QPS是5000、RT是100毫秒说明系统在健康地高并发运行两者天壤之别。2.3 吞吐量有两种口径别说混了吞吐量Throughput在中文技术文章里出现频率很高但口径其实有两种。一种是请求数口径即单位时间完成的请求数量这种口径下吞吐量约等于QPS或TPS压测时大家说的“吞吐量上不去了”通常就是这个意思。另一种是数据量口径比如每秒处理多少MB、多少GB多用于文件传输、日志收集、数据库同步场景。搞清楚这个区别你就能看懂“吞吐量很高但延迟也高”这种说法了。压测报告里如果只写“吞吐量”不写单位你最好追一句是每秒多少个请求还是每秒多少兆数据不然两个数差着量级根本没法对比。为了方便对照我把这五个指标整理成一个表。指标核心维度常用单位关注点典型使用场景QPS每秒查询/请求数次/秒系统每秒处理了多少次请求接口级压测、网关容量规划TPS每秒事务数笔/秒系统每秒完成了多少笔业务操作交易链路压测、业务容量评估RT响应时间毫秒/秒单个请求从发出到返回的耗时用户体验评估、慢请求排查并发数同时处理中的请求数个系统同一时刻承载的处理中请求量容量估算、线程池配置吞吐量单位时间完成的工作量请求/秒 或 MB/秒系统整体处理能力性能对比、压测报告汇总3. 并发数怎么算记住那个“收费站模型”就够了3.1 核心公式并发数 ≈ QPS × RT系统处于稳定状态时任意时刻正在处理中的请求数量约等于单位时间完成的请求数量乘以单个请求的平均耗时。这就是常说的Littles Law公式长这样并发数 ≈ QPS或TPS× RT单位秒这个公式不是拍脑袋拍出来的它本质上是排队论里的通用规律不依赖请求到达的分布。只要系统长时间稳定运行这个近似关系就成立。我第一次理解它是通过一个收费站例子每秒有1辆车到达收费站每辆车缴费平均耗时10秒那么收费站里包括正在排队和正在缴费的平均同时会有10辆车。这里“到达率1辆/秒”就是QPS“服务时间10秒”就是RT“10辆车”就是并发数。一个例子三件事全通了。3.2 用公式判断系统处于哪个阶段这个公式最有价值的地方不是算一个数而是能帮你判断系统容量状态。对照压测过程中QPS、RT、并发线程数三者的变化趋势基本可以定位系统处在哪个阶段线程数增加QPS同步上升RT基本不变系统还有余量瓶颈还没到。线程数增加QPS上升变慢RT开始明显变大系统接近饱和排队开始出现。线程数增加QPS不但不涨反而下跌RT急剧上升系统已经过载再压下去只会更差。出现第三种情况时问题往往出在CPU忙等、线程切换、锁竞争或连接池耗尽上。这时候不要盲目加机器先按公式算一下当前并发数再用并发数去倒查线程池和数据库连接池的配置是否匹配。3.3 线上排障时怎么活用这个公式这个公式不只是压测前用排障时更好用。举个例子线上监控显示某个核心接口QPS是4000RT从正常的200毫秒飙到800毫秒。按公式算一下系统内并发数从4000×0.2800涨到了4000×0.83200说明系统内部堆积了3200个并发请求。这时你要去查线程池、数据库连接池有没有打满以及下游依赖有没有变慢。我记得有一次排查线上接口变慢就是靠这个公式先算出并发数翻了几倍然后定位到数据库连接池的等待时间暴涨——真正慢的不是应用代码而是连接池不够用了。3.4 注意公式算出来的是平均并发不是你设置的线程数这一点非常重要Littles Law给出的是系统长时间运行下的平均并发数不是压测工具里设置的线程数上限。很多新手在JMeter里配了200个线程就以为系统承受了“200并发”这是不对的。线程可能处于阻塞等待状态并没有真正进入业务处理流程。真实并发必须用QPS乘RT反推。你压测完看两个数QPS和平均RT乘一下才是系统实际承载的并发量。如果乘出来的数远小于你配置的线程数说明线程大部分时间在等待压测策略有问题要么加线程数要么检查是否被限流了。4. 从业务量反推并发量一套可复用的四步估算流程4.1 第一步从日活和访问行为估算目标QPS做容量规划的第一步不是拍并发数而是从业务目标倒推QPS。假设你有一个交易系统日活用户100万平均每个用户每天发起20次业务请求。一天的有效流量集中在4小时约14400秒内那平均QPS大约是100万×20÷14400≈1389。注意这是平均值而线上流量有明显的波峰波谷。一般业务峰值QPS是平均值的3到5倍遇到活动会更高。我们保守取4倍峰值QPS约等于1389×4≈5556。也就是说你的系统高峰时段每秒可能要处理超过5500个请求。如果你不乘这个峰值系数直接拿平均值去设计容量大促来了必挂。4.2 第二步确定目标RTRT怎么定两个来源一是线上监控里的TP95或TP99历史数据二是业务上可接受的响应时间上限。如果系统还没上线就按行业经验和业务预期先定一个合理值比如核心交易链路RT控制在200毫秒下单接口控制在500毫秒。后续压测验证后再调整。这里特别提醒RT单位一定要转成秒再套公式。200毫秒就是0.2秒500毫秒就是0.5秒。单位搞错了算出来的并发数会整整差1000倍。4.3 第三步代入公式算并发数有了峰值QPS和目标RT直接代入公式峰值并发数 峰值QPS × 目标RT按上面的例子5556×0.2≈1111。这意味着系统在高峰时段平均需要同时处理约1111个请求。这个数就是你后续配置线程池、数据库连接池、Redis连接数的底层依据。但记住1111是一个理论平均值是理想情况下的基础值。架构设计不能刚好按这个数来一定要留冗余。4.4 第四步加安全系数再核算单机容量我习惯在这个基础值上乘以1.5到2的安全系数以应对突发流量、单机故障、慢请求毛刺等不可控因素。按刚才的1111设计并发容量应该在1667到2222之间。接下来要落到机器规模上。假设你的应用服务器单机压测能稳定支撑400QPSRT保持在200毫秒以内那么根据峰值QPS 5556至少需要5556÷400≈14台实例。考虑安全系数建议按20台左右规划。同理数据库连接池大小、Redis连接数也可以用类似的思路核算只是把“QPS”替换成你关心的资源维度。整个估算流程看着简单难在每个参数的来源都有据可查QPS来自业务预估和峰值系数RT来自压测或监控安全系数来自你对业务波动的理解。一旦哪个假设变了比如日活涨了50%你可以立刻重算不用从头再拍一遍。4.5 不同业务的估算系数差多少上面用的4倍峰值系数和1.5到2倍安全系数是通用经验值不同业务形态差异很大我用一个表说明业务类型峰值/均值系数安全系数说明资讯内容类5~81.5~2流量集中在早晚通勤瞬时爆发强电商交易类3~5日常、10以上大促2左右大促需按历史峰值或报名流量预估内部管理系统1.5~21.2~1.5使用人员固定波峰不明显直播互动类8~152以上突发性强需要按瞬时峰值的极限考虑这个表可以当参考但最靠谱的做法还是拉自己系统最近3个月的流量曲线算一下真实峰值系数比任何经验值都准。5. 压测报告里的QPS/TPS“虚高”多半是这四个原因5.1 线程在等待却把“活跃线程数”当成了并发数这是最常见的误读。JMeter的线程组里配了500个线程测试一跑很多新手直接把这500当成系统的并发承载能力说“我们支撑了500并发”。实际上如果被测接口RT是2秒每个线程每秒最多发出0.5个请求500个线程理论上最大QPS也只有250。但JMeter面板上显示的是“活跃线程数”500真正的并发数要用QPS乘RT算。我见过不少压测报告把配置线程数当并发数写导致数字虚高一大截后面做容量规划时照着错误数字配机器上线直接被流量打穿。5.2 失败请求也被算进了成功样本有些压测工具默认把HTTP 500也算进样本或者业务接口返回了错误码但代码逻辑里没有正确断言导致失败请求混进成功统计QPS和TPS自然虚高。我之前排查过一个线上事故某核心接口成功率已经掉到50%但压测报告里TPS居然比平时还高。后来发现原因是压测脚本里的响应断言写反了所有失败请求全部被计成成功样本数字全面失真。所以压测脚本里的断言、状态码过滤、业务返回码校验一个都不能省。跑完压测第一件事不是看吞吐量而是看错误率和成功率错误率不为零的QPS再高也不能写进结论。5.3 平均RT被长尾拖高并发数跟着算虚高用Littles Law反推并发数时如果RT取的是平均值而这个平均值被少数慢请求和排队时间拉得很高算出来的并发数就会明显大于真正在处理业务的请求数。这个数字数学上没错但它反映的是系统里的“淤积量”而不是“承载量”。我建议RT用TP95或TP99作为输入同时把RT拆成“排队时间处理时间”来看。如果排队时间占比高说明系统资源已经紧张这时候要分析的是为什么排队而不是纠结并发数本身。5.4 压测时间太短系统根本没进入稳定态压测只跑二三十秒数据基本不可信。JVM需要预热JIT需要编译热点代码连接池需要建立连接缓存需要填充这些都需要时间。系统还没稳定你记录到的TPS往往是偏高的。我的做法是先跑3到5分钟预热再正式压测至少3分钟并且只取稳定段的数据前期的锯齿状数据直接剔除。这个小习惯能让压测结论靠谱很多。6. 混合场景压测和恒定吞吐量怎么模拟真实流量怎么给某个交易限速6.1 单接口压测数据再漂亮也不代表线上扛得住很多团队做压测习惯挑核心接口一个一个压每个接口都跑得很好但放到线上一起跑就崩。原因很简单真实业务是多接口混合调用的它们会争抢CPU、内存、数据库连接、带宽等资源。比如搜索接口QPS很高但缓存命中率也高消耗资源少下单接口QPS低却涉及数据库写、分布式锁、库存扣减资源消耗大。单接口压测完全暴露不了它们之间的资源争抢混合场景才更接近真实。6.2 JMeter混合测试的配比怎么定混合测试的核心是定义业务模型。如果线上有流量监控数据直接按真实占比推导比如浏览:搜索:详情:下单70:15:10:5。没有数据就先按业务经验拍一个后续再校准。在JMeter里实现混合配比有两种常用方式。一种是用不同线程组分别模拟不同业务场景通过线程数比例控制并发占比但这种方法有个缺陷如果各场景RT差异很大实际打到服务器的请求比例会被RT改写线程数比例不等于请求数比例。另一种是用Constant Throughput Timer直接控制每个业务的TPS更精确。如果你只是粗略压测第一种就够用如果想精准模拟线上流量比例建议用第二种。6.3 用JMeter的Constant Throughput Timer限制某个交易TPS很多人问“怎么给某个交易限制TPS”JMeter里对应的组件就是Constant Throughput Timer恒定吞吐量定时器。这个组件的本质是让吞吐量稳定在设定值附近常用于混合测试中控制每个交易的TPS而不是把系统打满。用法上注意三点。第一Target Throughput填你希望达到的每秒事务数。第二Calculate Based on选择“all active threads in current thread group”表示按当前线程组所有线程计算选择“all active threads”表示按全局线程计算。如果目标是限制某个业务的全局总TPS一定要选all active threads否则实际总TPS会被线程数乘以目标值放大和预期差很多。第三这个定时器的实现原理是动态计算并插入等待时间让实际吞吐降到目标值以下。它只能降速不能提速。如果系统本身只能跑到50TPS你把它设成100TPS它不可能帮你把系统“提”上去。所以它更适合的用法是系统已经能跑到高TPS你想人为把某个交易压到指定吞吐量用来模拟限流或混合比例场景。6.4 混合测试结果怎么读混合场景跑完不要只看总TPS。要分别看每个接口的TPS是否符合预设比例、RT是否达标、瓶颈落在哪个资源上。比如总TPS上去了但下单接口的RT从100毫秒涨到800毫秒说明混合流量下写链路先成了瓶颈。这时候要拆分成单独压测确认问题根因是数据库锁竞争还是分布式事务开销还是库存服务的连接池被占满了。我可以给你一个典型的定位路径先看总TPS和错误率错误率异常直接进入日志排查再按接口维度拆TPS找出最先恶化的接口最后针对这个接口单独压测同时看CPU、内存、数据库连接、GC等资源指标确定瓶颈层级。我自己在实际操作中习惯先用单接口压测拿到系统的上限参考值再做混合场景压测看链路争抢情况最后才拿数据去和业务方对指标。做久了你会发现并发量数字只是起点真正值钱的是你拿到数字之后对系统的理解RT分位数是否稳定、错误率是否可接受、瓶颈在哪个资源上、容量冗余还有多少。这个过程中口径统一比精确计算更重要。如果团队里每个人都用同一套指标定义和估算流程哪怕估算结果有偏差大家也能快速对齐问题出在哪一环而不是在数字上争执半天。