This is an older technical note about using Ruby to define JMeter load tests.
The tooling has aged, but the idea still holds. Keep load-test scenarios in code, run them headlessly, and make the output repeatable enough to compare changes.
Why JMeter
JMeter is not fashionable, but it remains practical for HTTP load testing.
It can run without the GUI, produce machine-readable output, and exercise an application with concurrent requests.
The GUI helps when inspecting results. It should not be required to run the test.
Define the scenario in Ruby
The ruby-jmeter gem provides a Ruby DSL for generating and running JMeter tests. A small smoke scenario can look like this.
auth_token = ENV.fetch("SPREE_API_TOKEN")
test do
threads count: 10 do
header(name: "X-Spree-Token", value: auth_token)
visit name: "Products listing",
url: "http://localhost:3000/api/v1/products.json"
end
end.run
The original example used Spree Commerce because it was a real Rails application with an API and seed data.
The important part is not Spree. The important part is testing against an application shape close enough to the one you operate.
Run without the GUI
For repeatable runs, configure JMeter to emit a summary.
summariser.name=summary
summariser.interval=180
summariser.log=true
summariser.out=true
Then pass the properties file when running the test.
The output is not a full performance report, but it is enough to see request volume, average latency, min and max latency, active threads, and error percentage.
What this is good for
This setup works well for:
- creating a repeatable load-test scenario.
- keeping the scenario close to application code.
- running a quick comparison before and after a change.
- producing JMeter output that can be inspected later.
It is not a replacement for production observability or realistic capacity planning.
What to measure
Do not stop at average response time.
Look at errors, tail latency, saturation, database behavior, queue behavior, and external service calls.
A load test that only proves the happy path at low concurrency is a demo. A useful test should tell you what breaks first.