Your manager wants load test results next week, and you have never opened JMeter. You google "JMeter tutorial" and find 200 pages of English documentation that make your head spin. The deadline is closing in, the team has no experience, and you need something you can present to management.
Relax — you are not alone. This is where most QA engineers find themselves the first time they are asked to do performance testing. This article is a practical 6-step guide that takes you from nothing to a professional HTML report. In 30 minutes of reading you will know how to build a test plan, run a 50-concurrent-user load test, and interpret the results.
If you are not yet familiar with load testing as a concept, start here: What Is Load Testing? 7 Types of Performance Testing According to ISTQB.
What Is Apache JMeter?
Apache JMeter is an open-source, Java-based application built for performance testing web applications, APIs, and databases. JMeter simulates many users hitting a system at once (concurrent users) to measure how it performs under load.
What JMeter gives you:
- Open source and free — no commercial licence needed
- Multi-protocol — HTTP/HTTPS, REST API, SOAP, JDBC, FTP, JMS, LDAP
- GUI and CLI — the GUI to build test plans, the CLI to execute inside a CI/CD pipeline
- Extensible — hundreds of plugins via the JMeter Plugins Manager
- Distributed testing — run a test from multiple machines
- An industry standard — the de facto standard in Indonesian banking
Getting Ready: Installing JMeter
Prerequisites
- Java JDK 8 or newer (JDK 11+ recommended)
- 4 GB RAM minimum (8 GB recommended for large tests)
- Operating system: Windows, macOS, or Linux
Installation Steps
- Install the Java JDK — Download from
adoptium.netororacle.com/java. Confirm thatjava -versionreports the right version in your terminal. - Download JMeter — Go to
jmeter.apache.organd download the.zipor.tgzfrom the "Binaries" section. - Extract it — Unzip to a folder of your choosing (for example
C:\jmeteror/opt/jmeter). - Launch JMeter — Open a terminal, navigate to the
bin/folder, then run:- Windows:
jmeter.bat - macOS/Linux:
./jmeter.sh
- Windows:
- Verify — The JMeter GUI opens with an empty "Test Plan" in the left-hand panel.
Step 1: Building Your First Test Plan
A Test Plan is the blueprint of your load test. Every test plan needs at least:
- Thread Group — sets the number of virtual users, the ramp-up period, and the duration
- Sampler — the request to be sent (HTTP, JDBC, and so on)
- Listener — displays and records the results
Creating a Thread Group
- Right-click "Test Plan" → Add → Threads (Users) → Thread Group
- Configure:
- Number of Threads (users): 50 — the number of virtual users
- Ramp-Up Period (seconds): 30 — how long to bring all users online gradually
- Loop Count: 10 — how many times each user repeats the scenario
Meaning: 50 users start gradually over 30 seconds, and each user runs the scenario 10 times.
Adding an HTTP Request Sampler
- Right-click the Thread Group → Add → Sampler → HTTP Request
- Configure:
- Protocol: https
- Server Name or IP: your-domain.com
- Port: 443 (for HTTPS)
- Method: GET
- Path: / (or the endpoint you want to test)
Adding Listeners
- Right-click the Thread Group → Add → Listener → View Results Tree
- Also add: Add → Listener → Summary Report
- Also add: Add → Listener → Aggregate Report
Summary Report shows average response time, throughput, and error rate — the headline metrics you need.
Step 2: Adding the Essential Elements
Think Time (Timer)
Real users do not click without pausing. Add a delay between requests:
- Right-click the Thread Group → Add → Timer → Constant Timer
- Set Thread Delay: 1000 (1 second) — or use a Gaussian Random Timer for more realistic variation
Assertions (Validating the Response)
Make sure the server returns the right response, not an error page:
- Right-click the HTTP Request → Add → Assertions → Response Assertion
- Set Field to Test: Response Code
- Set Pattern: 200
This ensures any response that is not HTTP 200 is recorded as a failure.
HTTP Header Manager
Some APIs need specific headers:
- Right-click the Thread Group → Add → Config Element → HTTP Header Manager
- Add the headers you need, for example:
Content-Type: application/jsonAuthorization: Bearer {token}
Step 3: Parameterisation and Data-Driven Testing
A realistic test uses varied data — not the same request over and over.
CSV Data Set Config
- Create a CSV file of test data, for example
users.csv:username,password user001,pass001 user002,pass002 user003,pass003
- Right-click the Thread Group → Add → Config Element → CSV Data Set Config
- Set Filename: the path to the CSV file
- Set Variable Names: username,password
- In the HTTP Request, use the variables:
${username}and${password}
Each virtual user takes a different row — simulating real users with unique credentials.
Step 4: Running the Load Test
Running from the GUI (Development)
Click the green ▶ (Play) button in the toolbar. The GUI shows results in real time in the Listeners.
⚠ Important: the GUI consumes a lot of resources. For tests with 100+ users, always use CLI mode.
Running from the CLI (Production)
Non-GUI mode is the correct way to run a real load test:
jmeter -n -t test-plan.jmx -l results.jtl -e -o report-output/
The parameters:
-n— non-GUI mode-t— path to the test plan file (.jmx)-l— path to write the results (.jtl)-e— generate the HTML report once the test finishes-o— output folder for the HTML report
JMeter produces a complete HTML dashboard with response time, throughput, and error rate charts.
Step 5: Reading and Analysing the Results
Once the test finishes, open the Aggregate Report or the HTML dashboard. The metrics that matter:
| Metric | Meaning | Typical Target |
|---|---|---|
| Average Response Time | Mean response time | < 2 seconds |
| 90th Percentile (P90) | 90% of requests complete within this time | < 3 seconds |
| Throughput | Requests per second successfully processed | As the business requires |
| Error Rate | Percentage of failed requests | < 1% |
| Min/Max Response Time | The response time range | Max < 5 seconds |
Signs of a Performance Problem
- Response time climbs as users are added — the system is reaching maximum capacity
- Error rate spikes past a certain threshold — there is a bottleneck (connection pool, memory, CPU)
- Throughput stops rising even as users are added — the system has saturated
- Response time is unstable and fluctuating — possibly garbage collection, disk I/O, or a network issue
Step 6: Advanced Scenarios
Testing a REST API
To test a backend API rather than a web page:
- Use an HTTP Request with the POST/PUT method
- Add Body Data in JSON format
- Set the header
Content-Type: application/json - Use a JSON Extractor to pull data out of the response (a token, for instance) for the next request
Correlation: Dynamic Data
Many web applications use dynamic tokens (CSRF token, session ID). JMeter has to extract and pass those along:
- Add a Regular Expression Extractor or JSON Extractor to the response containing the token
- Store it in a variable:
${csrf_token} - Use that variable in the subsequent request
Distributed Load Testing
To generate very large loads (thousands of concurrent users), use distributed testing:
- Prepare several JMeter machines as "slaves"
- On the master machine, edit
jmeter.properties:remote_hosts=slave1_ip,slave2_ip - Run:
jmeter -n -t test.jmx -r -l results.jtl(the-rflag means remote)
Integrating JMeter with a CI/CD Pipeline
To automate load testing as part of the deployment pipeline:
Jenkins
- Install the Performance Plugin in Jenkins
- Add a build step: Execute shell → run the JMeter CLI
- Add a post-build action: Publish Performance test result
- Set a threshold: if error rate > 1% or P90 > 3s, the build FAILS
GitLab CI
performance_test:
stage: test
image: justb4/jmeter:latest
script:
- jmeter -n -t tests/load-test.jmx -l results.jtl -e -o report/
artifacts:
paths:
- report/
when: always
Common Mistakes to Avoid
- Running the test from GUI mode — the GUI consumes excessive resources and produces inaccurate results. Always use the CLI for a real test.
- Leaving out think time — with no delay, JMeter fires requests as fast as it can, which does not represent real user behaviour.
- A test environment that does not resemble production — results are only valid if the environment is comparable to production (hardware, data volume, network).
- Skipping the warm-up — start at low load for 1-2 minutes before ramping to the target.
- Ignoring resource monitoring — watch CPU, memory, and disk I/O on the target server while the test runs.
- Not running a baseline test — always run with 1 user first to confirm the script works correctly.
Load Testing in Regulated Industries
For Indonesian banking and fintech, load testing carries extra context:
- POJK 11/2022 (a Financial Services Authority regulation) requires periodic IT system performance testing
- Audit trail — keep every test artefact (.jtl files and HTML reports) for audit documentation
- Test data compliance — use synthetic data, never real customer data (UU PDP, the Personal Data Protection Law)
- SLA validation — make sure performance targets match the SLA the regulator has set
See also: 7 Types of Performance Testing According to ISTQB
Start Learning JMeter Hands-On
This tutorial gives you the foundation for load testing. To master JMeter in depth with real industry scenarios, Frans Training runs the Performance & Load Testing with JMeter programme, covering:
- Hands-on labs with banking and e-commerce scenarios
- Distributed load testing for thousands of concurrent users
- Integrating JMeter with Jenkins and GitLab CI/CD
- Bottleneck analysis and performance tuning
- Writing test reports that satisfy OJK audit standards
See also: The Difference Between Stress Testing and Load Testing | Free consultation
References
FAQ: Beginner Questions about JMeter
Can JMeter be used to test a REST API?
Yes, JMeter is very capable for API testing. Use an HTTP Request sampler with the POST/PUT method, add Body Data in JSON format, and set the header Content-Type: application/json. Use a JSON Extractor to pull data out of the response.
How many concurrent users can JMeter simulate?
On a single machine with 8GB RAM, JMeter can simulate 500-1,000 virtual users for HTTP testing. For larger loads, use distributed testing (master-slave), which can reach tens of thousands of users.
Can JMeter be integrated with Jenkins?
Yes. Install the Performance Plugin in Jenkins, add a build step to run the JMeter CLI, and set thresholds (error rate, response time) to determine pass/fail automatically.
JMeter GUI vs CLI — when should I use each?
The GUI is for building and debugging test plans. The CLI (non-GUI mode) is for running the real test. Never run a heavy load test from the GUI — the results are inaccurate because the GUI consumes excessive resources.
Ran Your First Test Plan Yet?
This tutorial is only the beginning. Next: master distributed testing for thousands of concurrent users, integration with a CI/CD pipeline, and bottleneck analysis against real core banking scenarios.
The Performance & Load Testing with JMeter programme takes you from beginner to a standard OJK auditors accept — with hands-on labs using real industry scenarios.
Free consultation: tell us what your team needs and we will help you pick the right schedule and programme.