Selenium 4 Grid Architecture

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!

Share On

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on tumblr
Share on email

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

Lifetime Membership Club

LIFETIME MEMBERSHIP BIG SALE - ALL LIVE COURES JUST - 10000 RS/149 USD
Attend All Live courses in just 10000 rs / $149 - offer ends 23rd March 2024