1. 性能测试的成败在动手压测之前就定了做性能测试这行有个挺普遍的现象很多人拿到需求的第一反应是打开 JMeter 开始录脚本压完之后拿着一堆报告说TPS 300平均响应时间 200ms性能还可以。结果被问到那到底算不算通过的时候就卡住了。性能指标、性能指标评估、性能测试通过标准这三件事其实是一条链上的三个环节——指标是尺子评估是用尺子的方法通过标准是拿尺子量完之后判定合格不合格的规则。尺子没校准后面两步全白搭。我自己踩过的坑里最贵的一次是给一个订单系统做压测脚本跑了三天报告漂亮得不像话上线第一天下午就崩了。复盘才发现我们压的是查询订单列表这个只读接口而真正压垮系统的是下单链路上一个带分布式锁的写操作。指标采集是对的评估逻辑也没问题挂在最开始——测的东西和真实业务流量结构不匹配。这篇内容适合三类人看一是刚接手性能测试任务、不知道从哪下手的测试同学二是需要给自己系统定一套容量验收标准的后端和运维同学三是被系统很慢能不能扛住大促这类模糊需求折磨过的技术负责人。我会把常用性能指标逐个拆开讲清楚它们到底在描述什么、怎么算、怎么采然后讲评估方法和通过标准怎么落地最后给一套可以直接抄的 JMeter 实操流程和排障经验。里面的参数和经验值都是我在实际项目里反复验证过的可以根据你自己的业务体量做等比例调整。2. 常用性能指标逐个拆解别只会背缩写2.1 并发类指标虚拟用户、并发用户、在线用户是三回事先把最容易混淆的三个词分开。**虚拟用户数VU**是压测工具层面的概念一个线程就是一个 VU它可能正在发请求也可能正在等响应还可能正在思考等待。并发用户数是业务层面的概念指同一时刻真正对系统施加压力的请求数量。在线用户数是最虚的一个指登录态还挂着的用户他可能正在看别的页面一分钟都不点一下你的系统。这三者之间的换算关系是整个性能测试里最容易出错的地方。很多人习惯性地把在线用户 1 万直接当成并发 1 万去设计线程数压出来的结果必然失真。实际项目中如果业务是典型的浏览型场景真正同时在发请求的比例通常在 5%~15% 之间如果是秒杀、抢购、定时任务这类瞬时集中场景这个比例可能冲到 50% 以上甚至全员同时。提示设计线程数时先问清楚业务方说的多少人在线到底是哪一种口径。问不清楚就按最保守的方式拆把在线用户拆成活跃比例 × 并发比例同时把峰值系数单独乘上去别把两个放大倍数揉在一起算。还有一个和并发强相关但常被忽略的指标是并发连接数它描述的是服务端同时维护的 TCP 连接数量。这个值和并发用户数通常不是一个量级尤其在 HTTP/1.1 长连接和 HTTP/2 多路复用下差异巨大。压测时如果压测机和被测服务之间的端口耗尽、TIME_WAIT 堆积你会看到并发上不去但服务端 CPU 却不高——这不是被测系统的问题是压测端自己的瓶颈。2.2 吞吐类指标TPS、QPS、RPS 到底差在哪**TPSTransactions Per Second**里的 Transaction 是一个业务事务的概念它可以是一整个下单动作包含查库存、锁库存、生成订单、扣减优惠券、发消息五六个接口调用。**QPSQueries Per Second**通常指单次请求或单次查询。**RPSRequests Per Second**在 Web 场景下基本等同于 QPS。所以严格来说同一个压测结果里 TPS 的数值往往小于 QPS 的数值把这两个数混着报是很容易引起误解的。我在做性能验收的时候会强制要求脚本里用**事务控制器Transaction Controller**把业务链路包起来这样报告里能同时拿到事务级 TPS和请求级 QPS两组数。给业务方看 TPS给开发定位瓶颈看 QPS两套数据对应两种视角。吞吐量和响应时间的关系可以用一个很直观的类比理解系统就是一家餐厅吞吐量是每小时能接待多少桌客人响应时间是每桌客人从进门到吃完出门花多久。并发用户数就是同时在餐厅里的桌数。这三者被一个叫利特尔法则的东西锁死了并发数 吞吐量 × 平均响应时间这个公式的价值在于你只要知道其中两个第三个就是算出来的。比如业务方要求支撑 500 并发、平均响应时间不超过 300ms那么系统必须提供500 / 0.3 ≈ 1667 TPS的吞吐能力。反过来如果实测下来系统在 200 TPS 时响应时间就已经 2.5 秒了那么它能扛的并发就是200 × 2.5 500刚好卡在边界上没有任何余量。注意这个公式要求响应时间和吞吐量在同一压力水平下测量并且是在系统未饱和的区间内。系统已经进入排队崩溃状态时并发数在涨、响应时间在涨、吞吐量反而在跌这时候公式给出的数字会严重误导你。2.3 响应时间类指标平均数是性能报告里最没用的数平均响应时间是所有性能指标里最容易被误用的一个。假设 100 个请求里 95 个耗时 50ms、5 个耗时 3000ms平均值算出来是 197ms看起来很美好但那 5 个用户已经接近超时了。平均值把极端值平滑掉了而性能问题恰恰藏在极端值里。所以我在所有正式报告里都会看分位数指标TP90、TP95、TP99有的场景还要看 TP99.9。TP99 500ms 的意思是 99% 的请求在 500ms 内返回。它比平均值更能反映最差的那部分用户的真实体验。业界比较常用的经验分布是指标描述含义常见参考区间普通业务系统关注重点TP50一半请求快于该值50~150ms系统常态性能TP9010% 请求慢于该值150~400ms一般用户体验下限TP955% 请求慢于该值200~500ms大部分用户感知边界TP991% 请求慢于该值500ms~1s慢请求与毛刺排查TP99.9千分之一请求慢于该值1~3s大促、核心链路必看Max最慢的一次无固定值定位极端卡顿这些数值只是参考不能生搬硬套。一个后台报表导出接口 TP99 是 5 秒完全正常一个登录接口 TP99 是 5 秒就是事故。判断标准必须结合业务场景这一点在后面的通过标准章节会详细展开。分位数还分两种算法响应时间分布直方图法和最近 N 次采样法。JMeter 默认用的是把请求响应时间排序后取分位点它反映的是整个测试周期内的全局分布。而 Prometheus Histogram 这类监控采集的是时间窗口内的分位数反映的是某一时刻的状态。两者数值不一样很正常别急着说谁的数据错了先确认口径。2.4 资源类指标CPU、内存、磁盘、网络怎么看到底应用层的指标只能告诉你慢了资源层的指标才能告诉你为什么慢。我一般会同时盯这几类CPU不只看使用率还要看%sy系统态占比、%waIO 等待占比、load average。使用率 60% 但 load 已经超过核数两倍说明有大量线程在排队瓶颈可能是锁竞争而不是算力不足。JMeter 压测机上如果 CPU 超过 80%压出来的结果基本不可信了。内存关注 RSS 增长曲线、GC 频率和 GC 暂停时间。Java 应用里Full GC 次数和单次 Full GC 停顿是两个关键数。我见过一个服务 CPU 不高、TPS 不低但响应时间每隔几分钟就出现一根尖刺最后定位到是堆内存设置偏小导致频繁 Full GC。磁盘 IO看IOPS、吞吐MB/s、await平均 IO 等待毫秒数。await 超过 20ms 一般说明磁盘已经有压力了机械盘更是如此。网络带宽压测机带宽打满是最常见的假瓶颈之一。千兆网卡理论 125MB/s实际能跑到 110MB/s 就不错了。如果响应体平均 100KB、目标 TPS 是 2000那带宽需求就是2000 × 100KB 200MB/s千兆网卡根本不够这时候你会看到 TPS 卡在 1100 左右上不去服务端却毫无压力。连接数与文件句柄netstat里的 TIME_WAIT 数量、ulimit -n的句柄上限这两个地方出问题非常隐蔽压测进行到中后段才爆发。实操心得压测机和服务端一定要分开部署并且压测机的资源水位要单独监控。我曾经花了半天时间排查一个服务端 TPS 上不去的问题最后发现是压测机自己开了 GUI 模式图形界面吃掉了大量 CPU改非 GUI 模式重压TPS 直接翻倍。2.5 稳定与错误类指标错误率比 TPS 更值得盯错误率是最容易被忽略、也最容易酿成大祸的指标。有些压测工具默认会在请求失败时继续往下跑报告里 TPS 漂亮得不行实际错误率已经 30% 了。我见过最离谱的一份报告TPS 1200、平均响应 80ms看起来完美打开错误率一看 47%——因为服务端在前面几秒就被打挂了后面返回的全是 502工具照样把它们当请求计数了。错误率要分类型看不能只看一个总数错误类型典型 HTTP 码说明是否可接受业务校验失败200 内含错误码参数非法、无库存等视业务而定压测脚本应避免客户端错误400 / 401 / 403 / 404脚本或鉴权问题零容忍说明脚本有 bug服务端错误500 / 502 / 503 / 504服务异常、超时、限流几乎零容忍连接类错误连接拒绝 / 超时端口耗尽、服务不可用零容忍我个人的底线是核心链路错误率必须为 0非核心链路不超过 0.1%且这个 0.1% 不能是 5xx只能是被预期的业务态。超过这个线的任何性能数据都不作为验收依据。除了错误率还要看超时率和成功率。这三个数在 JMeter 报告里对应 Error %、以及你自己通过断言定义的统计口径。一个关键细节超时阈值要和业务方约定不能简单沿用工具默认值。JMeter 的 HTTP 请求默认没有超时也就是会一直等下去结果就是你的响应时间数据被无限拉长。我一般会把连接超时设 5s、响应超时设 30s具体值按业务容忍度调整。2.6 前端与体验类指标后端指标好看不代表用户觉得快如果压测对象涉及 Web 或 App 页面光看后端接口的响应时间是不够的。用户感知的是整页加载而后端接口可能只占其中 30%。这类指标里比较有用的几个首字节时间TTFB从发起请求到收到第一个字节反映服务端处理能力加网络往返。首次内容绘制FCP页面第一个内容元素出现的时刻。可交互时间TTI页面能响应用户操作的时刻。页面完全加载时间所有资源加载完成这个值受图片和第三方脚本影响极大。压测页面级性能时JMeter 只能压接口和静态资源不能真实渲染。所以页面指标我一般用真实设备上的浏览器性能面板或者前端监控 SDK 来采集后端压测和前端监控是两套体系不能互相替代。2.7 中间件专项指标瓶颈往往藏在这里系统整体 TPS 上不去八成是某个中间件先扛不住了。我常看的几个应用服务器Tomcat 的线程池活跃数、等待队列长度。默认 200 个最大线程如果活跃数长期贴着上限且队列在涨说明后端处理能力不足。数据库慢查询数量、活跃连接数、连接池等待时间、锁等待时间。连接池最大连接数配置成 10 和配置成 100压测结果可能差好几倍。缓存命中率、大 key 数量、慢命令数量。命中率从 99% 掉到 90%后端数据库压力会成倍放大。消息队列生产速率、消费速率、堆积量。压测时如果消息生产上去了消费跟不上堆积会一直涨这种问题在上线后几小时才爆发。网关与负载均衡转发延迟、健康检查频率、连接复用率。3. 性能指标评估把一堆数字变成结论3.1 评估的第一步是确定口径不是确定阈值我接手过很多指标都采到了但得不出结论的现场问题基本都出在口径。评估之前必须先锁定五件事测的是哪条链路、用了什么流量模型、线程数和加压方式是什么、数据量是多少、环境是不是生产同构。其中数据量最容易糊弄人。一个只有 10 万条数据的订单表和一个有 1 亿条数据的订单表同样的 SQL 执行计划可能完全不同。压测库的数据量如果是真实量级的十分之一那结论基本没法用。我一般会要求压测库的数据量至少达到生产量级的 30%并且索引状态、分表分库结构要和生产一致。加压方式也直接决定结论。常见的有三种**阶梯加压Ramp-up**适合找拐点稳定持续加压适合验证稳定性尖峰冲击适合模拟秒杀。同一套系统用三种方式压得到的最大 TPS能差出一倍以上。3.2 找拐点比找最大值更有意义新手最关心最大 TPS 是多少老手最关心拐点在哪。拐点就是吞吐量停止增长、响应时间开始陡增的那个点。系统在拐点之前是线性可扩展的过了拐点就进入排队区再往后就是雪崩区。怎么找拐点用阶梯加压每 5 分钟涨一档线程数记录每一档的 TPS、平均响应时间、TP99、错误率、CPU。画成曲线之后拐点通常出现在这三个信号同时出现的时刻TPS 增速明显放缓、响应时间涨幅超过 TPS 涨幅、资源使用率突破 70%~80%。找到拐点之后容量规划的经验公式是可承载的稳定容量 拐点容量的 60%~70%。留出的余量要覆盖流量波动、数据量增长、节点故障后的负载转移这三种情况。一个节点的集群如果按 2/3 配置容量那么挂掉一个节点剩下 2/3 节点承担全部流量正好接近拐点还能撑住。这是容量规划里 N1 思路的具体落地。3.3 指标之间互相矛盾时怎么下判断实际评估中经常遇到矛盾数据比如 TPS 达标了但 TP99 超标或者响应时间达标了但 CPU 打满。我的判断优先级是这样的错误率和超时率优先于一切。有错误其他数字全部作废。分位数优先于平均值。TP99 超标就是超标平均值好看救不了。资源水位决定结论的可信度。CPU 长期 90% 以上时测出的 TPS 不能作为容量依据。稳定性优先于峰值。能稳跑 2 小时 800 TPS比冲上 1200 TPS 然后 10 分钟崩掉有价值得多。举个真实例子某次压测 TPS 达到目标值 1.5 倍看起来很成功但 TP99 是 2.8 秒超过约定的 1 秒。深挖发现是连接池配置偏小大部分请求在等连接。这种情况如果只看 TPS 就判定通过上线后高峰期用户会明显感觉到间歇性卡顿。TPS 达标但分位数超标本质上是系统靠排队换来的吞吐量这种吞吐量没有工程价值。3.4 基线对比比单次绝对值更有指导性性能评估最有效的手段其实是版本间的基线对比。同一个脚本、同一份数据、同样的加压方式跑上一版和这一版看 TPS、TP99、CPU 的变化率。如果这次改动让 TPS 掉了 15%那不管绝对值是否达标都得先查清楚原因。我一般会维护一个简单的基线表每次压测后把关键数字追加进去版本线程数TPS平均RTTP99错误率峰值CPU备注v1.0200850118ms640ms0%62%基线v1.1200812126ms780ms0%66%新增风控校验v1.2200901105ms520ms0%58%缓存优化这张表比任何单次报告都有说服力因为它能直接回答这次改得好不好。4. 性能测试通过标准怎么定才不算拍脑袋4.1 通用参考标准与实际落地时的修正业内流传比较广的一套参考标准是这样的核心接口平均响应时间不超过 200ms、TP99 不超过 500ms、非核心接口不超过 1s、错误率为 0、CPU 使用率不超过 75%、内存无持续增长且无频繁 Full GC。这些数字可以当起点但直接照搬到自己的项目上一定会出问题。修正的思路是按业务对延迟的敏感度分档。我把业务分成了四档每档对应不同的标准业务档位典型场景平均RTTP99单接口超时阈值错误率极敏感支付、登录、下单核心步骤≤100ms≤300ms1s0%敏感商品详情、购物车、库存查询≤200ms≤500ms3s≤0.01%一般列表查询、搜索、个人中心≤500ms≤1s5s≤0.1%宽松报表导出、异步任务、批处理≤2s≤5s30s≤0.5%这个分档的好处是能直接跟业务方对齐预期。业务方说要快你就把表拿出来问这个接口属于哪一档沟通成本立刻降下来。4.2 通过标准里必须写清楚的四件事一份能落地的通过标准至少要说清楚这四件事缺一个都会在验收时扯皮第一压力水平。明确在多少并发、什么流量模型下达到这些指标。只写响应时间 ≤500ms是没有意义的因为并发 10 和并发 1000 都能测出 500ms。第二持续时间。明确是连续稳定运行多久。我一般要求核心链路至少连续稳定压测 1 小时大促前的验收至少 2 小时并且要求中间没有明显的性能衰减趋势。有些系统前 10 分钟表现优秀20 分钟后开始内存泄漏拖慢这种只有长时压测才能暴露。第三资源水位。明确 CPU、内存、连接数等资源指标的上限以及资源水位超标时即使业务指标达标也不判定通过这条规则。第四数据量与数据结构。明确压测库的数据规模、索引状况。这条最容易被省略也是导致压测通过、上线崩溃的头号原因。4.3 一份可以直接改的通过标准模板下面这份模板我用了很多次你可以直接复制走把数值改成自己的【性能测试通过标准】 一、测试范围 1. 核心链路登录 → 浏览商品 → 加入购物车 → 下单 → 支付回调 2. 脚本使用事务控制器包裹报告同时输出事务级 TPS 与请求级 QPS 二、压力模型 1. 并发线程数500按峰值 5 万在线用户活跃率 20%并发率 5% 推算 2. 加压方式60s 内线性加满之后持续运行 120 分钟 3. 流量比例浏览 70%、加购 15%、下单 10%、支付 5%与生产日志统计一致 三、业务指标通过条件全部满足 1. 事务级 TPS ≥ 1200 2. 平均响应时间 ≤ 200ms 3. TP95 ≤ 500msTP99 ≤ 1000ms 4. 错误率 0其中 5xx 错误 0 5. 全程无请求超时 四、资源指标通过条件全部满足 1. 应用节点 CPU 平均 ≤ 70%峰值 ≤ 85% 2. 应用节点内存无持续增长压测前后 RSS 差异 ≤ 10% 3. Full GC 总次数 ≤ 3 次单次停顿 ≤ 500ms 4. 数据库活跃连接数 ≤ 连接池上限的 80% 5. 数据库慢查询1s数量 0 6. 缓存命中率 ≥ 95% 五、数据与环境要求 1. 压测库订单表数据量不少于生产量级的 30% 2. 索引、分表结构、参数配置与生产一致 3. 压测机与应用节点分离部署压测机自身 CPU ≤ 60% 六、判定规则 1. 任一业务指标未达标判定不通过 2. 资源指标超标但业务指标达标需给出容量余量结论后方可判定有条件通过 3. 压测中间出现错误率突增再恢复的情况视为不稳定判定不通过4.4 拿不准标准时的兜底策略有时候业务方真的给不出预期比如一个全新的内部系统没有历史流量数据。这种情况我的做法是反向定标先不做任何优化跑一次基准压测拿到当前系统的真实能力把这个数字乘以 1.5 作为短期目标乘以 3 作为半年目标。这样标准虽然不完美但至少是数据驱动的而且能形成版本迭代的路线图。另一种情况是只有历史数据、没有业务预期。那就从生产监控里导出过去 30 天的真实峰值把峰值流量放大 1.5 到 2 倍作为压测目标同时要求响应时间不超过日常水平的 1.5 倍。这个方法我在大促备战里用过很多次准确度相当高。5. JMeter 性能测试实操步骤从建脚本到出报告5.1 环境准备与线程模型设计先把环境理清楚。压测机建议单独一台不和被测服务混部配置不要低于被测节点。Java 版本要和 JMeter 版本匹配GUI 模式只用来编脚本正式压测一律用命令行模式。JMeter 的堆内存要在启动脚本里调大默认 1G 在几千线程的场景下会直接 OOM我一般设成物理内存的一半比如HEAP-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m。线程模型的设计直接对应前面讲的并发推算。假设我们按峰值 5 万在线用户、活跃率 20%、并发率 5% 推算需要的并发是50000 × 0.2 × 0.05 500。这个 500 就是线程组里的线程数。然后在阶梯加压时我会把这个数字拆成 10 档每档 50 个线程每档跑 3 分钟方便观察拐点。注意JMeter 的线程数和并发请求数不是一回事。如果脚本里有定时器、或者响应时间长实际瞬时并发会低于线程数。判断真实并发要看报告里的活跃线程数曲线不能只看你设的线程数。5.2 脚本录制、参数化与关联录制这一步现在基本用不上代理录制了我一般手写为主因为接口测试自动化里已经有的接口定义可以直接复用。JMeter 里最核心的几个元件是这么组织的Test Plan ├── User Defined Variables域名、端口、环境标识 ├── HTTP Cookie Manager保持登录态 ├── HTTP Header ManagerContent-Type、Token ├── CSV Data Set Config账号、商品ID、随机参数 ├── setUp Thread Group准备测试数据、预热 ├── Thread Group主压测线程组 │ ├── Once Only Controller登录 │ ├── Transaction Controller下单事务 │ │ ├── HTTP Request查库存 │ │ ├── HTTP Request锁库存 │ │ ├── HTTP Request创建订单 │ │ └── JSON Extractor提取订单号供后续请求使用 │ ├── Response Assertion响应码与业务码断言 │ └── Constant Throughput Timer控制目标 TPS └── tearDown Thread Group清理测试数据参数化是让压测数据不重复的关键。账号、商品 ID、订单号这些都要从 CSV 里读Sharing mode选All threadsRecycle on EOF设成False这样数据用完就报错能及时发现数据量不够。数据量至少要覆盖线程数 × 循环次数我一般会准备 3 倍冗余。关联提取上一个请求的返回值给下一个请求用用 JSON Extractor 或正则提取器。这里有个坑如果提取失败后续请求会带着空值发出去返回一堆业务错误报告里看着是响应正常但实际全废。所以提取器后面一定要接一个断言确认提取到的值非空。5.3 断言、定时器与集合点断言是保证压测结果可信的生命线。我会加三类断言响应码断言期望 200、响应体关键字断言期望包含成功标识、响应时间断言超过阈值就标记失败。第三类特别有用因为 JMeter 默认不会把慢请求算作失败加上时间断言之后报告里的错误率能直接反映慢请求比例。定时器决定压力分布。Constant Throughput Timer按目标 TPS 控制节奏Precise Throughput Timer更精确但配置复杂Gaussian Random Timer用来模拟真实用户的思考时间。做业务场景压测时我会用高斯随机定时器让每个虚拟用户有 1~3 秒的随机停顿这样压出来的数据比无脑狂发更接近真实。**集合点Synchronizing Timer**用来制造瞬时尖峰秒杀场景必用。设置方式是让 N 个线程攒齐后同时释放这个 N 就是瞬时并发数。用的时候要小心集合点如果设得比线程数还大脚本会一直挂着不执行最后超时。5.4 分布式压测与命令行执行单台压测机顶不住的时候就要上分布式。JMeter 的分布式用主从模式从节点启动jmeter-server主节点在jmeter.properties里配置remote_hostsip1:1099,ip2:1099。有几个细节必须注意所有节点的 JMeter 版本、Java 版本、插件版本必须完全一致否则报错很隐晦。脚本里的 CSV 数据文件必须分发到每个从节点且路径一致。从节点的系统时间要同步否则报告里的时间戳会错乱。主节点不参与施压默认它只负责收集和汇总所以主节点配置可以低一些。RMI 通信会带来额外开销从节点数量多的时候网络带宽要规划好。正式压测一律走命令行jmeter -n -t order_test.jmx -l result_$(date %Y%m%d_%H%M).jtl \ -e -o ./report_$(date %Y%m%d_%H%M) \ -Jthreads500 -Jrampup60 -Jduration7200参数说明-n非 GUI 模式-t指定脚本-l输出结果文件-e -o生成 HTML 报告-J传入自定义属性。脚本里用${__P(threads,100)}这样的写法引用就能在不改脚本的情况下调整参数非常适合放在 CI 里跑。实操心得.jtl结果文件会非常大500 线程跑 2 小时可能几百 MB。压测结束后先把它压缩归档再生成 HTML 报告。如果只关心汇总数据可以在user.properties里加jmeter.save.saveservice.*相关配置只保留必要字段文件能小一大半。5.5 结果报告的阅读顺序拿到 HTML 报告之后我习惯按这个顺序看先看 Errors 表确认错误类型和数量再看 Response Time Over Time 曲线找毛刺和趋势然后看 Transactions Per Second 曲线确认加压过程中 TPS 是否稳定最后看聚合报告的 TP95/TP99。按这个顺序能在两分钟内判断出这次压测到底有没有效。报告里几个容易被忽略的图表Active Threads Over Time用来看实际加压是否按预期进行Response Time Percentiles用来看整体分布形状Latency vs Response Time用来分离网络延迟和服务端处理时间。如果一个请求的 Latency 是 50ms 而 Response Time 是 2000ms说明服务端处理慢如果两者都是 2000ms那可能是网络或者请求本身发送就慢。6. 常见问题与排查实录6.1 压力上不去TPS 卡在一个数上不动这是最高频的问题。排查顺序我总结成一个由外到内的清单先看压测机。CPU 是否打满、带宽是否打满、端口是否耗尽、JMeter 日志里有没有 OutOfMemory。压测机的问题占了这类故障的一半以上。再看网络链路。用ping和traceroute确认延迟正常用iperf测一下两端之间的实际带宽。跨机房压测时链路质量经常是瓶颈。看服务端入口。Tomcat 线程池是否已满、Nginx 的worker_connections是否够、网关有没有限流。看连接池。数据库连接池、HTTP 客户端连接池是否已经打满等待队列是否在涨。看下游依赖。第三方接口、缓存、消息队列是否成为瓶颈。看锁。有没有全局锁、分布式锁导致串行化。这一点在写操作上特别明显。有一次我排查了两天的 TPS 上不去的问题最后发现是脚本里一个Once Only Controller里的登录操作因为配置了All threads共享模式导致所有线程在等同一把锁白白浪费了大量时间。改成每个线程独立登录之后TPS 直接提升 40%。6.2 响应时间出现规律性毛刺响应时间曲线每隔固定时间出现一根尖刺通常指向几个原因JVM GC看 GC 日志时间戳是否对应、定时任务比如每 5 分钟跑一次的数据同步、日志切割或刷盘、监控采集有的 APM 采集频率高会带来额外开销、连接池定期重建连接。定位方法很简单把毛刺的时间点记下来去这几类日志里对时间戳。对上哪个就是哪个。我遇到过最隐蔽的一次是操作系统层面的cron任务在跑日志归档把磁盘 IO 打满了应用日志写入被阻塞表现出来就是响应时间抖动。如果是 GC 引起的调优方向是调整堆大小、换垃圾回收器、减少对象创建。上线前建议做一个长时稳定性压测至少 2 小时专门用来抓这类周期性问题。短时间压测完全看不到这类现象。6.3 业务指标达标但资源指标超标怎么办这种情况说明系统还能跑但没有余量。判断方法是算一下余量系数把当前 TPS 往上加 20%、30%、50% 各压一次看什么时候资源打满、什么时候错误率出现。得出这个极限值之后再和业务侧的流量增长预期对比。如果余量系数低于 1.3也就是流量涨 30% 系统就撑不住那这个版本不能上线得先做优化。优化的优先级一般是先查慢 SQL 和索引、再看缓存命中率、再看连接池和线程池配置、最后才考虑加机器。加机器是最后手段因为架构层面的问题加机器往往解决不了只是把问题推迟。6.4 常见问题速查表现象可能原因快速验证方法处理方向TPS 卡住不动压测机瓶颈、连接池满、全局锁查压测机资源、连接池监控分离压测机、加大连接池响应时间规律毛刺GC、定时任务、日志刷盘时间戳比对 GC 与 cron 日志调 GC 参数、错峰任务错误率突然升高服务被打挂、限流触发、超时查服务端日志和限流规则降低压力、调阈值内存持续增长内存泄漏、缓存无上限压测前后 RSS 对比排查泄漏点、加缓存上限TPS 达标但 TP99 超标排队换吞吐、线程池偏小看响应时间分布直方图扩线程池、异步化改造短时正常长时衰减泄漏、连接未释放、文件句柄耗尽压 2 小时看趋势查句柄与连接回收数据库 CPU 高慢查询、缺索引、全表扫描开慢查询日志加索引、改 SQL提示排查性能问题有一条铁律——先看资源再看日志最后看代码。绝大多数人会本能地从代码开始查实际上资源层和日志层能解决 80% 的问题而且速度快得多。最后分享一个我自己的习惯每次压测结束后不管结果好坏都花十分钟写一份三行记录——这版系统的能力边界在哪、这版的瓶颈是什么、下一版要优先改什么。攒上十几个版本之后这份记录比任何性能测试教程都值钱因为它记录的是你自己系统的真实脾气。系统性能这件事没有通用答案只有对你自己这套架构越来越准的手感。