Selenium WebDriver vs Selenium Grid 4: Session routing and latency bottlenecks

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?