Can I run my existing JMeter .jmx file without changing it?

Yes. Upload the .jmx your team already maintains and it runs as it is. JMeter is a first-class project type on HyperExecute, so there is no rewrite, no proprietary scripting language, and no re-validation of a plan you already trust. Whole folders are supported, which is how a plan and its CSV data files get uploaded together.

Why did my run generate more virtual users than my plan specifies?

By default the thread count inside the .jmx is replicated onto every machine in every region rather than divided across them. A 250 user plan running on 3 machines in each of 2 regions generates 1,500 virtual users, not 250. Set the Total Load Distribution overrides in the portal and the platform divides users proportionally instead. Check this before the first billed run.

How many virtual users can a single test reach?

Concurrency is a plan entitlement: 100 concurrent virtual users on Free, up to 2,000 on Basic, up to 8,000 on Pro, and a custom figure on Enterprise. What you actually achieve inside that ceiling depends on what each virtual user does. Browser-driving samplers reduce it, as do missing HTTP timeouts, large payloads, and long chained workflows. A plan built from lightweight HTTP samplers with explicit timeouts reaches far more than one that drives a browser per user.

Which regions can generate load?

Six named regions are documented: East US in Richmond, Virginia, which is the default, West US 2 in Moses Lake, Washington, Central India in Pune, Southeast Asia in Singapore, Brazil South in Sao Paulo State, and Mexico Central in Queretaro State. You set the split as a percentage of total users per region. Multi region load generation is an Enterprise plan entitlement; Free, Basic and Pro run single region.

Can I trigger a JMeter run from my CI pipeline?

Not directly. JMeter on HyperExecute is configured through the Projects portal and there is no CLI or YAML path for it. Gatling is the format that runs from both the portal and a hyperexecute.yaml committed in your repository, so a git-driven load pipeline should use Gatling. The JMeter flow is eight fields and a Run button with no YAML to learn.

How is my test data distributed across load generators?

Turn on Split CSV and each generator reads a unique slice of the input file, so parallel executions are not all replaying the same rows. Without it, every machine starts at row one, which measures your cache rather than your system. The same run configuration also carries Job Labels for tracing a run back to a build.

What reports do I get after a run?

Five: a Summary Report covering virtual users, ramp-up, average response time, throughput, bandwidth, regions and duration, a Timeline Report, Request Stats, an Errors report grouping codes and counts with their sample distribution, and Logs. Metrics can be toggled between milliseconds and seconds.

Does this cover browser or UI performance?

No. This is protocol level load testing, which measures what your servers do under concurrent request volume. For what a user actually sees in the browser, run Selenium or Playwright on the automation cloud instead. Both run on the same platform, so the split costs you nothing operationally.

Which Java versions are available?

Java 11, which is the default, and Java 25. Those are the two options offered on the run form. Two JMeter user properties are also overridable per run: jmeter.save.saveservice.subresults, which you set to false to shrink results files under heavy load, and httpclient.socket.https.cps, which caps characters per second on HTTPS downloads.

Do I need to keep load generator infrastructure running?

No. Generators are provisioned when a run starts and destroyed when it finishes, so there is no fleet sitting idle between tests and nothing to patch. That is the difference from a self-hosted JMeter master and slave setup on cloud VMs, where the coordination and the idle cost are yours. Concurrency is drawn from your plan pool. If you are weighing this against a managed JMeter service you already pay for, the BlazeMeter alternative comparison sets the plan ceilings and metering side by side.

JMeter Cloud Load Testing

Upload the .jmx your team already maintains. TestMu AI provisions the load generators, drives the run, and tears the infrastructure down when it finishes.

Start free with Google

Start free with Email

Automate Browser Flows from your
Terminal with Kane CLI

Explore Kane CLI

Trusted by 3M+ users globally at

+Read case study

Run the Load Plan Your Team Already Maintains

JMeter is a first-class project type on HyperExecute. Existing .jmx plans run without a rewrite.

Start free with Google

NO REWRITE

Upload the Plan You Maintain

Create a JMeter project, upload the .jmx and its CSV data files, and save. Whole folders are supported.

Start free

Existing .jmx test plans run without a rewrite.
Standard and custom JMeter thread groups both work.
Java 11 by default, or Java 25, chosen at run time.

EIGHT FIELDS

Configure Load in Eight Fields

Set total users, duration, ramp-up, machine count, regional split, Split CSV, job labels and Java version.

See the field reference

Split load across six regions as a percentage of users.
Split CSV gives each generator its own slice of test data.
Job labels trace a run back to a build or scenario.

FIVE REPORTS

Five Reports for Every Run

Summary, Timeline, Request Stats, Errors and Logs land against the job as soon as the run completes.

Start free

Response time, throughput and bandwidth per run.
Errors grouped by code, count and sample distribution.
Toggle reported metrics between milliseconds and seconds.

Before your first billed run

Do the Virtual User Math First

By default HyperExecute replicates the thread count in your .jmx onto every machine in every region rather than dividing it. We put this first because it is the single most expensive surprise in distributed load testing, and it is the detail we found missing from every vendor page we reviewed while building this one. A plan written for 250 users, run on 3 machines in each of 2 regions, fires 1,500 virtual users and bills six times the virtual user hours you expected.

Users in plan

250

Machines per region

Regions selected

Actually generated

1,500 VU

Set the Total Load Distribution overrides and the platform divides users proportionally instead. 500 users across 2 regions at 50 percent each becomes 250 per region, packed evenly across machines as 84, 83 and 83, without exceeding the maximum users per machine threshold.

What Erodes Achievable Load

Your ceiling is whatever your plan entitles: 100 concurrent virtual users on Free, up to 2,000 on Basic, up to 8,000 on Pro. Inside that, browser-driving samplers pull the achievable figure down, along with missing HTTP timeouts, large payloads, and long chained workflows. Size a run against that list, not against a headline number.

Where the Scope Ends

This is protocol level load testing. It answers what your servers do under concurrent request volume, not what a browser renders. For UI behaviour, run Selenium or Playwright on the same platform.

JMeter or Gatling on the Same Runner

Start free with Google

Both plan formats are supported natively. They are configured through different surfaces, so pick by how your team works.

JMeter

Gatling

Plan format

.jmx

Java DSL .java simulation

Portal path

Yes, and it is the only path

Yes

hyperexecute.yaml and CLI

Yes

Load shaping

Portal form, eight fields

Portal form or system properties

Reports

Five named reports in the dashboard

Gatling HTML, collected as a job artifact

Run config versioned in your repo

Yes, beside the simulation

Existing plans run unchanged

Yes

One Platform for Load and Functional Runs

The grid that runs your load plan already runs your Selenium, Playwright, Cypress and Appium suites.

HyperExecute

Automation Cloud

KaneAI

Real Device Cloud

HyperExecute

The orchestration cloud that runs your load plans and your functional suites on the same grid.

More about HyperExecute

Performance Workload

JMeter and Gatling plans run as a first-class job type, not a workaround.

Managed Generators

Load machines are provisioned per run and destroyed when the run ends.

Job Artifacts

Reports and logs are collected against the job for every execution.

Performance Testing Plans and Limits

Start free with Google

Concurrency, virtual user hours, load generators and test duration are all plan entitlements. Verified on the pricing page on 8 September 2026.

Free

Basic

Pro

Enterprise

Price, annual

$79 / month

$349 / month

Custom

Price, monthly

$99 / month

$449 / month

Custom

Concurrent virtual users

100

Up to 2,000

Up to 8,000

Customizable

Virtual user hours / month

100, introductory

2,000, introductory

8,000

Customizable

Load generators

Up to 2

Up to 20

Customizable

Max test duration

40 minutes

2 hours

6 hours

Customizable

Load regions

Single region

Multi region

Some Love from our Customers

As Best Egg expanded its product offerings and entered new markets, we knew our old testing infrastructure couldn’t keep up.
With support from Tenny Agustin, our Engineering Operations Lead, we modernized our approach with

TestMu AI

Best Egg

best-egg

Excited to Share My Learning Journey with Kane AI & Lambda Tool!
I'm pleased to announce that I've recently gained hands-on experience exploring Kane AI through the Lambda Tool and it’s been a fantastic journey of upskilling!

KaneAI

Suryateja Goud

suryateja-goud

See how is #Futureready to enable blazing-fast test orchestration seamlessly integrated with organizations' existing CI/CD platforms, using #Microsoft Azure.

TestMu AI