BrowserContext 内存与长期会话容量规划

BrowserContext 允许在共享浏览器启动开销的同时隔离存储和会话状态。每个活动上下文都会消耗资源。浏览器版本、宿主镜像、页面或配置文件策略变化后，资源增长斜率也可能改变。容量规划应测量完整浏览器组，而不是沿用旧的上下文上限。

BrowserContext 只是在共享浏览器基础设施中隔离存储和会话状态，不是操作系统、进程或安全边界。需要这些边界时，应使用独立浏览器或宿主。

BotBrowser 支持 ENT Tier 3 Per-Context Fingerprint，可在一个浏览器进程中的多个 BrowserContext 分配独立配置文件（按上下文隔离与已发布的基准测试）。这些基准只描述其中列明的测试配置，既不保证其他宿主、工作负载、配置文件或生命周期下的容量，也不提供适用于所有环境的安全上下文数量。设置准入上限前仍须测量完整浏览器组。

摘要

• 在目标浏览器版本、配置文件、宿主和代表性工作负载下测量完整浏览器组；其他环境的上下文数量不能直接当作容量上限。
• 准入上限应设在最高可重复运行点或更低，同时为关闭中的上下文、浏览器任务和宿主服务留出余量。
• 分别观察创建、稳定运行、空闲、关闭和恢复阶段；关闭上下文不代表内存会立即回到基线。
• 余量耗尽时暂停准入。浏览器组恢复或还原到已接受版本后，先确认余量确已恢复，再恢复准入。

目录

• 定义发布单元和工作负载
• 测量整个浏览器组的容量曲线
• 设置可逆的准入和队列边界
• 运行、恢复和回滚
• 记录决策、交接并重新验证
• 实践结论

定义发布单元和工作负载

建立可重复的工作负载

选择一小组能代表服务的工作负载。文档流程、表单流程、图形密集型页面和后台任务可能呈现不同的内存增长斜率。使用合成值和受控目标。测试是为了运行页面生命周期，而不是重放客户的私有数据。

为每种工作负载命名并记录修订版。记录会话如何开始、执行什么操作、怎样完成，以及何时关闭上下文。已接受版本和候选版本必须运行相同修订版的流程。如果应用发生变化，应先更新流程，再比较浏览器版本。

每轮测试都用相同方式预热浏览器。有些部署先创建浏览器组，再逐步接入上下文；另一些部署则在打开首个页面前创建固定规模的组。选择与实际服务一致的模式并保持不变。冷启动和预热组的结果回答的是不同的容量问题。

将每次流程的 workloadRevision 和 activeContextCount 写入记录，确保候选版本与已接受版本使用同一测试条件。

先分类工作负载，再统计上下文

容量规划应从工作负载类别开始，而不是从一个醒目的总数开始。文本流程、图片丰富的页面、媒体页面和图形密集型报告可能有截然不同的内存与延迟曲线。给类别命名，选择代表性流程，并在记录中明确预期的完成状态。

每类工作负载都要区分创建、活动使用、空闲和关闭阶段。创建阶段反映启动开销；活动使用显示真实页面所需的资源；空闲时间会暴露保留状态；关闭阶段则用于确认会话结束后资源是否归还。只看活动数量，会漏掉可能主导长期服务的生命周期工作。

比较冷启动和预热状态

分别测量冷启动的浏览器组，以及已完成一次代表性流程的预热组。冷启动结果有助于规划启动行为，预热结果有助于规划稳定运行。浏览器、配置文件、宿主、路由、存储和图形策略保持一致，才能把差异归因于生命周期状态，而不是环境变化。

如果服务会复用上下文，记录复用规则和有意保留的状态；如果会关闭上下文，记录关闭操作及确认恢复所用的观察期。没有存储规则的复用策略可能让无关任务之间泄漏状态；过于频繁的关闭则可能把容量消耗在反复启动上。

记录宿主和容器条件

相同的浏览器和配置文件在更大的宿主、更小的容器，或采用不同图形策略的宿主上，表现可能不同。把宿主类别、容器限制、路由、存储、扩展和显示模式与上下文数量一并记录。这样审核者才能判断旧容量记录是否仍然适用。关于 Linux x64 上构建版本选择与宿主资源的关系，可参阅 Linux x64 上如何选择 Standard 与 Trimmed Build。

迁移到新的宿主类别时，重新进行冷启动和预热观察。不要用简单算术放大容量建议。浏览器共享开销、页面组成和生命周期时序都会改变曲线形状。带有余量且实际测过的较小运行点，比未经验证的较大数字更有用。

测量整个浏览器组的容量曲线

测量完整浏览器组

先记录发布信息：浏览器版本、配置文件系列、宿主类别、容器限制、路由策略、存储策略和代表性工作负载。在创建上下文前测量浏览器组，然后在多个活动上下文数量下重复测量。覆盖创建、稳定运行、空闲和关闭阶段。

有用的结果不是一个通用数字，而是适用于指定发布版本和工作负载的容量曲线：

• 创建首个上下文前的基线内存。
• 上下文活动期间的内存增量。
• 并发增加时的创建延迟。
• 上下文关闭后的资源恢复。
• 清理完成后宿主剩余的余量。

读取内存曲线

至少测量三个上下文数量。仅比较基线和最大值，可能看不到阶跃变化、平台期或清理延迟。每个测量点都记录上下文数量、已用内存、可用内存、创建延迟、页面完成情况、关闭延迟和关闭后的恢复结果。

当斜率大致稳定时，趋势有参考价值，但不要假定增长必然线性。页面可能在上下文启动后才加载 Worker 或媒体资源；浏览器版本也可能在跨过资源边界时增加共享进程。运行上限应为这些变化以及已在处理的工作预留空间。

应整体观察浏览器组。单个上下文的数据可能漏掉浏览器进程、共享内存、图形缓冲区、网络池，以及宿主或容器开销。容量属于运维实际能够暂停并排空的整个组。

选择有用的测量点

测量点应对应实际运行决策。小规模组能显示启动行为，中等规模组能反映正常队列，更大的组能揭示创建延迟、内存压力或清理何时改变趋势。宿主达到不安全状态前就应停止，并记录停止原因。

测量的用途是让下一步决策更明确。如果浏览器组离上限还很远，可以接入下一个有界批次；如果恢复变慢，应暂停并排空组；如果结果不稳定，应在改变工作负载前，用已接受版本重复同一测量点。

计入浏览器和宿主的额外开销

上下文内存只是整个浏览器组的一部分。浏览器进程、共享内存、图形缓冲区、网络池、文件描述符、磁盘活动和宿主服务都需要资源。按单个上下文估算可能显得安全，但整个浏览器组已经接近运行边界。

在记录中保留宿主和容器限制。更大的宿主可能支持不同的运行点，但不会让某个特定版本的结果变成通用结论。宿主扩容或容器限制改变后，重新测量曲线。

对比轻量页面和代表性页面

轻量页面可显示启动基线；代表性页面则能显示生产实际需要的资源。服务同时支持两类工作时，应保留两者的测量结果。不能因为轻量页面测得的上下文上限较高，就把它直接用于媒体或图形工作负载，后者需要单独测量。

每类工作负载都记录同一组字段：浏览器和配置文件、宿主、路由、存储、扩展、图形策略、活动上下文数量、内存、延迟、完成情况、关闭行为和恢复情况。不要把敏感页面细节写入共享摘要，但应保留足够的运行信息以便比较曲线。

运行验收检查

请在自己的环境中运行这些通过或失败检查，并为每项保留记录。只有检查 1、2 和 4 到 7 全部通过，才接受某个容量。

1. 基线：在未打开任何上下文时，记录宿主内存、宿主 CPU 和浏览器组内存。基线已记录且多次读数可重复，则通过。
2. 阶梯测试：至少分三档提高活动上下文数量。每一档先保持稳定使用和一段空闲时间，再记录 activeContextCount、groupMemory、creationLatency 和错误数。该档处于你自己的延迟和错误预算内，且宿主仍有余量，则通过。
3. 接受的容量：记录为检查 2 通过的最高一档，并把准入上限设在该值或更低。
4. 关闭后恢复：打开并关闭上下文 N 个循环，N 要大到足以显示趋势。内存稳定在基线附近，且不随循环单调增长，则通过。关闭不一定归还全部内存，因此要解释残余差值，而不是默认它无害。
5. 排队请求：把组填满到上限，再提交一个请求。它在声明的等待时间内被准入，或被拒绝或延后并向组负责人发出清晰信号，则通过。
6. 暂停与恢复：让组越过其暂停边界。准入暂停，并且只在余量恢复后才恢复，则通过。
7. 重新运行：在浏览器更新、配置文件刷新、宿主或容器变更、页面修订或生命周期变更之后，重复检查 1 到 6。

设置可逆的准入和队列边界

设置带有余量的预算

预算应写明正常运行上限、暂停边界、恢复边界，以及有权调整这些设置的负责人。预留足够资源，以容纳正在关闭的上下文、重启中的浏览器进程，以及部署所需的宿主服务。

不要只根据可用内存推导上限。CPU、文件描述符、共享内存、网络连接、磁盘空间和页面响应时间都可能先成为瓶颈。记录触发暂停准入的指标，以及用于解释达到上限原因的指标。

宿主扩容后重新评估预算。增加内存并不自动意味着旧浏览器版本或页面工作负载可以安全地提高并发。重新运行同一条容量曲线，再由负责人根据结果调整上限并设定回滚条件。

观察队列状态

队列状态清晰可见时，准入控制更容易运行。记录排队任务、活动上下文、已完成任务、最早任务的 queueAge，以及触及暂停点时采取的操作。有界队列可以拒绝或延后新任务，同时让活动会话安全完成。

不要让重试循环掩盖已满的浏览器组。反复创建失败意味着应暂停或排空，而不是继续创建更多工作。记录恢复操作，并让负责该组的运维人员能够执行。

让准入操作可逆

准入控制应有明确负责人，并能通过可逆操作调整。浏览器组达到批准的运行点时，暂停新任务或将其延后到有界队列。让活动流程完成，然后观察内存和延迟是否恢复。不要用重试或无界队列掩盖组已满的事实。

恢复记录应说明运维人员采取了什么操作、完成了哪些任务，以及队列排空后有什么变化。如果资源没有恢复，应保留已接受的基线，并一次检查一种工作负载。在不了解恢复行为前提高并发，只会让下一次测量更难解释。

仅在需要时拆分工作负载组

只有工作负载确实具有不同的运行边界或恢复路径时，才分组。媒体流程可能需要不同于纯文本任务的限制；移动端目标可能需要不同的宿主类别。组的数量应便于运维人员理解各自的预算。

每组都需要名称、工作负载类别、浏览器和配置文件组合、宿主类别、路由与存储策略、准入负责人、已接受上限、暂停边界、恢复规则和回滚包。没有负责人的组就不是可执行的运行边界。

运行、恢复和回滚

覆盖完整生命周期阶段

创建、稳定运行、空闲和关闭阶段的资源形态不同。即使稳定运行时内存可接受，快速创建大量上下文的服务仍可能需要创建速率限制。会话持续数小时的服务，需要在较长空闲期后检查恢复情况。

将每次观测标记为 lifecyclePhase（创建、活动、空闲或关闭），并在排空后记录 recoveryResult，避免混合解释不同阶段的数据。

按支持的生命周期关闭上下文，并等待正常清理信号后再打开下一组进行测试。记录内存是否回到预期范围。如果没有，不要马上把差异归为容量问题，应先检查页面工作负载、下载、媒体、Worker 和扩展。

准入控制应为清理留出空间。暂停新任务可让活动会话完成，也让浏览器有时间释放资源。宿主承压时若重试循环继续创建上下文，原本可恢复的情况可能变成故障。

运行长期浏览器组

长期运行的组需要与服务时长相匹配的观察窗口。监测活动上下文数量、组内存、可用内存、创建延迟、关闭延迟、队列等待时间、完成任务数，以及排空后的恢复情况。使用聚合值，不要记录私有页面内容。

指标越过暂停边界时，先停止接入新任务。让安全的任务完成，按策略排空上下文；若候选版本无法恢复，则还原已接受版本。记录浏览器组是否回到原来的范围。若没有，应保持暂停，在提升版本前检查工作负载或宿主。

检查关闭与复用决策

有些服务每项任务结束后都会关闭上下文；另一些服务会在受控会话中复用上下文。测量服务实际采用的生命周期。复用可以减少启动开销，但需要明确存储和会话策略。关闭可以减少保留状态，却会增加创建成本。

正确选择取决于应用和隐私策略，并应记录在容量记录中。复用上下文若改变了预期状态，就不要把它用于无关任务。关闭上下文后资源若没有恢复，应暂停准入并检查工作负载，再考虑提高并发。

记录决策、交接并重新验证

比较浏览器和配置文件变更

即使页面看起来正常，浏览器维护版本也可能改变内存、启动、进程布局或关闭行为。配置文件刷新也可能改变图形、语言、存储或权限，从而改变页面工作负载。首次比较时应把这些变化分开。

浏览器版本应与匹配的配置文件包配对。固定宿主类别、路由策略、存储策略、扩展和工作负载修订版。先测已接受组合，再测候选组合。如果候选版本需要临时缓解措施，记录原因、测得的效果及移除条件。

只发布有用的容量信息

分享容量结果时，应提供汇总测量数据，不包含客户宿主详情、私有内存样本、内部进程名称或容易被误认为通用上限的数字。应测量自身部署所用的浏览器版本、配置文件、宿主和工作负载。

容量记录模板

每个浏览器版本和工作负载类别保留一份记录，包括准确的浏览器构建版本、配置文件系列、目标平台、宿主内存、容器限制、显示与图形策略、路由与存储策略、已接受运行上限、回滚条件和负责人。工作负载与生命周期测量项如下：

字段	记录内容
workloadRevision	比较时使用的固定流程修订版
activeContextCount	每个测量档位同时活动的上下文数
groupMemory	每个测量点的浏览器组内存
creationLatency	每档的上下文创建延迟
closeLatency	关闭延迟及关闭后的资源恢复
lifecyclePhase	创建、活动、空闲或关闭阶段
queueAge	决策时最早排队请求的等待时间
recoveryResult	浏览器组是否回到已接受的运行范围

浏览器、宿主、配置文件、页面、扩展、图形或网络发生变化后，重新打开记录。容量规划是持续的发布控制，不是一次性基准测试。

让容量建议随版本更新

容量数字只适用于对应的浏览器版本、配置文件系列、宿主类别、工作负载和运行策略。浏览器维护、配置文件刷新、页面修订、扩展更新、图形变化、路由变化或宿主镜像变化后，都要重新检查。原记录仍可作为参考，但上限可能需要调整。

现有的 Scaling BrowserContexts 介绍上下文隔离和通用资源取舍。本页侧重实测内存曲线、长期观察、准入和恢复。Browser Release Validation 介绍范围更广的候选版本升级流程。

实际容量交接

浏览器组投入生产前，交接浏览器与配置文件组合、宿主类别、workloadRevision、已接受运行上限、暂停边界、恢复规则和回滚包。明确谁可以暂停准入。没有负责人的队列会让测量结果沦为假设。

说明测量窗口和未覆盖的条件。如果曲线只覆盖文本流程而不包括媒体，就应明确写出。如果观察持续了 30 分钟，而服务会运行整夜，应安排更长时间的观察，不要把短时结果当成长时间运行的证据。

容量记录应与发布流程一同维护。浏览器大版本、配置文件刷新、页面修订、宿主镜像、扩展、图形栈、路由策略或存储策略变化后，重新检查记录。可重复的小型记录能避免服务悄然沿用过时的上下文预算。

服务有多个队列时，应分别记录。短文本任务的队列可能很快排空，而大型报告队列仍在处理。把它们合并，可能让健康队列看起来受阻，也可能让繁忙队列显得还有余量。每次评估都写明队列、工作负载类别和负责人，让运行决策对应到正确的服务路径。

浏览器组达到运行边界时，应先采取运行操作，而不是猜测原因：停止接入新任务，让安全的任务完成，并观察恢复情况。候选版本无法回到批准范围时，还原已接受版本，然后以稳定基线检查工作负载。

公开来源

• BotBrowser 性能优化：组内存与启动调优指南
• BotBrowser 按上下文隔离：单个浏览器进程内的按上下文配置
• BotBrowser 基准测试方法：已测试的硬件、构建、方法，以及按上下文的规模和生命周期结果
• Playwright BrowserContext：BrowserContext 的存储、会话和 Cookie 隔离

实践结论

不存在可移植到所有环境的安全上下文数量。只有目标浏览器组完成代表性工作负载、保持在延迟与资源预算内，并在关闭和排空后恢复，才能接受该上限。保持准入可逆：达到记录的边界时暂停，恢复后再开放；浏览器、配置文件、工作负载、宿主或生命周期变化时重新测量。 容量数字还取决于浏览器运行在哪里，因为托管端点会用公开的会话上限取代自测值：托管浏览器与自托管浏览器 对比两种成本结构。