skip to content

Node Slot Configuration

3 roadmaps4 questions

Declaring a node's slots and stereotypes in a toml file or on the command line, and matching them against a request's capabilities. A capability nobody declared never gets a slot.

on this pageshow

explore

questions

4

In Selenium Grid, what does a Node's --max-sessions flag default to, and what silently caps it?

level: middleimportance: must knowfreq 60%

answer

  1. The default is not a fixed number
  2. Count the cores on the host
  3. Two different settings share one name
  4. Slots you never declared cannot be filled
  5. override-max-sessions lifts the processor clamp

basics

~20 s

A Selenium 4 Node's --max-sessions defaults to the number of processors its JVM reports. Selenium clamps any higher value back to that number unless --override-max-sessions true is passed, and a Node never runs more sessions than it declared slots.

solid answer

~40 s

In Selenium 4 the default is not a constant: `NodeOptions` sets it from `Runtime.getRuntime().availableProcessors()`, on the stated rule of one browser session per processor. `getMaxSessions()` then returns `min(configured, availableProcessors)` unless `--override-max-sessions true` is passed, so `--max-sessions 12` on a four-core host quietly yields four. Two further ceilings apply. Each driver reports its own maximum — Chrome and Firefox report the processor count, while Safari reports one and cannot be overridden. And `LocalNode` caps itself at `min(--max-sessions, number of slots built)`, so you can never run more sessions than the `[[node.driver-configuration]]` blocks declared seats for. Slots and concurrency are separate numbers: extra slots widen which stereotypes the Node serves, they do not raise throughput.

code

bash · 6 lines
bash
java -jar "$SELENIUM_JAR" node \
  --max-sessions 6 \
  --override-max-sessions true \
  --session-timeout 180 \
  --detect-drivers false \
  --driver-configuration display-name="Prescription queue Chrome" max-sessions=6 stereotype='{"browserName":"chrome","browserVersion":"131"}'

go deeper

for a junior

Recall that the flag exists, that its default is derived from the machine rather than fixed, and that a Node cannot run more browsers at once than the number it was configured for.

for a middle

Be ready to explain the resolution in order: the processor-count default, the clamp, the override, each driver's own maximum, and the Node taking the smaller of its flag and its slot count.

for a senior

Demonstrate that you diagnose a Node running fewer sessions than configured by reading its startup log for the detected processor count and the clamp warning, rather than assuming the Grid is at fault.

for a principal

Own when the override is justified at all: what evidence about memory and CPU headroom you require first, and how you stop a per-host exception spreading into the fleet's standard start command.

## Two different settings share the name max-sessions Selenium 4's Grid Node has two capacity numbers, and confusing them is the single most common sizing mistake. | Setting | Where it is written | What it limits | |---|---|---| | `--max-sessions` | the `[node]` section, or the flag | concurrent sessions across the whole Node | | `max-sessions` | inside one `[[node.driver-configuration]]` block | how many slots that one stereotype builds | | `--override-max-sessions` | the `[node]` section, or the flag | whether the processor-count clamp still applies | | the driver's own ceiling | `WebDriverInfo`, not configurable | Safari and Internet Explorer report 1 | ## Where the default comes from `NodeOptions.DEFAULT_MAX_SESSIONS` is `Runtime.getRuntime().availableProcessors()`, read once when the Node's JVM starts. There is no fixed constant to memorise: the same start command produces four slots on a four-core box and sixteen on a sixteen-core one. Selenium logs the detected count on startup and states the rule behind it plainly — **one browser session per available processor**. The rule is a heuristic about the browser process, not about the Grid. A real Chrome renders, paints and runs JavaScript; two of them on one core simply take turns, and the suite gets slower and flakier rather than faster. ## The clamp, and how to lift it `NodeOptions.getMaxSessions()` does not take your number at face value: 1. It reads the configured `max-sessions`, rejecting zero or a negative value outright. 2. It reads `override-max-sessions`, which is `false` by default. 3. If your value is above the processor count **and** the override is on, it returns your value. 4. Otherwise it returns `Math.min(yourValue, availableProcessors)`. So `--max-sessions 12` on a four-core prescription-queue Node quietly yields four. Adding `--override-max-sessions true` yields twelve, together with several warnings in the log about session stability and about the host running out of resources. The override is a measured exception for a machine with plenty of RAM and light pages, never a default. ## Ceilings the driver imposes Each driver reports a maximum through `WebDriverInfo.getMaximumSimultaneousSessions()`. Chrome and Firefox report the processor count. **Safari and Safari Technology Preview report 1, and that one is hard**: `NodeOptions` checks them by name before the override is consulted, so no flag raises it. Internet Explorer also reports 1 but is not on that list, so the override does raise it — against Selenium's own recorded advice. Per driver-configuration block the effective slot count is therefore `min(block max-sessions, driver ceiling)`, unless the override is on. ## The number that actually caps concurrency `LocalNode` sets its own ceiling to `Math.min(maxSessionCount, factories.size())` — the smaller of `--max-sessions` and the total number of slots built. Both directions bite: - Three blocks of four slots on a four-core host give **twelve slots but four concurrent sessions**. The extra slots buy *shape* — which stereotypes the Node can serve — not throughput. - One block of two slots with `--max-sessions 8` gives **two concurrent sessions**. You cannot run more sessions than you declared seats for. When a session is created the Node increments a counter first and refuses the request if it has passed the ceiling, then scans its slots for the first free one whose stereotype matches. ## Getting a slot back A slot is released when the client calls quit, or when `--session-timeout` expires. The Node keeps live sessions in a cache with expire-after-access set to that value: 300 seconds by default, clamped up to a floor of ten, with a sweeper running every thirty seconds. A prescription-queue test whose client process was killed therefore holds its seat for five minutes unless you shorten the timeout. ## Sizing the prescription-queue Node The suite that exercises the pharmacy's prescription queue needs Chrome and Firefox, and its host has four cores. Working the numbers through: - Declare **two blocks**, one per browser, each with `max-sessions = 4`. That is eight slots, so either stereotype can be served at any moment. - Leave `--max-sessions` alone. It resolves to four, and `LocalNode` therefore runs four sessions at once out of the eight declared seats. - Check memory before trusting the core count. Four real browsers rendering the queue's long prescription table can exhaust the host's RAM well before the CPU saturates, in which case the honest ceiling is `--max-sessions 2`. - Reach for `--override-max-sessions true` only with that measurement in hand, and only on the host it was measured on. - Never raise a block's `max-sessions` hoping to speed the run up. Slots and concurrency are different numbers, and only the second one is throughput.

  • Three driver-configuration blocks of four slots each run on a four-core Node. How many sessions run at once?
    Four. Twelve slots exist, so twelve stereotypes are servable, but `LocalNode` caps itself at `min(--max-sessions, slot count)` and `--max-sessions` defaults to the processor count. The extra slots buy shape — which browsers the Node can match — rather than throughput. Raising throughput needs more cores, or the override and the risk that comes with it.
  • Does --override-max-sessions true let you run several Safari sessions on one host?
    No. `NodeOptions.getDriverMaxSessions` checks Safari and Safari Technology Preview by name first and returns their hard maximum of one, before the override is consulted at all. Internet Explorer also reports one but is not on that list, so an override does raise it — against Selenium's own logged advice about parallel Internet Explorer runs.
  • What does --session-timeout do to a slot that is already busy?
    The Node holds live sessions in a cache whose expiry is reset on every access, set to `--session-timeout`: 300 seconds by default, never less than ten. A session that receives no WebDriver command for that long is killed and its slot released, with a sweeper running every thirty seconds. A crashed client therefore holds its seat for the full window.

saying these in an interview costs you the question

  • Quotes a fixed number as the --max-sessions default instead of the processor count
  • Assumes raising --max-sessions above the core count alone raises concurrency
  • Confuses the Node-wide --max-sessions with max-sessions inside a driver-configuration block
  • Believes declaring more slots increases how many sessions run at once
  • Thinks --override-max-sessions can lift Safari past one session per host
open as a page

A Selenium Grid Node runs Chrome, yet requests pinning browserVersion never match its slot. Why, and what fixes it?

level: seniorimportance: should knowfreq 45%

basics

~20 s

The Node auto-detected Chrome, so its stereotype declares only a browser name and a platform, never a version. Selenium 4 treats an undeclared version as no match. Declare the version explicitly in a driver-configuration stereotype instead.

open as a page

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%

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.

open as a page

In Selenium Grid, what is a Node's stereotype and which session requests will match that slot?

level: juniorimportance: nice to knowfreq 30%

basics

~20 s

A stereotype is the fixed set of capabilities one Node slot advertises, such as browser name chrome and browser version 131. Grid gives a request that slot only when the request's capabilities match the declared values.

open as a page