skip to content

How would you size a Selenium Grid Node's slot layout for a mixed-browser suite, and what does over-declaring cost?

level: principalimportance: should knowfreq 35%

answer

  1. Two ceilings, not one
  2. Cores set the honest starting point
  3. More slots widens, it does not speed
  4. The override lifts the clamp and the risk
  5. session-timeout is how a seat comes back

basics

~20 s

Start from one browser session per processor, declare one stereotype block per browser and version the suite must reach, and hold the concurrent ceiling at the core count. Extra slots widen what a Node serves, never how fast it serves.

solid answer

~40 s

Treat it as two numbers. Slots are declared per `[[node.driver-configuration]]` block and decide which stereotypes the Node can match; concurrency is capped by `LocalNode` at `min(--max-sessions, total slots)`, and `--max-sessions` defaults to the processor count. So three blocks of four slots on a four-core host give twelve slots and four concurrent sessions. I start from one session per processor, check it against the memory one real browser holds, and take the smaller. I declare fully qualified `browserVersion` values so version-pinned requests can match at all, tune `--session-timeout` before reaching for `--override-max-sessions true`, and treat the override as a per-host exception with measurements written down. Homogeneous Nodes cost more machines but isolate driver upgrades and failures; mixed Nodes pack a small estate more tightly.

go deeper

for a junior

Know that a Node has a limit on concurrent sessions and that it comes from the machine by default. You are not expected to choose the numbers, only to read them off a running Node.

for a middle

Be able to say which setting moves which ceiling, and to predict the concurrent session count for a given set of driver-configuration blocks on a host with a known core count.

for a senior

Demonstrate operating judgment: how you measure a real browser's memory footprint before trusting the per-processor rule, and what evidence you demand before overriding the processor clamp.

for a principal

Own the fleet-wide policy: homogeneous versus mixed Nodes, where version pinning lives, when an override is sanctioned, and how you stop the advertised slot count drifting away from real capacity.

## Two ceilings, and only one of them is throughput Sizing a Grid Node is one decision expressed as two numbers, and a lead who conflates them will buy hardware that does nothing. - **Slots** are declared: one `[[node.driver-configuration]]` block with `max-sessions = n` builds `n` seats carrying that stereotype. Slots decide *what* the Node can serve. - **Concurrency** is capped: `LocalNode` runs at most `min(--max-sessions, total slots)` sessions at once, and `--max-sessions` itself defaults to the host's processor count and is clamped back to it unless `--override-max-sessions true` is set. Concurrency decides *how much* the Node can serve. Adding stereotypes widens the first number. Only cores, memory and the override move the second. ## Where the first number honestly comes from Selenium's own default rule is one browser session per available processor. It is a defensible starting point rather than a law, and I treat it as the first of four inputs: - **Cores.** The processor count the Node's JVM reports, which is what `--max-sessions` defaults to anyway. - **Memory.** Usually the real constraint. A browser rendering the pharmacy's long prescription table holds far more RAM than a core's worth of CPU suggests, so measure one session's resident set against the host and take the smaller of the two ceilings. - **The stereotypes the suite actually sends.** A browser nobody requests does not need slots; a version somebody pins needs a block that declares it. - **Observed behaviour.** A Node sitting at 40% CPU while sessions time out is not short of slots, and adding some will not help. ## Shape versus throughput | Layout on a four-core host | Slots | Concurrent sessions | What it buys | |---|---|---|---| | one block, Chrome, `max-sessions = 4` | 4 | 4 | full throughput on one stereotype | | two blocks, Chrome and Firefox, 4 each | 8 | 4 | either browser, unchanged throughput | | two blocks of 4, `--max-sessions 8` plus override | 8 | 8 | more throughput, contended CPU and memory | | one block, Chrome, `max-sessions = 2` | 2 | 2 | half the host wasted, whatever the flag says | The third row is the only one that raises throughput, and it is the only one that risks the Node. ## One browser per Node, or every browser on every Node Homogeneous Nodes — one stereotype each — cost more machines but isolate failure and upgrade cleanly: a driver whose version drifts takes down only its own capacity, and you can restart that Node without touching the rest. Mixed Nodes pack the fleet more tightly and are the right call for a small estate, at the price of a blast radius that covers every browser the pharmacy suite needs. Safari forces the question anyway, since its driver reports a hard maximum of one session per host that no override lifts. ## The levers, in the order I reach for them 1. **Declare the stereotypes the suite actually asks for**, with fully qualified `browserVersion` values, so version-pinned requests can match at all. 2. **Set per-block `max-sessions` to the number of that browser you want available**, not to a round number. Slots are free; concurrency is not. 3. **Leave `--max-sessions` at the processor default** until a measurement says otherwise. 4. **Tune `--session-timeout` before reaching for the override.** At its 300-second default a crashed client holds a seat for five minutes; a shorter value returns capacity that was never doing work. The floor is ten seconds and the Node sweeps every thirty. 5. **Use `--override-max-sessions true` last**, on a specific host, with the CPU and memory evidence written down beside it. ## What over-declaring costs Declaring far more slots than the Node can run is not free. It buries the real ceiling behind a slot count nobody can reconcile with observed throughput, it invites the assumption that capacity has been added when nothing changed, and it makes the fleet's advertised size a fiction that anyone planning against it will get wrong. Under-declaring is worse in one specific way: a stereotype you never declared cannot be matched at all, so a whole class of requests has nowhere to go regardless of how idle the host is. ## What this decision is not How wide the browser and viewport matrix ought to be is a separate call, owned elsewhere; take the matrix as given and size the Nodes to serve it. How the suite splits itself across workers, and what a request does while every matching slot is busy, are likewise other people's problems. This decision is narrow: given the stereotypes I must serve and the hardware I have, how many seats of each do I declare, and what ceiling do I let the Node run at.

  • You must serve three browser versions but the host has only two cores. What do you declare?
    All three stereotypes, each with a small `max-sessions`. Slots are cheap; concurrency is not. The Node still runs at most two sessions at once because `LocalNode` caps at `min(--max-sessions, slot count)`, but every one of the three request shapes can be served — just not simultaneously. A stereotype you never declared cannot be matched at all.
  • When is one browser per Node better than every browser on every Node?
    When failure isolation and driver-version churn matter. A Node pinned to one browser and one driver binary can be upgraded and restarted without touching the others, and a crash-looping driver takes down only its own capacity. Mixed Nodes are cheaper for a small estate but put every browser the suite needs behind one host.
  • What does raising --session-timeout to an hour actually risk?
    Seats stay reserved by sessions nobody is driving. The Node expires a session only after that long with no WebDriver command, so a crashed client holds a slot for an hour and the Node's effective capacity silently drops. Raise it only for genuinely slow steps; the floor is ten seconds and the sweeper runs every thirty.

saying these in an interview costs you the question

  • Sizes a Node from a wall-clock target rather than from host cores and memory
  • Declares many slots and expects throughput to rise with the slot count
  • Sets override-max-sessions true as a default rather than a measured exception
  • Never revisits session-timeout, so abandoned sessions hold seats for five minutes
  • Puts every browser on every Node without weighing the blast radius