CLI Power User, DevOps & Product Guide

Futuristic Webload is designed for high-fidelity browser automation and load testing. Unlike traditional tools that rely on fragile selectors, our engine uses AI-assisted deterministic replay to ensure stability across releases.

The Core Workflow

Follow these steps to go from zero to a 10,000-user load test:

1. Record (The Blueprint)

Use the local UI to record your browser session. Every click, scroll, and network request is captured with high precision. The result is a recording.json file.

2. Approve & Harden

Open the recording in our visual editor. Approve the steps, inject databank parameters (CSV/JSON), and add validation checkpoints. This "Approval" phase ensures the script is bulletproof before scaling.

3. Replay (Local or Sharded)

Execute the script using load-test.exe. Start with a single user (-runXUser 1) to verify logic, then scale using shard-run.exe for distributed on-prem execution or our Cloud Run service.

4. Analyze & Ingest

Use the Runs-Manager to view real-time reports. Ingest results into your database using the Import Engine to build custom dashboards in Grafana or PowerBI.

The runs-manager.exe is a high-performance control hub built on the .NET Kestrel engine. It serves as the bridge between your local test environment and your enterprise data infrastructure, handling everything from real-time UI serving to massive-scale SQL ingestion.

1. High-Performance Control API

Runs-Manager exposes a RESTful API for controlling your local cluster. It uses the Kestrel web server for maximum efficiency. You can control its binding and visibility via standard CLI arguments:

• Default Binding: http://127.0.0.1:5057
• Localhost Enforcement: For security, the server rejects any connection not originating from the loopback address.
• Port Override: Use runs-manager.exe --urls "http://127.0.0.1:8080" to change the service port.

2. Database Import Engine (The DevOps "One-Shot")

Designed for CI/CD pipelines, this mode allows you to ingest an entire run's results into your database with a single command. It supports MSSQL, MySQL, and Oracle.

runs-manager.exe -ImportToDatabase \
  -Database mysql \
  -ConnectionString "server=localhost;user=root;password=...;database=fwl_results" \
  -WebLoadDir "C:\Runs\run-001" \
  -TableMappingsJSON "mappings.json" \
  -TableConflictPolicy FailAllOnAnyBlockedTable

mappings.json Structure

Use this JSON to map specific test datasets (TSV files) to your enterprise database tables. Any dataset not in the mapping will use the default FWL_<name> convention.

{
  "http_report.tsv": "Production_Traffic_Logs",
  "steps_report.tsv": "QA_Test_Steps_Historical",
  "js_errors.tsv": "Frontend_Regressions",
  "navigation_vitals.tsv": "UX_Performance_Metrics"
}

Advanced Import Logic

3. Auditability & Correlation

Every row imported into your database is enriched with metadata for easy correlation with CI/CD build IDs:

• import_batch_id: A high-precision timestamp (yyyyMMddHHmmssfff) representing the ingestion session.
• source_file_rel: Tracks exactly which shard or worker produced the data.
• source_row_no: Enables deep-diving back to the original local TSV log for debugging.

shard-run.exe is a specialized wrapper designed for Massive Scale. It abstracts the complexity of manually calculating user offsets and slot IDs across a cluster of VMs.

shard-run.exe -shardsConfig shards.json -- -replay recording.json -runXUser 100

1. Shards Configuration (shards.json)

This file defines the workload distribution for the specific node. It is typically generated by your CI/CD pipeline (Jenkins/GitHub Actions) or a master orchestrator.

{
  "userStart": 1,
  "usersInShard": 50,
  "runGroupId": "Global-Load-Test-May-2026"
}

2. CI/CD Orchestration Contract

When Shard-Run executes, it enforces a standard environment contract to ensure results are correctly grouped in the cloud or database:

• RUN_SLOT: Automatically set to worker-<N> based on the node index.
• FWL_RUN_ID: Propagates the runGroupId to all child processes.
• FWL_SYNCPOINT_WORKERS_DIVISOR: Configures the synchronization barrier for workers.

The core load-test.exe engine is built for reliability. It follows a strict precedence contract: CLI Flags > JSON Script Config > Environment Variables.

1. Installation & Environment Prep

Before running load tests, ensure the Chromium engine and OS dependencies are installed on your worker nodes.

// Windows / PowerShell
.\OS_Scripts\Install-Playwright-Chromium.ps1 -BinDir "C:\FWL\bin"

2. Base Commands

3. Replay & Orchestration Options

These flags control the concurrency, speed, and behavior of the browser workers.

4. Advanced Orchestration (Internal Contracts)

Used primarily by shard-run or cloud orchestrators to manage sync points and distributed state.

5. Vitals & Metrics Tuning

Control the overhead of telemetry collection for massive scale runs.

6. The Deterministic Engine

Futuristic Webload differs from traditional tools by using a Time-Independent Replay logic. Instead of hardcoded "Wait 5s" commands, the engine observes the state of the DOM and the network to determine when it is safe to proceed, ensuring your tests don't flake during server-side lag.

Sync Points

In distributed runs, workers can be configured to "Wait for Go" at specific steps. This allows you to coordinate 10,000 users to click "Submit" at the exact same millisecond, creating a true peak-load spike.

7. Environment Fallbacks

8. Practical Examples

Multi-Environment Testing

Run the same recording.json against different environments without modifying the script:

// Test against Staging
load-test.exe -replay recording.json -baseUrlOverride "https://staging.myapp.com"

// Test against Production
load-test.exe -replay recording.json -baseUrlOverride "https://prod.myapp.com"

Extreme Load Optimization (10k+ Users)

When scaling to massive numbers, disable all heavy telemetry to minimize node CPU/RAM usage:

load-test.exe -replay recording.json -runXUser 200 -noVitals -noBrowserSnapshot

Longevity & Soak Testing

Keep the load constant by recycling databank users indefinitely:

load-test.exe -replay recording.json -runXUser 50 -recycleUsers

Headful Debugging

Watch exactly what the browser is doing during a failure:

load-test.exe -replay recording.json -withUX -replaySpeed 0.5

Using External Databanks

Inject a fresh dataset without touching your main script file:

load-test.exe -replay recording.json -databankFile "prod_users.json" -useDatabank random

1. mTLS / Client Certificates

Futuristic Webload supports secure handshake protocols for high-security environments.

2. Futuristic Captcha Bypass

The bypass flow uses signed JWT tokens issued by our service. Tokens can be provided via:

• CLI flag -captchaBypassLicense
• Environment variable FWL_CAPTCHA_BYPASS_LICENSE
• Local license file at ./Licenses/FWL_CAPTCHA_BYPASS_LICENSE.txt

Our model is built for flexibility, catering to both occasional testers and large-scale enterprise performance teams.

1. Prepaid Tokens

Every action in the Futuristic ecosystem (Cloud Runs, AI Analysis, Identity Injections) consumes Tokens. Tokens are prepaid and never expire.

• Cloud Run Tokens: Scaled by execution time and concurrency.
• AI Analysis Tokens: Consumed per report generated or log analyzed.
• Identity Tokens: Consumed when using the Identity Injection Service for complex auth flows.

2. Subscription Tiers

While tokens handle consumption, subscriptions unlock advanced platform features:

• Community: Free local execution, limited AI support.
• Pro: Full AI integration, high-concurrency cloud runs, priority support.
• Enterprise: Dedicated infrastructure, SSO, custom data retention policies, and mTLS v2 support.

Q: Why does the browser say "Not Secure" during certificate replay?

Playwright uses an internal TLS proxy to inject your Client Certificate into the handshake. This triggers a standard browser warning because the proxy uses a self-signed cert for the local intercept. Your connection to the actual server is secure, and the certificate is passing correctly.

Q: How do I handle 10,000+ concurrent users?

Use shard-run.exe to distribute the load across multiple VM nodes. We recommend max 100-200 users per node depending on your CPU/RAM specs.

Q: Does the AI see my source code?

No. By default, the AI only has access to the run artifacts (TSVs, logs, screenshots). It does not access your source code or internal network unless you explicitly grant read-only folder access via the Runs-Manager settings.

Q: How do I disable all logs for peak performance?

Use the -noVitals and -noBrowserSnapshot flags. This minimizes disk I/O and CPU overhead during massive load tests.