You’ve now seen how step can be used to build meaningful automation scenarios. However, one critical aspect still has to be covered: scalability.

Pre-requisites

• You’ve completed the local step installation guide
• You’ve completed the first execution guide
• You’ve completed the Chrome automation guide
• You’ve completed the real-world scenario guide

Parallel executions

Let’s now look at how concurrency can be implemented and managed in order to build a large-scale automation grid. Let’s go back to our plan and add concurrency on our ForEach artefact by increasing the number of threads to 2.

If you run the plan again, you’ll notice that two browser instances are now running concurrently during the plan’s execution.

There’s one last problem with our setup however: only one of the browser instances is shut down properly at the end of the scenario, which causes for instances to accumulate.

The reason is that errors (including FAILED steps) are propagated up the execution tree, and cause for certain parent nodes to terminate their execution, by default. In our case, the For loop performs all 10 failed runs but the Session node terminates immediately after, without invoking the call made to closeDriver.

We must therefore check the box “continue on error” on our root sequence node to tell step to continue with the execution anyway, which will allow the Session node to invoke the closeDriver Keyword even when previous steps have failed.

Both browsers will now correctly terminate.

Grid capacity

Let’s assume we now want to keep scaling our executions. Of course a single host will quickly run out of resources and won’t be able to handle the increasing workload indefinitely. You can check the current capacity of the entire platform at any given time by browsing the Grid view, which is accessed from the top-level menu.

In the screenshot above, you’ll see that your agent has a default capacity of 10 Tokens. A Token is an execution slot which can be reserved for Keyword execution. It prevents agents from overloading and allows users to calibrate them instead. For instance, an agent with over 16 CPUs at its disposal may be able to service and scale up to 32 tokens. Actual limitations and values obviously depend from the host’s capacity and the type of workload applied via Keywords.

Notice that during execution, tokens in use are marked accordingly, meaning that you can monitor in real time the effective capacity of your platform:

Scaling out

The good news is that adding agent to an existing setup is very easy. If you have a second host at your disposal, you may go back to our quick setup guide, install just the agent component from step onto this new host and edit its configuration file (under step-agent-x.y.z/conf/AgentConf.json) to change the default controller url value from localhost:8081 to <your_controller_host>:8080.

If you just want to get a sense of what a second agent would look like, you can also just start a second one on your local computer (without editing anything). You should then see a second entry in the grid view:

Scaling your grid in the cloud

step is also available as SaaS (Software as a Service), for this version you can set the desired agents easily in the step Portal either when creating a new cluster or for an existing cluster.