Manage parallel Selenium Grid 4 session capacity by tuning Node max-sessions and the New Session Queue instead of only adding more Nodes
domain: selenium.dev · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Understand Grid 4's core components: the Router (entry point for all requests), Distributor (assigns new sessions to Nodes by capability match), New Session Queue (holds pending requests), and Session Map (tracks session-id to Node)
Set each Node's max-sessions to match real hardware capacity, since over-committing sessions causes timeouts rather than more real parallelism
Configure the New Session Queue's request timeout so pending requests fail with a clear error instead of hanging silently when the Grid is saturated
Register Nodes with accurate stereotypes (browserName/platform/version) so the Distributor routes capability-matched requests instead of relying on round-robin luck
Monitor queue depth via the Grid's status endpoints or its OpenTelemetry traces to determine whether throughput is Node-bound or queue-bound before scaling
Known gotchas
Increasing parallel test threads without raising Node max-sessions just grows the New Session Queue and increases wait time rather than real parallelism
Standalone mode (all Grid components in one process) has no meaningful horizontal scaling beyond a single machine's capacity — real scale-out needs the hub-and-node/Docker/Kubernetes deployment
A queue-saturation timeout looks like a generic session-start failure if queue metrics aren't checked first, easily mistaken for a Node or browser crash
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?