Linux x64 上如何选择 Standard 与 Trimmed Build

根据工作负载选择构建

BotBrowser Standard Build 与 Trimmed Build 面向不同的会话形态。Standard 是默认发行版本，保留完整的浏览器能力，适合交互时间较长、页面类型较复杂、需要覆盖更广功能面的自动化与质量保障。Trimmed 是面向企业客户的精简发行版本，重点降低 Linux x64 环境中短会话反复启动、执行和结束所产生的运行成本。

选择构建时，最重要的问题不是哪一个在单项数字上更快，而是哪一个更符合实际任务。一个持续几十分钟、包含多次交互和媒体处理的会话，启动时间只占总成本的一小部分。一个只完成少量授权检查、随后立即关闭的短会话，则会反复支付启动与初始化成本。两类工作放在同一张容量表里，会得到误导性的平均值。

因此，构建选择应成为部署设计的一部分。团队需要明确会话长度、页面范围、交互复杂度、资源峰值、清理要求和故障恢复方式，再用同一套代表性任务比较两个候选版本。公开基准可以帮助形成初步判断，但生产上限只能由自己的环境验证。

Standard Build 适合哪些工作

Standard Build 是大多数部署的起点。它适合以下情况：

• 会话持续时间较长，启动成本在完整流程中占比较低。
• 工作流包含复杂交互、媒体、下载、打印、扩展或较广的浏览器功能。
• 质量保障需要尽量覆盖标准发行版本的完整能力。
• 团队尚未建立区分短会话与长会话的队列，也没有独立的容量基线。
• 发布风险比单位时间吞吐更重要，希望先使用默认发行路径建立稳定记录。

Standard 并不代表低效率。对于长时间运行的任务，页面本身、网络等待、业务操作和外部服务通常决定总耗时。即使另一个构建缩短了启动阶段，这部分收益也可能被较长的会话时间稀释。此时更值得关注的是完成率、页面行为、资源趋势和维护成本。

新项目通常也应先用 Standard 建立基线。团队可以在这一阶段明确任务成功条件、收集非敏感运行指标、验证关闭流程，并识别真正的限制因素。如果观察结果表明上下文准备和短会话周转占用了较大比例，再把 Trimmed 纳入对照会更有意义。

Trimmed Build 适合哪些工作

Trimmed Build 面向短会话、重复周转和资源预算较紧的 Linux x64 部署。典型场景包括经服务所有者授权的页面可用性检查、地区配置回归、短流程隐私一致性 QA，以及每个任务都能在明确边界内开始和结束的企业工作池。

它更适合满足以下条件的系统：

• 单个任务较短，上下文准备时间在总耗时中占有可见比例。
• 工作负载结构稳定，可以定义代表性页面和操作。
• 调度器具备有界队列、背压、取消和完整清理能力。
• 团队能在目标 Linux x64 镜像和目标主机类别上执行重复对照。
• 每次发布都保留上一版可用构建，并能够按浏览器组排空和回退。

Trimmed 不应被理解为 Standard 的普遍替代品。精简构建的价值来自特定工作负载与特定运行环境的匹配。任务越长、功能面越广，启动阶段节省的相对价值通常越低。任务越短、周转越频繁，降低准备阶段成本越可能影响整体容量。

在适当语境中解读公开结果

BotBrowser 的公开对照基准在同一 Linux x64 主机上比较了 Standard 与 Trimmed。两组运行使用一致的主要版本、匹配的 profile 包、授权任务、目标页面和执行条件，并在每轮结束后检查清理结果。

在该受控环境中，Trimmed 更快完成了短会话工作负载，同时降低了处理器和内存压力。两种构建都完成了代表性任务，并让主机恢复到干净的工作状态。这个结果支持在重复准备占总任务时间较大时评估 Trimmed。

这些结果支持三个有限但实用的结论。

第一，短会话部署值得单独衡量上下文准备成本。公开对照中，最明显的差异出现在反复发生的准备阶段，而不是通过牺牲任务完成率获得。若生产流程经常创建、执行少量授权步骤并关闭，减少重复成本可能带来明显收益。

第二，资源峰值与平均值同样重要。主机可能在大部分时间保持平稳，却在并发启动、首次导航或集中清理时失去余量。公开结果中的 CPU 与内存峰值变化说明，评估不能只看整场平均值。

第三，稳定完成与干净退出必须和速度一起验收。只报告更短耗时而不确认完成率、取消路径和资源回收，会把风险留给生产环境。公开基准把成功结果和清理状态放在同一份报告中，这种结构比单独追求最快数字更值得复用。

这些结果不能直接决定另一台主机的并发上限。页面、账号流程、网络路线、图形配置、存储、虚拟化方式和邻近服务都会改变资源曲线。公开结果用于说明两种构建在受控条件下存在可测差异，不是对所有环境的固定承诺。

用一张决策图组织评估

下面的流程把构建选择分成任务分类、对照测量、发布验收和运行复查四个阶段。任何阶段发现功能覆盖不足、资源余量不足或结果无法复现，都应回到 Standard 或上一版批准构建。

执行经过授权的短会话 QA

有效对照必须来自真实但已授权的任务。空白页面或只有一次导航的演示可以确认环境能够启动，却不足以批准生产容量。代表性短会话应包含实际会发生的页面加载、必要交互、结果确认、页面关闭和上下文清理。

为每一类任务写明入口、完成条件、最长允许时间、取消方式、重试策略和产物保留规则。账号、页面与数据必须由相应所有者授权。需要使用凭据时，让工作节点通过受控秘密管理获得最小权限，不要把凭据写入 profile、命令、基准文件或日志。

如果生产任务包含截图、文档、下载、媒体或后台活动，基准也应包含这些工作。为了得到更漂亮的数字而移除必要资源，会让候选构建在错误的任务上获胜。反过来，把极少出现的重型任务混入所有短会话，也会掩盖 Trimmed 对主要队列是否有价值。

工作负载差异明显时，应拆成多个类别。轻量可用性检查、登录后状态确认和页面报告生成可以分别测量。调度器随后为不同类别设置独立队列和资源预算，而不是用一个全局平均值管理所有任务。

建立可重复的对照

两种构建必须在同一条件下运行。保持主机类别、操作系统镜像、BotBrowser 主版本、profile 包、任务版本、网络类别、图形设置、存储方式和预热策略一致。每次只改变构建类型，才能把观察到的变化合理归因于候选版本。

测试顺序也要避免环境偏差。如果 Standard 总在空闲主机上运行，而 Trimmed 总在缓存已热或邻近服务繁忙时运行，结果就难以比较。可以交替运行两个候选，或者为它们准备配置一致的隔离主机，并记录每轮开始时的资源状态。

对照要覆盖完整生命周期：浏览器准备、上下文创建、首次代表性导航、授权工作、结果确认、上下文关闭和浏览器停止。短会话的收益可能集中在前半段，但关闭阶段决定容量何时真正归还调度器。任务完成后仍占用资源的构建，不能只凭页面较快就获得批准。

不要只保留平均值。记录多轮结果的分布、异常、取消、重试和清理时间，观察波动是否可解释。候选构建偶尔非常快、偶尔超过服务期限，可能不如稍慢但稳定的构建。容量服务需要可预测性，因为不可预测的长尾会占住队列和恢复余量。

基准记录应包括浏览器版本、构建类型、部署镜像、主机类别、任务修订、网络类别、测试时间、审批人和结果文件位置。运行证据按内部保留策略存放，不记录页面敏感内容。这样在版本变化或结果漂移时，团队能够确认比较是否仍然有效。

设定资源预算

构建评估至少需要两组指标。第一组描述用户可见结果，包括任务完成率、总耗时、首次可用时间、取消结果、重试和清理完成。第二组描述主机成本，包括 CPU 压力、可用内存、内存峰值、存储活动、网络使用、打开文件和队列等待。

完成率优先于速度。若候选版本更快，但某些授权页面无法正常完成、结果不一致或关闭路径不可靠，就不应进入生产。需要明确区分应用本身的失败、外部网络失败和主机容量失败，以免通过增加资源掩盖功能问题。

总耗时要按生命周期拆分，但不需要暴露内部实现。可以记录浏览器准备、上下文准备、任务活动和清理四个运维阶段。这样既能判断 Trimmed 的收益是否落在高频阶段，也能发现某个阶段的改善是否被另一个阶段抵消。

资源指标要同时看稳定状态和峰值。稳定内存决定一个工作池能否持续运行，峰值决定它能否承受并发启动、导航突发和集中回收。平均 CPU 较低并不代表没有短时饱和，较低的内存均值也不代表不会触发主机回收。

队列指标能说明优化是否真正转化为服务能力。候选构建降低了准备成本，但上游网络或页面操作仍是主要瓶颈时，完成量可能没有明显变化。此时应保留对照结果，但不要仅依据浏览器阶段的改善提高生产上限。

根据证据规划容量

一个可靠的容量计划不是“每台主机运行多少个上下文”，而是“在满足服务目标和恢复要求时，允许多少工作进入每个资源池”。固定数字容易脱离页面、版本和主机环境，而资源预算能随着证据更新。

为每个任务类别设定内存、CPU、队列时间和完成时间预算。预算应保留处理页面波动、主机维护、任务取消和浏览器替换的余量。基准中达到的最高负载只是观察点，不应直接成为生产上限。

逐步增加工作量，在每一步等待运行进入可观察状态。比较完成量、延迟、错误、清理时间和主机余量。当服务目标开始恶化，或恢复所需余量不足时停止。批准的运行点应低于这一位置，并写明适用的版本、任务和主机条件。

浏览器组与主机可以分别设置预算。浏览器组限制正在运行和正在准备的上下文，主机限制所有浏览器组的总体资源。当任一预算用尽时，调度器实施背压，不再把请求无限放入内存队列。

短会话还需要限制创建速率。即使稳定状态能够容纳现有任务，同时启动过多工作也可能制造瞬时峰值。调度器可以分阶段接收和创建，在准备时间或资源压力上升时暂停，再等待当前任务进入稳定状态。

定义发布验收标准

Trimmed 的发布验收应覆盖产品行为、隐私配置一致性、性能和恢复四个方面。产品行为检查代表性页面是否按预期完成；隐私配置检查使用已批准的 profile 与区域方案确认会话配置没有偏离；性能检查比较完整生命周期；恢复检查验证取消、超时、关闭和浏览器替换。

验收环境应使用准备进入生产的镜像和配置。开发机结果可以发现明显回归，但不能替代目标 Linux x64 主机的证据。容器限制、图形访问、存储挂载和网络路径都可能改变实际表现。

测试账号和页面必须由所有者批准。QA 只收集完成判定和必要的非敏感运行指标。截图、日志或页面产物确有需要时，应进入受保护的证据位置，并设定访问与保留期限。性能比较不需要保存完整页面数据。

候选版本还要通过故障路径。受控取消一部分任务，模拟正常超时，停止接收新工作并排空浏览器组。确认调度租约、页面、上下文和浏览器都能按顺序结束，容量只在清理完成后返回队列。

若 Standard 与 Trimmed 的页面结果不同，应先视为发布阻断，而不是用性能收益抵消。调查可以从任务日志、版本记录和最小化的授权证据开始。问题没有得到解释前，继续使用已批准的 Standard 或上一版 Trimmed。

从有限部署开始

完成实验室对照后，不要立即把全部短会话迁移到 Trimmed。建立独立的候选部署组，只接收已定义、已授权并通过验收的任务类别。其余工作继续使用 Standard。

候选组应有单独的运行标识、指标和告警，但不应记录 profile 内容、凭据或页面敏感数据。观察任务完成、排队、资源余量、取消、清理和浏览器组替换趋势，并与相同任务的 Standard 基线比较。

发布期间保持任务分配稳定。不要同时更换浏览器构建、主机规格、profile 包、网络供应方和页面流程，否则出现变化时无法定位原因。确需组合变更时，拆成多个阶段，每个阶段重新建立基线。

扩大候选组前，确认收益能够持续复现，并且没有功能覆盖或稳定性退化。扩容决策应记录证据、负责人、适用任务和回退条件。Trimmed 只接收已经证明适合它的任务，不能因为空闲容量而承接未验证的长会话或复杂功能流程。

准备并演练回退

回退不应依赖事故现场临时编写步骤。发布前保留上一版已批准镜像、profile 包引用、部署配置和调度标签。Standard 与 Trimmed 部署组都应能被调度器明确识别，避免活动任务在构建间迁移。

触发回退时先停止候选组接收新任务，再让能够在服务期限内完成的会话自然结束。超出期限的任务按既定取消策略处理。不要在活动浏览器上直接替换二进制，也不要把一个会话的存储转接给不同构建下的新身份分配。

候选组排空后，把新任务指向已批准构建。确认队列、完成率和主机余量恢复，再决定是否关闭候选资源。保留版本、时间线、任务类别和非敏感运维指标，供后续分析。

回退后不要立即以同样配置再次发布。先重现代表性任务，判断问题来自构建、页面变化、网络、主机还是发布组合。修订验收条件后，从有限部署重新开始。能够频繁、低风险地回退，才有条件持续比较不同构建。

明确适用边界

以下情况应继续使用 Standard，或者让相应任务留在 Standard 队列：

• 代表性任务依赖 Trimmed 未覆盖的浏览器功能。
• 会话时间较长，准备阶段差异对总完成量影响很小。
• 任务类别变化频繁，无法形成可重复的对照。
• 团队没有有界队列、完整清理、部署组排空或版本回退能力。
• 候选结果波动较大，无法在相同条件下复现。
• 性能改善伴随页面行为、完成率或恢复能力退化。
• 目标环境不是经过验证的 Linux x64 部署形态。

继续使用 Standard 不是错失优化，而是依据证据选择更合适的风险边界。团队仍可通过任务分类、资源预算、背压和发布治理改善 Standard 部署。等短会话队列更稳定、验证条件更成熟后，再重新评估 Trimmed。

何时考虑 Trimmed

当短会话准备成本反复出现、公开基准的收益方向与本地观察一致、功能覆盖满足任务要求，并且团队具备有限发布与回退能力时，可以考虑 Trimmed。

决策记录应回答以下问题：

• 哪些授权任务进入 Trimmed，哪些仍留在 Standard？
• 对照使用了什么版本、主机、镜像、profile 与任务修订？
• 完成率、总耗时、资源峰值、队列和清理结果如何？
• 生产预算保留了多少恢复空间，谁批准这个预算？
• 哪些变化需要重新基准，哪些信号会触发排空和回退？
• 上一版批准构建是否仍可部署，回退是否经过演练？

这些答案比单个性能数字更能决定发布质量。Trimmed 的价值在于让合适的短会话以更低运行成本完成，而不是让所有任务追求同一个并发目标。

运行中的复查周期

进入生产后，基准不会永久有效。BotBrowser 版本、操作系统镜像、主机硬件、图形配置、页面内容、网络路线、profile 包或任务流程发生实质变化后，都应重新执行代表性对照。

日常面板关注任务完成、排队、取消、清理、浏览器组替换和资源余量。趋势比一次峰值更有解释力。排队时间持续增长、关闭时间逐渐变长、内存无法回落或候选组替换频率上升，都说明原容量判断需要复查。

定期抽取 Standard 对照也有价值。若 Trimmed 的优势随页面或版本变化而缩小，团队可以在影响服务目标前调整任务分配。对照不必持续占用大量生产资源，但应使用同一任务定义和同一证据格式。

将复查结果写回容量记录。记录新的适用范围、预算、审批日期和下一次复查条件。旧结果可以保留用于趋势分析，但不能继续代表已经变化的环境。

部署前检查清单

准备采用 Trimmed 前，确认以下项目：

• 已将短会话与长会话、复杂功能任务分开。
• 代表性任务来自获授权页面，并有明确完成和清理条件。
• Standard 与 Trimmed 使用相同版本、主机类别、镜像、profile、网络和任务流程。
• 对照覆盖浏览器准备、上下文准备、任务活动和清理。
• 结果同时包含完成率、耗时、资源峰值、队列和退出状态。
• 容量预算低于实验中的极限位置，并保留恢复余量。
• 调度器具备有界队列、背压、取消、租约和完整清理。
• 候选部署组只接收已经验收的任务类别。
• 上一版批准构建、配置与调度标签仍可使用。
• 排空和回退步骤经过演练，不需要修改活动浏览器。
• 运行指标不包含凭据、profile 内容或页面敏感数据。
• 版本、主机、页面或策略变化后会触发重新验证。

选择适合任务的发行版本

公开 Linux x64 基准表明，在受控短会话工作负载中，Trimmed 能更快完成任务，并降低处理器与内存压力，同时保持任务结果与清理质量。这个结论足以说明 Trimmed 值得进入企业短会话部署的候选列表，但不足以替代本地容量验证。

Standard 仍是完整功能面与长会话的默认选择。Trimmed 适合边界清晰、可重复测量、能够有限发布和快速回退的短会话队列。两者可以同时存在，由调度策略按任务类别分配，而不是要求整个组织只选择一种构建。

需要建立本地基线时，可先阅读浏览器自动化性能指南和按上下文配置的容量规划。企业发行方式与适用范围请查看企业方案和套餐页面。