Question
Selenium WebDriver vs Selenium Grid 4: Session routing and latency bottlenecks
Rin River
0 reputation · 02 Dec 2025, 07:59 UTC
10.4K views
Loading…
0 reputation · 02 Dec 2025, 07:59 UTC
The goal is to quantify the delay between a WebDriver client requesting a new session and the first executable command being acknowledged by a Grid 4 node. The round‑robin session router can unevenly distribute sessions when nodes differ in capability or startup time, potentially creating a backlog that is invisible to the test code but observable in the Grid console.
Key constraints include the default capacity limits per node, the possibility of network latency between hub and nodes, and the fact that the /session endpoint returns a session ID while the first /session/:id/execute/sync call may experience variable latency. Uncertainty remains about whether the observed spikes are due to protocol overhead, node initialization, or the router’s load‑balancing strategy.
To resolve these questions, we need to identify reliable metrics and decide on a routing strategy that balances fairness and throughput.
1. Which Grid 4 metrics endpoint provides the most accurate view of the session queue and node utilization?
2. How can we isolate the protocol overhead from node startup time when measuring /session latency?
3. Should a custom capacity‑based router be preferred over the default round‑robin approach when nodes have heterogeneous capabilities?
1. Best metrics endpoint
The /metrics endpoint (Prometheus format) is the most granular source. It exposes grid_new_session_queue_size, grid_node_sessions_count, grid_node_max_sessions, and grid_session_creation_duration_seconds_bucket. These metrics give real‑time queue depth, per‑node load, and latency histograms that you can scrape or tail with curl -s http://:4444/metrics | grep -E "grid_".
2. Isolating protocol overhead from node startup
To separate the two, pre‑warm nodes: wait until each node reports status: UP in /status before sending session requests. Then measure time from client POST /session to the hub’s Session created log entry (router + node session creation). Subtract the node’s own session_created duration (available in the node’s logs or via the Grid event bus). The remainder is protocol/router latency.
3. Router choice for heterogeneous nodes
The default round‑robin router (org.openqa.selenium.grid.router.RoundRobin) treats all slots equally, so a node with slower browser startup or fewer maxSessions can become a backlog. A capacity‑based router that weighs free slots, historical creation time, and capability match is recommended for mixed‑hardware clusters. Implement the Router interface, load it via ServiceLoader, and test its distribution against round‑robin with a simple script that logs selected node IDs.
Verify Grid version: curl -s http://:4444/status | grep version.
Collect baseline metrics:
seleniumcurl -s http://:4444/metrics | grep "grid_" > baseline.txt
Warm all nodes (ensure status: UP for each).
Run a burst of parallel session requests (e.g., 50) and record timestamps of Session request received, Node selected, and Session created from hub logs.
Calculate per‑session latency: Session created - Session request received.
Subtract node‑reported creation time (from node logs) to isolate protocol/router latency.
Deploy a simple custom router that logs node ID and free slots, restart the hub, and compare distribution to round‑robin.
Could you confirm the exact Grid 4.x version you are running and the number of nodes with differing maxSessions values? This will help tailor the router implementation details.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.