The primary purpose of Browser Synthetic Monitoring is to perform browser-based testing. To help you test browsers in the locations of your users, Browser Synthetic provides agents in locations around the world. Your scripts, however, are run in a separate location for the security reasons discussed in the next section.
Security Considerations for Scripting
The browsers configured in synthetic jobs are run on shared Windows machines. Because synthetic scripts are written in native Python, they are not run on the shared Windows machines. Instead, each synthetic script is executed in isolation within a Docker container in a location mapped to the configured browser location. This isolation of the agents and scripts guarantees the safety of the data handled by the scripts and has no effect on the performance of the agent.
How This Affects Your Synthetic Jobs
You should understand how the locations of the agent/browser and where the script is executed may affect your synthetic job. For example, if the location of the execution container and the configured browser are not in the same region, you may expect to see some network latency. Also, if you are using the Python Requests library to make HTTP requests, you should know where the request is being made from.
The following sections provide some insight as to how your job may be affected.
URL Measurements are used to test site availability and will not be affected because no script is being executed.
Your script can use different libraries to make HTTP requests. The WebDriver API is used to mimic the browser making HTTP requests. To make cURL-like requests to test REST APIs or to retrieve data, you can use an HTTP library such as the Requests library. The tables below describe how the script is executed and the types of problems you may encounter.
|Script Execution Flow
The WebDriver API is used to test the functionality of web pages. You may experience network latency between the execution of the script and the results if the locations of the Docker container and the browser are different.
Because the script is running in a different location, network latency may increase the time to complete the execution of the script. The browser test results collected through this process, however, are not affected by this latency, and thus, the results will be reliable.
|Script Execution Flow
If you are using something other than WebDriver to make HTTP requests, such as the Requests library, you should know where the HTTP request is being made from.
You should also understand that the Controller UI only captures browser metrics, so you may want to capture output from your requests in the script console.
Mapping of Execution Containers and Browser Locations
The table below lists the available browser locations as well as the corresponding provider and container location.
|* Browser Location
US East (N. Virginia)
|London, United Kingdom
|Hong Kong, China
|Asia Pacific (Tokyo)
|Seoul, South Korea
|Asia Pacific (Singapore)
|Asia Pacific (Sydney)
|US West (Oregon)
|San Francisco, California
|Sao Paulo, Brazil
|San Antonio, Texas
*Some of the locations are enabled only based on requests in the new regional clouds. To add missing locations in any regional cloud, raise a support ticket with the list of required locations.
Hosted Agent Coverage Variations
Synthetic hosted agents have the following coverage variations:
- The US EUM cloud has access to both AWS and Azure locations.
- The Frankfurt EUM cloud has access to only AWS locations.
- The Sydney EUM cloud has access to only AWS locations.
The Bombay EUM cloud has access to only AWS locations.