Standard or Trimmed Build on Linux x64

Choose the Build for the Workload

BotBrowser Standard and BotBrowser Trimmed address different operating needs. Standard is the general distribution and retains the broad browser feature surface expected by long sessions, interactive work, and varied applications. Trimmed is an enterprise distribution for short, repeatable sessions on Linux x64, where browser and context preparation represent a meaningful share of the full task cost.

Build choice should begin with the work a team is authorized to perform. A brief service availability check, a regional configuration review, or a privacy consistency check with a small number of approved steps may benefit from a lighter preparation cycle. A longer session that uses media, downloads, document workflows, extensions, or persistent state may gain little and may require Standard's broader coverage.

Neither build should be selected from a concurrency target or a headline percentage alone. The useful questions are operational: How long does a representative task run? Which browser capabilities does it require? What proves that it completed correctly? How is it cancelled? When are its resources returned? How quickly can the deployment return to an approved build?

Standard remains the sensible starting point for most new deployments. It provides a stable baseline before the team separates short work from long work or understands which stages consume its resource budget. Trimmed becomes a candidate when repeated preparation and cleanup are visible constraints in a mature, bounded short-session queue.

The two editions can coexist. A scheduler can route validated short-session classes to a Trimmed pool while leaving interactive, long-running, or functionally broad tasks on Standard. This is usually more reliable than forcing every workload into one distribution.

Read the Public Results in Context

The public Linux x64 benchmark compared BotBrowser Standard and BotBrowser Trimmed on the same host. Both sides used a matched major version and profile package, the same authorized task, the same external destination, and equivalent run conditions. Cleanup was checked after every repeat.

In that controlled environment, Trimmed completed the short-session workload faster and placed less pressure on processor and memory resources. Both editions completed the representative work and returned the host to a clean operating state. The result supports evaluating Trimmed when repeated setup is a meaningful part of total task time.

The published method remains available in the performance benchmark. It records a directional result for one host, release, and workload. It does not establish the capacity of another host or promise the same outcome for different pages, networks, operating images, or BotBrowser releases.

Three parts of the result are useful beyond the original test. First, short-session deployments should measure preparation separately because they pay that cost for every task. Second, peaks matter alongside averages because admission can fail during a brief burst even when the long-term average looks comfortable. Third, completion and cleanup belong beside speed in every report. A shorter task is not an improvement if it finishes incorrectly or leaves capacity unavailable.

The observed direction may provide a starting hypothesis for local testing. It should not become a production limit. Page complexity, account flow, network route, graphics configuration, storage, virtualization, neighboring services, and session duration all alter the resource curve. A local comparison is required before capacity or release decisions.

The following workflow keeps the benchmark in its proper role. It starts with workload classification, moves through a paired comparison, uses a limited release, and returns to an approved build whenever evidence is incomplete.

Run Authorized Short-Session QA

A useful evaluation starts with a representative task, not an empty page. The task should include arrival at an authorized page, the essential approved actions, a clear completion condition, page closure, context cleanup, and browser shutdown. A simple startup check can confirm that an image launches, but it cannot approve a production workload.

Define each task class separately. Record its expected duration, required browser features, acceptable result, maximum execution time, cancellation policy, retry policy, and artifact destination. If a production task uses downloads, screenshots, documents, media, background activity, or persistent storage, include those requirements in the comparison. Removing necessary work to improve a benchmark creates a result that cannot support deployment.

Pages, accounts, and data used for QA should be authorized by their owners. Test credentials should have the least permission needed and should enter the environment through its secret-management path. They should not appear in profiles, benchmark definitions, command histories, screenshots, or general-purpose logs.

Failure paths are part of the workload. Include controlled cancellation, an ordinary timeout, a page-level failure, and a browser replacement. Confirm that each path releases its scheduler lease and returns capacity only after cleanup completes. A candidate that performs well only on successful sessions has not yet demonstrated operational readiness.

Keep privacy review focused on the approved configuration and user-visible outcome. Confirm that the intended profile package, regional settings, network policy, and storage policy are applied through supported deployment paths. Retain only the evidence needed for approval, protect it according to internal policy, and avoid recording page content or credentials when a completion code and non-sensitive runtime metric are sufficient.

QA should compare the same task revision on both builds. If page results differ, treat the difference as a release blocker until it is understood. A performance improvement does not compensate for missing browser behavior, an inconsistent result, or unreliable cleanup.

Plan Capacity from Evidence

Capacity planning asks how much admitted work a pool can complete while preserving service targets and recovery margin. It should not begin with a universal number of contexts per host. The safe operating point depends on session duration, page complexity, host class, operating image, network behavior, and the other services sharing the machine.

Separate work into classes with similar costs. A one-page availability check should not share one global average with a session that generates a document or holds state for several minutes. Classification allows the scheduler to maintain different queues, deadlines, and budgets. It also makes a Standard versus Trimmed comparison easier to interpret.

Increase admitted work gradually. At each step, wait long enough to observe completion, queue delay, cancellation, cleanup, and resource recovery. Stop increasing when service objectives begin to degrade or when the remaining margin is too small to replace a browser, drain a host, or absorb a page slowdown. The approved production point should remain below that observation and should identify the exact release, host class, image, and task revision it covers.

Short sessions also need an admission-rate budget. A pool may handle its steady state while still becoming unstable if too many tasks enter preparation at once. Bounded queues, admission control, and backpressure allow the scheduler to pause new work while existing sessions become stable or finish cleanup.

Capacity records should be reviewed when BotBrowser, the profile package, the operating image, host hardware, graphics settings, network provider, target pages, or task logic changes. An old benchmark remains useful history, but it no longer proves the current limit after a material change.

Set a Resource Budget

A useful resource budget connects user-visible results to host conditions. Start with completion rate, full task duration, first usable result, cancellation outcome, retry count, and cleanup completion. Then add CPU pressure, available memory, memory peaks, storage activity, network use, open-file pressure, and queue wait.

Average values describe the usual state, while peaks describe whether the pool can survive synchronized preparation, navigation bursts, or concentrated cleanup. Both are needed. A comfortable average can hide a brief period that causes admission failure, and a low memory average can hide a peak that triggers system reclaim.

Reserve headroom for recovery. The pool must be able to replace a browser, drain a host, handle normal page variance, and complete controlled cancellation without crossing its operating limit. Capacity that consumes all available CPU or memory during an ideal run is not production capacity.

Define warning and stop conditions in operational terms. Examples include sustained queue growth, completion below the approved baseline, cleanup taking longer than its service objective, memory failing to return after a pool drains, or host pressure leaving too little replacement margin. The exact values belong to the deployment's private operating policy and should come from local evidence.

Resource budgets also prevent a browser-stage improvement from being mistaken for a service improvement. If network wait or page activity remains the dominant cost, faster preparation may not increase completed work. Keep the measured improvement, but do not raise admission until the full service shows stable benefit.

Build a Reproducible Comparison

Standard and Trimmed should run under equivalent conditions. Hold constant the BotBrowser major version, profile package, Linux x64 image, host class, task revision, network category, graphics configuration, storage arrangement, and warm-up policy. Change only the candidate build.

Control order effects. Alternate the builds on the same host or use isolated pools with equivalent configuration. Record the host's starting condition for each series. A Standard run on an idle host cannot be compared fairly with a Trimmed run during maintenance or beside a memory-heavy service.

Measure the full lifecycle: browser preparation, context preparation, first representative navigation, authorized task activity, result confirmation, context closure, and browser shutdown. The benefit of a short session may appear early, but capacity does not return to the scheduler until the final cleanup stage finishes.

Retain distributions rather than only averages. Review ordinary variation, slow cases, cancellations, retries, and cleanup duration. A candidate that alternates very fast runs with unexplained delays may be less useful than a slightly slower but predictable baseline.

Each comparison report should identify version, build, deployment image, host class, task revision, network category, time window, and approving owner. Store non-sensitive metrics under the team's evidence policy. This record allows another reviewer to repeat the test and helps the team recognize when later conditions no longer match the approved result.

Reproducibility does not require publishing operational credentials, private routes, or detailed implementation information. It requires a stable task definition, equivalent inputs, a clear lifecycle, and enough non-sensitive context to explain the decision.

Include a Standard control whenever a new Trimmed result is reviewed. A candidate measured only against its own previous run can reveal drift, but it cannot show whether the change came from the build or from the shared environment. The control should use the same task definition and evidence format so reviewers can compare completion, duration, cleanup, and host margin without reconstructing the experiment.

Treat outliers as information instead of deleting them automatically. Record whether a slow or failed session came from the page, network, host, task logic, or browser lifecycle. If the cause cannot be separated with approved operational evidence, repeat the paired series and keep the uncertainty in the release decision. A clean average produced by excluding unexplained results is not a reliable capacity baseline.

Define Release Acceptance

Release acceptance should cover function, privacy configuration, performance, and recovery. Function confirms that representative pages and actions complete as expected. Privacy configuration confirms that the approved profile, regional settings, network policy, and storage policy remain attached to the intended task. Performance covers the full lifecycle and resource budget. Recovery covers cancellation, timeout, cleanup, browser replacement, and host draining.

Run acceptance on the image and host class intended for production. Developer-machine results can reveal obvious regressions but cannot replace Linux x64 deployment evidence. Container limits, graphics access, storage mounts, neighboring services, and network paths can all change the result.

After the paired comparison, release Trimmed to an isolated candidate pool. Send only task classes that passed acceptance. Leave broader or untested work on Standard. Give the candidate pool separate deployment identity, metrics, alerts, and drain controls without placing profile contents, credentials, or sensitive page data in telemetry.

Keep other variables stable during the first release. Avoid changing the browser build, host shape, profile package, network provider, and page workflow at the same time. When combined changes are unavoidable, introduce them in stages and establish a new baseline at each stage.

Before expanding the candidate pool, confirm that completion, queue behavior, resource margin, cancellation, cleanup, and browser replacement remain within their approved ranges. Record the evidence, owner, task scope, and rollback conditions. Do not route unvalidated long sessions into Trimmed simply because the pool has spare capacity.

Prepare and Rehearse Rollback

Rollback should exist before release. Preserve the previous approved image, profile-package reference, deployment configuration, and scheduler labels. Standard and Trimmed pools should be distinguishable so active work does not move between builds unexpectedly.

When a rollback condition occurs, stop new admission to the candidate pool. Allow sessions that can finish within their service window to complete, and apply the existing cancellation policy to the rest. Do not replace browser files beneath an active session or transfer its storage into a session assigned to another build.

After the pool drains, route new work to the approved build. Confirm that queue behavior, completion, cleanup, and host margin recover before retiring candidate resources. Preserve the release identity, timeline, affected task class, and non-sensitive operational metrics for review.

Rehearse this sequence during acceptance. A written plan that has never drained a candidate pool is weak evidence. The team should know who can pause admission, how it confirms drainage, how it restores routing, and what proves recovery.

After rollback, reproduce the representative task and separate build effects from page, network, host, or release-combination changes. Revise acceptance conditions where necessary, then restart with a limited pool. Reliable rollback makes continued comparison possible without turning every evaluation into a high-risk migration.

Keep the Scope Boundaries Clear

Standard should remain the selected build when sessions are long, the task requires broad browser features, the workload changes too often to support repeatable evidence, or the team lacks bounded queues, full cleanup, pool draining, and rollback. It should also remain selected whenever Trimmed produces a functional difference, unstable result, or insufficient recovery margin.

Trimmed is worth evaluating when short-session preparation repeats often, the authorized workload is stable, the public result's direction is also visible locally, required features pass acceptance, and the team can release and roll back by pool. Its purpose is to reduce the operating cost of suitable work, not to set a universal concurrency target.

The public benchmark applies to the tested BotBrowser 148 Linux x64 comparison. It does not promise identical behavior on another platform or release. Standard remains available through the public distribution path. Trimmed is part of the enterprise distribution and should be evaluated against the current enterprise release materials.

Revisit the decision after material changes. Browser releases, profile packages, host hardware, operating images, graphics configuration, page content, network routes, and task revisions can all invalidate an older capacity record. Routine dashboards should track completion, queueing, cancellation, cleanup, pool replacement, and resource margin. Trends that move away from the approved baseline should trigger a new comparison.

The decision record should state which authorized tasks use each build, what evidence supports the assignment, who approved it, what changes require retesting, and what conditions trigger rollback. That record is more useful than a single performance number because it preserves the boundaries under which the number was meaningful.

For a broader capacity method, read Browser Automation Performance and Scaling Browser Contexts. Enterprise availability and engagement options are described on the Enterprise page and Pricing page.