Node.js 服务上线前，很多问题并不是功能跑不通，而是在并发上来之后才暴露出来。要在 Ubuntu 上把性能测试做得有判断价值，关键是先分清自己要回答的问题：是想知道接口能扛多少请求，还是想找出代码里真正拖慢响应的热点；下面就按这两条线，把几种常用工具的定位、安装方式和最基础的使用方法理清楚，方便你按场景选择。
JMeter：适合需要图形化编排测试流程的场景
如果你希望通过可视化界面组织测试计划，或者一次性把线程组、请求参数、监听结果放在一个地方管理，Apache JMeter 仍然是 Ubuntu 上很稳妥的选择。它是老牌开源负载测试工具，覆盖面比较广，不只是 Node.js Web 应用，静态资源和动态接口也都能测。
安装方式如下：
sudo apt update
sudo apt install jmeter
它的基本思路，是模拟多名用户并发访问你的 Node.js 应用，再结合结果面板观察吞吐、响应时间等指标。实际操作时，可以按下面这个顺序搭建测试：
- 启动 JMeter，创建一个测试计划。
- 添加线程组，设置虚拟用户数和每个用户的循环次数。
- 添加 HTTP 请求默认值和具体的 HTTP 请求，填入 Node.js 应用的 URL 与参数。
- 添加监听器，执行后查看测试结果。
JMeter 的优点是功能完整，适合测试流程较多、需要反复调整参数的情况；代价是配置步骤相对更多，做简单接口压测时未必是最高效的选择。
Artillery：更适合 Node.js 项目的脚本化压测
如果你更偏向命令行和配置文件驱动的方式，Artillery 会更贴近现代 Node.js 团队的使用习惯。它本身就面向 HTTP、WebSocket 和 Socket.io 负载测试设计，轻量、上手快，对已经习惯 YAML 或 JSON 的开发者尤其友好。
安装命令是：
npm install -g artillery
一个基础测试脚本可以这样写：
config:
target: "http://your-nodejs-app.com"
phases:
- duration: 60
arrivalRate: 20
scenarios:
- flow:
- get: /
执行测试时只需要一条命令：
artillery run your-test-script.yml
这类写法的优势，在于测试配置可以直接进版本库，便于团队协作和重复执行。像上面这个例子里，duration: 60 表示持续 60 秒，arrivalRate: 20 表示每秒到达 20 个新用户，请求场景则定义为访问根路径 /。如果你的目标是持续迭代接口性能，Artillery 往往比纯图形化工具更省事。
wrk：适合快速打高并发、直接看吞吐和延迟
当你更关心极限压测能力，希望用较轻的工具快速生成高并发请求，wrk 是非常常见的选择。它使用 C 编写，压测性能本身很强，适合直接对 HTTP 服务做高强度请求，并在终端里立即查看结果。
Ubuntu 下安装也很直接：
sudo apt install wrk
示例命令如下：
wrk -t12 -c400 -d30s http://your-nodejs-app.com
这条命令表示使用 12 个线程、400 个并发连接，持续压测 30s。执行结束后，wrk 会在终端输出延迟分布、吞吐量等结果，适合做快速基准比较，或者验证某次优化前后是否有明显变化。
不过也要注意，wrk 更偏向“把请求打上去再看结果”，在流程编排和复杂业务场景描述方面不如 JMeter、Artillery 灵活，所以更适合短平快的高并发测试任务。
Node.js 内置分析工具：适合定位代码层面的性能瓶颈
前面几种工具主要回答的是“服务在压力下表现怎样”，如果你还想进一步知道“到底是哪段代码拖慢了性能”，那就该用 Node.js 内置的性能分析工具 了。Node.js 自带的 --prof 和 --inspect，就是用来做运行时剖析的。
最直接的用法是：
node --prof your-script.js
运行之后会生成 V8 性能分析文件，你可以再借助 Chrome DevTools 去查看执行热点，分析哪些函数占用了更多 CPU 时间。和纯压测工具相比，这一类方法不负责制造大量外部请求，而是更专注于解释程序内部的耗时结构。
换句话说，如果你已经通过 wrk 或 Artillery 发现接口在压力下变慢，但还不知道问题出在计算逻辑、同步阻塞还是某些热点函数上，内置分析工具才是下一步真正有用的手段。
怎么选工具，结果才更有参考价值
把这几类工具放在一起看，其实可以按目标来分工：
- 需要图形化配置和更完整的测试流程，可以优先看 JMeter。
- 需要脚本化、易维护、贴近 Node.js 项目协作方式，可以用 Artillery。
- 需要快速打高并发、直接观察吞吐和延迟，可以用 wrk。
- 需要进一步定位代码热点和运行时瓶颈，就用 Node.js 自带的
--prof或--inspect。
还有一点很关键：性能测试结果是否可信，很大程度上取决于测试环境是否接近真实生产环境。压测本身会对服务造成明显压力，因此更稳妥的做法，是放在低峰时段或专门的测试环境执行，避免影响线上用户。只有测试条件和真实流量特征足够接近，最后得出的吞吐、延迟和瓶颈判断才真正有意义。
