Within our small, yet dynamically developing company we test hundreds of tasks every day. They are all checked in test environments as well as in environments which are closer to real situations. The vast majority of tasks connected with the web are checked using our wide range of autotests.
Around six months ago, the number of tests and tasks grew to the point where our little Selenium farm was struggling with the number of requests from new Firefox or Chrome sessions at peak times. It looked something like this: a queue builds up on the Selenium grid from sessions waiting for a free browser. Users continue to launch autotests, and this queue continues to grow, while browsers busy with old tasks and sessions lag behind with timeouts.
At that time, the maximum number of nodes divided between Firefox, Chrome, Internet Explorer and PhantomJS was around 200. One of the options I came up with for solving this problem was to monitor the number of free nodes prior to testing and then hold tests back using setUp() until more free nodes became available.
The format of the request is pretty nifty: it’s a GET request with a body. For the tests we’ll use cURL and check what the command will return:
In our company, all tests for Selenium are written in PHP and a similar request here will look like this:
In theory, tests requested in setUp() for a defined number of slots and waiting sessions could be put on hold. However, this is not so convenient if your resources are unevenly distributed over different browsers. For example, at Badoo the number of nodes for Firefox is a third larger than those for Chrome, Internet Explorer and MS Edge which use only around 10 nodes (and these can be divided by version). It looks like there are probably no more nodes left for Chrome, although Selenium Grid says that there are still free nodes available.
So now we know which browsers are free and in what quantity they are shown in the Selenium Grid. All that remains is to check the setup() method (or similar):
carry out a check for the number of free nodes;
in this test, we added a short waiting period (for example, two minutes) before the test times out;
remember that these parameters don’t need to be requested every second.
For us, it now looks like Selenium tests run a little slower at peak hours, but are overall far more stable. Considering that we have several hundred tests launching automatically, this idea has made life a lot simpler for those in our company working on tests.