As and when the size of a Grid farm starts increasing, you will start having to worry about a lot of things.
Since the Hub is the single point of interaction for a test with an actual node on which all the browser interactions are carried out, all tests end up bumping up the network traffic on the Hub. So when the hub starts to manage say 50 (or) above Selenium nodes wherein each of the node on an average serves 10 concurrent sessions, the number of interactions that the hub has to have with all its nodes in peak traffic is roughly around 500 (This can be equated to 500 Http calls running back and forth).
The latest version of Talk2Grid brings in a new utility which basically has the ability to enrich your current RemoteWebDriver instance with the ability to toggle between the Hub and Node when it comes to routing browser interaction operations.
This new enrichment causes your RemoteWebDriver instance with :
- The ability to route all browser interactions directly to the node on which the session was created.
- Talk to the hub only when your test signals an end by invoking RemoteWebDriver.quit()
This enrichment greatly reduces the network load on the Hub machine. But it also has its own set of issues :
The Hub uses the below two parameters to decide which of the sessions should be marked as stale/timed-out/hung and be cleaned up forcibly from the server side.
- cleanUpCycle – This parameter can be set at the Hub side. This is usually set in milliseconds. When set, this value determines how often should the Hub poll against all its proxies (Remember that a proxy represents one node in the Selenium Hub farm), to check which of its sessions have gone stale/hung and then clean-up those sessions.
- timeout – This parameter can be set at the Hub side. This is usually set in seconds. When set, this value represents the maximum time the hub will wait before marking a session as idle.
In the traditional fashion since all the test requests go via the Hub, the Hub manages the sessions and their validity internally. But now that we are going to re-direct all the browser interactions from the tests directly to the node, we need to ensure that the values for the above two parameters are provided such that, its greater than the time it takes to run one test case on an average.
Code samples and more information is available on GitHub.