大多数企业负载测试起始于会议上有人提出的一个数字。五千虚拟用户。 一万虚拟用户。测试通过，报告归档，但应用程序仍然在季度的第一个星期一崩溃。
圆整的数字容易达成共识，但几乎一无所知。真实流量是突发性的，功能之间分布不均，而且在流量峰值时刻组合发生变化。一个发送一成不变、相同请求的测试会调用与生产环境不同的代码路径，缓存行为、查询计划和锁竞争都与实际系统无关。
以下是如何利用已有数据构建流量模型，以及怎样运行测试使结果有实际意义。
目录
- 是什么让企业流量难以伪造
- 流量数据通常存在哪里
- 如何从生产数据构建流量模型
- 流量模型出错的地方
- 真实企业流量模式长什么样
- 如何在 LoadView 中运行模型
- 如何将模型与生产环境对比验证
- 总结
- 常见问题解答
是什么让企业流量难以伪造
有三点会让团队在直接以用户数进行测试时踩坑。
**并发数和到达率不是同一个数字。**当利益相关者说“我们需要支持 5,000 用户”，请问他们指哪个。五千人同时登录与五千次会话每小时启动是完全不同的测试。错估成偏大的情况会浪费数周去调优永远不会达到的负载，错估成偏小的测试结果则毫无意义。并发用户测试只有在你明确是哪一个数字时才有意义。这是基于到达率模型（反映用户实际出现方式）与并发模型（维持固定用户数）之间的区别。面向公共的流量几乎总是前者。有边界用户群的系统——呼叫中心桌面、许可席位、代理门户——确实表现为后者。
**流量有自己的形态，形态决定破坏力。**连接池、自动扩展组和即时预热应用服务器都响应变化率而非仅仅是峰值容量。一个能轻松处理 2,000 并发用户的系统，若在九十秒内达到峰值，途中也可能崩溃。
**事务组合随流量变化而移动。**正常流量时，电商网站主要是浏览行为。闪购期间，结账和库存调用在相同请求数中占比大幅上升。仪表盘上总数看起来一样，但数据库负载却大不相同。
平坦的虚拟用户数和有形态的到达曲线可以产生相同的平均吞吐量，但会压力完全不同的堆栈部分。
流量数据通常存在哪里
你不需要新的监控手段。大部分数据已经在某处写入磁盘。工作重点是将日志拼接成会话，并在统计之前过滤掉机器人流量。
来源 | 要提取的数据 |
|---|---|
Web 服务器和负载均衡器访问日志 | 按端点的每秒请求数，状态码分布，最繁忙时段的实际时间戳 |
APM 或真实用户监控（Dynatrace，Datadog，New Relic） | 会话时长，页面间时延，交互间的实际思考时间 |
Web 分析（GA4 导出，Adobe Analytics） | 每小时会话数，设备和浏览器分布，地理位置，入口页面 |
CDN 日志（CloudFront，Fastly，Akamai） | 缓存命中率，源站卸载率，哪些资源未命中 |
身份提供商或单点登录日志（Okta，Entra ID） | 登录率和会话并发，通常是内部应用唯一可用信号 |
批处理调度器和数据库 | 峰值时段还有哪些其他任务在运行 |
内部企业应用通常根本没有分析标签。认证日志和应用服务器日志填补了这一空白——登录事件提供到达率，单个会话的首次和最后请求之间的时间则给出持续时长。
如何从生产数据构建流量模型
模型由四个输出定义：到达率、事务组合、思考时间分布和地理分布。
步骤 1：选择你要建模的精确时间窗口
不是“峰值流量”，而是某个具体日期的某个具体小时，从你的日志中提取。选择过去十二个月中最高吞吐量的一小时，再选择一个覆盖你最糟糕业务事件的时段——月末结账、开放注册、黑色星期五、季度报告。两个窗口都要建模，它们的形态几乎从不相同。
步骤 2：统计会话数，而非请求数
每秒请求数是最容易提取但最不稳定的数字。发布一个前端版本，将三个 API 调用捆绑成一个，请求数大减三分之一，实际需求毫无变化。每小时会话数跟踪用户实际行为。在单页面应用中差异最大，一次点击可能触发十几个后台 API 调用。
提取窗口内每小时会话数，以及平均和第 90 百分位会话时长。保留两个数字，尾部时长在步骤三中至关重要。
步骤 3：将会话转换为并发数
利用小律连接到达率和并发数：
并发会话数 = 每小时会话数 ×（平均会话分钟数 ÷ 60）
18,000 会话/小时 ×（6 分钟 ÷ 60）= 1,800 并发会话
针对该应用运行 18,000 并发虚拟用户，测试的是比实际峰值大十倍的负载。你可能会因为达标的测试失败，然后浪费一整个迭代去追查生产场景绝不会遇到的瓶颈。
小律用的是均值，所以将 P90 作为单独的容量检测，而非公式的第二读数。以 6 分钟均值和 22 分钟 P90 输入，得出大约 6,600 并发数——假设所有会话都达到最慢10%的时长。这个数字偏保守，是进行容量规划时的重要参数，尤其当长会话占用稀缺资源如报告线程或数据库连接时。
步骤 4：将流量分解为业务事务
将端点分组为业务事务，而非按 URL 统计：搜索、查看详情、加入购物车、提交索赔、导出报告、运行工资单。然后记录两套组合——整小时内每个事务占比及峰值一分钟内的占比。
如果任一事务的两套组合差距超过几个百分点，就要在测试中同时纳入并分别运行两个场景。仅用小时粒度组合构建测试会导致峰值时某个急剧上升的事务承载不足。
步骤 5：从真实会话中提取思考时间
不要猜测思考时间，也不要用固定值。固定五秒的暂停会将所有虚拟用户同步成行进队伍，导致测试请求成锁步同时涌入，产生真实用户群永远不会出现的尖峰吞吐量。
利用 RUM 或 APM 数据提取真实会话内连续页面加载间隔，重现为分布。企业用户思考时间往往是双峰的：操作熟悉时短间隔，阅读文档或接电话时长间隔。
步骤 6：将负载增长曲线匹配为真实曲线
绘制窗口内每分钟会话数，塑形测试负载曲线以匹配。三种形态覆盖大多数企业应用：
- **近垂直。**产品发布、票务开售、市场开盘。峰值并发在两分钟内达成。
- **阶梯式。**内部应用按时区在早上9点逐个上班，每个区域形成一步。
- **方波式。**批处理和集成流量。全量开启，全量关闭，无平滑渐变。
步骤 7：将负载放置在用户所在地区
根据分析或 CDN 日志中的地理分布，从相同区域发起负载。这不仅是为了测量远程用户的延迟。延迟反过来影响并发数：280 毫秒的往返比 20 毫秒长，会话持续更久，相同到达率产生更高并发。仅从一个地区测试将完全掩盖这一点。
流量模型出错的地方
**每个虚拟用户对应唯一数据集。**十万个用户如果登录账号、产品 ID、账户号相同，缓存命中率几乎达到 100%。生产环境并不会这样。使用足够宽泛的数据集参数化——账户池、SKU 列表、每次运行唯一订单 ID——测试前先将测试缓存命中率与生产进行对比，再信任结果。
**峰值期间没有额外负载。**企业峰值常与预定工作重合：夜间ETL、索引重建、报告生成、备份窗口、复制追赶。若校验作业与批处理集成峰值皆在凌晨2点，且无背景负载的干净测试环境无法复现真实系统表现。
**协议级测试针对浏览器密集型应用不适用。**HTTP 级别测试仅重放录制期间请求，无法执行 JavaScript、触发懒加载调用或运行第三方标签。对单页面应用或复杂内部门户，客户机所做的大部分工作以及决定用户看到内容的交互都被忽略。真实浏览器 Web 应用负载测试是测量负载下客户端渲染的唯一途径。
**仅测试“理想路径”。**真实流量包括遗弃购物车、后退循环、登录失败、过期令牌、烦躁的双击。登录失败值得设置独立场景：它们触及身份提供商，通常绕过缓存，并往往触发加写锁定逻辑。
真实企业流量模式长什么样
三种常见模式，以及每种对模型的要求。
零售闪购或新品发布
到达呈近垂直趋势，组合压缩为三个事务：产品详情、添加购物车、结账。若产品页面可缓存，CDN 命中率会提升，因为所有人请求相同的爆款商品，使得简单测试看似容易。压力落在不可缓存的调用上——库存检查、购物车写入、支付授权——同时冲击原点，单SKU产生行级锁竞争。建模时应用峰值分钟的组合，而非整小时。
内部 ERP 的月末结账
会话量平淡，会话时长却不平凡。报告导出和批量过帐运行数分钟，会话并发攀升，尽管到达率看似平稳——小律对你不利。此外还叠加在会计结账批处理上，背景负载成为测试一部分。长会话报告和过帐用户拆为单独事务类别并单独定义时长，而非折叠为单一均值。
保险开放注册
数周的高负载，最后两天高峰猛增。会话运行长时间，因为用户阅读计划文件，认证和下载请求密集。数周阶段为耐力测试，内存泄露、连接池耗尽和日志量比峰值并发更关键。高峰两天需单独建模。
如何在 LoadView 中运行模型
模型一旦建立，测试设置随之而来。LoadView 提供三种负载曲线，模型会告诉你选哪个：
负载曲线 | 当你的模型说明 |
|---|---|
Load Step Curve | 你有目标并发数，想观察响应时间随增加变化 |
Goal-based Curve | 你的模型表达为吞吐量——每间隔的事务或会话数——或正验证 SLA |
Dynamic Adjustable Curve | 你想在测试过程中变更负载和区域分布，以找出系统临界点 |
使用EveryStep Web Recorder录制会话流程，使脚本在真实浏览器中按照用户路径执行，覆盖分析中显示的桌面和移动浏览器。使用地理分布负载注入网络设定区域分布，与模型第七步匹配。
对于从不访问公共互联网的应用，使用本地注入器在防火墙内进行负载测试并报告到同一平台——这也是多数内部 ERP 和门户流量建模的方式。
如何将模型与生产环境对比验证
流量模型只是一个假设，除非你将其输出与真实情况比对。测试运行时抓取后端指标——数据库等待事件、连接池饱和度、队列深度、自动扩展活动、CDN 源请求率、身份提供商限流。这些信号能解释以下指标含义。
测试结束后，将以下五项指标与同期生产环境进行对比：
- **每事务吞吐量。**测试吞吐量远低于相同用户数的生产值时，思考时间过长或脚本遗漏调用。
- **事务组合百分比。**偏差说明脚本中的分支逻辑与用户行为不符。
- **缓存命中率。**测试为 95%，生产为 70%，说明数据集过窄。
- **错误率及类型。**生产环境几乎总有基线错误率，测试0错误往往意味着遗漏了部分场景。
- **平均会话时长。**验证第三步中并发计算的正确性。
然后根据这五项分析负载测试结果，调整脚本重测。两次迭代通常足以达到可信赖的模型。
常见问题解答
我实际上需要多少虚拟用户？
根据每小时会话数和平均会话时长计算，而非选定一个整数。处理 18,000 会话/小时且平均会话时长为六分钟的系统，其并发会话数约为 1,800，不是 18,000。对你的 P90 会话时长做相同计算，可获得用于容量规划的保守估计。
我可以直接重放生产流量，而不是建模吗？
重放适合验证你已构建的模型。单独用重放有严重局限：录制流量含需清洗的个人数据，会话令牌过期，且不可信地重复执行状态写操作。且无法超过录制时流量，这是你最需要测试的扩容边界。
流量模型多久重建一次？
每次发布影响前端或用户流程时，每次业务改变导致事务组合变化时，以及已知高负载事件前。对稳定应用，季度重建是合理底线。
我该做协议层测试还是用真实浏览器测试？
两者回答不同的问题。协议级测试每虚拟用户成本低，适合测后端和 API 容量。真实浏览器测试执行 JavaScript、懒加载调用和第三方标签，是测量单页应用客户端负载体验的唯一方式。多数企业项目两者兼顾。
我的内部应用没有分析数据怎么办？
用认证日志获取登录率和会话时长，用应用服务器日志获取各端点请求量，用批处理调度器监控峰值期间其他运行任务。内部应用很少带分析标签，但总有认证和服务器日志。
总结
真实流量模式由四个指标组成，而非一个数字：会话到达速度、会话行为、用户操作间的思考时长和连接地理位置。所有数据都已在你的日志中。
提取这四项，通过小律计算出可数据支持的并发数，塑造一个真实时段的负载曲线而非直线。然后与生产环境结果比较，调整模型。虽然比直接选个整数更费力，但这是你能够真正依赖、付诸行动的测试方式。
在真实浏览器中测试你的流量模型
LoadView 在 40 多个 AWS 和 Azure 区域的真实浏览器中运行你的会话流程，支持你根据测量的到达模式塑造负载曲线。企业负载测试方案提供子账户、单点登录及从遗留工具迁移脚本。
预约演示，与 LoadView 性能工程师一起深入你的流量模型。