1. 先聊聊我为什么会在项目里用 kylinPET
做了快十年的性能测试，工具换了一茬又一茬，最早用 LoadRunner，后来团队全面转 JMeter，再到现在不少项目里直接用 kylinPET。国产工具这个事，前几年大家还停留在“能跑脚本就行”的印象里，但说实话，最近两年再看 kylinPET，它已经不是你印象里那个只会做简单 HTTP 压测的小工具了。
我第一次认真接触 kylinPET，是因为一个银行核心系统的接口压测项目。那会儿甲方明确要求不能用开源工具做生产环境旁路验证，LoadRunner 的 License 又贵得离谱，而且新版本的安装和破解折腾起来非常麻烦。团队里有人提了一嘴国产工具，说 kylinPET 在做高仿真录制这块挺扎实，支持 HTTPS、WebSocket、TCP/UDP 这些协议，单机并发也能做得很大。当时我还有点将信将疑，毕竟 JMeter 用顺手了，脚本体系、插件生态都是现成的。
结果项目做下来，kylinPET 的表现确实超出了我预期。最让我意外的是它的脚本录制方式：不需要像 JMeter 那样配 HTTP 代理服务器，也不需要像 LoadRunner 那样装一堆录制组件，它通过网关代理的方式直接把客户端和服务器之间的 TCP 交互完整抓下来，录制出来的脚本和真实请求几乎是字节级一致。这意味着什么？意味着你压测出来的响应时间、错误率，比 JMeter 那种“按 HTTP 请求模板回放”的方式要真实得多。
这篇文章不是让你立刻把 JMeter 扔了换工具，而是结合我这几个项目的实际操作经验，把 kylinPET 的技术原理、使用流程，还有它和 JMeter、LoadRunner 的真实差距一次说清楚。适合正在选型性能测试工具的团队、刚入行想知道怎么选工具的人，以及被并发数上不去折磨过的老手。
2. 和 JMeter、LoadRunner 的多维度对比：不吹不黑
2.1 协议支持与脚本录制：仿真度差在哪里
先看 LoadRunner。它最强的地方是协议库非常丰富，老牌的 Web HTTP/HTTPS、TCP、UDP、FTP、SMTP、Oracle、SAP 都有对应协议，甚至能录 C/S 架构的 Socket 程序。但代价是脚本语言是类 C 语言，写起来繁琐，而且大部分协议包还要额外买 License。想录一个 Dubbo 接口或者 gRPC 接口，LoadRunner 基本上帮不上忙，只能自己手写封装。
JMeter 靠插件吃饭。HTTP 协议王者，REST/gRPC、WebSocket、MQTT 都有第三方插件支持。但它本质上是“按请求模板回放”，它发出的每个请求都是基于 JMeter 自己解析 HTTP 报文后重建的，和真实客户端发出的报文字节并非完全一致。对于 REST API 这种标准结构影响不大，可一旦遇到报文里有动态生成的非标准字段，或者 TLS 指纹、HTTP/2 连接复用这类细节，JMeter 很容易失真。
kylinPET 走的是另一条路：网关代理录制。你在客户端和服务器之间挂一个 kylinPET 的网关代理，所有 TCP 数据包都会经过它，然后按协议格式解析、转成脚本。因为它从 TCP 流层面录，所以请求内容、时序、连接复用方式都跟真实交互完全一致。像 HTTPS 的双向证书认证、WebSocket 的长连接收发、TCP 自定义私有协议的二进制报文，它都能直接录出来。这块仿真度，说实话已经超过了大部分开源方案。
kylinPET 官方支持的协议覆盖 HTTP/HTTPS、HTTP/2、WebSocket、TCP/UDP、FTP、MQTT、Dubbo、gRPC 等主流协议。Dubbo 和 gRPC 这两点是 LoadRunner 很难做到的，也是我在实际项目里特别看重的。
2.2 并发模型与资源消耗：单机上限差在哪
说到高并发，这里面的门道特别多。
LoadRunner 的经典架构是 Controller + Load Generator，每个虚拟用户是一个进程或线程，并发数能做到成千上万，但 License 是按虚拟用户数卖的，你想跑到 5000 并发，就得付 5000 用户的钱，而且 Load Generator 本身的资源消耗不小。
JMeter 是纯 Java 应用，默认一个线程对应一个虚拟用户。线程本身的消耗就把单机并发上限限制死了。JVM 内存、线程栈、GC 停顿，每一样都是瓶颈。我曾经在一台 8 核 16G 的机器上跑 JMeter 压测，3000 个线程的时候 GC 就开始变得很频繁，TPS 上不去，CPU 反而被 JVM 吃光。后来有人用 ArralList 的虚拟线程模型或者分布式负载方案，但分布式又引入了同步和统计误差的问题。
kylinPET 的设计思路是“多进程 + 多线程 + CPU 绑定”。它把负载机上的 CPU 核心分配给不同的压力进程，每个进程内部再跑多条线程，而且允许你绑定 CPU 核心，减少上下文切换。单机跑 5 万到 10 万连接，在合适的硬件上是能做到的。我实测过一台 32 核 64G 的物理机，跑 8 万条 WebSocket 长连接，负载机 CPU 占用大约在 40% 左右，稳定性不错。
这个设计很符合高并发压测的逻辑：压测工具本身不应该成为瓶颈，它应该合理地用满硬件资源，把压力真正施加到被测系统上。JMeter 在高并发场景下的短板，恰恰就在这里。
2.3 使用成本与上手难度：License、配置、团队协作
LoadRunner 的问题大家心知肚明：贵，而且生态封闭。企业版按模块收费，一个 Web 协议模块可能就大几万，加上每年维护费，小团队根本扛不住。破解版虽然有人用，但在正规项目里风险太大，不展开说了。
JMeter 的优势是开源免费，插件丰富，社区资料多。从脚本编写、自定义断言到 CI/CD 集成，都有成熟方案。缺点是学习曲线也不算低，要真正做好一个压测脚本，你得懂 JSR223 脚本、懂正则提取器、懂 JSON 提取器、懂 BeanShell，还要处理证书、处理编码、处理各种乱码问题。很多初学者问“JMeter 怎么测接口”“JMeter 压测怎么确认并发数”，本质上就是被这些细节卡住了。
kylinPET 在学习成本上做得更接近 LoadRunner 的交互模式，但比 LoadRunner 轻。它提供图形化的场景设计界面，脚本录制完基本不需要手动写代码，参数化、关联、断言都通过界面配置。安装也是 Windows 下双击安装包，License 激活后就能用，没有复杂的 JDK 环境和插件依赖。团队协作方面，kylinPET 支持脚本导出和导入，方便版本管理。
有一点要实话实说：现在 JMeter 也有 AI 辅助生成性能测试脚本的趋势，比如用 ChatGPT 写 JSR223 脚本或者生成压测计划 XML，确实能省不少事。但在“录制真实报文”这个环节上，AI 生成脚本仍然是基于模板，替代不了网关代理录制带来的仿真度优势。
2.4 辅助能力与生态：从监控到报告的差距
LoadRunner 的 Analysis 报告最经典，能生成非常规范的产品级报告，适合交付给客户。JMeter 的聚合报告、表格监听器、Backend Listener 配合 Grafana + InfluxDB，也能搭出比较漂亮的监控看板。
kylinPET 的监控和报告模块做得也挺全：事务响应时间分布、TPS 趋势、错误率、网络吞吐量、服务器资源监控都有，还支持在报告里对比不同测试轮次的数据。它有一个特色功能是“网络环境仿真”，可以模拟带宽限制、丢包率、延迟抖动，这个在测弱网场景时特别有用。JMeter 要模拟这些需要装额外的插件，LoadRunner 老版本里也有类似功能，但操作复杂。
不过 kylinPET 的生态还是比不过 JMeter。JMeter 有海量插件，从自定义采样器到分布式压测方案，你能想到的社区基本都做过。kylinPET 的插件机制相对简单，目前主要靠官方迭代。如果你需要和一些特定的监控系统深度集成，可能要自己开发或等待官方支持。
3. 核心原理拆解：高仿真和高并发是怎么做到的
3.1 多进程多线程 + CPU 绑定，为什么能压出更高并发
性能测试工具本身也是一个程序，它消耗 CPU、内存、网络连接。如果你用 JMeter，开 5000 个线程，JVM 里就要维护 5000 个线程栈，每个线程默认栈大小 1MB，光线程栈就吃掉 5GB 虚拟内存，GC 压力非常大。
kylinPET 的做法是把压力机的 CPU 核心切成多个工作进程，每个进程负责固定数量的虚拟用户，进程内再用事件驱动的方式处理网络 I/O，而不是一个用户一个线程死等。这种模型有点类似 Nginx 的事件驱动架构，能支撑的连接数要远高于线程模型。
它还支持 CPU 亲和性绑定。把某个压力进程绑定到一个物理核心上，减少进程在不同核心之间切换的开销，保证每个进程的计时精度。对于压测这种对时间精度要求很高的场景，这个设计能明显降低响应时间统计的抖动。
我个人的实际操作经验是：跑高并发场景前，先把压力机上的其他服务全停掉，然后用 kylinPET 的“环境检查”功能看一下当前机器的 CPU 核心数、内存占用、连接数上限。Windows 下默认的 TCP 端口范围只有 5 万多，高并发压测一下就会端口耗尽，需要在注册表里调整MaxUserPort和TcpTimedWaitDelay。这个问题在 JMeter 里一样会遇到，但在 kylinPET 的并发场景里更容易暴露，因为它的并发确实能拉得很高。
3.2 无代理网关录制：为什么录出来的脚本更真实
很多人被“录制脚本”四个字误导了，以为所有工具的录制都一样。其实差别很大。
JMeter 的录制是基于 HTTP 代理服务器。你在浏览器里配置代理指向 JMeter，JMeter 把经过的 HTTP 请求解析、生成对应的 HTTP Sampler。这种方式只适用于 Web 应用，而且只能录到应用层的 HTTP 请求，录不到 TCP 层的一些细节。
LoadRunner 的录制基于协议级捕获，但它生成的是类 C 脚本，需要把录到的数据转换成web_url、web_submit_data之类的函数调用。这种转换过程也可能丢一些非标准字段。
kylinPET 的网关代理录制，关注点在会话流，而不只是单个请求。所有 TCP 数据包都会经过它，它按配置的协议类型解析出请求和响应，然后生成脚本。因为是直接解析 TCP 流里的二进制报文，所以请求头、请求体、连接状态、HTTP/2 帧顺序都能保留下来。遇到动态变化的字段，比如 token、session ID、时间戳，它会自动给出关联标记，你只需确认一下就行。
实际用下来，kylinPET 录出来的 HTTPS 脚本回放成功率非常高。JMeter 录制 HTTPS 经常要导入证书，如果前端用了客户端证书双向认证，JMeter 的配置会非常麻烦。kylinPET 的网关代理直接处理证书交互，回放的时候用录制的会话上下文恢复，省了很多事。
3.3 动态关联与数据驱动，脚本稳定性的关键
脚本录完能不能稳定跑，关键看关联处理。
HTTP 类的动态数据，JMeter 用正则表达式提取器或 JSON 提取器来提取。这在标准化接口里够用，但遇到复杂的动态逻辑，比如 token 由前一个响应的某个字段经过加密算法生成，JMeter 的正则就很难搞，还得写 BeanShell 或 JSR223 脚本。
kylinPET 提供了自动关联和手动关联两种方式。自动关联会在录制阶段分析哪些请求字段的值在响应中出现过，自动建立关联关系。手动关联则允许你通过界面指定字段来源。它对二进制协议也支持关联，比如 TCP 报文中的序列号、长度字段、校验值。这个能力在做私有协议压测时是刚需。
数据驱动方面，kylinPET 支持从文件、数据库读取测试数据，也可以配置多个数据池做组合。比如模拟用户登录的账号密码，可以从 CSV 文件里循环读取；模拟不同商品 ID，可以从数据库查询结果里取值。这些配置都在界面上完成，不用写代码，团队里的新人上手很快。
有一个容易踩坑的地方：关联的提取范围要控制好。如果你把整个响应报文都作为提取源，脚本回放时会因为报文体太大导致性能下降。我在项目里通常只关联必要的字段，其他字段都忽略。
3.4 网络环境仿真，不只是“带宽限制”这么简单
弱网测试一直是移动端性能测试的重点，但传统工具做弱网模拟很麻烦。
JMeter 有一些插件可以模拟网络延迟和丢包，但配置起来不够直观，而且对 TCP 层的控制比较弱。想模拟 3G、4G 网络的延迟抖动、带宽波动，需要额外安装系统级的网络模拟工具。
kylinPET 内置了网络环境仿真功能，可以在压力机上直接设置网络参数：带宽、往返延迟、丢包率、抖动、乱序比例等。它可以在网关代理的转发过程中注入这些网络损伤，也就是说你的客户端不需要做任何配置，只需把流量走到 kylinPET 的代理上，就能模拟目标网络环境。
我在一个 App 接口性能评估项目里用上了这个功能。产品想知道用户在弱网环境下接口的响应时间能不能接受，我直接建了三个场景：WiFi 环境、4G 正常环境、弱网（延迟 200ms，丢包 3%）环境，每个场景跑 15 分钟。kylinPET 报告里能清晰看到不同网络场景下的 TPS 和响应时间差异，这份数据产品评审时特别认可。如果用 JMeter 做，我得额外部署 WANem 之类的工具，麻烦不少。
4. 实操：在 kylinPET 里完成一次完整压测
4.1 安装与初始配置
kylinPET 的安装包可以从官网申请下载，支持 Windows 和部分 Linux 版本。Windows 版本安装很简单，双击安装包，选择安装目录，一路下一步就行。装完第一次启动会要求激活 License，申请试用版 License 后填入即可。
需要注意几点：
- 如果压力机和被测服务器在同一台机器上，压测结果没有参考价值，因为资源互相争抢，测出来的 TPS 完全不真实。
- 压力机建议用物理机，尽量不要用虚拟机。虚拟机的 CPU 调度和网络中断处理会影响压测的稳定性。
- kylinPET 安装目录尽量用英文路径，避免个别协议组件在中文路径下出问题。我遇到过一台机器因为路径里有中文，TCP 录制死活起不来，改路径后正常了。
安装完建议先检查网络连接数和端口范围配置。Windows 上可以通过命令查看当前 TCP 连接数限制：
netsh int ipv4 show dynamicport tcp netsh int ipv4 show global如果动态端口范围太少，用管理员权限调整：
netsh int ipv4 set dynamicport tcp start=1025 num=64510 netsh int ipv4 set global timestamps=enabled这两个命令能让压力机支持更多并发连接，实测很有效。
4.2 录脚本、回放与参数化
打开 kylinPET，新建工程后选择“录制脚本”。录制前要把被测系统的域名或 IP 加入到录制过滤列表，避免抓到无关流量。
录制方式选择“网关代理”，然后把客户端的网络代理指向压力机 IP 和 kylinPET 监听的端口。如果客户端和压力机是同一台机器，代理地址填 127.0.0.1 就行。
录制完成后，脚本列表里会显示所有捕获到的会话。你可以对每个会话重命名、分组、设置思考时间。回放前先做一次“试运行”，确认脚本能跑通。试运行阶段的重点是看两个地方：
- 动态关联是否生效。如果回放时某个请求出现 401 或业务报错，多半是 token 或 session 没关联对。
- 断言是否满足需求。kylinPET 支持按响应码、响应内容关键字、响应时间做断言。
参数化这一步，kylinPET 的操作路径是：选中脚本里的某个请求字段，右键设置为参数，然后在“数据池”里配置数据来源。我一般用文件参数化，几百个账号放在 CSV 里，循环取用。要注意数据量要足够大，如果并发是 1000，数据只有 50 条，很可能出现重复使用导致的冲突，登录接口会直接报错。
4.3 场景设计：并发、思考时间、持续时长
场景设计是压测的灵魂，工具只是实现方式。
kylinPET 的“压力场景”模块支持配置：
- 并发用户数：按阶梯或固定值。
- 加载方式：一次性加载、梯度加载、渐进加载。
- 思考时间：固定值、随机范围。
- 运行时长：按时间或按迭代次数。
- 停止条件：错误率阈值、响应时间阈值。
我常用的方案是先跑一个 10 分钟的小并发冒烟测试，比如 100 并发，确认脚本稳定、指标正确，再上正式场景。正式场景用梯度加载：每秒增加 20 个用户，跑到目标并发后再持续 20 分钟，最后观察系统在压力释放后的恢复情况。这样能拿到系统容量拐点和资源回收情况。
有一个细节：思考时间不能全设为 0。很多初学者做压测喜欢把所有思考时间删掉，想着这样可以压更大的压力。实际上没有思考时间会导致请求频率过高，压出来的结果是“极限请求压力”而不是“模拟用户行为压测”。真实用户不可能毫秒不差地连续点按钮，所以压测结果会虚高响应时间，反而误导性能判断。kylinPET 里可以给每个会话添加思考时间，我一般设置为 1~3 秒随机。
4.4 监控与报告解读
压测运行过程中，kylinPET 能实时显示 TPS、响应时间、错误数、网络吞吐量。它还支持显示压力机自身的 CPU、内存使用率，这个对判断负载机是否达到瓶颈很有用。
服务器侧的监控需要额外配置，kylinPET 可以监控 Windows/Linux 服务器性能指标。我在压力机上开服务器监控时，发现步骤如下：
- 服务器管理器里添加目标服务器 IP。
- 如果监控 Linux，需要在目标机器上开启 SSH 服务，kylinPET 通过 SSH 协议采集数据。
- 配置要监控的指标：CPU、内存、磁盘 I/O、网络带宽、TCP 连接状态。
报告导出有两种方式：详细报告和摘要报告。详细报告按事务维度输出响应时间分布、TPS 曲线，适合内部复盘；摘要报告适合直接贴给客户，格式比较规范。
报告解读里我最看重三个指标：
- 99 线响应时间：比平均响应时间更能反映用户真实体验。
- 错误率：大于 0.1% 就要开始关注，大于 1% 基本可以判定系统不达标。
- 并发用户数变化趋势：梯度加压下，TPS 如果出现明显下降平台，说明系统触达了瓶颈。
5. 常见问题与排查实录
5.1 问题速查表
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 录制不到任何流量 | 代理没配对、过滤列表写错 | 先抓包确认流量是否经过压力机；检查过滤列表 IP/端口 |
| 脚本回放失败，报 401/403 | 动态关联没设置好 | 打开响应日志，定位失败请求，检查关联字段来源 |
| 并发数提不上去 | 本机端口耗尽 | 用netstat查看 TIME_WAIT，调整 TCP 端口范围 |
| 压力机 CPU 高但 TPS 低 | 脚本里有重操作或正则提取范围过大 | 检查是否每请求都做了大报文解析；减少不必要断言 |
| HTTPS 回放证书校验失败 | 客户端不信任录制证书 | 检查 kylinPET 网关证书是否导入系统信任区；确认双向认证配置 |
| 响应时间曲线周期性波动 | 负载机资源释放不准 | 开启 GC 日志或在报告里叠加压力机 CPU 曲线对照 |
| 服务器监控数据为空 | SSH 端口不通、账号权限不足 | 用命令行ssh user@ip先手动连一下，确认能连上 |
5.2 一个排查案例：并发一直卡在 2000 上不去
有个项目压测一个 WebSocket 网关，目标是 5000 并发。JMeter 脚本能跑通，但压到 1700 并发时 TPS 就开始抖动，错误率往上飙。一开始我以为被测系统瓶颈，换 kylinPET 重新跑，结果发现 2000 并发以内响应时间都很稳定，2000 以上压力机先出问题。
排查过程：
第一步，看压力机网络连接数。命令netstat -s发现大量端口处于 TIME_WAIT 状态。因为 JMeter 每次请求可能新建 TCP 连接，而 WebSocket 长连接场景里连接建立和关闭频率高，TIME_WAIT 数量快速膨胀，最后端口耗尽，新连接失败。
第二步，调整系统参数。把动态端口范围扩大，开启时间戳选项，TIME_WAIT 时间从默认 120 秒缩短到 30 秒。需要注意，缩短 TIME_WAIT 在某些严格环境下可能影响连接可靠性，我这个场景是内网压测，风险可控。
第三步，调整脚本连接复用方式。在 kylinPET 里勾选“连接复用”，让虚拟用户持续复用已有连接，减少频繁建连。
调整后，单机 5000 并发稳定跑完 30 分钟，压力机 CPU 占用约 40%，没有出现端口耗尽问题。这次排查给我的经验是：高并发压测遇到瓶颈，先别急着怀疑被测系统，先看压力机自身指标。很多时候，瓶颈根本不在对方，而在你这边的负载工具配置。
5.3 性能测试面试题里的高频坑
有不少做性能测试的朋友在看机会时会刷“性能测试面试题”，里面有些问题和 kylinPET 的实践结合很紧密，比如：
- “怎么确定系统的并发用户数？”这个问题不能只答“压测压出来的”，更应该描述怎么通过场景设计拿到容量拐点。
- “TPS 和 QPS 有什么区别？”实际工具里 TPS 指的是每秒事务数，QPS 是每秒查询数，有的工具统计口径不同，kylinPET 里可以在报告模板里切换。
- “压测结果不稳定怎么办？”这个问题的答题思路就是我在 5.2 节里的排查路径：先看工具自身消耗，再看被测系统指标，最后看网络链路。
这些面试题背后考察的其实是你对工具原理的理解，而不只是会不会操作按钮。很多 JMeter 操作教程会让你记住界面步骤，但你真理解了“线程模型决定单机上限、录制原理决定脚本仿真度”，无论换哪个工具都能迅速上手。
6. 关于三种工具的最终选择建议
工具从来不是越贵越好，也不是开源免费就无脑选。
如果是短期项目、需要快速出标准报告、客户不关心工具品牌，LoadRunner 依然是稳妥的选择，前提是预算充足。如果团队本身 Java 技术栈很强、测试体系已经深度绑定 JMeter 生态，没必要为了换而换。
但如果你的项目有几个典型特征：协议比较新、需要真实录制报文、并发要求高、希望脚本维护成本低，那么 kylinPET 确实值得纳入候选。尤其是 Dubbo、gRPC、WebSocket 这类协议，kylinPET 的录制能力比 JMeter 插件方案要省心很多。我在项目里用下来，感觉它更像是“LoadRunner 的国产替代”，但价格和使用门槛都友好一大截。
要说它的不足，我觉得主要在这几点：一是社区生态还不够大，遇到问题能搜到的案例少，很多时候要自己看官方文档或者问技术支持；二是插件能力偏弱，想扩展一些非标准协议或者做特殊逻辑，不如 JMeter 灵活；三是报告的美观度和定制程度，比起 LoadRunner 的 Analysis 还是略有差距，不过日常交付够用。
最后说个小技巧，可能很多人不知道。kylinPET 支持在运行过程中动态调整并发数，不用停掉场景。这对阶梯加压场景很有用，你可以先跑到 2000 并发放着观察几分钟，如果系统稳定，直接在控制面板里把并发调到 3000，继续观察。JMeter 要用这种方式就得通过 GUI 动态修改变量，操作麻烦得多。
我个人现在的习惯是：JMeter 继续用来做接口级的功能验证和小并发冒烟测试，kylinPET 负责正式的高并发场景和需要真实录制的协议压测。两者不冲突，反而互补。压测工具选型也是一样，别迷信某一个，能解决你实际问题的就是合适的。
如果你手头正好有 Recorder 类型的项目要做高并发验证，或者被 HTTPS 录制折磨得够呛，可以拿 kylinPET 试试，先跑一个最熟悉的业务脚本，对比一下和你现在工具的数据差异。实践一次，比看十篇对比文章都有用。
