做了几年性能测试最大的一个感受是大部分团队不是不会用压测工具而是根本分不清负载测试、并发测试和压力测试到底在测什么更不知道压测报告里的那些数字到底该怎么解读。工具一跑完截图一发平均响应时间200ms、TPS 5000、错误率0%看起来漂亮但要问一句“拐点在哪”“系统什么时候会崩”“连接池有没有被打满”能答上来的没几个。这篇整理就是把这些年的实测经验一次性捋清楚把负载、并发、压力测试的边界讲透再把高频故障和排查思路整理成一份能直接对照使用的清单。适合测试工程师、准备做性能优化的开发以及需要向上面汇报结论的技术负责人。1. 负载、并发、压力测试先把概念掰开这三个概念在执行层面确实很像都是拿工具制造请求、看系统表现所以特别容易被混着用。但它们的测试目的、方法、结果分析完全是三条路。搞清楚定义后面的指标解读和问题排查才有落脚点。1.1 负载测试到底在测什么负载测试的核心是模拟预期负载检验系统在真实业务场景下的表现。这里的“负载”不只是并发用户数还包括请求频率、数据量、混合业务比例。比如一个电商核心链路不能只把首页接口和下单接口各自压一遍而是让购物车、库存、支付等接口按线上比例混合调用这样得出的负载结论才贴近真实。很多团队的做法是拿到压测工具把线程数调到几千一上来就往下碾压挂了就得出一个“系统性能不行”的结论。这个结论不客观。几千并发把系统打垮只能说明系统存在上限不能说明它在预期负载下是否合格。负载测试要回答的问题只有一个线上高峰流量进来时系统能不能稳定、高效地处理完。正确做法是梯度加压从预期峰值的60%起步按70%、80%、90%、100%、120%逐级加码每个档位稳定运行一段时间记录响应时间、TPS、错误率和资源利用率。为什么要稳定跑一段时间因为系统像弹簧短时间冲击可能扛得住但在持续负载下内存泄漏、连接池耗尽、缓存雪崩这些慢变量才会逐渐暴露。压一分钟就换档这些长期性问题很容易被漏掉。实操中单接口压测每个档位建议跑5到10分钟全链路压测10分钟起时间实在紧也必须保证3分钟以上再短数据波动太大。1.2 压力测试和负载测试的边界在哪简单一句话负载测试在预期范围内找问题压力测试超出预期找极限切割线就是预估流量。压力测试要做的是逐步把系统推过拐点看它在超出预估几倍甚至十倍流量时如何表现。重点观察三件事第一系统的吞吐量极限在哪第二极限附近错误率和响应时间会不会急剧恶化第三撤掉压力后系统能不能恢复到正常水位。这里必须引入一个特别关键的概念拐点。很多团队只关心最高TPS是多少其实比最高TPS更重要的是拐点的位置。拐点之前TPS会随着并发数增加而上升过了拐点TPS不再上涨甚至回落响应时间呈非线性猛增错误率开始冒头。这个拐点才是系统真正的容量边界它决定了一个系统该不该扩容、要不要限流、数据库要不要拆分。找拐点的方法不复杂逐渐增加并发数同时观察TPS曲线。当TPS增长明显减缓甚至掉头向下时把并发数记下来再用附近的值复测一次排除偶发波动的影响。有一点必须提醒压力测试会把系统打得很惨尤其在过载阶段系统可能短时间失去响应。不要拿生产库的数据来试错压力测试要在独立环境做或选择业务低峰期并做好完整预案。1.3 并发测试最容易被人忽视的环节并发测试和负载、压力的关注点完全不一样。负载和压力看系统的处理能力并发看的是多个用户同时做同样操作时业务数据和系统资源会不会乱。秒杀时100个用户同时提交订单库存会不会被扣成负数同一个账号多端同时登录会话状态会不会被后登录的覆盖同一笔订单被连续点击提交会不会生成多笔支付单。不跑这类场景光看TPS再漂亮上线后第一次抢购活动就可能翻车。这类测试最常见的产出不是性能报表而是一堆奇奇怪怪的日志。我见过最普遍的现象是接口响应时间看起来全绿数据库日志里却全是锁等待超时。如果只看平均响应时间谁都不会想到底层锁竞争已经严重到影响业务了。所以做并发测试时不要只盯聚合报告要把数据库日志、应用日志、中间件日志全部打开看有没有报错、有没有锁等待、有没有重复执行。数据正确性永远排在性能指标前面这是性能测试里最容易被本末倒置的一件事。2. 性能指标怎么读才不会被平均数骗压测结果出来后最忌讳的就是直接甩一张聚合报告截图。聚合报告里的平均数给人“看着还行”的感觉但它掩盖了长尾请求、错误请求和资源瓶颈。要做出可靠判断至少把响应时间、吞吐量、错误率、资源指标四个维度串起来看缺一个都可能得出偏颇的结论。2.1 响应时间不能只看平均值平均响应时间是最会骗人的指标。1000个请求里999个耗时20ms只有1个因为Full GC停了5秒平均值约25ms听起来非常健康可那1个用户的体验早就崩了这就是平均数的陷阱少数极端值把整体数据拉平了。所以现在性能测试普遍用百分位指标。p95表示95%的请求耗时低于这个值日常容量评估主要看它p99表示99%的请求耗时低于这个值用来观察长尾问题。如果p99和p95差距特别大说明存在一批特慢请求往往是GC停顿、数据库慢查询、下游接口超时造成的。这些长尾请求才是真正的隐患源头。JMeter聚合报告默认里有90% Line也可以开启显示p95和p99。另外建议用后端监听器把指标实时上报到监控平台看整条时间曲线而不是压测结束后看一个汇总数字。数据曲线比孤立平均值有用得多因为你能看到系统从哪个时间点开始恶化。2.2 吞吐量和错误率必须搭配看TPS指每秒完成的事务数QPS指每秒完成的查询数接口压测场景里用TPS更严谨因为一个事务可能包含多次查询。吞吐量一旦脱离错误率很容易被误读。TPS同样是800错误率0%和错误率5%代表的是完全不同的状态。错误率上升往往是系统逼近瓶颈的早期信号通常比响应时间恶化出现得更早。压测时我习惯同时盯错误率一旦从0开始增长说明系统进入不安全区这时候再看错误类型能快速判断是超时错误还是业务错误。不同业务的错误率容忍度不一样可以参照这组经验值核心交易链路低于0.1%普通查询接口低于0.5%非核心可重试的异步任务可以放宽到1%到5%。当然最终要结合业务定义“什么算失败”比如超时后重试成功的请求算不算失败在压测前就要定清楚。2.3 资源指标才是系统真实状态的照妖镜应用层指标好看不代表底层没问题。TPS涨了30%但服务器CPU已经从40%飙到90%说明应用余量不足再来一波流量就可能导致超时。资源指标一般看四个维度要联动分析不能孤立看。CPU要区分用户态和系统态us高说明应用计算密集比如频繁的序列化、加解密、正则回溯sy高说明系统调用频繁可能在大量线程切换iowait高则怀疑磁盘读写成为瓶颈。内存不要只看空闲量更要关注交换分区和GC频率Java应用里频繁GC导致的卡顿比内存不足暴露得更早。磁盘看util和IOPSutil到80%以上基本可以认定磁盘拖了后腿。网络除了带宽还要关注TCP重传率重传率升高通常意味着网络或对端处理异常。这些指标在压测时要联动看。比如TPS掉下来了同时CPU飙高、磁盘util打满基本可以判断是日志同步写或数据库刷盘拖累了处理链路。只有把各维度串起来才能分清谁是因谁是果。3. 压测工具选型与脚本设计的门道工具选错会让整轮压测事倍功半。但选工具不能只看哪个火要看团队情况、协议类型和被测系统形态。这里先说清楚几种主流工具的差别和适用场景再说脚本设计的几个关键点。3.1 工具怎么选不是越贵越好JMeter是普及度最高的选择开源支持HTTP、TCP、JDBC、JMS等多种协议插件生态丰富团队里随便一个测试同学都能很快上手写脚本。缺点也很明显它是Java应用单机高并发时自身资源消耗大需要配合分布式部署。Gatling基于Scala和Netty实现底层异步IO单机发压能力更强生成的报告特别直观但脚本要用Scala写学习成本高一些。k6的脚本用JavaScript写天生适合集成到CI/CD里做持续性能验证很方便。wrk是轻量级命令行工具一条命令就能对单个HTTP接口发起大并发配合wrk2还能控制固定吞吐率做快速冒烟效率极高。选型按这个标准卡就行协议支持够不够、脚本维护方不方便、有没有实时监控、团队上手要多久。大部分Web服务场景优先JMeter追求更高压测效率和报告美观的团队可以用Gatling验证单接口性能用wrk需要自动化回归压测的上k6。工具不是越重越好要匹配场景。3.2 JMeter脚本设计的关键参数JMeter脚本几个参数设置不对结果就会“水”。线程组里的Number of Threads是并发用户数Ramp-up period是全部线程拉起的耗时我习惯设到30到60秒让并发量逐步到达目标值模拟真实用户渐进式进入而不是开关一拉全部冲进去。Loop Count做压力测试时通常设为forever配合运行时长来控制。参数化必须上心。如果不做参数化1000个线程拿同一个手机号或订单号打接口很容易被架构层查重或缓存拦截压测结果严重失真。最常见做法是用CSV Data Set Config从外部文件读取参数一行对应一条数据保证每个请求数据都不一样。断言一定要加。HTTP请求后面加响应断言判断状态码是否为200或者响应体是否包含预期返回标识。不加断言的话接口就算返回500JMeter也可能统计为成功。这一处细节可以直接毁掉整轮压测的可信度。聚合报告里除了看样本数、平均值、错误率建议把p95、p99百分位列显示出来。线程组参数建议可以参考这张表参数建议设置说明Number of Threads按压测目标设定一般从基线值起步梯次增加Ramp-up period30~60秒模拟用户渐进进入避免瞬间冲击Loop Count压力测试用forever配合运行时长短控制总量CSV参数化每条数据独立防止请求命中缓存或查重逻辑响应断言必须配置防止错误请求被统计为成功3.3 分布式压测的正确姿势单机压测到几千并发时压测机自身往往先扛不住。JMeter每个线程都消耗内存线程拉多以后压测机本身的GC和CPU调度会拖慢发压速度导致数据偏差。这时候就需要分布式压测。分布式结构很简单一台控制机加几台执行机。执行机启动jmeter-server监听端口控制机在jmeter.properties里配置remote_hosts然后统一发起测试。配置里常见的坑有三个执行机和控制机时间不一致导致监控数据时间轴错位压测前要校准时钟执行机脚本版本不一致导致结果差异每次压测前必须同步测试计划防火墙没放行JMeter通信端口控制机连接失败。并发数不是简单除以执行机数量就完事。每台执行机也要控制线程数避免单机负载过高反而成了新瓶颈。单机线程数控制在几百到一千以内比较稳具体看脚本复杂度和请求体大小。压测过程中要监控执行机的CPU和内存如果执行机已经满载先调整压测配置再继续否则所有结果都值得怀疑。4. 一轮完整压测的实操流程这部分写一套可以直接照搬的流程按步骤走基本不会出大问题。我把一轮压测拆成四个阶段每个阶段都有必须完成的动作跳过一个步骤后面都可能要返工。4.1 环境与数据准备压测环境必须独立。拿生产环境直接压是最不推荐的尤其是写入型链路一根稻草都可能引发线上事故。使用专用测试环境时配置最好和生产同规格或者按明确比例缩配这样才能把结果换算回生产容量。缩配时要记录清楚参数方便后续推算。数据准备经常被忽略。压测时数据库只有几万条数据接口几秒跑完线上几千万条数据时慢查询全浮出来了。测试数据量至少要有代表性的数量级同时要和真实数据区分开避免污染。线上环境的定时任务、消息消费、监控告警等干扰项也要在压测前梳理一遍能关就关不能关就记录它对指标的干扰。4.2 基线测试与冒烟验证正式开压前先做一次冒烟验证用5到10个并发用户把每个脚本单独跑一遍。目的不是测性能是验证脚本本身没问题参数化数据能不能取到、断言是否生效、接口是否返回预期结果。这一步省不了否则压到一半发现几百个请求全因参数错误失败前面白干。冒烟通过后记录一组低并发下的基线数据包括正常响应时间、TPS、错误率。基线数据是之后每一档的参照物没有基线就无法判断高并发下的指标变化是真实性能退化还是环境波动。4.3 梯度加压找拐点正式压测从基线并发数开始按阶梯往上加。以50、100、200、400、800的序列为例每个档位运行10分钟左右记录TPS、响应时间、错误率、服务端CPU和内存。每结束一档对比上一档的数据变化趋势。判断拐点靠规则并发数继续增加TPS增长明显放缓甚至回头下行响应时间非线性上升说明到了容量边界。立即停止加压记下并发数再用附近的值做重复验证。重复验证很重要第一次出现拐点可能是环境波动连续两次同样规律才可信。下面是一张压测记录示例表描述拐点出现时的常见变化形态并发数TPS平均响应时间错误率观察结论5098045ms0%稳定100190048ms0%稳定200260070ms0%正常增长4002700320ms1.2%拐点出现8002300850ms8.5%过载恶化4.4 压力测试与恢复验证拐点确认后如果要做压力测试就在拐点并发数基础上继续加观察系统进入过载状态后的表现。锁等待、连接池耗尽、线程池爆满、内存溢出多数都在这阶段集中爆发。全程打开监控重点看错误类型变化不同故障的报错特征差异很大。压完别忘了恢复验证撤掉压力让系统空转一段时间观察CPU、内存、连接池、线程数能否回到压测前水平。恢复不了说明存在泄漏或残留状态这类问题上线后迟早会以故障形式爆出来。恢复验证是整轮压测最后一个闭环也是一轮压测完整与否的标志。5. 高频故障清单与排查实录这一节把性能测试中最高频的故障整理成清单每条都给出现象、排查动作和解决方向。你可以直接对照使用不用从头翻文档。5.1 数据库连接池被打满现象应用日志报连接不可用或请求超时数据库监控里连接数接近max_connections接口响应时间在并发抬升后迅速恶化。排查第一步去数据库执行show full processlist看会话在做什么。大量线程处于Sleep状态多半是连接泄漏大量线程处于Waiting for lock或执行同一个慢SQL那是锁竞争或SQL性能问题。然后查代码确认连接是否及时归还事务边界是否拉得太长比如一个事务里嵌了多次外部接口调用。最后检查连接池参数像HikariCP的maximum-pool-size设多大空闲回收策略有没有配。SHOW FULL PROCESSLIST; SELECT * FROM information_schema.INNODB_TRX; SHOW STATUS LIKE Threads_connected;解决方向连接数放大要在数据库max_connections允许范围内否则只会把数据库拖死优化慢SQL减少连接占用时间给连接池配等待超时快速失败而不是无限排队业务上尽量缩短事务内的外部调用耗时。5.2 内存膨胀与GC卡顿现象响应时间出现周期性尖刺Java服务端CPU居高不下监控上Full GC频繁堆内存回收后仍不下降。排查用jstat观察GC频率和耗时确认是否出现频繁Full GC。再用jmap导出堆快照分析哪个对象占用了大量空间。常见原因是压测数据量大导致缓存区塞满或业务代码在循环里不断创建对象更严重的是真实的内存泄漏。jstat -gcutil pid 1000 jmap -dump:formatb,fileheap.bin pid jstack pid thread_dump.txt解决方向对象分配压力大就调大堆内存、调整GC策略比如切换G1并设置合理的停顿目标缓存写穿要给缓存加容量上限和淘汰策略确认是内存泄漏就得修复代码后重新验证。5.3 线程池排队与拒绝现象日志出现任务拒绝异常接口返回限流或服务不可用状态码服务端线程数打满新请求排队队列满了被直接丢弃。排查先看线程池参数核心线程数、最大线程数、队列容量是否合理。再用jstack看大量线程处于什么状态。是WAITING等连接池放行还是BLOCKED卡在锁上还是RUNNABLE但长时间执行数据库操作线程被卡在哪一步决定问题根源是连接池容量、锁竞争还是下游慢调用。解决方向给下游依赖加超时控制防止线程被慢调用拖死合理设置线程池大小最大线程数根据业务场景估算而不是拍脑袋填200队列要有界配熔断保护。特别注意线程池调大能缓解一时压力但数据库和缓存能不能扛住要配套观察。5.4 压测机自身成了瓶颈现象服务端各项指标都很低TPS却一直上不去一看压测机CPU已经100%网络带宽跑满内存被JVM占用过多。压测机自身资源耗尽发出的请求本身就不稳定延迟和丢包会混进结果导致误判。压测前先观察压测机资源如果单台发压困难用分布式压测把负载分摊到多台机器。压测中也要盯着执行机的CPU和网络执行机满了就先调压测配置不要硬着头皮把一轮跑完。5.5 响应时间周期性抖动现象TPS和响应时间曲线出现规律的锯齿状波动比如每几分钟固定一次尖峰。排查思路是把压测曲线和服务端GC监控对齐看尖峰是否和Full GC重合再查应用内有没有定时任务、批量任务在固定间隔触发还要检查磁盘IO日志同步写全量落盘时频繁日志刷新会让响应时间周期性抖动。网络设备和防火墙的流量核查偶尔也会造成周期波动。解决方向定时任务错峰执行日志改异步写和采样写GC参数调整减少停顿。这类问题排查比较费时间但只要理解了曲线规律定位就不算难。6. 压测之外的个人经验6.1 别把压测报告当成功劳簿压测真正难的不是把工具跑起来而是面对一堆指标和日志时冷静判断系统真实的处境。我见过太多团队把压测结果做成汇报材料填几个漂亮数字就宣布性能达标却没人关心系统离崩溃还有多远、哪个环节会先到极限。数字好看的报告不一定是好报告能把拐点和瓶颈讲清楚的报告才真正有价值。我的实践体会是性能测试一定要以业务目标为起点。做之前先回答三个问题预期峰值是多少、哪些是核心链路、什么算不可用。这些问题有了答案后续所有测试和分析都有了依据。跑完以后哪怕数据不好看也不要藏着掖着把拐点、瓶颈、错误类型全部摆出来这样的报告才真正有用。6.2 数据稳定比单次好看更重要最后分享一个小技巧一次压测的结论最好结合两次不同日期的重复测试来下。系统性能受环境波动影响很大单测一次就拍板容易出现今天能扛5000并发、明天扛不住3000的反差。多测两轮数据稳定了结论才有说服力。另外压测不是做一次就结束的事。每次发版涉及接口逻辑、中间件参数或数据库结构变化都应该跑一轮关键链路的回归压测。只要简单场景验证没有性能回退就能省掉很多线上半夜查问题的痛苦。性能测试说到底就是让问题在可控环境里提前暴露而不是等用户先替你踩出来。希望这份整理能让你下一次压测少走一些弯路。
做了几年性能测试最大的一个感受是大部分团队不是不会用压测工具而是根本分不清负载测试、并发测试和压力测试到底在测什么更不知道压测报告里的那些数字到底该怎么解读。工具一跑完截图一发平均响应时间200ms、TPS 5000、错误率0%看起来漂亮但要问一句“拐点在哪”“系统什么时候会崩”“连接池有没有被打满”能答上来的没几个。这篇整理就是把这些年的实测经验一次性捋清楚把负载、并发、压力测试的边界讲透再把高频故障和排查思路整理成一份能直接对照使用的清单。适合测试工程师、准备做性能优化的开发以及需要向上面汇报结论的技术负责人。1. 负载、并发、压力测试先把概念掰开这三个概念在执行层面确实很像都是拿工具制造请求、看系统表现所以特别容易被混着用。但它们的测试目的、方法、结果分析完全是三条路。搞清楚定义后面的指标解读和问题排查才有落脚点。1.1 负载测试到底在测什么负载测试的核心是模拟预期负载检验系统在真实业务场景下的表现。这里的“负载”不只是并发用户数还包括请求频率、数据量、混合业务比例。比如一个电商核心链路不能只把首页接口和下单接口各自压一遍而是让购物车、库存、支付等接口按线上比例混合调用这样得出的负载结论才贴近真实。很多团队的做法是拿到压测工具把线程数调到几千一上来就往下碾压挂了就得出一个“系统性能不行”的结论。这个结论不客观。几千并发把系统打垮只能说明系统存在上限不能说明它在预期负载下是否合格。负载测试要回答的问题只有一个线上高峰流量进来时系统能不能稳定、高效地处理完。正确做法是梯度加压从预期峰值的60%起步按70%、80%、90%、100%、120%逐级加码每个档位稳定运行一段时间记录响应时间、TPS、错误率和资源利用率。为什么要稳定跑一段时间因为系统像弹簧短时间冲击可能扛得住但在持续负载下内存泄漏、连接池耗尽、缓存雪崩这些慢变量才会逐渐暴露。压一分钟就换档这些长期性问题很容易被漏掉。实操中单接口压测每个档位建议跑5到10分钟全链路压测10分钟起时间实在紧也必须保证3分钟以上再短数据波动太大。1.2 压力测试和负载测试的边界在哪简单一句话负载测试在预期范围内找问题压力测试超出预期找极限切割线就是预估流量。压力测试要做的是逐步把系统推过拐点看它在超出预估几倍甚至十倍流量时如何表现。重点观察三件事第一系统的吞吐量极限在哪第二极限附近错误率和响应时间会不会急剧恶化第三撤掉压力后系统能不能恢复到正常水位。这里必须引入一个特别关键的概念拐点。很多团队只关心最高TPS是多少其实比最高TPS更重要的是拐点的位置。拐点之前TPS会随着并发数增加而上升过了拐点TPS不再上涨甚至回落响应时间呈非线性猛增错误率开始冒头。这个拐点才是系统真正的容量边界它决定了一个系统该不该扩容、要不要限流、数据库要不要拆分。找拐点的方法不复杂逐渐增加并发数同时观察TPS曲线。当TPS增长明显减缓甚至掉头向下时把并发数记下来再用附近的值复测一次排除偶发波动的影响。有一点必须提醒压力测试会把系统打得很惨尤其在过载阶段系统可能短时间失去响应。不要拿生产库的数据来试错压力测试要在独立环境做或选择业务低峰期并做好完整预案。1.3 并发测试最容易被人忽视的环节并发测试和负载、压力的关注点完全不一样。负载和压力看系统的处理能力并发看的是多个用户同时做同样操作时业务数据和系统资源会不会乱。秒杀时100个用户同时提交订单库存会不会被扣成负数同一个账号多端同时登录会话状态会不会被后登录的覆盖同一笔订单被连续点击提交会不会生成多笔支付单。不跑这类场景光看TPS再漂亮上线后第一次抢购活动就可能翻车。这类测试最常见的产出不是性能报表而是一堆奇奇怪怪的日志。我见过最普遍的现象是接口响应时间看起来全绿数据库日志里却全是锁等待超时。如果只看平均响应时间谁都不会想到底层锁竞争已经严重到影响业务了。所以做并发测试时不要只盯聚合报告要把数据库日志、应用日志、中间件日志全部打开看有没有报错、有没有锁等待、有没有重复执行。数据正确性永远排在性能指标前面这是性能测试里最容易被本末倒置的一件事。2. 性能指标怎么读才不会被平均数骗压测结果出来后最忌讳的就是直接甩一张聚合报告截图。聚合报告里的平均数给人“看着还行”的感觉但它掩盖了长尾请求、错误请求和资源瓶颈。要做出可靠判断至少把响应时间、吞吐量、错误率、资源指标四个维度串起来看缺一个都可能得出偏颇的结论。2.1 响应时间不能只看平均值平均响应时间是最会骗人的指标。1000个请求里999个耗时20ms只有1个因为Full GC停了5秒平均值约25ms听起来非常健康可那1个用户的体验早就崩了这就是平均数的陷阱少数极端值把整体数据拉平了。所以现在性能测试普遍用百分位指标。p95表示95%的请求耗时低于这个值日常容量评估主要看它p99表示99%的请求耗时低于这个值用来观察长尾问题。如果p99和p95差距特别大说明存在一批特慢请求往往是GC停顿、数据库慢查询、下游接口超时造成的。这些长尾请求才是真正的隐患源头。JMeter聚合报告默认里有90% Line也可以开启显示p95和p99。另外建议用后端监听器把指标实时上报到监控平台看整条时间曲线而不是压测结束后看一个汇总数字。数据曲线比孤立平均值有用得多因为你能看到系统从哪个时间点开始恶化。2.2 吞吐量和错误率必须搭配看TPS指每秒完成的事务数QPS指每秒完成的查询数接口压测场景里用TPS更严谨因为一个事务可能包含多次查询。吞吐量一旦脱离错误率很容易被误读。TPS同样是800错误率0%和错误率5%代表的是完全不同的状态。错误率上升往往是系统逼近瓶颈的早期信号通常比响应时间恶化出现得更早。压测时我习惯同时盯错误率一旦从0开始增长说明系统进入不安全区这时候再看错误类型能快速判断是超时错误还是业务错误。不同业务的错误率容忍度不一样可以参照这组经验值核心交易链路低于0.1%普通查询接口低于0.5%非核心可重试的异步任务可以放宽到1%到5%。当然最终要结合业务定义“什么算失败”比如超时后重试成功的请求算不算失败在压测前就要定清楚。2.3 资源指标才是系统真实状态的照妖镜应用层指标好看不代表底层没问题。TPS涨了30%但服务器CPU已经从40%飙到90%说明应用余量不足再来一波流量就可能导致超时。资源指标一般看四个维度要联动分析不能孤立看。CPU要区分用户态和系统态us高说明应用计算密集比如频繁的序列化、加解密、正则回溯sy高说明系统调用频繁可能在大量线程切换iowait高则怀疑磁盘读写成为瓶颈。内存不要只看空闲量更要关注交换分区和GC频率Java应用里频繁GC导致的卡顿比内存不足暴露得更早。磁盘看util和IOPSutil到80%以上基本可以认定磁盘拖了后腿。网络除了带宽还要关注TCP重传率重传率升高通常意味着网络或对端处理异常。这些指标在压测时要联动看。比如TPS掉下来了同时CPU飙高、磁盘util打满基本可以判断是日志同步写或数据库刷盘拖累了处理链路。只有把各维度串起来才能分清谁是因谁是果。3. 压测工具选型与脚本设计的门道工具选错会让整轮压测事倍功半。但选工具不能只看哪个火要看团队情况、协议类型和被测系统形态。这里先说清楚几种主流工具的差别和适用场景再说脚本设计的几个关键点。3.1 工具怎么选不是越贵越好JMeter是普及度最高的选择开源支持HTTP、TCP、JDBC、JMS等多种协议插件生态丰富团队里随便一个测试同学都能很快上手写脚本。缺点也很明显它是Java应用单机高并发时自身资源消耗大需要配合分布式部署。Gatling基于Scala和Netty实现底层异步IO单机发压能力更强生成的报告特别直观但脚本要用Scala写学习成本高一些。k6的脚本用JavaScript写天生适合集成到CI/CD里做持续性能验证很方便。wrk是轻量级命令行工具一条命令就能对单个HTTP接口发起大并发配合wrk2还能控制固定吞吐率做快速冒烟效率极高。选型按这个标准卡就行协议支持够不够、脚本维护方不方便、有没有实时监控、团队上手要多久。大部分Web服务场景优先JMeter追求更高压测效率和报告美观的团队可以用Gatling验证单接口性能用wrk需要自动化回归压测的上k6。工具不是越重越好要匹配场景。3.2 JMeter脚本设计的关键参数JMeter脚本几个参数设置不对结果就会“水”。线程组里的Number of Threads是并发用户数Ramp-up period是全部线程拉起的耗时我习惯设到30到60秒让并发量逐步到达目标值模拟真实用户渐进式进入而不是开关一拉全部冲进去。Loop Count做压力测试时通常设为forever配合运行时长来控制。参数化必须上心。如果不做参数化1000个线程拿同一个手机号或订单号打接口很容易被架构层查重或缓存拦截压测结果严重失真。最常见做法是用CSV Data Set Config从外部文件读取参数一行对应一条数据保证每个请求数据都不一样。断言一定要加。HTTP请求后面加响应断言判断状态码是否为200或者响应体是否包含预期返回标识。不加断言的话接口就算返回500JMeter也可能统计为成功。这一处细节可以直接毁掉整轮压测的可信度。聚合报告里除了看样本数、平均值、错误率建议把p95、p99百分位列显示出来。线程组参数建议可以参考这张表参数建议设置说明Number of Threads按压测目标设定一般从基线值起步梯次增加Ramp-up period30~60秒模拟用户渐进进入避免瞬间冲击Loop Count压力测试用forever配合运行时长短控制总量CSV参数化每条数据独立防止请求命中缓存或查重逻辑响应断言必须配置防止错误请求被统计为成功3.3 分布式压测的正确姿势单机压测到几千并发时压测机自身往往先扛不住。JMeter每个线程都消耗内存线程拉多以后压测机本身的GC和CPU调度会拖慢发压速度导致数据偏差。这时候就需要分布式压测。分布式结构很简单一台控制机加几台执行机。执行机启动jmeter-server监听端口控制机在jmeter.properties里配置remote_hosts然后统一发起测试。配置里常见的坑有三个执行机和控制机时间不一致导致监控数据时间轴错位压测前要校准时钟执行机脚本版本不一致导致结果差异每次压测前必须同步测试计划防火墙没放行JMeter通信端口控制机连接失败。并发数不是简单除以执行机数量就完事。每台执行机也要控制线程数避免单机负载过高反而成了新瓶颈。单机线程数控制在几百到一千以内比较稳具体看脚本复杂度和请求体大小。压测过程中要监控执行机的CPU和内存如果执行机已经满载先调整压测配置再继续否则所有结果都值得怀疑。4. 一轮完整压测的实操流程这部分写一套可以直接照搬的流程按步骤走基本不会出大问题。我把一轮压测拆成四个阶段每个阶段都有必须完成的动作跳过一个步骤后面都可能要返工。4.1 环境与数据准备压测环境必须独立。拿生产环境直接压是最不推荐的尤其是写入型链路一根稻草都可能引发线上事故。使用专用测试环境时配置最好和生产同规格或者按明确比例缩配这样才能把结果换算回生产容量。缩配时要记录清楚参数方便后续推算。数据准备经常被忽略。压测时数据库只有几万条数据接口几秒跑完线上几千万条数据时慢查询全浮出来了。测试数据量至少要有代表性的数量级同时要和真实数据区分开避免污染。线上环境的定时任务、消息消费、监控告警等干扰项也要在压测前梳理一遍能关就关不能关就记录它对指标的干扰。4.2 基线测试与冒烟验证正式开压前先做一次冒烟验证用5到10个并发用户把每个脚本单独跑一遍。目的不是测性能是验证脚本本身没问题参数化数据能不能取到、断言是否生效、接口是否返回预期结果。这一步省不了否则压到一半发现几百个请求全因参数错误失败前面白干。冒烟通过后记录一组低并发下的基线数据包括正常响应时间、TPS、错误率。基线数据是之后每一档的参照物没有基线就无法判断高并发下的指标变化是真实性能退化还是环境波动。4.3 梯度加压找拐点正式压测从基线并发数开始按阶梯往上加。以50、100、200、400、800的序列为例每个档位运行10分钟左右记录TPS、响应时间、错误率、服务端CPU和内存。每结束一档对比上一档的数据变化趋势。判断拐点靠规则并发数继续增加TPS增长明显放缓甚至回头下行响应时间非线性上升说明到了容量边界。立即停止加压记下并发数再用附近的值做重复验证。重复验证很重要第一次出现拐点可能是环境波动连续两次同样规律才可信。下面是一张压测记录示例表描述拐点出现时的常见变化形态并发数TPS平均响应时间错误率观察结论5098045ms0%稳定100190048ms0%稳定200260070ms0%正常增长4002700320ms1.2%拐点出现8002300850ms8.5%过载恶化4.4 压力测试与恢复验证拐点确认后如果要做压力测试就在拐点并发数基础上继续加观察系统进入过载状态后的表现。锁等待、连接池耗尽、线程池爆满、内存溢出多数都在这阶段集中爆发。全程打开监控重点看错误类型变化不同故障的报错特征差异很大。压完别忘了恢复验证撤掉压力让系统空转一段时间观察CPU、内存、连接池、线程数能否回到压测前水平。恢复不了说明存在泄漏或残留状态这类问题上线后迟早会以故障形式爆出来。恢复验证是整轮压测最后一个闭环也是一轮压测完整与否的标志。5. 高频故障清单与排查实录这一节把性能测试中最高频的故障整理成清单每条都给出现象、排查动作和解决方向。你可以直接对照使用不用从头翻文档。5.1 数据库连接池被打满现象应用日志报连接不可用或请求超时数据库监控里连接数接近max_connections接口响应时间在并发抬升后迅速恶化。排查第一步去数据库执行show full processlist看会话在做什么。大量线程处于Sleep状态多半是连接泄漏大量线程处于Waiting for lock或执行同一个慢SQL那是锁竞争或SQL性能问题。然后查代码确认连接是否及时归还事务边界是否拉得太长比如一个事务里嵌了多次外部接口调用。最后检查连接池参数像HikariCP的maximum-pool-size设多大空闲回收策略有没有配。SHOW FULL PROCESSLIST; SELECT * FROM information_schema.INNODB_TRX; SHOW STATUS LIKE Threads_connected;解决方向连接数放大要在数据库max_connections允许范围内否则只会把数据库拖死优化慢SQL减少连接占用时间给连接池配等待超时快速失败而不是无限排队业务上尽量缩短事务内的外部调用耗时。5.2 内存膨胀与GC卡顿现象响应时间出现周期性尖刺Java服务端CPU居高不下监控上Full GC频繁堆内存回收后仍不下降。排查用jstat观察GC频率和耗时确认是否出现频繁Full GC。再用jmap导出堆快照分析哪个对象占用了大量空间。常见原因是压测数据量大导致缓存区塞满或业务代码在循环里不断创建对象更严重的是真实的内存泄漏。jstat -gcutil pid 1000 jmap -dump:formatb,fileheap.bin pid jstack pid thread_dump.txt解决方向对象分配压力大就调大堆内存、调整GC策略比如切换G1并设置合理的停顿目标缓存写穿要给缓存加容量上限和淘汰策略确认是内存泄漏就得修复代码后重新验证。5.3 线程池排队与拒绝现象日志出现任务拒绝异常接口返回限流或服务不可用状态码服务端线程数打满新请求排队队列满了被直接丢弃。排查先看线程池参数核心线程数、最大线程数、队列容量是否合理。再用jstack看大量线程处于什么状态。是WAITING等连接池放行还是BLOCKED卡在锁上还是RUNNABLE但长时间执行数据库操作线程被卡在哪一步决定问题根源是连接池容量、锁竞争还是下游慢调用。解决方向给下游依赖加超时控制防止线程被慢调用拖死合理设置线程池大小最大线程数根据业务场景估算而不是拍脑袋填200队列要有界配熔断保护。特别注意线程池调大能缓解一时压力但数据库和缓存能不能扛住要配套观察。5.4 压测机自身成了瓶颈现象服务端各项指标都很低TPS却一直上不去一看压测机CPU已经100%网络带宽跑满内存被JVM占用过多。压测机自身资源耗尽发出的请求本身就不稳定延迟和丢包会混进结果导致误判。压测前先观察压测机资源如果单台发压困难用分布式压测把负载分摊到多台机器。压测中也要盯着执行机的CPU和网络执行机满了就先调压测配置不要硬着头皮把一轮跑完。5.5 响应时间周期性抖动现象TPS和响应时间曲线出现规律的锯齿状波动比如每几分钟固定一次尖峰。排查思路是把压测曲线和服务端GC监控对齐看尖峰是否和Full GC重合再查应用内有没有定时任务、批量任务在固定间隔触发还要检查磁盘IO日志同步写全量落盘时频繁日志刷新会让响应时间周期性抖动。网络设备和防火墙的流量核查偶尔也会造成周期波动。解决方向定时任务错峰执行日志改异步写和采样写GC参数调整减少停顿。这类问题排查比较费时间但只要理解了曲线规律定位就不算难。6. 压测之外的个人经验6.1 别把压测报告当成功劳簿压测真正难的不是把工具跑起来而是面对一堆指标和日志时冷静判断系统真实的处境。我见过太多团队把压测结果做成汇报材料填几个漂亮数字就宣布性能达标却没人关心系统离崩溃还有多远、哪个环节会先到极限。数字好看的报告不一定是好报告能把拐点和瓶颈讲清楚的报告才真正有价值。我的实践体会是性能测试一定要以业务目标为起点。做之前先回答三个问题预期峰值是多少、哪些是核心链路、什么算不可用。这些问题有了答案后续所有测试和分析都有了依据。跑完以后哪怕数据不好看也不要藏着掖着把拐点、瓶颈、错误类型全部摆出来这样的报告才真正有用。6.2 数据稳定比单次好看更重要最后分享一个小技巧一次压测的结论最好结合两次不同日期的重复测试来下。系统性能受环境波动影响很大单测一次就拍板容易出现今天能扛5000并发、明天扛不住3000的反差。多测两轮数据稳定了结论才有说服力。另外压测不是做一次就结束的事。每次发版涉及接口逻辑、中间件参数或数据库结构变化都应该跑一轮关键链路的回归压测。只要简单场景验证没有性能回退就能省掉很多线上半夜查问题的痛苦。性能测试说到底就是让问题在可控环境里提前暴露而不是等用户先替你踩出来。希望这份整理能让你下一次压测少走一些弯路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
