如果你曾经为了回答“压测到底该跑多少虚拟用户”这种问题，花上整整两天时间从APM工具里导出数据、清洗CSV、旋转透视表，那这篇教程就是为你准备的。

它的目标很明确：让你直接从生产环境的遥测数据里，推导出工作负载模型需要的每一个数字，耗时不超过五分钟，中间没有任何需要“凭经验猜”的环节。

打开网易新闻 查看精彩图片

每到黑五，整个团队都在重复同一个噩梦

每年黑五前几周，性能工程师和SRE都会撞上同一块铁板：有人需要一份峰值季压测用的工作负载模型，而时间正一分一秒地溜走。

常规做法是登录APM工具，导出CSV文件，在电子表格里做数据透视，再对用户流程做各种“合理推测”。整个过程要牵扯好几个人，花上好几天，最后拿出来的模型还常常是错的。

这套手动流程到底有多折腾？光是在APM里抓数据、整理再校验，就要耗掉13到22个小时。这还没算上反复的评审、等待权限审批，以及那种“日期范围搞错了，全部推倒重来”的经典时刻。现实中，绝大多数团队几乎会花掉整整一个冲刺迭代周去搭建一个工作负载模型，然后在上线压测时发现：场景权重还是不对。

比工时浪费更危险的，是业务风险。低估峰值流量会导致资源预备不足；用错误的用户旅程假设建模，会把压测容量全浪费在低影响流程上。这两种结果都意味着，黑五的备战是建立在猜测上的，而且这个风险要到最糟糕的时刻才会暴雷。

自动化方法：把两天压缩到五分钟

本文要讲的方法，就是用直接的观测性查询，换掉那一整条手动流水线。我会用New Relic（NRQL）和Dynatrace（USQL）一步步演示，但思路适用于任何能暴露会话和事务数据的APM平台。

我还用Java Spring Boot搭了一个叫Peak Workload Analyzer的小工具，如果你不想自己写查询，它可以直接把所有查询跑完并给出结果。

在动手之前，你需要备好几样东西：一个已经为应用开启了浏览器或APM检测的New Relic或Dynatrace账户；Java 11以上环境；Maven 3.6以上；以及至少30天的生产流量历史窗口，其中必须覆盖一个已知的峰值期，比如去年的黑五。

先搞懂两个关键概念

整篇教程会反复出现两个度量：

每秒请求数（RPS）：应用在一秒内收到的HTTP请求数。这是你压测时最主要的目标指标。

会话（Session）：单个用户从进入应用到离开所经历的完整连续访问。会话数量和时长，是构建并发用户公式的基础。

一旦你把RPS和会话的关系理清，虚拟用户所需的那几个数字就不再是拍脑袋的产物，而是从生产遥测里直接拉出来的铁数据。

通过直接对接APM的数据接口，整个工作负载建模可以在几分钟内跑完，而且每一步都可复现、可追溯。下一篇我将继续拆解具体的NRQL和USQL查询构建，以及如何用这些查询把你的第一次自动化压测模型真正跑起来。