How to Use Apache JMeter for Load Testing: Complete Beginner’s Guide

Introduction

When deploying a web system or adding new features, conducting load testing (performance testing) is essential. Without sufficient testing, high traffic can lead to slower response times and degraded user experience, potentially resulting in system crashes or service downtime. This, in turn, may cause user churn and a loss of trust.

One tool that can help is the open-source load testing tool Apache JMeter. JMeter allows you to simulate actual traffic to websites or APIs, measure performance, and identify bottlenecks.

In this article, I will guide JMeter beginners through each step, from installation and creating a basic test plan to checking the results.

Overview of JMeter

What is JMeter?

Apache JMeter is an open-source performance testing tool developed and maintained by the Apache Software Foundation. Using JMeter, you can simulate situations where a large number of users access a system simultaneously, and measure response time, throughput, and system stability. Common use cases include:

Simulating high traffic to websites or APIs and measuring response performance.
Testing simultaneous connections to databases or servers to identify bottlenecks.
Checking system stability and limits under high load.

JMeter supports load testing across a wide range of protocols and services, including:

HTTP / HTTPS
SOAP / REST APIs
JDBC (database query load)
FTP / SMTP / JMS and more

GUI Mode vs. CLI Mode

JMeter can be used either through a graphical interface (GUI mode) or via the command line (CLI mode). While GUI mode is more intuitive, it is not suitable for high-load testing. The recommended approach is to use GUI mode to create test plans and switch to CLI mode for actual load testing. Below are the characteristics of each mode.

GUI Mode

GUI mode allows you to operate JMeter through a graphical interface. It provides a tree structure and icons for building test plans, making it intuitive even for beginners.

Main uses:

Creating and editing test plans: Add samplers (e.g., HTTP requests) and listeners via drag-and-drop, set parameters, variables, and thread counts.
Debugging test scenarios: Execute single requests to check responses and status codes, adjusting the design as needed.
Visualizing results (for development/testing purposes): View results in graphs, tables, and tree views to monitor response times and processing.

Key characteristics:

Intuitive operation: Beginner-friendly interface.
High resource consumption: Not suitable for large-scale load tests.
Development-focused: Not recommended for long-duration or high-load tests in production.
Supportive role: Best practice is to execute production load tests in CLI mode.

CLI Mode

CLI mode executes JMeter from the command line, consuming fewer resources and suitable for large-scale load testing.

Main uses:

Large-scale load testing: Supports thousands to tens of thousands of virtual users, enabling stress tests and scalability checks close to real-world scenarios.
Long-duration stability tests: Ideal for multi-hour or multi-day endurance tests, which may fail in GUI mode.
CI/CD integration: Can be run via Jenkins, GitHub Actions, or other CI tools for automated testing and performance regression detection.
Distributed testing: Run multiple JMeter servers controlled from a master node for large-scale distributed load.

Key characteristics:

Lightweight and fast: No GUI rendering, significantly reducing CPU and memory usage.
Automation-friendly: Parameters can be specified via command line and scheduled for automated execution.
Flexible output: Detailed logs in .jtl (XML/CSV), HTML reports can be generated with e -o.
Environment-agnostic: Works on servers or Docker containers without GUI, ideal for CI/CD or cloud environments.

Installing JMeter

Check Java

In this example, we’ll perform the JMeter load test on a Windows machine.
Open the Command Prompt and run the following command:

If the Java version is displayed, you’re all set.

C:\Users\user>java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)

If Java is not installed, install OpenJDK or Oracle JDK.

Download JMeter

Download JMeter from the official site:
Apache JMeter – Download Apache JMeter

Click the ZIP file for the latest version to download it.

Extract the downloaded ZIP file to a directory of your choice, then run

jmeter.bat to open the GUI.

Creating a Test Plan

A JMeter test plan defines the scenario (user behavior and business requirements) and the actual load configuration for testing.

Components of a test plan

Thread Group: Defines virtual users, request repetitions, ramp-up period, etc.
Sampler: Defines requests to be sent (HTTP, JDBC, FTP, etc.).
Listener: Displays and visualizes test results (trees, graphs, reports).
Config Element: Stores common settings (base URLs, authentication, CSV data).
Pre-Processor / Post-Processor: Manipulates data before requests or extracts values after responses.
Assertion: Verifies responses (e.g., HTTP 200 status, expected text in response).

Sample Scenario

Before creating a test plan, clarify the scenario. For the website https://quiz.eeengineer.com/quiz/public, a sample scenario is:

Objective:

Simulate 100 concurrent users with 50 requests per second, ensuring response times stay under 2 seconds. This identifies performance bottlenecks and validates site durability.

Scenario Steps:

Access the quiz list page.
Access a quiz detail page using a quiz ID loaded from a CSV file.
Return to the quiz list page.

Configuring the Test Plan

Rename the test plan and optionally add a description.

Next, create a Thread Group.
In JMeter, a “thread” represents a virtual user, and a “thread group” is a collection of those virtual users.
This section defines the type and level of load to be applied during the test.

The load configuration is as follows:

Number of Threads (users): 100
Specifies the number of virtual users. In this example, we assume a scenario where 100 virtual users access the website simultaneously.

Ramp-up period (seconds): 30
Specifies how long it takes to start all the defined threads. Here, the 100 threads will start gradually over 30 seconds.
If the ramp-up period is not configured, all threads will start at once, which can cause a sudden load spike on the server — potentially leading to CPU spikes, reaching the database connection limit, or other unintended behavior.
It’s important to set an appropriate ramp-up period to simulate a realistic increase in user activity and ensure stable test execution.

Loop Count: 300
Specifies how many times each virtual user repeats the test scenario. In this case, each user will perform the same test 300 times.
If you select “Infinite”, the load will continue until the test is manually stopped.

Next, configure HTTP Request Defaults.
This allows you to define common default settings (initial values) that will be applied to all HTTP Request Samplers within the test plan.

The configuration for HTTP Request Defaults is as follows:

Protocol：https
Server name or IP : quiz.eeengineer.com

Next, configure the HTTP Request Sampler.
An HTTP Request Sampler is a component that allows JMeter to actually send requests to the target system under test.
Within the test plan, it serves as the core element responsible for generating the requests.

The configuration for the HTTP Request Sampler is as follows.
This request will display the list of quizzes.

Method：GET
Path：/quiz/public

Next, create a sampler to display individual quizzes.
Set it up so that each quiz page is accessed by specifying a random number between 1 and 5.

First, create a CSV file containing quiz IDs, and configure CSV Data Set Config to load those values into JMeter.

The settings to configure in CSV Data Set Config are as follows:

Filename：quiz_ids.csv
Store this file in the same folder as the JMX test plan file.
Variable Names：quizid
Specify the variable to which the random values will be assigned.

Once the CSV Data Set Config is set up, configure the sampler.

Method：GET
Path：/quiz/public/${quizid}
Use the variable quizid that was specified earlier.

After viewing the individual quiz page, the test returns to the quiz list page.

Next, configure the Constant Throughput Timer.
This timer is used to maintain a consistent number of requests per second (throughput).
In other words, it controls how many requests you want to send per second during the load test.

The configuration for the Constant Throughput Timer is as follows:

Target throughput (in samples per minute): 3000
This example targets approximately 50 requests per second, which corresponds to 3,000 samples per minute.

Calculate Throughput based on: all active threads
This setting controls throughput based on the total number of requests from all threads (i.e., virtual users).

Next, configure the Duration Assertion.
An assertion is a mechanism to verify whether the test results are correct.
The Duration Assertion sets an upper limit on response time.

The configuration for the Duration Assertion is as follows:

Apply to：Main Sample and sub-samples
Applies to all samples.
Duration in milliseconds：2000
Checks whether the response is returned within 2000 ms.

This completes the configuration of the actions to be performed during the load test.
Next, add settings to display the test results.
Below is an example configuration for a Listener.

Add a Summary Report.

Next, add a Response Time Graph.

This completes the test plan configuration.
Make sure to save the settings you have created.

Executing the Test Plan

Executing the Test Plan in GUI Mode

Now it’s time to run the test plan.
First, verify that the test plan executes correctly by running it from the GUI.
As shown below, click the green Start button.

Check the Summary Report.
If the Error % is not high, the test should be running correctly.
If any items show a high Error %, review and adjust the relevant settings.

Click Response Time Graph > Graph.
The response time graph will be displayed over time, as shown below.

Executing the Test Plan in CLI Mode

Once you have confirmed that the test runs correctly in the GUI, try running it in CLI mode.
For Windows users, execute the following command from the Command Prompt:

C:\Users\user>cd C:\Users\user\Desktop\apache-jmeter-5.6.3
C:\Users\user\Desktop\apache-jmeter-5.6.3>
C:\Users\user\Desktop\apache-jmeter-5.6.3>"bin\jmeter.bat" -n -t "quizapp-performance-test\quizapp-performance-test.jmx" -l "quizapp-performance-test\result.jtl" -e -o "quizapp-performance-test\report"
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
Creating summariser <summary>
Created the tree successfully using quizapp-performance-test\quizapp-performance-test.jmx
Starting standalone test @ 2025 Oct 5 08:00:49 JST (1759618849935)
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445
summary +    318 in 00:00:10 =   31.8/s Avg:   405 Min:   269 Max:  1499 Err:     0 (0.00%) Active: 34 Started: 34 Finished: 0
summary +   1517 in 00:00:30 =   50.7/s Avg:   454 Min:   267 Max:  4382 Err:    11 (0.73%) Active: 100 Started: 100 Finished: 0
summary =   1835 in 00:00:40 =   45.9/s Avg:   445 Min:   267 Max:  4382 Err:    11 (0.60%)
summary +   1489 in 00:00:30 =   49.6/s Avg:   434 Min:   267 Max:  2347 Err:     9 (0.60%) Active: 100 Started: 100 Finished: 0
summary =   3324 in 00:01:10 =   47.5/s Avg:   440 Min:   267 Max:  4382 Err:    20 (0.60%)
summary +   1510 in 00:00:30 =   50.3/s Avg:   439 Min:   264 Max:  1654 Err:     0 (0.00%) Active: 100 Started: 100 Finished: 0
summary =   4834 in 00:01:40 =   48.3/s Avg:   440 Min:   264 Max:  4382 Err:    20 (0.41%)
summary +   1488 in 00:00:30 =   49.7/s Avg:   412 Min:   264 Max: 21039 Err:     1 (0.07%) Active: 100 Started: 100 Finished: 0
summary =   6322 in 00:02:10 =   48.7/s Avg:   433 Min:   264 Max: 21039 Err:    21 (0.33%)
Terminate batch job (Y/N)? Y

C:\Users\user\Desktop\apache-jmeter-5.6.3>

“bin\jmeter.bat”
The JMeter executable file (Windows batch file). Running this file starts JMeter.

-n
Option to run in Non-GUI mode. This executes the test from the command line without opening the GUI.

-t “quizapp-performance-test\quizapp-performance-test.jmx”
Specifies the test plan (.jmx file). quizapp-performance-test.jmx is the test definition file created in GUI mode.

-l “quizapp-performance-test\result.jtl”
Specifies the location to save the execution results (JTL file). JMeter writes the results of each sampler (response times, statuses, etc.) to this file. It can later be used for generating reports and creating graphs.

-e
Option to automatically generate an HTML report (available in JMeter 3.0 and later).

-o “quizapp-performance-test\report”
Specifies the folder for the report output. Used together with -e. The specified folder will contain an HTML report with graphs and dashboards.

Reviewing the Report

The result.jtl file records the results of each request, including elapsed time, status codes, request size, and more.

An HTML report is also generated.
Click the index.html file in the report directory to view it.
The report will be displayed as shown below.

How to Read JMeter Test Results

After generating the HTML report, you can analyze the performance of your web application using several key metrics.

When reviewing load test results, it is important not to focus only on the average response time. You should also check throughput, error rate, and response time percentiles to understand how the system behaves under load.

Throughput

Throughput represents the number of requests processed by the system during a specific period of time.

For example, if the throughput is 50 requests per second, it means that the system is processing approximately 50 requests every second.

Throughput is an important metric for understanding how much traffic your system can handle. If the throughput stops increasing even when you increase the number of concurrent users, the system may have reached a performance bottleneck.

Error %

Error % represents the percentage of requests that failed during the load test.

Errors can occur for various reasons, such as HTTP errors, connection failures, timeouts, or failed assertions.

Ideally, the error rate should be close to 0%. If the error rate increases as the load increases, you should investigate whether the web server, application server, database, network, or another component has reached its capacity limit.

Average Response Time

Average response time represents the average amount of time required to complete a request.

For example, if the average response time is 500 ms, requests took approximately 500 ms to complete on average.

However, the average alone may not accurately represent the user experience. A small number of very slow requests can be hidden when looking only at the average value.

For this reason, response time percentiles are also important when analyzing load test results.

90th, 95th, and 99th Percentiles

Percentiles show how response times are distributed across all requests.

For example:

90th percentile = 1,000 ms means that 90% of requests completed within 1,000 ms.
95th percentile = 1,500 ms means that 95% of requests completed within 1,500 ms.
99th percentile = 3,000 ms means that 99% of requests completed within 3,000 ms.

Percentiles are useful because they help identify slow requests that may not be visible when looking only at the average response time.

In particular, the 95th and 99th percentiles are commonly used to evaluate the performance experienced by slower users.

For example, even if the average response time is 500 ms, a 99th percentile of 5,000 ms means that some users are experiencing significantly slower responses.

Therefore, when analyzing JMeter load test results, it is important to evaluate multiple metrics together:

Throughput: How many requests can the system process?
Error %: Are requests failing under load?
Average Response Time: What is the overall response time?
90th / 95th / 99th Percentiles: How slow are the requests experienced by the slower users?

By monitoring these metrics while gradually increasing the load, you can identify when system performance begins to degrade and investigate potential bottlenecks.

Conclusion

In this article, we covered the basics of load testing with Apache JMeter, from installation and test plan creation to test execution and result analysis.

Apache JMeter allows you to simulate multiple users accessing a web application and measure how the system performs under load. By configuring components such as Thread Groups, HTTP Requests, Assertions, and Timers, you can create load test scenarios that reflect real-world traffic patterns.

We also looked at how to run JMeter in non-GUI mode and generate an HTML report. For actual load testing, non-GUI mode is generally recommended because it consumes fewer resources and is more suitable for generating a large amount of traffic.

When analyzing load test results, do not focus only on whether the requests succeeded. Metrics such as response time, throughput, error rate, and percentiles are also important for understanding the overall performance of the system.

JMeter is a powerful tool not only for generating load but also for identifying performance issues and understanding how your system behaves under different traffic conditions.

Once you are comfortable with the basic JMeter workflow, try gradually increasing the number of users or requests and observe how the performance of your web server, application server, database, and operating system changes.