When I play a script in the editor, where does the script traffic originate?

Before launching a load test, it’s smart to play your script in the editor with a single bot, just to make sure the script is working correctly. This saves you the time and expense of running a load test with a broken script.

When you play a script in the editor, you’ll see live feedback as the steps are executed, but the bot traffic isn’t actually coming from your web browser. Instead, it’s coming from a Protocol Bot or a Browser Bot running on one of our engines. The bot runs the script and streams back the results to your browser so you can see what’s going on.

Normally these bots live on one of our shared engines in North America, Europe, Asia, South America, and Australia. The location is chosen somewhat at random each time you play your script.

But if you need to run your scripts from a specific location, you can configure it.

Specifying a cloud region for script playing

If you’d like to play from a specific cloud region, you can do so in Settings by choosing that region from the Script Player dropdown. Loadster will always try to play from your preferred region. Occasionally if the script player in that region is over-utilized or having trouble, we might have to fall back on AWS Lambda or a different region, but this is rare.

Specifying a self-hosted engine for script playing

If you have a self-hosted Loadster Engine, you can play scripts from it too. This is often necessary if you need to hit a site that’s running on a private network, inaccessible from our public cloud regions. Your self-hosted engines will appear in the same Script Player dropdown on the Settings page, and you can choose them the same way.

AWS Lambda fallback when a script player is unavailable

Each of our shared script players is a dedicated machine with a fixed IP address, which you’ll see next to its name in the Script Player dropdown. If that machine is unavailable (maybe it’s overloaded, restarting, or having network trouble), Loadster might play your script on AWS Lambda in the same or a nearby AWS region instead.

The same fallback applies to monitors running from that location, so your monitoring keeps going even if one of our machines is having a bad day.

Most of the time you won’t notice the difference, with one exception. Traffic from AWS Lambda comes from Amazon’s IP ranges for that region, not from the script player’s fixed IP address. If your firewall only allows the script player IPs, requests can be blocked while the fallback is in effect.

Playing scripts from a fixed IP address with a self-hosted engine

If your script traffic always needs to come from a known IP address, a self-hosted Loadster Engine is the most reliable option. Self-hosted engines never fall back on AWS Lambda. If a self-hosted engine is offline, scripts and monitor cycles that depend on it won’t run until it comes back.

Another option is to allow traffic based on a special header instead of an IP address, as described in whitelisting IP addresses.