Guide

Browser Clouds

Overview.

Browser clouds are a centerpiece of the Perforator platform.

Launching hundreds or thousands of real browser instances on a single server is not technically possible from a hardware limitations perspective. So the only solution to apply a load on your website from managed and distributed browsers is to have a horizontal scaling via creating multiple servers instead of dedicating a single beefy machine.

Please just imagine how many hardware resources you need to start 10k concurrent browser instances. Real-world numbers would begin from 10K CPU cores and 10TB of RAM, no joking here.

Perforator takes care of all the pain related to the management of the browser clouds. You can focus on the actual logic of the load test while Perforator handles the rest:
- Provision hardware resources required for the load test.
- Start and stop browser clouds on top of such hardware resources.
- Distribute browser sessions across multiple servers and regions.
- Automatically capture and analyze networking activity from browser sessions.

Actual communication with the browsers in the cloud is done via industry-standard Selenium (WebDriver) protocol.

Note: All browser clouds are created for single-tenant use, so all hardware resources within the browser cloud are allocated for your use only without being affected by noisy neighbors.
Architecture Diagram

Flow.

Perforator comes with a set of open-source load generators, and all such integrations take care of the communication with browser clouds via API.

1. Load generator you launch automatically requests a brand new browser cloud and awaits its readiness when you start a new performance test.

2. Platform automatically calculates how many servers have to be provisioned and distributed across different regions according to requested browser concurrency.

3. Platform automatically starts servers and makes sure that all instances are healthy. It automatically replaces unhealthy ones behind the scene.

4. Platform automatically adjusts our own load balancer via exposing dedicated Selenium hub endpoint and connecting it to remote servers. All communication with remote browsers is done via selenium protocol, and such a dedicated hub endpoint handles selenium requests.

5. Load generator requests and orchestrates brand-new browser session in the cloud for every concurrent iteration. The load generator automatically starts a new browser session whenever a previous one is terminated, either normally or exceptionally. For example, if load generator concurrency is 1000, then 1000 concurrent browser sessions will be active at any given moment of time. Note: There are some exceptions to such rules during ramp-up and ramp-down phases, but this is configurable via dedicated settings on the load generator side.

6. Load generator sends commands/actions to remote browsers according to your own load testing scenarios and logic.

7. Perforator automatically captures all networking activity from browsers in the cloud so that you can filter, aggregate, and visualize it later.

8. Perforator automatically terminates browser cloud at the end of the performance test.
Execution Log Screenshot

Location.

Perforator automatically distributes all servers dedicated to your browser cloud across the following US-based regions:
- AWS us-east-1
- AWS us-east-2
- AWS us-west-1
- AWS us-west-2

Perforator tries to distribute all the servers evenly across regions, so your website should receive evenly distributed traffic from multiple locations.

For example, if your load test requires 1000 concurrent browsers, then please expect the following distribution:
- 250 browsers in AWS us-east-1
- 250 browsers in AWS us-east-2
- 250 browsers in AWS us-west-1
- 250 browsers in AWS us-west-2

Characteristics.

Whenever you launch a new browser cloud, every browser within such cloud has the following characteristics:
- Browser type: Chrome
- Browser version: 121.0.6167.85
- CPU: 1 dedicated virtual core, 3GHz
- RAM: 1GB
- Networking: at least 50Mbps

Note: Perforator takes care of browser upgrades, releasing new version once new Chrome stable is available for the public and well tested within the platform. Usually, it takes around a month, but some delays might happen if we see unstable behavior.

Details.

You can see essential information about the launched browser cloud on the execution details page.

Browser Cloud Key
Unique identifier of the browser cloud.

Browser name
Name/Type of the browser. It is "Chrome" for all browser clouds currently.

Browser version
Browser cloud uses this version for all browsers. Browser cloud can only start the most recent version, i.e., there is no option to use an outdated browser version.

Capacity
Browser cloud capacity, i.e., how many simultaneous browser sessions can be running at any given time.

Requested Duration
The maximum amount of time browser cloud stays OPERATIONAL generating a load on the target system. Browser clouds are allocated using hourly increments.

Utilization
Amount of credits deducted from your account to start such a browser cloud. It is calculated as Capacity multiplied by Requested Duration. Note: Perforator deducts at least 16 credits, even if you launch a test with lower concurrency. Enterprise-level contracts might have negotiable minimums.

Status
Status of the browser cloud. Please see the following section to understand better all the different stages.

Requested At
Timestamp, when the browser cloud was requested.

Ready At
Timestamp, when the browser cloud became serviceable, i.e., OPERATIONAL. The actual logic of the load test started executing at this time.

Terminating At
Timestamp, when the browser cloud was requested to be terminated.

Terminated At
Timestamp, when the system completely turned off the browser cloud and cleaned up its associated resources.

Actual Duration
Duration of the browser cloud when it was serviceable. It is calculated as Terminating At minus Ready At.

Note: All timestamps are formatted according to the local timezone of your browser.

Statuses.

Browser cloud proceeds through multiple dedicated stages during its lifecycle, beginning when you request a new browser cloud till its complete termination.

QUEUED

Such status is a default when Perforator receives a request to provision a new browser cloud. The platform has a pretty big hardware capacity, but it is still limited, so we process all browser cloud requests in FIFO order. Browser cloud stays queued till we have enough available resources to fulfill your request.
Note: Credits(browser hours) are returned back to your account if you cancel the browser cloud while it is still queued.

PROVISIONING

Perforator has enough hardware resources and began starting servers to back your browser cloud. The system automatically applies health checks to ensure that all servers are fully functional.
Note: Credits(browser hours) are returned back to your account if the browser cloud can't be initialized successfully, for example, due to hardware errors.

OPERATIONAL

Browser cloud is fully serviceable at this time, i.e., it can process browsers related commands and actions. The cloud stays serviceable when it becomes operational up to the requested duration. Load generator begins generating actual load on the target system only when the browser cloud is ready.

TERMINATING

Perforator has begun stopping servers associated with the browser cloud. Termination starts in the following cases:
- Unsuccessful provisioning.
- The load test is finished.
- The browser cloud is expired according to the requested duration.
- Manual emergency shutdown from UI.

TERMINATED

Perforator has completely shut down all servers associated with the browser cloud. It might take a few minutes to clean up all associated resources.

Emergency shutdown.

There might be unexpected cases when the load generator you launched became unresponsive, but you need to shut down the browser cloud to prevent the target system from overloading.

Perforator allows you to terminate browser cloud manually via web UI to support such a case.
Note: Terminate button is available only when browser cloud is QUEUED, PROVISIONING, or OPERATIONAL.
Previous Chapter: Executions
Next Chapter: Codeless Load Generator