Performance Engineering for Test Suites and Grid Capacity: Configuration, Design Patterns, and Trade-Offs

1. Browser reuse versus isolation

Creating a browser session is expensive, so reuse looks attractive. But a reused session also reuses cookies, storage, history, service workers, open windows, extensions/profile state, and sometimes AUT-side session state. That changes the test contract.

2. Headless versus headed

Headless mode can reduce display/rendering overhead and is operationally convenient in CI, but performance differences vary by browser, version, GPU/display stack, page behavior, and container/VM environment. A headless result is not proof of headed performance or vice versa.

Record the mode as benchmark metadata. If the product risk includes headed-only behavior, keep at least a representative headed lane instead of replacing coverage with a faster but different execution mode.

3. Local WebDriver versus Grid

Local WebDriver removes network and Grid routing/queueing from session creation. Grid adds useful distribution and browser/OS capacity but also adds transport, queue, Node placement, and infrastructure failure domains.

4. Concurrency versus saturation

The fastest stable point is usually before the maximum theoretical worker count. Once a constrained layer saturates, queueing theory becomes visible operationally: offered work grows faster than service capacity, queues grow, p95/p99 latency rises, and timeouts/flakes appear.

Current Grid defaults Node max sessions to available processors and warns that overriding the recommended one-browser-per-processor model can reduce stability. Treat that as a starting safety guard, not proof that every CPU can sustain one heavyweight test for your AUT/browser/profile/evidence mix.

5. Evidence richness versus IO/storage

Always-on screenshots, video, HAR-like data, page source, console logs, and trace bundles can dominate IO at scale. The wrong optimization is “turn all evidence off.” A better design is tiered capture:

• small manifest/version/session metadata always;
• screenshot + targeted DOM/log evidence on failure;
• richer network/video/tracing on selected suites or diagnostic reruns;
• bounded retention and per-attempt names so retries never overwrite first failure.

Measure bytes and write/upload time. Chapter 17’s diagnostic value still applies; Chapter 25 merely quantifies the cost.

6. Per-test setup versus fixture reuse

Fast API/database fixture setup can be safely reused only when the reused resource is immutable or correctly partitioned. Browser state is especially risky to share. A practical rule is to amortize expensive infrastructure setup (for example starting a disposable AUT once per worker) while keeping mutable test identity, browser session, and evidence namespace isolated per test unless a different contract is explicitly proven.

7. Browser matrix breadth versus feedback time

Chapter 16 established risk-based compatibility coverage. Performance engineering gives that policy a schedule: fast per-change lanes can cover the highest-risk browser/viewport combinations; broader cross-browser matrices can run on merge or schedule. Do not delete coverage solely because it is slow—move it to a cadence justified by risk and capacity.

8. Dedicated Grid versus shared capacity

A shared Grid improves utilization but introduces workload interference: another team’s browser mix, video settings, or long sessions can change your queue wait. A dedicated Grid costs more infrastructure but makes capacity and benchmark results more reproducible.

If benchmarking on shared capacity, record queue/session/Node state during the run. Otherwise you cannot distinguish your code change from neighbor load.

9. Configuration ownership: put the knob in the correct layer

The following table organizes the key choices and evidence for Configuration ownership: put the knob in the correct layer. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

10. Decision table: choose by observable behavior

The following table organizes the key choices and evidence for Decision table: choose by observable behavior. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

Knowledge checks

Answer from the operating model, then reveal the explanation.

Summary and next bridge

• Performance controls also change isolation, portability, and diagnostics.
• Fresh sessions remain the reliability baseline; reuse is an explicit trade-off.
• Headless/local/Grid choices must be measured, not assumed.
• Concurrency stops being useful at the first constrained layer.
• Evidence and browser-matrix policies can be tiered without deleting essential coverage.

Lesson 4 diagnoses misleading benchmarks, resource leaks, retry amplification, AUT throttling, and saturation failures using a fixed evidence-first sequence.

Primary references and version notes

• Selenium downloads — stable client and Grid release baseline.
• Getting started with Selenium Grid — CPU/RAM sizing and session-capacity guidance.
• Grid CLI options — current max-sessions, queue timeout, retry interval, and related controls.
• Grid GraphQL support — observable max sessions, session count, nodes, slots, and queue size.
• Grid observability — traces, events, and logs for distributed diagnosis.
• Performance testing with Selenium is discouraged — why WebDriver suite timing is not a substitute for load/performance tooling.