浏览器自动化性能：大规模优化指南

当浏览器任务随着并发增加而变慢时，首先要判断瓶颈来自哪种资源或队列。BotBrowser 提供配置文件隔离和工作负载控制，但无法承诺适用于所有主机的实例数量；调整容量前，应在目标页面、路由和主机上共同测量。

摘要

• 先测量有代表性的冷启动与热运行，再设定 worker 上限。
• 找出受限资源，并为有界队列定义明确的准入与恢复规则。
• 每次只调整一项成本，再用相同工作负载和服务目标决定接受或回滚。

目录

• 先测量实际负载
• 用背压保护预算
• 一次只调整一项成本
• 用恢复证据验收版本
• BotBrowser 的适用范围
• 实践结论

先测量实际负载

浏览器自动化对内存、CPU 时间、存储和网络容量的占用比例，取决于页面本身和页面上执行的操作。一次简短的文本页面导航，与带有媒体、截图、下载或多个应用步骤的长会话，表现截然不同。因此容量规划应从真实的任务组合出发，而不是预设一个固定的实例数量目标。BotBrowser 可以在受控的测试环境中并行运行相互隔离的配置，便于你测量自己的任务组合，但不能保证在其他构建、平台或硬件上得到同样的吞吐量。

生产环境的容量取决于应用实际使用的页面、浏览器模式、会话时长、网络路由、版本、图形后端、配置文件包、主机和并发度。在调整内存、CPU、网络或生命周期设置之前，应把这些输入放在一起测量。目标是让任务稳定完成并保持一致的隐私保护，而不是追求尽可能多的 worker 数量。

性能同时也是可靠性问题。内存耗尽会让浏览器在操作途中退出，留下不完整的结果和受损的会话状态。过载的 CPU 会拖慢每个实例，使页面加载时间和超时失败增加。遗留的浏览器进程会逐渐耗尽主机资源。没有内存余量的主机可能让一次浏览器退出扩大为更大范围的服务中断，所以要为正常的负载波动和同时启动预留容量。

建立容量基线

选取一小组能代表生产环境的任务，包括一个快速页面、一个较重的页面、最长的正常会话，以及任何会捕获媒体或下载文件的工作流。在目标主机类型上，用计划使用的 BotBrowser 版本、配置文件系列、路由策略和浏览器模式运行同一组任务。

记录完成任务数、失败任务数、排队延迟、总耗时、启动耗时、内存压力、CPU 饱和度、存储活动和网络吞吐量。延迟应使用百分位数，而不是单一平均值，因为平均值会掩盖那些决定超时和排队行为的慢任务。

冷启动和热运行要分开测量。冷启动结果反映主机替换和部署恢复的情况，热运行结果反映稳定服务的情况。两者都重要，但合并成一个数字会让版本对比难以解读。

为每类工作负载保留一份书面基线。记录应标明主机类型、版本组合、配置文件系列、页面集合、路由地区、浏览器模式、测试时间窗口和结果，不应包含页面内容、凭据或个人浏览数据。

设定资源预算

先为操作系统、监控、部署活动和同时启动预留容量，剩余部分才是浏览器工作负载的预算。内存、CPU、存储和网络应作为各自独立的限制来对待，因为一个任务可能耗尽其中一项，而其他项看起来仍然正常。

内存规划应参考观察到的峰值和持续趋势。CPU 规划既要看饱和度，也要看任务延迟。存储规划应包含配置文件访问、下载、临时产物和日志。网络规划除了目标页面，还应包含获批的路由。

预算还需要容错余量。超时后立即重试的 worker 可能比原任务带来更大的压力。在批准生产上限之前，应在预发布环境的测量中包含正常重试和恢复活动。

把症状对应到能解释它的指标

症状只说明该往哪里看，不说明该改什么。下表把常见现象与能定论的指标配对，让容量评审从实测数据开始，而不是先猜主机。

症状	应读取的指标	决策
排队等待上升而 CPU 持平	p95_queue_wait 对比 completion_latency	限制来自准入策略；排队等待回落后才增加按类别的名额
常驻内存上升而 CPU 很低	各已开上下文的 rss_per_context	关闭空闲上下文或减少页面重量；瓶颈在内存而不是 CPU
CPU 贴近主机上限	cpu_saturation 与 error_rate_after_retry	降低并发，或把短会话迁到精简构建
吞吐持平但 p95 页面时间上升	按路由看 p95_page_time 与 error_rate_after_retry	单一慢依赖或慢路由；先定位该 URL 再加主机
error_rate_after_retry 随 queue_depth 上升	每个已完成任务的重试次数	背压在清理完成前就归还了容量；把重试延后

开工前先读出与事故相符的那一行。在错误的那一行上加主机只会掩盖真正的限制，既增加成本又恢复不了服务目标。

按固定顺序排查事故

把顺序写成策略，两个值班人员才会得到同一个结论：

1. 先冻结新准入，让样本在被读取时不再变化。
2. 把故障并发下的 rss_per_context 与上一个通过验收的并发下的同一值对比。数值持平且主机空闲内存低于标称值的四分之一，说明问题在主机。
3. 把 p95_queue_wait 与 completion_latency 对比。排队等待高于完成延迟而 CPU 低于标称值的二分之一，说明问题在准入策略。
4. 对比两个并发水平下的 launch_duration。启动时间随并行读取配置文件的数目一起增长，说明问题在配置文件存储。

只有第 2 步和第 4 步都持平、并且第 3 步显示等待停在队列里，才能排除主机问题。先改越过策略线的那一行；同时改两行会让事故失去责任人。四分之一和二分之一是本部署的运行策略，不是适用于所有浏览器的通用事实。

用背压保护预算

在浏览器任务前放置一个有界队列。只有当部署对某类工作负载还有容量时，才接纳新任务。队列达到上限后，按服务策略拒绝、延后或重定向任务，不要让调用方直接创建无限量的浏览器任务。

当不同工作负载的成本或服务目标差异明显时，使用独立的队列。长时间的媒体任务不应占满短应用检查所需的所有名额。按类别设置公平调度和上限，比单一的全局并发数更容易运维。

明确队列的归属。调度器应区分等待中、进行中、已完成、已取消和状态不确定的任务，这样恢复时不会悄悄重复执行任务。在队列层面设置重试上限和延迟重试，并且只在上一个会话干净关闭之后才归还容量。

背压应响应持续的证据，而不是单个噪声样本。队列延迟、任务延迟、浏览器退出、主机余量和清理完成情况合在一起，能提供有用的综合视图。当多个指标同时超出获批范围时减少准入，恢复之后再逐步放开。

在浏览器版本、主机镜像、配置文件系列、路由或工作负载发生变化后，应重新审视预算。以前的上限只是历史观察，并不意味着可以获得同样的吞吐量。重新运行基线，能让运维决策始终建立在当前证据之上。

20 个上下文通过而 40 个上下文失败的工作负载

同一台主机、同一组页面、同一个配置文件系列，可能在 20 个上下文的容量评审中通过，在 40 个时失败。失败有三类常见原因，每一类留下的指标不同。

• 主机内存。 rss_per_context 持平，但总常驻内存越过了主机空闲内存，内核开始回收页面，最慢的上下文卡住。决策是减少每台主机的上下文数或换更大的主机。
• 配置文件加载时间。 launch_duration 随并发增长，因为每个上下文在启动时都要读取自己的配置文件。本地存储和更小的配置文件集合能缩短启动路径，主机本身不是限制。
• 准入策略。 CPU 远低于上限、内存稳定，但 p95_queue_wait 持续增长。队列接纳工作的速度快于清理归还容量的速度，应拆分类别或延后重试。

在第一次卡顿后冻结准入，把 40 个上下文的场景跑一次。如果 rss_per_context 和 launch_duration 与 20 个上下文时一致，主机不是原因，修复在队列。如果两者出现偏离，先修正资源再调准入，因为策略改动无法找回已经失去的内存。

把选定的原因、两个并发水平，以及 rss_per_context、launch_duration 和 p95_queue_wait 写进该工作负载的容量决策记录，下一次评审就能从这次对比开始，而不是从空白页开始。

一次只调整一项成本

在受控的预发布工作负载中，一次只验证一项优化。把任务完成情况、浏览器退出状态、内存趋势、页面创建延迟、截图完成情况和上下文关闭，与未改动的版本配置进行对比。对比期间保持配置文件系列、网络路由、图形后端和页面集合不变。

内存与页面生命周期

把堆内存上限当作与工作负载相关的控制项。上限过低会终止正常的 JavaScript 工作，上限过大又会挤占主机余量。应在代表性工作流中测量保留的堆内存，并且只在应用负责人参与并准备好回滚方案时才修改上限。

及时关闭页面，让浏览器能释放已完成工作所占用的资源。调用 page.close() 为浏览器提供了清晰的生命周期边界，而导航到另一个 URL 并不会结束对该页面的持有。每条退出路径都要关闭浏览器本身，并借助部署层的监督进程识别无响应的 worker。

const page = await context.newPage();
try {
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  // 在这里读取工作流需要的数据。
} finally {
  await page.close();
}

当工作流只需要文档时，优先使用 domcontentloaded，而不是等待网络空闲。空闲检测在较重的页面上可能多花数秒，而 DOM 早就准备好了。导航和操作的超时应根据获批的服务目标与观察到的延迟分布来确定，并把超时当作明确的失败处理，同时保留足够的诊断信息，以区分页面延迟和资源压力。

根据观察到的生命周期证据回收浏览器实例。只有在预发布和生产趋势都表明回收能提升稳定性之后，才引入任务数或时间边界，并保持该边界可配置，每次版本变更后复查。只在页面代表同一个会话和同一个身份方案时才复用页面，当存储或配置文件状态必须隔离时，创建新的上下文。

在应用日志中记录启动完成、退出状态、stderr、任务耗时、队列延迟和上下文关闭，并用标准的操作系统工具监控主机内存。根据主机实测容量和服务目标设置告警，关注趋势，不要等到资源耗尽才发现问题。

CPU 与视频帧率

保留应用需要的浏览器功能。禁用后台行为、扩展、媒体或更新服务，可能改变页面行为和运行安全性。先从文档中的版本配置开始，只有当代表性的 QA 确认工作流不依赖某项功能后，才移除它。

根据实测的 CPU 饱和度限制并发。逐步增加 worker，同时跟踪完成的工作、浏览器错误、排队时间和主机余量。截图、媒体、复杂 JavaScript 和 Canvas 工作负载需要不同的上限，因此通用的每核实例数比例并不可靠。

当不需要完整的视觉播放时，可以降低视频帧率。视频较多的页面即使自动化只需要偶尔的画面更新，也会持续占用解码和渲染资源。对于启用了 Video FPS Control 的配置文件，--bot-video-fps 会单独设置实际视频帧率，与页面看到的媒体 FPS 报告值分开。

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --bot-video-fps=1:30 \
  --headless

把它用于视频密集的监控、QA 或长时间运行的页面，前提是逐帧的视频像素不属于结果的一部分。语法请参阅 Video FPS Control，所测试的工作负载请参阅基准测试。基准测试中的 CPU 降幅只是某一个视频工作负载的参考范围，不是容量承诺，也不是通过或失败的界限。

按工作负载类别区分，而不是对所有页面使用同一个全局值。以视频为主要内容的页面通常需要正常帧率，而只在后台保留视频元素的页面往往不需要。在同一台主机上，用同一组页面和同样的并发度，对比修改前后的 CPU，并让采样窗口足够长，覆盖稳定播放阶段，而不仅仅是页面启动。

还要检查对工作流真正重要的输出类型。DOM 提取、API 捕获、截图和像素级媒体检查对较低视觉帧率的容忍度各不相同，像素输出会跟随实际帧率。把这项设置放在启动配置文件或任务定义旁边，让下一位运维人员能看出哪些任务使用了较低的媒体帧率，并把它与显示 FPS 控制区分开。

网络与存储

屏蔽不必要的媒体可以减少网络和渲染工作。保留应用在布局、交互、认证和隐私验证中需要的资源，并用代表性页面测试每一条屏蔽规则。当文字渲染很重要时，保留样式表和字体。

当路由带宽有限时，选择性路由可以让指定的请求路径不经过代理。规则语法及所需的许可请参阅 Proxy Selective Routing。匹配的请求会直接连接，所以应在获批的网络策略下决定哪些资源可以不经过代理路由，并在凭据、地区或出口变化时重复验证路由。

代理会给它承载的每个请求增加网络延迟。基准测试期间保持路由稳定，并在更改出口地区前比较 p95 request latency。

把配置文件包放在高速本地存储上，而不是网络挂载的卷上。配置文件只在启动时加载一次，它的相对成本取决于完整的启动流程。对于经常重启实例的部署，本地存储可以减少启动路径上与网络相关的延迟。

图形与无界面主机

增加容量能提供有用的余量，但不能修复无界队列、不完整的清理或不合适的图形后端。在增加主机之前先测量工作负载，只有当队列和清理已经验证无误、持续的工作负载仍无法满足服务目标时，才增加容量。

无头模式可以减少一部分窗口系统的工作，但页面仍然要使用图形、网络、JavaScript 和存储资源，所以应把差异视为取决于工作负载。保持图形支持开启，因为移除它可能改变依赖 WebGL 或 WebGPU 的工作负载的渲染能力。

当部署环境没有物理显示器时，请参阅 Linux GPU 后端指南。在 Linux 上，让可比较的 worker 使用一致的图形后端。移除必需浏览器能力的改动，不算有效的性能改进。

用恢复证据验收版本

比较代表性的运行阶段

候选版本应使用相同的工作负载类别和主机镜像，与获批的基线对比测量。冷启动、热稳态工作和受控关闭应作为独立的阶段。冷启动说明新 worker 能否可预期地投入服务。稳态阶段说明缓存和连接稳定之后，队列延迟和资源使用是否保持稳定。关闭阶段说明在任务完成、取消和失败之后，容量是否能够归还。

每个阶段要运行足够长的时间，才能暴露页面响应和路由延迟的正常波动。应比较完成时间和队列延迟的分布，并结合持续的内存压力、CPU 争用、存储活动和网络使用。把 p95 queue delay 与完成延迟并列，避免 worker 变快掩盖准入等待增长。简短的成功运行对基本兼容性有用，但不足以批准生产资源预算。

记录做出决策所用的工作负载组合，包括普通任务、支持的最长会话和一个经授权的失败场景。这样当应用、路由、主机镜像或浏览器版本日后变化时，验收记录依然有用。

采用明确的验收标准

版本验收应回答：服务是否在保留运行余量的同时完成了所需的工作。应把成功完成情况、预期的错误处理、队列增长、清理完成情况和恢复时间放在一起评审。不能仅仅因为最快的任务变快了，而较重的任务变得不够可靠，就让版本通过。把 SLO 与测量窗口一并写入验收记录。

以现有的服务目标作为决策边界。如果没有正式的目标，就在对比候选版本之前，先根据当前获批的版本建立一个。记录任何有意的权衡，例如以小幅增加延迟换取更低的持续内存压力，并获得应用负责人的批准。

在同一份验收计划中包含隐私和功能检查。即使主机利用率下降，只要节省资源的改动移除了必需的渲染、存储、媒体或网络行为，就属于回归。只有当代表性工作流仍能产生经授权的结果时，性能证据才能支持发布；恢复观测同时记录 queue depth。

演练背压与恢复

验收测试应包含一段到达量超过可用服务能力的时期。确认有界队列执行了预期的准入策略，保护了正在进行的工作，并在需求回落后恢复到正常范围。观察重试是否按策略延后，而不是立刻增加更多压力。

同时还要测试一次受控的 worker 中断。监督进程应识别出不可用的 worker，保留清晰的任务结果，并且只在有容量时才接纳替代任务。已完成的工作不得被悄悄重复，状态不确定的工作应遵循应用的对账策略。

中断之后，验证内存、存储活动、队列延迟和完成延迟是否恢复到获批的运行范围。服务在清理尚未完成时就恢复接收任务，说明还没有完全恢复。在证据表明任务流和主机余量都稳定之前，保持较低的准入。

保留回滚证据

每项性能改动都需要一个回滚条件和一位负责人。条件可以是队列持续增长、完成可靠性下降、清理不完整，或失去恢复余量。应在上线前就定义好，这样决策就不必依赖事故中临时的解读。

为候选版本和获批基线都保留版本标识、主机镜像、工作负载清单、路由类别、配置记录、观察窗口和汇总结果。把候选与基线的 release_id 和观察窗口对应保存。日志按组织的保留和访问策略存放，并从记录中删除凭据、页面内容和个人数据。

在分阶段发布期间，只有上一阶段在足够长的观察窗口内满足验收标准，才继续扩大范围。如果出现回滚条件，应停止继续扩大，减少准入，完成或对账已接纳的工作，并恢复到最近一次获批的配置。回滚之后要重复代表性基线测试，确认恢复已经完成，而不是假定切换版本就足够了。

BotBrowser 的适用范围

对于视频较多的会话，BotBrowser 支持 --bot-video-fps（ENT Tier2，适用于启用了 Video FPS Control 的配置文件），它会降低实际的视频解码和渲染帧率，同时单独设置媒体 FPS 的报告值。在不需要完整视觉帧率的场景下，这可以减少 CPU 占用，因此值得把它作为上述计划中的一项受控改动来测试。BotBrowser 不能保证每种工作负载都能节省 CPU 或达到某个容量数字，不能替代由运维方负责的容量基线、排队、背压和清理，也不能在降低实际帧率之后保留逐帧的像素输出。当工作流需要采样视频像素时，请调高实际值。

对于要评估按上下文工作流的部署，Per-Context Fingerprint（ENT Tier3）是依赖许可的可选方案，应使用与现有拓扑相同的授权工作负载和隐私要求来做基准测试。把结果视为特定工作负载的证据，而不是通用的容量承诺。BotBrowser 不设置主机容量、队列策略、代理性能或页面行为，这些决定仍由应用负责人做出。

下载 BotBrowser 准备部署，或联系我们的企业团队进行基础设施规划。实现细节可参考 Headless 服务器设置、Docker 部署指南、CLI 配方和截图最佳实践。

当页面除了主机容量还要选择队列提示时，scheduler.postTask 优先级提供取消与回退记录，让这个边界保持清晰。

公开来源

• BotBrowser FPS Control
• BotBrowser 基准测试
• BotBrowser Proxy Selective Routing
• BotBrowser Linux GPU Backend
• Playwright Page API

实践结论

先建立包含队列延迟、完成延迟、资源压力和清理情况的工作负载基线。依据这些数据设置有界准入策略，每次只调整一项成本，并保留上一版配置；只有同一组代表性任务在发布后仍满足服务目标，才扩大使用范围。