Executors

When you upload a script instead of using a scriptless builder, MaxoPerf runs it through one of many underlying load-testing and browser-automation tools. This page lists every supported executor, meaning every engine MaxoPerf can run a test with.

Executors, not a manual picker

MaxoPerf detects the executor from the file you upload. A .jmx is JMeter, a k6 .js/.ts is k6, a Taurus YAML’s executor: field names its own executor, and so on. You never pick the executor from a dropdown. Upload the right file, and MaxoPerf infers the executor and validates the scenario against its rules.

Scenario and files: MaxoPerf shows the detected executor as a badge once it recognizes the uploaded file. There is no manual executor picker.

Executor source of truth

packages/test-config/src/detect-taurus-executors.ts (SUPPORTED_TAURUS_EXECUTORS) defines the authoritative executor list. It is the single source of truth for the database engine-kind enum, the Platform API DTOs, and this page. When MaxoPerf validates your upload, it checks the executor value against this same list.

The full executor catalog

Executor	Underlying tool	Entrypoint file kind	Support level	Notes
taurus	Taurus native HTTP runner	.yaml / .yml (no executor: key, or executor: taurus)	First-class	The default when no executor: is set. Handles HTTP requests itself, with no separate engine. Good for simple HTTP load with a single declarative YAML.
jmeter	Apache JMeter	.jmx (referenced by scenarios.*.script) or direct .jmx upload	First-class	The most widely used executor. Upload your .jmx directly or reference it from a YAML. MaxoPerf validates JMX well-formedness and thread-group presence.
k6	Grafana k6	.js / .ts k6 script	First-class	Full k6 support via direct upload or a YAML reference. Your k6 script is the entrypoint.
selenium	Selenium WebDriver	.py script or Selenium IDE .side file	First-class	Real-browser tests (see Browser tests). Gets full video, step timeline, HAR, and console capture on Chrome/Chromium.
playwright	Playwright	.js / .ts / .mjs / .cjs / .mts / .cts Playwright spec or library script (any file name), uploaded directly or referenced by scenarios.*.script with executor: playwright	First-class	Real-browser tests on Chrome, Edge and Firefox, one or several per test. MaxoPerf tells it apart from other JavaScript executors by file content as well as extension. An uploaded playwright.config.* is wrapped, not replaced. Uses the same capture pipeline as Selenium tests (see Playwright tests).
gatling	Gatling (Scala)	.scala simulation file	Supported	Point scenarios.*.script at a Gatling Scala simulation. Runs through the Gatling execution path; configure Gatling-specific settings in the YAML rather than a dedicated console UI.
locust	Locust (Python)	locustfile.py or any .py with from locust import	Supported	Manages Locust’s master/worker topology and metrics collection. Upload locustfile.py as a test asset and reference it from the YAML.
apiritif	Apiritif (Python HTTP client)	.py Apiritif script	Supported	Python-native HTTP client framework with a recorder. Good for teams that prefer Python over YAML or JavaScript. Pure HTTP, not a browser executor.
wdio	WebdriverIO	.js / .ts WebdriverIO spec	Supported	Browser automation through the WebdriverIO JavaScript API. Coverage is similar to Selenium, without the dedicated capture pipeline.
robot	Robot Framework	.robot keyword-driven test	Supported	Runs Robot Framework keyword-driven tests as load. Good for teams already invested in Robot Framework.
siege	Siege	URL-list file or inline URLs	Supported	Simple multi-threaded HTTP benchmarking. Effective for quick URL-list hammering; limited scenario expressiveness compared to JMeter or k6.
ab	Apache Benchmark (ab)	No file (URLs specified inline in the YAML)	Supported	The classic HTTP microbenchmark. Good for single-endpoint baseline measurements; not suited to multi-step flows.
vegeta	Vegeta (Go)	.txt URL-list or inline targets	Supported	High-performance HTTP load generator with constant-rate (rate:) attacks. Better rate control than ab for sustained throughput tests.
tsung	Tsung (Erlang)	Tsung XML config	Supported	Distributed load testing for HTTP, WebSocket, XMPP, and more. Complex setup; use when you need Erlang-based distributed load or XMPP protocol support.
molotov	Molotov (Python asyncio)	.py Molotov scenario	Supported	Async Python load-testing library. Scenarios are Python functions decorated with @scenario.
grinder	The Grinder	.py Grinder script (Jython)	Supported	Java-based framework with Jython scripting. Legacy tool; prefer JMeter or k6 for new work.
junit	JUnit (Java)	Maven pom.xml or JAR	Supported	Runs Java JUnit load tests. Requires a Maven project structure; better suited to teams with existing JUnit performance tests.
testng	TestNG (Java)	Maven pom.xml or JAR	Supported	Like junit, using the TestNG framework. Same considerations apply.
mocha	Mocha (Node.js)	.js Mocha test file	Supported	Runs Node.js Mocha tests as load. Prefer k6 for new JavaScript load tests.
pbench	Pbench-fio / Pbench tools	Pbench config	Supported	Performance benchmarking suite from Red Hat. Niche use case. Use it when you need Pbench’s tooling in particular.
scalable	Scalable (internal)	YAML	Supported	An internal executor for distributed load-generation scenarios. Rarely needed, because MaxoPerf handles distribution at the runner-fleet level.
external	External process	Any command	Supported	Runs an arbitrary external process as the load generator. MaxoPerf validates that the command: key is set. Use only when no other executor fits.

This list is live

This table mirrors SUPPORTED_TAURUS_EXECUTORS. If you count a different number of rows than you expected, the code changed after the last update to this page, and the code wins.

Choosing between executors

Most new MaxoPerf tests should use one of the first-class executors:

• taurus (native): a single declarative YAML with no external tooling.
• jmeter: for teams with existing JMX files, or who need JMeter’s plugin ecosystem.
• k6: for teams that prefer JavaScript and want fast iteration on API load tests.
• selenium / playwright: for browser tests, see Browser tests.

The other supported executors work well but get less specialized console tooling. If you hit a problem with one of them, MaxoPerf support can help.

Specifying the executor in a YAML

execution:
  - executor: locust          # must be one of the executors listed above
    concurrency: 20
    hold-for: 5m
    scenario: locust-scenario

scenarios:
  locust-scenario:
    script: locustfile.py     # must be uploaded as a Test asset

Single executor per YAML

MaxoPerf enforces exactly one executor: value per YAML (or none, defaulting to taurus). If you need to run two different engines together, create two separate tests and combine them into a VarioTest.

HTTP error statuses on Apiritif requests

On the apiritif executor, a request fails when the response status is 400 or higher, the same as in JMeter. The sample is counted as an error, and the run’s Errors tab groups it under Client errors (4xx) or Server errors (5xx).

If you assert on the status yourself (an assert with subject: http-code, on a request, the scenario, or an included scenario), your assertion decides and the automatic check is off for every request in that scenario, not only the request you assert on. To expect an error status without an assertion, switch the automatic check off for the scenario:

scenarios:
  expect-errors:
    auto-assert-ok: false     # 4xx/5xx responses are no longer failures
    requests:
      - url: https://api.example.com/legacy

Scenarios that keep the old behaviour

A scenario that sets certificate (client certificates) keeps the previous behaviour: HTTP error statuses are not failures there.

Where to go next

• Performance tests: load-testing with any executor.
• Functional API tests: single-iteration correctness checks.
• Browser tests: real-browser tests with selenium or playwright.
• Scriptless test builders: build a test with no script.