做性能测试这行手里没几个压测工具出门都不好意思跟人聊并发。前些年面试简历上写“熟练使用 LoadRunner、JMeter”基本是标配这两年风向悄悄变了开始有人问“你有没有用过国产的性能测试工具”。我一开始也以为是形式主义直到一个压测项目翻车被测系统跑在国产操作系统上用的是自定义 TCP 长连接协议JMeter 配了一堆插件还是模拟不出真实的报文交互LoadRunner 在这种环境下连虚拟用户都起不来。后来团队引入了 kylinPET才把这块硬骨头啃下来。这篇文章把我这段时间深度使用 kylinPET 的体会写出来重点讲它的高仿真和高并发到底是怎么实现的再和 JMeter、LoadRunner 做一个横向对比。不管你是刚入行的测试新人还是正在做压测工具选型的老手这篇文章应该都能给你一个相对清晰的判断框架。1. 从一次“压测任务翻车”说起为什么要重新审视压测工具1.1 当被测系统升级到“国产生态”传统工具开始力不从心先说那次翻车。项目背景不复杂一个面向内部业务的接入网关协议用的是自定义 TCP 长连接心跳、鉴权、业务报文混在一个链路里。放在以前这类压测我大概率会用 LoadRunner——它有很丰富的协议支持写 C 脚本也灵活。但问题来了被测环境整体迁移到了国产操作系统和国产 CPU 的服务器上LoadRunner 的 Load Generator 在这个平台上的兼容性非常尴尬装倒是能装跑起来却经常出现虚拟用户进程异常退出排查几天都定位不到根因。换 JMeter 呢JMeter 基于 Java理论上跨平台没问题但面对自定义 TCP 协议我得自己写 Java Sampler 或者用 TCP Sampler 再配一套协议解析逻辑。报文里面有时间戳、序列号、MD5 加签光是把这些动态参数处理干净就花了两天。更难受的是JMeter 在高并发长连接场景下线程一多客户端本身的 CPU 和内存先爆了测出来的结果根本分不清是被测系统的瓶颈还是压测端的瓶颈。这时候有同行推荐了 kylinPET说是国产协议级仿真工具能直接跑在国产环境里而且单机就可以模拟非常大的连接数。我当时半信半疑但确实没有更好的选择了。用下来之后才发现这个工具在“协议仿真”和“高并发”两个维度上的设计思路跟 JMeter、LoadRunner 完全不是一个路子。1.2 kylinPET 是什么不是“国产 JMeter”而是“协议级高仿真压测工具”kylinPET 我后来查了一下资料它是国内团队开发的一款协议级性能测试工具定位和 JMeter 这种“请求级模拟”的工具不太一样。JMeter 把每个用户抽象成线程线程里跑 HTTP 请求、JDBC 请求这些采样器kylinPET 则更接近 LoadRunner 的思路先从真实业务流量里录制协议报文然后在脚本里做参数化、关联和报文编辑再按照真实的状态机把交互过程回放出来。换句话说JMeter 关注的是“我发出了多少个请求”kylinPET 和 LoadRunner 关注的是“我在协议层完整重现了真实用户和服务器之间的交互”。所以 kylinPET 在官网资料里常强调“高仿真”不是营销话术它在 TCP/UDP、HTTP/HTTPS、WebSocket 等协议上确实能做到报文级别的模拟连连接建立、Keep-Alive 维持、连接释放这些传输层细节都算在压力模型里。“高并发”则是它的另一个卖点。官方宣传中提过在普通 PC 上就可以模拟千万级的并发连接。这个数字听起来有点夸张但理解了它的底层模型之后你会发现这不是虚标而是确实换了一条技术路线。1.3 这篇文章能解决什么问题我把这段时间的实操经验整理成文主要回答三个问题kylinPET 的高仿真和高并发技术上到底是怎么实现的底层模型和 JMeter、LoadRunner 有什么本质区别三款工具在协议支持、脚本开发、分布式压测、成本、国产化适配这些维度上各自优势在哪里如果我现在要做一个真实业务的高并发压测用 kylinPET 应该怎么上手有哪些常见的坑可以提前避开这些问题搞清楚了你做压测工具选型的时候就有了自己的判断依据不至于听销售吹得天花乱坠也不至于看着网上的对比文章一脸懵。2. 高仿真技术拆解kylinPET 是怎么“模拟真实用户”的2.1 录制与协议还原抓包级回放而不是“再点一遍”JMeter 最常用的脚本来源是 HTTP(S) Test Script Recorder说白了就是起一个本地代理把浏览器或客户端的 HTTP 流量截获下来生成采样器。这种方式对 HTTP 请求没问题但有一个明显缺陷它把“用户”抽象成了“请求序列”TCP 连接怎么建的、连接是否复用、客户端状态怎么保持这些信息在脚本里是丢失的。所以 JMeter 压测的时候被测系统看到的是一堆“无状态的请求”而不是一群“真实的用户”。kylinPET 的录制方式不一样。它支持从网卡抓包或者导入 pcap 报文文件然后对报文做协议解析还原出完整的交互会话。这意味着什么TCP 三次握手、TLS 握手、连接复用、应用层报文里的每一个字段都会被提取到脚本里。你在回放的时候相当于把一个真实用户的网络行为在协议层完整重现了一遍。举个例子我们当时压测的那个自定义 TCP 网关客户端连接上来之后要先发一个鉴权报文服务端返回一个带 token 的响应之后所有业务报文都要带这个 token。JMeter 的 TCP Sampler 处理这种场景非常麻烦你得自己维护 socket、自己解析响应、自己写 token 提取逻辑。kylinPET 这边录制之后脚本里自动就有连接管理、收发报文的逻辑token 这种动态值用关联函数一标整个流程就通了。2.2 动态数据关联与报文处理token、时间戳、MD5 加签高仿真不只是把报文原样重放一遍还要应对业务里的动态数据。常见的几类登录 token / session登录接口返回的 token 要提取出来在后续请求里带上。时间戳很多接口会对时间戳做校验脚本里要每次生成当前时间。序列号 / 随机数订单号、流水号这类字段不能每次都用同一个值。签名MD5、SHA256、HMAC 加签用时间戳和密钥算出来防止报文被篡改。JMeter 处理动态数据的手段是正则表达式提取器、JSON Extractor、BeanShell/Groovy 脚本以及 __time()、__Random() 这类函数。功能上都能实现但代码量不小。kylinPET 的处理方式更贴近 LoadRunner 的关联correlation录制完之后把需要动态化的字段识别出来然后用界面配置上下文参数、正则表达式或者脚本函数去替换不需要写一大段 Java 代码。这里有一个容易踩的坑如果你压测的是人脸识别系统这类涉及图片上传的服务报文里可能带着 base64 编码的图片数据或者二进制文件。JMeter 里要做 multipart/form-data 上传脚本里改来改去经常出问题。kylinPET 因为是录制还原的路径直接把原始请求体保存下来只需要把图片文件路径参数化改动成本小很多。当然二进制报文的参数化本身也是要注意的不能简单当成字符串替换否则长度一变化协议解析就乱了。2.3 高仿真到底“仿真”了什么连接、流量、时序、状态机很多刚从接口测试转过来的人会问我用 JMeter 模拟请求和用 kylinPET 高仿真压测到底差在哪我打个比方吧。JMeter 压测有点像打电话做问卷调查你只管一个问题接一个问题地问每次拨号、挂断都是重复劳动问到一半对方说什么你也不太关心只要问题问完就行。kylinPET 的高仿真则更像一个真人坐席在跟客户沟通不仅话术一样语气语调、停顿节奏、上下文理解甚至客户挂电话之后你还在系统里记了一笔状态这些都会被还原。落到技术上kylinPET 高仿真还原的至少有三层连接层连接怎么建、什么时候建、是否复用、长连接多少秒无心跳会断开这些传输层行为都会影响服务器的连接状态表。流量层请求大小、响应大小、发包间隔、并发突刺都要贴近真实业务。状态机层客户端按照业务逻辑推进状态比如“未登录 - 已登录 - 下单 - 支付”每个状态下的请求内容不一样服务端也能感知到这种状态流转。这也是为什么实测下来有些服务用 JMeter 压测时 TPS 看起来挺高但一旦用 kylinPET 做协议级高仿真压测性能数据就明显下降——因为服务端在真实用户行为下承担的上下文管理开销远高于“无脑发请求”的开销。不是 JMeter 不准而是它模拟的压力模型更乐观。3. 高并发原理单机千万连接背后的工程模型3.1 JMeter 的线程模型为什么会撞墙JMeter 的并发模型是这样的一个线程组里配几个线程每个线程就代表一个虚拟用户。线程多了之后客户端的 JVM 要维护大量线程对象、线程栈、以及每个线程持有的 socket 连接。JVM 默认堆内存可能只有几个 GB线程一多光线程栈就吃掉大几 GB再算上连接缓冲区和采样器对象内存基本不够用。更关键的是Java 的线程在操作系统层面是重量级资源线程切换、锁竞争、GC 停顿都会带来额外开销。JMeter 的 GUI 模式下跑高并发尤其要命所以压测通常要用命令行模式jmeter -n -t。即便你用非 GUI 模式单机压到几千并发客户端主机的 CPU 和内存占用也会高得吓人。想再往上走就得走分布式Master-Slave 一堆机器配置同步、结果合并都是麻烦事。当然这不是说 JMeter 一无是处。对于 HTTP/HTTPS 接口压测单机 1000-3000 并发已经能满足很多中低端场景的需求要压更高并发可以堆机器。只是机器堆多了成本上去了运维复杂度也上去了。3.2 LoadRunner 的分布式体系能力强但是真贵LoadRunner 的架构是 Controller 多个 Load Generator。Controller 负责场景设计、调度和结果收集Load Generator 负责生成压力。它的虚拟用户模型可以配置成进程模式或线程模式通过分布式部署支持的并发用户数可以做到很大。但代价也很明显。LoadRunner 是按虚拟用户数授权计费的想模拟 1 万个虚拟用户你就得买 1 万个的 License这笔费用对大企业来说都要批很久。加上 Load Generator 需要单独部署每个 LG 上的虚拟用户数也不是无限的超过一定量就要加机器。整套体系从规划到运维都不便宜。而且 LoadRunner 的重心一直在大企业传统项目对新兴技术的跟进速度慢一些像容器化部署、云原生环境下的压测用起来总觉得有点“重”。新手学习曲线也陡光是折腾安装、汉化、License 激活就能劝退一批人。3.3 kylinPET 的事件驱动与连接池模型kylinPET 的高并发能力核心在于它没有采用“一个用户一个线程”的模型而是把连接管理和业务执行分离。连接本身是 I/O 密集型的资源等待网络数据时 CPU 是空闲的没必要占一个线程。kylinPET 的底层用事件驱动 连接池的方式来管理大量 socket连接的建立、收发数据、超时处理都是异步非阻塞的。打个比方传统线程模型就像一个饭店雇了一万个服务员每个服务员只盯一桌客人客人不说话的时候服务员就干站着事件驱动模型则像一个中央调度台一万桌客人的需求都汇到一个大屏幕上调度员看哪个桌有动静就处理哪个桌一个人就能招呼全场。kylinPET 就是后面的思路所以它可以用相对少的线程管理海量的并发连接。我们实测的时候单台普通配置的 Linux 服务器用 kylinPET 做长连接压测连接数很轻松就推到了几十万客户端自身的 CPU 占用还能控制在合理范围内。再往上主要是操作系统层面的资源限制比如文件描述符数量、端口范围、内核参数而不是压测工具本身扛不住。这个“天花板”比 JMeter 高一个数量级这就是它在宣传里敢提“千万级连接”的底气。注意一个概念要分清连接数不等于业务 TPS。一千万连接可以同时挂在那里但真正每秒能处理的业务报文数取决于报文大小、处理逻辑和被测系统的能力。kylinPET 的优势是“压力模型可以做到很大”但你想让压测产生足够的业务负载场景设计和脚本效率同样重要。3.4 压测端资源调优常识这些参数不调什么工具都白搭不管用什么工具做高并发压测压测端自身的操作系统参数都要调一下否则连接数一上去报错先出现在客户端。我列一下最常用的几项 Linux 配置# 最大文件描述符数默认 1024 肯定不够 ulimit -n 1048576 # 临时端口范围默认 32768-60999 会限制大量短连接 sysctl -w net.ipv4.ip_local_port_range1024 65535 # 开启 TIME_WAIT 复用长连接场景关系不大短连接场景很关键 sysctl -w net.ipv4.tcp_tw_reuse1 # 增大 SYN 队列抗住连接突刺 sysctl -w net.ipv4.tcp_max_syn_backlog65535 sysctl -w net.core.somaxconn65535JMeter 分布式压测的时候还要额外处理 Master 和 Slave 之间的 RMI 通信、防火墙放行端口之类的问题。kylinPET 的负载生成器相对省心但它同样依赖底层操作系统资源你在压测前不调这些参数测出来的最大连接数一定偏小。4. 三款工具硬核对比一张表看懂差异4.1 底层模型与并发能力对比先上硬菜把三款工具的底层模型放一张表里对比维度kylinPETJMeterLoadRunner核心模型事件驱动 连接池Java 线程组进程/线程 LG 分布式单机并发量级十万级以上长连接场景可更高数千级受 JVM 和资源限制明显数千级/每 LG靠机器堆分布式能力支持多负载生成器Master-Slave配置繁琐Controller LG成熟稳定协议支持TCP/UDP/HTTP/HTTPS/WebSocket 等支持自定义HTTP/HTTPS/FTP/JDBC/JMS/TCP 等依赖插件数百种协议企业级协议覆盖广协议仿真深度高报文级录制与回放中请求级模拟为主高支持复杂协议录制关联脚本语言图形化配置 脚本函数Java/Groovy/BeanShellC/Vuser、JavaScript这张表里 JMeter 的“单机并发量级”我写的比较保守因为实际上也见过有人把 JVM 调疯了跑出大几万并发但那是拿服务器硬堆出来的CPU 和内存开销非常夸张不具备普适性。kylinPET 的“十万级以上”在我实际项目中确实验证过而且当时压测机还是一台不算新的 16 核 64G 服务器。4.2 脚本开发与调试体验对比脚本开发这块三款工具的路线完全不同。JMeter 的优势是组件化添加线程组、HTTP 请求、断言、监听器都是点点点非常适合接口测试和中小型压测项目。它内置了响应断言可以校验返回码、响应文本、JSON 路径这一点在接口测试里非常好用。但遇到复杂业务流转你得写 Groovy 脚本比如处理 MD5 加密签名、从身份证号里提取生日、做正则提取、解析嵌套 JSON代码量一下就上来了。而且 JMeter 的脚本排错本质上就是“跑一遍看报错”调试体验比较原始。LoadRunner 走的是 VuGen 录制 脚本编辑的路子。它对脚本的控制力最强C 语言底子好的人能写出非常细腻的压测逻辑。编译报错信息相对清楚关联也是自动加手动这块体验至今不落后。问题在于它的脚本语言和 debug 方式对现代程序员来说有点陌生而且 VuGen 在 Windows 上才能开发很多纯 Linux 环境下开发调试并不方便。kylinPET 给我的感觉是“把 LoadRunner 的思路国产化、现代化了”。录制还原出脚本之后需要动态化的字段直接在界面上配置支持正则、JSONPath、脚本函数复杂的逻辑也提供了脚本编辑能力不过风格更轻量。跟 JMeter 比它对协议细节的暴露更充分跟 LoadRunner 比它上手门槛低一些不用专门学一门老派语言。4.3 监控、报告与问题定位能力对比压测不只是把压力打上去就完事还得看结果。三款工具在这一层的差异也挺明显。JMeter 自带监听器View Results Tree、Aggregate Report、Summary Report监听器数据可以通过 Backend Listener 推到 Grafana/InfluxDB做成实时仪表盘。这是 JMeter 最强的地方——开源生态你想接什么监控都可以自己写。但它的原生报告比较朴素一个压测做完除了 TPS、响应时间、错误率这些基础指标要分析瓶颈根因还是得自己去查服务器监控。LoadRunner 的 Analysis 组件是经典的强项可以生成非常详尽的图表包括事务响应时间细分、Web 资源监控、系统资源监控还能把不同图关联起来分析。这个体验在商业工具里确实是标杆。缺点是整套体系封闭要接入自定义监控指标比较费劲数据一般只能导出不好直接和内部的监控平台联动。kylinPET 的结果分析功能做的是“够用且直观”TPS、响应时间分布、错误率、并发用户数这些核心指标都有图表也比较清晰。它在协议层的诊断信息更细比如可以定位到具体某个报文的收发时序对排错非常有帮助。但你要拿它对接 Grafana 这类开源可视化平台灵活性大概率不如 JMeter。4.4 成本、生态与国产化适配对比成本这块JMeter开源免费这是它最大优势但分布式压测机器、后续维护、脚本开发的隐性成本不低。LoadRunner商业授权按虚拟用户数收费价格不秀气适合预算充足的企业。kylinPET国产商业软件具体价格要联系厂家按场景谈整体比 LoadRunner 便宜很多而且不绑定国外授权体系。国产化适配是这次对比里最现实的一环。现在不少项目的被测系统都跑在国产操作系统和国产芯片上压测工具本身最好也能跑在同样环境里。JMeter 依赖 Java理论上跨平台但国产环境下的 JDK 兼容性、某些 jar 包的 CPU 指令集问题踩过的都懂。LoadRunner 在国产服务器的支持上更是短板。kylinPET 作为国产工具对国产操作系统、国产 CPU 的适配是原生支持的这也是它能中标很多政企项目的原因。我个人的看法是不要神化“国产化”三个字压测工具好不好用最终还是看技术实力。但同为商业工具kylinPET 在本地化支持、技术响应速度上确实比国外大厂要快得多。4.5 选型建议什么场景上什么工具做选型没有“最好的工具”只有“最合适的工具”。我按场景给个参考接口测试、简单 Web 性能测试、预算有限的团队直接用 JMeter。免费、资料多、社区活跃主流问题都能搜到答案。大型政企项目、有合规要求、要求协议覆盖面极广LoadRunner 依然是稳妥选择前提是预算充足、环境不敏感。国产化环境、自定义协议、长连接高并发、协议级高仿真kylinPET 是值得认真考虑的选择尤其当你发现 JMeter 模拟不了真实协议或者 LoadRunner 在国内环境跑不起来的时候。浏览器端真实渲染性能测试以上三款都不是最优解这类场景更适合用 JMeter 的 WebDriver Samplerjpgc - WebDriver Sampler或者专门的浏览器压测工具因为它不是协议仿真而是端到端页面加载仿真和协议级压测完全两个维度。5. kylinPET 实战从录制到高并发压测的完整操作流5.1 环境准备与安装部署kylinPET 支持 Windows 和 Linux 环境安装包不大从官网申请下载后解压即用没有特别复杂的依赖。Windows 上用起来顺手但真正做高并发压测我还是建议放到 Linux 服务器上性能和稳定性都更靠谱。部署步骤很简单上传安装包到压测机解压到指定目录。确认 JDK 环境已配置好kylinPET 的控制台需要 Java 运行环境这个和 JMeter 类似。修改 /etc/security/limits.conf把最大文件描述符数调大建议至少 1048576。关闭防火墙或者放行控制台端口避免压测机和控制台通信被拦截。启动控制台确认能正常打开界面。提示建议先在 Windows 上把脚本调通再放到 Linux 压测机上跑大规模并发。调试阶段的并发不需要很大Windows 的图形化界面操作更直观可以减少很多试错成本。5.2 录制业务场景并处理动态参数部署好之后第一步是录制脚本。以 HTTP 登录 业务查询为例操作路径大概是在 kylinPET 里新建一个性能测试项目选择协议类型HTTP/HTTPS、TCP、UDP 等。配置录制方式可以是网卡抓包模式也可以设置代理模式指向工具内置的录制端口。启动录制用客户端浏览器或真实业务客户端去操作目标系统把完整的业务链路跑一遍。结束录制工具会生成一个包含请求序列、请求头、请求体、响应校验规则的脚本。在脚本里找到登录接口返回的 token 字段右键选择“关联”提取为参数。找到请求里带时间戳或签名的字段用函数替换成动态值。保存脚本先单用户跑一遍确认业务能通。这里要说下 HTTPS 的证书坑。JMeter 录制 HTTPS 脚本需要在浏览器里导入它的 CA 证书否则抓到的都是加密乱码。kylinPET 录制 HTTPS 也有类似的证书配置你在录制前先在客户端安装它的根证书否则同样解不开 HTTPS 报文。这个问题知乎上天天有人问“jmeter录制https脚本失败”本质上都是证书没配好。5.3 设计压测场景并发数、持续时间、加压模式脚本通了之后进入场景设计。kylinPET 的场景配置项我挑几个关键的讲并发用户数这里填的是虚拟用户数不是连接数。如果业务是短连接每个用户会不断建连和断连如果是长连接虚拟用户数和连接数基本对应。发起方式支持一次全量发起、阶梯加压、随机延迟发起。阶梯加压是我最推荐的方式它能帮你找到系统的性能拐点。持续时间建议不要低于 10 分钟。很多系统的内存泄漏、连接泄漏问题跑 1 分钟看不出来跑 10 分钟就暴露了。思考时间模拟用户操作间隔。如果你做的是容量评估思考时间要贴近真实业务如果你做的是极限压力测试思考时间可以设成 0直接打满。断言/校验在脚本里配置响应码、响应内容的关键字校验TM 上有没有报错需要用断言来判定。kylinPET 里可以基于录制时的响应快照自动生成断言也可以手动加规则。拿“压测怎么确认系统的并发数”这个常见问题来说我的标准操作就是梯度加压。比如从 100 并发开始每 5 分钟加 100一直加到系统出错率超过 5% 或者响应时间翻倍那个拐点就是系统当前架构下能支撑的最大并发数。这个方法论在 JMeter 里用 Ultimate Thread Group 也能做但在 kylinPET 里配置更顺手。5.4 运行压测并解读关键指标场景配置完点击运行压测就开始了。跑的过程中重点盯这几个指标TPS每秒事务数注意是“业务成功”的事务不是请求数。响应时间关注 P95、P99平均值很容易被极端值拉偏。错误率超过 1% 就要警惕超过 5% 基本可以判定系统已经扛不住了。客户端资源压测机自身的 CPU、内存、文件描述符使用情况排除压测端瓶颈。服务端资源CPU、内存、磁盘 IO、网络带宽、连接数配合定位系统瓶颈。压测结束之后看报告不要只看最大值。比如 TPS 平均值很高但响应时间呈现“爬坡后平线”的形态大概率是连接池被打满如果响应时间一开始正常跑几分钟后直线上升那就要怀疑内存泄漏或者 GC 问题。这些形态分析比单纯看一个“总通过数”有价值得多。6. 我踩过的坑kylinPET 与 JMeter 排障实录6.1 场景一连接数上不去一开始以为是工具问题第一次用 kylinPET 做长连接压测我在场景里配了 5 万个虚拟用户结果跑到 8000 多就报错提示“无法建立更多连接”。我当时第一反应是工具不行后来排查了一圈发现是压测机的文件描述符上限没改。Linux 默认 ulimit -n 是 1024不调高它哪来的 5 万连接调完之后又遇到端口不够的问题因为大量短连接导致客户端端口耗尽TIME_WAIT 状态堆积。后面把 tcp_tw_reuse 打开端口范围扩大情况才好转。这类问题其实跟选什么工具没关系操作系统参数不调JMeter 和 LoadRunner 一样会撞墙。注意高并发压测之前先做压测机自身的能力验证。用工具直接打空接口或者建一批连接不发送业务数据确认客户端能稳定维持目标连接数再开始真实业务压测。这一步非常关键能帮你把“压测端问题”和“被测系统问题”快速隔离开。6.2 场景二脚本回放报 token 失效动态参数没处理干净录完脚本第一次回放登录是成功的但业务请求全部报鉴权失败。打开报文一看请求头里的 token 还是录制时的旧值没有替换成登录接口返回的新 token。这个问题我在 JMeter 里也常遇到说白了就是关联没做或者正则表达式写错了。kylinPET 里做关联比 JMeter 直观自动关联能识别一部分复杂场景需要手动标。我的建议是不要依赖自动关联脚本录制完先跑一遍用“回放对比”功能看一下哪些请求的响应值和录制时不一致把不一致的字段逐个处理干净。JMeter 里处理动态参数更是这样正则表达式提取器的匹配规则一定要用单接口调试验证过再压测别等到压测跑起来才发现所有请求都在拿着过期 token 打。6.3 场景三压测结果 TPS 比 JMeter 低是被测系统差还是压测端弱有一次我用 kylinPET 压测一个内部系统结果 TPS 比之前用 JMeter 测出来的低了 30%。项目组差点把 kylinPET 否了我在旁边看了半天最后发现不是工具变弱了而是 JMeter 的脚本里没有模拟真实的业务状态流转请求是一个个独立打过来的kylinPET 的脚本则是完整还原了登录、鉴权、业务调用、心跳维持的全过程服务端需要为每个连接维护更多上下文资源消耗自然就上去了。这给了我一个很深的教训性能测试的结果永远不能脱离压力模型来讨论。你说一个系统 TPS 是 5000前提是“怎么压出来的 5000”。是 1000 个并发用户每个跑 5 个无状态请求还是 1000 个真实用户模拟完整业务链路两个数字背后是两种完全不同的系统负载。所以遇到“工具 A 比工具 B 数据差”的争论先看脚本和场景设计是否等价。6.4 新手常问的几个问题速查表问题建议JMeter 断言怎么写推荐用响应断言校验响应码、响应文本、JSON 路径复杂校验用 Groovy 脚本JMeter 上传文件怎么做HTTP 请求里选择 multipart/form-data添加文件参数先抓包确认请求体格式JMeter 请求体/响应体怎么格式化安装 JSON 插件或在线格式化排错时更直观kylinPET 回放报文对不上怎么办检查动态参数、时间戳、证书、字符集编码逐步排除LoadRunner 汉化包装了没用检查汉化包版本和安装路径建议使用英文原版团队内部统一术语压测机出现 resultcollector 相关弹窗这是 JMeter 的已知问题检查 result collector 配置不要直接覆盖已存在的输出文件先改名另存压测要压多久按场景需求稳定性测试建议至少 1 小时容量测试至少 10 分钟并发摸底可以短一些7. 写在最后我的选择与建议工具这东西用久了会有感情但选型的时候不能讲感情。JMeter 我用了很多年它的开放生态和易用性短时间内没有哪个工具能完全替代LoadRunner 在传统企业测试体系里依然是老大哥该有的能力都有但如果你问我现在做一个新项目我会怎么选我的答案是先看被测系统的协议复杂度、并发量级和运行环境再决定工具。如果被测系统是标准 HTTP 接口并发也就几千团队里没人愿意折腾商业工具那 JMeter 依然是性价比之王。如果业务涉及自定义协议、长连接高并发或者明确要求跑在国产化环境里kylinPET 值得你花一两天时间试试。它给我的整体感觉是“懂性能测试的人做出来的工具”很多细节——比如报文级回放、连接池模型、结果诊断的细致程度——都能看出设计者对压测场景的理解不是停留在发个请求看个 TPS 的层面。最后再分享一个小技巧不管用哪款工具做高并发压测第一次跑的时候一定先小并发验证脚本正确性再慢慢加压力。很多人一上来就怼高并发脚本里有问题也发现不了跑出来的数据全是垃圾最后还要花大把时间排错。先 1 个用户跑通再 10 个用户看稳定性然后 100、1000、5000 一路压上去每一步都确认数据合理再进入下一个量级。这个习惯能帮你省下无数个加班的夜晚。