Start with a question, not a tool
“Let’s check performance” isn’t enough to plan a test. You need a question a number can answer: will the cart handle traffic from the campaign, how many users can the API take before response times stop being acceptable.
A good goal has three parts:
- load: how many users or requests per second,
- threshold: for example, 95% of responses under 800 ms,
- error margin: for example, fewer than 1% of requests failing.
These numbers are examples. Take yours from production data or business assumptions.
Types of tests
- Load test checks behaviour under expected traffic.
- Stress test looks for the point where the system starts to break.
- Soak test holds a steady load for many hours and reveals memory or connection leaks.
- Spike test checks a sudden jump in traffic, for example after a newsletter goes out.
A load test of a few key services is enough to begin with.
The JMeter test plan
A basic plan has a few elements:
- Thread Group: the number of virtual users, ramp-up and duration,
- HTTP Request: requests to the endpoints under test,
- HTTP Header Manager: headers, such as the authorisation token,
- CSV Data Set Config: test data, so each user logs in to a different account,
- Assertions: checks of the response code and content, because a fast 500 is still an error.
Set the ramp-up so traffic grows gradually. Starting every user in the same second tests the server accepting connections more than the application.
Run it without the GUI
The JMeter interface is for building the plan. Run the test itself from the command line, because the GUI uses resources and distorts the results:
jmeter -n -t plan.jmx -l results.jtl -e -o report/The -n flag turns off the GUI, -l saves the raw results and -e -o generates an HTML report. The report directory must be empty.
The load generator shouldn’t run on the same machine as the system under test. Otherwise you’re measuring two applications fighting over the CPU.
How to read the results
Average response time hides problems. If 90 requests take 100 ms and 10 take 5 seconds, the average looks tolerable, while every tenth user waits a very long time. So look at:
- percentiles (p95, p99): how long the slowest-served users wait,
- throughput: how many requests per second the system actually handles,
- error rate: it usually grows with load,
- server resources: CPU, memory, database connections.
The moment throughput stops growing while response times climb points to the bottleneck.
Environment and data
Results are only as good as the environment. A test on a small instance with an empty database won’t tell you much about production. In one of my projects I ran performance tests of key backend services under simulated production load. Preparing realistic traffic is usually the most laborious part of such a test.
Record the application version, the configuration and the input data. Without them you can’t compare two runs.
Summary
A first performance test doesn’t have to be big. One question, a few services, gradual ramp-up and watching p95 instead of the average already give you a useful answer. If you want to check your system before an important release, describe your project.