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 withe -o. - Environment-agnostic: Works on servers or Docker containers without GUI, ideal for CI/CD or cloud environments.
Installing JMeter
Check Java
JMeter runs on Java, so first confirm that Java is installed. On a Windows machine, open the Command Prompt and execute:
Since JMeter runs on Java, first make sure that Java is installed.
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.
- Randomly select a quiz detail page.
- 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 of 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, configure CSV Data Set Config to generate the random numbers.
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 variablequizidthat 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 assumes receiving requests from 50 users per second. Over 60 seconds, the throughput will be 50 × 60 = 3000 requests.
- 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.
he 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.
Conclusion
本記事では、Apache JMeter を使った Web システムの負荷テストの基本を、インストールからテストプIn this article, we covered the basics of web system load testing using Apache JMeter, from installation and creating a test plan to executing tests and reviewing reports.
When conducting load tests, it is especially important to keep the following points in mind:
- Ramp-up settings: Simulate realistic increases in load.
- Assertions: Use them to quantitatively evaluate response quality.
- Result reports (HTML output): Visualize bottlenecks and use the insights for improvements.
Performance testing is not a one-time task. Its true value comes from continuous execution with each development and release cycle.
By incorporating JMeter-based load testing as part of an ongoing quality improvement process, you can proactively prevent performance issues and ensure stable system operation.
English 
Japanese
コメント