JMXPress

Performance engineering workbench

Everything around the JMeter run

Record a journey, turn it into a test plan, run it across your own machines, watch the application while it runs, and keep a report that outlives the run.

Get started Read the docs

One workbench, three engines: JMeter · k6 · Gatling

app.jmxpress.in/apm/monitor
Service response time ms 3,444
19,35415,01110,6686,3251,98201:50 PM02:20 PM02:50 PM
Request count count 16.0
34.126.519.011.53.9201:50 PM02:20 PM02:50 PM
Error rate percent 0
1.160.580-0.58-1.1601:50 PM02:20 PM02:50 PM

Service response time

ms latest 3,444 · min 2,320 · avg 7,585
19,35415,88012,4058,9315,4561,98201:48 PM02:03 PM02:18 PM02:33 PM02:48 PMTime
19,35415,88012,4058,9315,4561,98201:48 PM02:03 PM02:18 PM02:33 PM02:48 PMTime
19,35415,88012,4058,9315,4561,98201:48 PM02:03 PM02:18 PM02:33 PM02:48 PMTime
Line Area Bar
Every metric the provider exposes, charted side by side. Open one to read the numbers off it. Line, area or bar - the same data, drawn how you need it.

The work around a load test, in one place

A recorder, a spreadsheet of test data, somebody’s laptop, a monitoring tab nobody saved and a results file emailed afterwards. JMXPress keeps them together and attaches them to the run they belong to.

  1. Record or bring a plan

    Capture a journey in a browser, or bring a JMX, a Postman collection, a HAR file or an OpenAPI specification.

  2. Set the load and the data

    Threads, ramp, duration, the CSVs the plan reads, and which machines generate the load.

  3. Run it and watch

    Live client-side figures from the run, and server-side metrics from your APM for the same window.

  4. Keep the report

    A report that outlives the run, with the monitoring that was collected alongside it.

What it does

Every one of these is in the product today.

Record a journey

Capture a real user journey through a browser and turn it into a test plan, without writing one by hand.

Run the test

From one machine or several, with the load profile and the test data the plan actually needs.

Watch it while it runs

Client-side figures from the run, and server-side figures from the application under test, side by side.

APM monitoring

Connect the monitoring you already pay for, and keep what it said about each test.

Reports that outlive the run

What happened, in a form you can send to somebody who was not watching.

Diagnostics

When a run shows a problem inside the application rather than in front of it.

See everything it does
The JMXPress Run page, where a test plan, its load profile and the machines it runs on are set before a test starts

While it runs

Both sides of the same test

Client-side figures come from the results file as JMeter writes it: samples, errors, throughput and percentiles. Server-side figures come from the APM you already use, for the window the run occupied.

They are kept apart on purpose. One is what your load generator saw from outside; the other is what the application said about itself. The difference between them is the network and whatever queues in front of it.

  • Readings only — a gap in the data stays a gap
  • Each provider’s own rate limits respected
  • The monitoring is kept with the run’s report

APM monitoring

Connect the monitoring you already pay for

A read-only credential is enough. It is sealed with a key held outside the database row, and is never sent back to a browser, written to a log, or put into a generated test plan.

Dynatrace AppDynamics Datadog New Relic AWS CloudWatch Azure Application Insights

Start with a recording

The quickest way in is to record a journey and run it. The documentation walks through it from an empty account.

Get started Getting started guide