Tutorial 22 - Selenium 4 Grid
Why do we need Selenium grid? Quick Overview
When our hub is overloaded and is not able to handle any further requests from the client, in that scenario we can go for distributed execution using Selenium grid.
Selenium grid distributes our test cases (can be parallel or sequential test cases) for remote execution on different browsers/machines. Thus the grid (hub) has the ability to control the environments (nodes) where our browser tests are run. Selenium grid offers load balancing: whichever node is free, grid hub automatically distributes the tests to that particular node.
Look at the diagram.
The test cases get routed to Hub and Hub sends request to specific node. The Hub or controller is connected to multiple nodes 1, 2, 3, etc. Each node may use different browser and different operating system combination. Thus, hub distributes our test cases and execute them in parallel remotely.
What’s new in Selenium grid 4 ?
In earlier versions of selenium grid, we would need to setup hub and node separately. However Selenium grid 4 introduces 3 different modes:
Standalone mode (easiest mode to spin up selenium grid, hub/node together in one machine),
Hub and node mode (classic/traditional grid that comprises of starting a hub, starting and registering a node, both hub and node are started individually),
Distributed mode (setup all components individually viz router, sessions, nodes, distributor, session queuer).
We will study each one of these.
Selenium Grid 4 Distributed Architecture
Let us understand the grid 4 architecture in simple steps:
We first start with starting the event bus
Once event bus is started, we start the sessions
Once sessions is started, we start the session queuer. Whenever the client (selenium webdriver code) is sending any session creator request, the request is queued in session queuer
The next component is Distributor that is responsible for creating the session
Once distributor is started, we then start router component which is the client facing component. Whatever session creator requests we are sending, they go to router.
Router redirects the requests to appropriate component based on command type
Finally, node is created
The distributor than sends the node information to sessions
The Sessions updates the node information in sessions map
So below is the summary for the grid 4 architecture lifecycle. See the red coloured text/arrows in below diagram.
Selenium client sends the session creation request to router.
Router adds the session request to session queuer.
& 4. Distributor picks up the session request from queuer and sends it to Sessions.
5. Sessions maps the session id to whichever node is free (for session creation request).
6. Once session id is mapped with Node uri, the browser is launched and session gets created
This was the simplest explanation of how grid 4 works. We will understand the flow better in upcoming articles.
References
https://www.selenium.dev/documentation/grid/applicability/
https://www.selenium.dev/documentation/grid/components/
Thank you for reading!