1. 这不是“测一测就完事”的活儿性能、压力、负载、稳定测试到底在测什么很多人第一次接触这几个词是在项目上线前被测试同事拉进一个叫“压测会议”的会议室里。PPT第一页赫然写着“性能、压力、负载、稳定测试”底下还列了一堆指标TPS、RT、CPU使用率、错误率……当时我就坐在那儿想这不就是让系统多跑几下看看会不会崩吗后来自己亲手搭过三次压测平台、调过二十多个线上服务的瓶颈点才真正明白——这四个词根本不是同一件事的四种说法而是四把不同刻度、不同方向、不同目的的手术刀专用来解剖系统在真实世界里的“生理反应”。性能测试是给系统做一次标准体检。它问的是“在理想条件下你最快能跑多快最稳能扛多久”比如一个下单接口在单机2核4G、数据库无其他干扰、网络延迟1ms的实验室环境里每秒最多处理多少笔订单这个数字就是它的“能力基线”。它不关心你有没有突发流量也不管你连续跑三天会不会内存泄漏它只认数据只服参数。压力测试是往系统血管里直接推肾上腺素。它不满足于“你本来能跑多快”而是要逼出“你崩溃前最后一秒能扛多少”。我们会持续加压——从100并发开始每30秒加50直到错误率突破5%、响应时间翻倍、或某台机器CPU飙到98%再也降不下来。这时候系统不是“慢了”而是开始“说胡话”返回502、超时、数据错乱、甚至部分节点静默离线。压力测试的价值从来不是为了证明系统能扛住而是为了精准定位那个“临界点”在哪以及临界点之后系统是优雅降级还是原地爆炸。负载测试更像一场72小时不间断的马拉松模拟。它不追求峰值而关注“可持续性”。我们会把并发量稳定维持在预估日常峰值的120%持续运行4~8小时观察内存是否缓慢上涨、连接池是否耗尽、日志磁盘是否写满、GC频率是否异常升高。很多系统能扛住10分钟的峰值却在第3小时因线程池未回收导致请求堆积最终雪崩。负载测试盯的就是这种“温水煮青蛙”式的慢性衰竭。稳定性测试则是把系统扔进一个“故障模拟器”里泡一周。它不加压但会主动制造混乱随机kill一个Pod、拔掉一台数据库网线、让Redis主从同步延迟飙升到30秒、把Nginx配置热更新失败三次……然后看整个链路的熔断、重试、降级、告警、自愈机制是否按设计工作。它测的不是代码而是架构的“免疫系统”。这四个测试就像汽车出厂前的四道关卡性能是百公里加速测试压力是极限过弯测试负载是高速长途续航测试稳定是暴雨砂石颠簸路面的综合耐久测试。少一道车都能开但你敢不敢载着家人上高速我见过太多团队只做性能测试就上线结果大促第一天凌晨三点监控告警连成一片运维同学一边敲命令一边骂娘——不是系统不行是没把它放在真实世界的“显微镜”下看过。关键词“性能、压力、负载、稳定测试性能及指标”背后藏着的是一整套工程化质量保障体系。它不靠感觉不靠经验靠的是可复现的场景、可量化的数据、可归因的根因。接下来我们就一层层拆开这套体系从设计思路、核心指标、实操细节到那些只有踩过坑的人才知道的“玄学时刻”。2. 四把手术刀怎么选测试目标决定一切而不是工具好不好看很多人一上来就想问“用JMeter还是Locust用Prometheus还是Zabbix”——这就像病人刚进诊室就问“医生我该用青霉素还是头孢”问题本身就有偏差。工具只是刀而决定切哪一刀、切多深、切哪里的永远是你的测试目标。2.1 性能测试目标是建立基线不是找Bug性能测试的核心诉求是回答一个问题“在标准配置下这个服务的理论吞吐能力是多少”所以它的设计必须满足三个刚性条件环境纯净、流量可控、结果可比。环境纯净意味着不能和开发、测试环境混用。我曾参与过一个支付网关的性能测试初期直接在测试环境跑结果发现DBA前一天给数据库加了全表扫描的统计任务导致TPS波动高达40%。后来我们单独部署一套最小化环境仅包含网关、下游mock服务、独立MySQL实例关闭所有非必要插件连JVM参数都和生产保持一致。这才拿到可信基线。流量可控不是“越多越好”而是“节奏越准越好”。比如测一个查询接口我们要控制QPS恒定在500持续5分钟观察RT均值、p95、p99是否稳定。如果用JMeter的“Concurrency Thread Group”就必须配合“Precise Throughput Timer”否则线程启动有抖动QPS实际是锯齿状的。实测下来用Gatling的reachRps策略更稳因为它底层是基于Actor模型做速率控制误差能压到±2%以内。结果可比每次测试必须记录完整上下文。我强制团队用模板记录JVM版本、GC算法G1/CMS、数据库连接池大小、网络延迟用ping -c 10 target_ip | tail -1取平均、甚至Linux内核参数如net.core.somaxconn。有一次两个版本对比v2比v1慢15%排查半天发现是v2部署机的vm.swappiness60而v1是10大量内存被swap出去根本不是代码问题。提示性能测试报告里必须包含“有效请求数占比”。我见过太多报告把30%的超时请求也计入TPS计算结果TPS虚高上线后立刻打脸。真正的TPS 总成功请求数/总耗时秒数超时、5xx、业务错误码一律剔除。2.2 压力测试目标是找到拐点不是压垮它压力测试的设计哲学是“渐进式施压实时观测”。它拒绝“一把梭哈”因为系统崩溃的路径往往不是线性的。比如一个电商详情页可能在2000并发时RT突增但错误率仍0.1%到3500并发时缓存击穿导致DB连接池耗尽错误率瞬间跳到12%而到了4000并发限流组件生效错误率又回落到2%但用户看到的全是“系统繁忙”。所以我们的压测脚本必须支持动态调节初始并发设为预估峰值的50%每30秒增加10%并发不是固定数值避免在低并发区浪费时间当错误率3%或RT p95 2s时暂停加压维持当前并发2分钟观察是否自愈若2分钟内未恢复则记录当前并发为“初步拐点”再尝试降低10%并发确认拐点区间工具选择上JMeter在复杂逻辑编排如登录态保持、动态token生成上更成熟但分布式压测节点管理麻烦Locust用Python写脚本极其灵活支持协程并发单机压测能力是JMeter的3倍但对HTTP/2、gRPC支持较弱。我们现在的方案是Web API用Locust内部RPC服务用k6原生支持gRPC和WebSocket且指标输出格式与Prometheus天然兼容。注意压力测试中监控必须比压测提前5分钟启动。很多团队等压测开始才开监控结果拐点出现时关键指标如JVM线程状态、GC日志根本没采集到。我们要求Prometheus的scrape_interval设为5s且所有exporternode_exporter、jmx_exporter、mysqld_exporter必须在压测脚本run之前就位。2.3 负载测试目标是验证可持续性不是熬时间负载测试最容易犯的错误是把它当成“长时间的压力测试”。其实恰恰相反负载测试的并发量通常低于压力测试拐点但它的时间维度更长对系统“慢性病”的检出能力更强。典型场景模拟双11零点后2小时的平稳高峰。我们预估峰值是8000 QPS那么负载测试就设为7000 QPS持续6小时。重点观测三类指标内存类JVM堆内存使用率是否缓慢爬升0.5%/小时需警惕、Metaspace是否增长、Native Memory是否持续占用用pmap -x pid定期抓取连接类数据库连接池活跃连接数是否稳定、HTTP客户端连接池如OkHttp的ConnectionPool是否出现连接泄漏、Netty EventLoop线程数是否随时间增加存储类磁盘IO wait%是否超过20%、日志文件写入速度是否超过磁盘吞吐如SATA SSD约150MB/s、InnoDB buffer pool hit rate是否低于95%有一次做订单中心负载测试前4小时一切正常第5小时开始RT p95缓慢上升。查监控发现MySQL的Threads_connected从200涨到350但应用端连接池配置明明是max200。最后定位到是Druid连接池的removeAbandonedOnBorrowtrue配置在高并发下误判连接泄漏频繁触发removeAbandoned导致连接重建开销剧增。这个Bug在压力测试里根本不会暴露因为压力测试时间短连接来不及“变老”。2.4 稳定性测试目标是验证容错能力不是考验运气稳定性测试的本质是混沌工程Chaos Engineering的轻量级实践。它不追求“系统永不宕机”而是验证“当某个部件失效时系统能否按设计降级”。我们采用“故障注入三原则”可控故障必须能随时启停不能影响其他测试环境。比如用ChaosBlade在K8s集群里注入网络延迟必须指定namespace和label selector确保只影响被测服务。可观测故障注入前后必须有明确的观测断言。例如“注入Redis主从延迟30s后订单查询接口错误率应1%且降级返回默认库存值”。可回滚每个故障脚本必须自带恢复命令。我们用Ansible Playbook封装chaos-inject.yml和chaos-recover.yml一一对应执行前自动备份关键配置。常见故障类型优先级排序按线上故障概率网络类服务间网络延迟模拟跨机房调用、网络丢包模拟弱网、DNS解析失败模拟K8s CoreDNS异常中间件类Redis主节点宕机验证哨兵切换、Kafka Broker不可用验证重试与死信队列、MySQL主库只读验证读写分离路由基础设施类Node节点NotReady验证Pod自动漂移、磁盘空间不足模拟日志写满、CPU Throttling模拟资源配额超限实操心得稳定性测试最忌“撒大网”。曾有个团队同时注入5个故障结果告警风暴根本无法定位根因。我的建议是每次只注入1个故障持续30分钟验证通过后再进行下一个。一个完整的稳定性测试周期至少要覆盖3类故障且每类故障要重复2次验证可重现性。3. 指标不是数字游戏每个关键指标背后的“身体语言”解读测试报告里堆满指标不等于读懂了系统。真正的高手能把一串数字翻译成系统的“生理报告”。下面这些指标我按重要性排序并附上它们在真实场景中“说人话”的含义。3.1 TPSTransactions Per Second别只看峰值要看“有效吞吐”TPS是性能测试最常被引用的指标但也是最容易被误解的。很多人以为“TPS越高越好”其实不然。TPS的分母是“总耗时”不是“压测时长”。比如压测跑了10分钟但前2分钟在预热warm-up后1分钟在收尾cool-down真正稳定期只有7分钟。那么TPS 有效请求数 / 7分钟不是/10分钟。TPS必须和成功率绑定。一个TPS5000但错误率15%的系统实际可用吞吐是4250。而TPS4500、错误率0.1%的系统可用吞吐是4495.5反而更高。TPS的粒度要匹配业务。支付系统看“支付成功TPS”不是“HTTP请求TPS”。因为一个支付流程包含下单→调用支付网关→回调通知→更新订单状态4个接口。如果只统计第一个接口的TPS会严重高估能力。我们定义“业务TPS”的公式业务TPS 成功完成的业务单元数/业务单元完成耗时总和其中“业务单元完成耗时”指从用户点击“支付”到收到“支付成功”页面的端到端时间。这个数据必须通过全链路追踪如SkyWalking聚合不能靠单点埋点。实测案例某优惠券发放服务压测显示TPS12000但业务方反馈大促时发券失败率高。查链路发现90%的请求卡在“校验用户资格”环节该环节依赖一个外部风控API平均RT达800ms。于是我们把“校验资格”改为异步化TPS降到9500但业务成功率从82%升到99.97%。可见TPS要为业务价值服务不是为数字服务。3.2 RTResponse Timep95和p99才是老板关心的“用户体验”平均响应时间Avg RT是个危险的指标。它像班级平均分掩盖了学霸和学渣的巨大差异。一个系统90%的请求RT100ms但10%的请求RT2s比如缓存穿透查DBAvg RT可能是300ms看起来很健康但那10%的用户已经怒卸载APP了。所以必须看分位数p50中位数代表“一半用户”的体验。如果p50500ms说明基础体验已不佳。p95代表“95%用户”的体验。这是SLOService Level Objective的常用阈值。比如“95%的请求RT1s”。p99代表“最差的1%用户”的体验。这是系统健壮性的试金石。p99突然飙升往往预示着资源争抢如锁竞争、GC停顿。计算p99的陷阱很多工具如JMeter默认用“采样点”计算分位数但采样点可能丢失长尾请求。正确做法是压测工具将每个请求的RT原始数据毫秒级实时推送至时序数据库如InfluxDB再用percentile(99)函数计算。我们实测发现JMeter GUI模式下p99误差可达±15%而用Backend Listener推送到InfluxDB后误差±2%。注意RT必须区分“服务端RT”和“客户端RT”。服务端RT是代码执行时间从Controller入口到Response写出客户端RT还包括网络传输、SSL握手、DNS解析。线上问题排查必须先确认是哪一端的RT高。我们用eBPF技术在宿主机层捕获TCP连接的SYN/ACK时间戳能精准分离网络耗时。3.3 错误率Error Rate5xx是“病危通知”4xx是“操作指南”错误率不是简单的“失败请求数/总请求数”。必须按HTTP状态码分类因为它们代表完全不同的语义状态码含义运维动作开发动作500/502/503/504服务端崩溃、网关超时、上游不可用立即扩容、切流量、查日志查异常堆栈、线程dump、GC日志400/401/403客户端参数错误、未登录、权限不足检查前端埋点、用户行为分析优化参数校验提示、完善鉴权逻辑429限流触发检查限流规则、评估是否需扩容分析热点key、优化限流粒度如从IP级到用户ID级有一次压测错误率稳定在0.3%全是400。团队以为是前端传参问题查了半天。最后发现是压测脚本里一个UUID生成器bug导致10%的请求携带了非法字符被Spring Validation拦截。这就是典型的“4xx错误率高但和后端性能无关”。实操技巧在压测脚本里对5xx错误自动触发“紧急快照”立即调用jstack -l pid thread_dump.log、jstat -gc -h10 pid 1000 10 gc.log、curl http://localhost:8080/actuator/prometheus metrics.txt。这些文件在压测结束后自动打包上传为根因分析省下黄金30分钟。3.4 系统资源指标CPU、内存、IO谁在“说谎”应用层指标TPS、RT是结果系统层指标CPU、内存、IO是原因。但它们经常“说谎”需要交叉验证。CPU使用率高 ≠ 程序有问题。Java应用在Full GC时CPU可能飙到90%但这只是GC线程在疯狂工作不是业务代码卡死。此时要看jstat -gc的FGCTFull GC次数和FGCTFull GC耗时。如果FGCT0且FGCT1s那就是GC问题不是CPU问题。内存使用率高 ≠ 内存泄漏。JVM堆内存使用率85%很常见只要Old Gen使用率稳定不持续上涨且没有频繁Full GC就是健康状态。真正的泄漏信号是jstat -gccapacity显示Old Gen容量不变但jstat -gc显示Old Gen已用空间持续增长。IO wait%高 ≠ 磁盘慢。Linux的iowait%表示CPU在等待IO完成的时间占比。但如果应用是纯计算型如图像识别它根本不发IO请求iowait%高就说明要么磁盘真慢要么有其他进程如日志轮转、备份脚本在霸占IO。用iotop -o可以精准定位是哪个进程在刷盘。我们总结了一个“三指标联动诊断法”如果RT高 CPU高 GC正常 → 检查代码热点用Arthasprofiler start如果RT高 CPU正常 内存缓慢上涨 → 检查内存泄漏用MAT分析heap dump如果RT高 CPU正常 IO wait% 30% → 检查磁盘IO用iostat -x 1看await和svctm提示不要迷信“CPU使用率70%就安全”。我们遇到过一个案例CPU使用率始终65%但RT p99在第4小时突然翻倍。查perf top发现90%的CPU时间花在pthread_mutex_lock上——原来是新引入的一个全局锁在高并发下成了瓶颈。CPU没满但线程全在排队等锁。3.5 自定义业务指标这才是真正的“心跳”所有通用指标都是在描述系统的“躯体”而自定义业务指标才是它的“心跳”。订单系统必须监控“支付成功到库存扣减完成的延迟”。这个延迟超过5秒就意味用户已付款但库存未锁可能超卖。搜索系统必须监控“召回率”和“相关性得分p95”。TPS再高搜不到商品也是废柴。推荐系统必须监控“曝光-点击率CTR”和“点击-成交转化率CVR”。这两个指标下降说明推荐算法失准和服务器性能无关。我们要求每个核心服务必须在/actuator/metrics里暴露至少3个业务指标且这些指标要接入告警系统。比如“优惠券发放失败率0.5%持续5分钟”必须触发企业微信告警而不是等用户投诉。实操心得业务指标的采集一定要“侵入式埋点”而不是“旁路日志解析”。日志解析延迟高、格式易变、漏采率高。我们用Micrometer统一埋点所有指标走同一套上报通道保证实时性和准确性。4. 从脚本到报告一次完整压测的12个关键实操环节纸上得来终觉浅。再完美的理论不落到键盘上都是空中楼阁。下面是我梳理的一次生产级压测的12个关键环节每个环节都附上血泪教训。4.1 环境准备宁可多花2天绝不省1小时步骤1环境克隆不是“搭建”而是“克隆”。用Terraform脚本从生产环境的IaCInfrastructure as Code仓库里拉取最新版的K8s集群、数据库、缓存配置一键部署到压测环境。我们禁止手动修改任何配置所有变更必须走Git PR。步骤2数据脱敏与构造生产数据不能直接用。我们用Faker库生成100万条模拟用户数据含手机号、地址、设备ID再用Anonymize工具对敏感字段加密。特别注意用户ID必须是递增的模拟真实ID生成逻辑否则分库分表路由会失效。步骤3监控对齐把生产环境的Grafana Dashboard复制一份到压测环境所有Prometheus查询语句里的jobprod-api改成jobstress-api。并验证rate(http_requests_total{code~5..}[5m])等关键指标能正常采集。踩坑记录某次压测RT一直偏高查了半天。最后发现是压测环境的/etc/resolv.conf里DNS服务器指向了内网一个老旧的BIND解析延迟平均300ms。换成阿里云DNS223.5.5.5后RT直降40%。所以环境准备清单里必须有一项“DNS配置检查”。4.2 脚本开发用代码思维写脚本不用录制思维步骤4协议选择Web页面用HTTPApp接口用HTTP/2开启HPACK压缩内部RPC用gRPC二进制序列化带流控。绝对不用“录制回放”方式因为录制的脚本无法处理动态token、时间戳、签名。步骤5逻辑分层Locust脚本必须分三层# layer1: 基础请求封装带重试、超时、错误码处理 def api_call(self, method, url, jsonNone): with self.client.request(method, url, jsonjson, catch_responseTrue) as response: if response.status_code ! 200: response.failure(fHTTP {response.status_code}) return response.json() # layer2: 业务流程如下单创建订单→支付→查询状态 task def place_order_flow(self): order_id self.api_call(POST, /order, json{item_id: 123}) self.api_call(POST, f/pay/{order_id}, json{method: alipay}) self.api_call(GET, f/order/{order_id}) # layer3: 用户行为模型80%用户下单20%用户只浏览 class BrowseUser(HttpUser): tasks [browse_only] wait_time between(5, 15)步骤6参数化与关联所有动态值必须参数化用户ID从CSV文件读取商品ID从Redis缓存获取避免热点订单号用Snowflake算法本地生成不依赖DB。关联值如订单创建返回的order_id必须用正则或JSONPath提取存入self.locust.user_data供后续请求使用。实操技巧在脚本里加入“健康检查任务”每5分钟自动调用一次/health接口如果连续3次失败自动停止压测并告警。这能避免压测脚本自己挂了还在空跑。4.3 压测执行像外科医生一样精准控制步骤7预热Warm-up正式压测前先用50%目标并发跑5分钟。目的是让JVM JIT编译热点代码、数据库连接池填满、OS Page Cache加载热数据。没有预热的压测结果毫无参考价值。步骤8阶梯加压用Locust的--step-time 30 --step-users 100 --users 5000参数实现每30秒加100用户直到5000。同时在Grafana里开一个“RT p95 vs 并发数”看板实时观察拐点。步骤9拐点确认当RT p95突破阈值如1s时暂停加压维持当前并发5分钟。如果RT回落说明是瞬时抖动如果持续高位记录此并发为“拐点”。然后降低10%并发再跑5分钟确认拐点区间。踩坑记录某次压测拐点出现在3200并发RT p951020ms。团队认为还能加又冲到3500结果错误率瞬间到18%。复盘发现3200并发时MySQL的Threads_running已达200max_connections200再加一点新连接就被拒绝。所以拐点确认必须结合数据库连接数、线程数等底层指标。4.4 监控采集指标要“全”更要“准”步骤10全链路埋点在Spring Cloud Gateway层用OpenTelemetry SDK注入traceId透传到所有下游服务。每个服务的Controller方法用Timed注解自动记录RT并打上业务标签如serviceorder,endpoint/create。步骤11系统层快照在压测开始前、拐点出现时、压测结束时各执行一次快照脚本# jvm.sh jstat -gc -h10 $PID 1000 10 jstat_gc_$(date %s).log jstack -l $PID jstack_$(date %s).log # system.sh iostat -x 1 10 iostat_$(date %s).log vmstat 1 10 vmstat_$(date %s).log步骤12报告生成用Python脚本从InfluxDB拉取所有指标自动生成PDF报告。报告必须包含关键结论页1句话总结系统拐点在XX并发p95 RTXXXms错误率XX%TPS/RT曲线图带拐点标注资源水位图CPU、内存、IO、网络根因分析页如“RT飙升源于MySQL连接池耗尽建议max_connections从200调至300”实操心得报告里必须有一栏“本次压测与上次对比”。比如“TPS提升12%但p99 RT恶化8%”这比单纯说“TPS5000”有价值得多。我们用Git管理报告模板每次迭代都保留历史版本方便回溯。5. 那些没人告诉你的“玄学时刻”10个高频问题与独家排查技巧再严谨的流程也挡不住现实的魔幻。下面这些是我在上百次压测中亲手踩过、亲手填平的坑。它们不会写在教科书里但能让你少熬3个通宵。5.1 问题1压测TPS上不去但CPU、内存都很闲现象Locust显示并发5000但服务端TPS只有800JVM CPU30%堆内存使用率50%。排查思路先看网络ss -s查看socket连接数是否达到net.core.somaxconn上限默认128。如果是echo 1024 /proc/sys/net/core/somaxconn。再看线程jstack PID | grep java.lang.Thread.State | wc -l查看线程总数。如果1000可能是线程池配置过大线程切换开销反超。最后看锁jstack PID | grep parking to wait for | wc -l如果100说明大量线程在等锁。独家技巧用Arthas的thread -n 5命令直接找出CPU占用最高的5个线程并显示它们在执行哪行代码。比看jstack日志快10倍。5.2 问题2RT忽高忽低像心电图一样抖动现象RT p50稳定在200ms但p99在100ms~2000ms之间无规律跳变。根因JVM的CMS GC或G1的Mixed GC导致STWStop-The-World。验证jstat -gc -h10 PID 1000 10看GCTGC总耗时和FGCTFull GC耗时。如果FGCT0且单次500ms就是它。解决升级JDK11改用ZGC或Shenandoah GC它们STW时间10ms。或者把GC日志打开用GCViewer分析调整-XX:MaxGCPauseMillis200。注意不要盲目调大堆内存堆越大GC时间越长。我们有个服务把Xmx从4G调到8G结果Full GC时间从300ms涨到1200ms。5.3 问题3压测脚本报大量“Connection refused”现象Locust日志里全是ConnectionRefusedError: [Errno 111] Connection refused。根因不是服务挂了而是客户端端口耗尽。Linux默认net.ipv4.ip_local_port_range 32768 60999只有28232个端口。Locust单机并发5000每个连接用一个端口28232/5000≈5.6意味着每6个请求就要复用端口。而TIME_WAIT状态默认持续60秒端口复用不过来。解决# 扩大端口范围 echo net.ipv4.ip_local_port_range 1024 65535 /etc/sysctl.conf # 缩短TIME_WAIT时间 echo net.ipv4.tcp_fin_timeout 30 /etc/sysctl.conf # 开启端口复用 echo net.ipv4.tcp_tw_reuse 1 /etc/sysctl.conf sysctl -p5.4 问题4数据库连接池耗尽但应用日志没报错现象MySQL的Threads_connected飙升到max_connections但应用日志里没有“Cannot get JDBC connection”错误。根因Druid连接池的maxWait默认是-1无限等待所以连接拿不到时线程就卡在getConnection()上不抛异常只拖慢RT。验证jstack PID | grep DruidDataSource.getConnection看有多少线程卡在这里。解决把maxWait设为30003秒超时就抛异常这样错误率会立刻上升问题暴露得更快。5.5 问题5压测时Redis响应慢但Redis监控一切正常现象应用侧Redis命令RT1000ms但Redis自身的latency doctor和INFO commandstats显示所有命令都在1ms内。根因网络问题。Redis是单线程它处理快但客户端发请求、收响应的网络往返慢。验证在应用服务器上执行redis-cli -h redis-host -p 6379 --latency看P95延迟。如果10ms就是网络问题。解决检查Redis客户端连接池配置。Lettuce默认ioRatio5050%时间处理IO在高并发下不够调成ioRatio80。或者换用Jedis它对网络延迟更不敏感。5.6 问题6同样的脚本在JMeter和Locust上结果差2倍现象JMeter压测TPS2000Locust压测TPS4000但服务端监控显示负载几乎一样。根因JMeter默认用HttpClient 4.x每个线程一个连接连接复用率低Locust用aiohttp协