Performance Testing with JMeter: A Complete Guide from Zero to Proficient
When a banking application fails to handle the surge in transactions on payday, or an e-commerce platform crashes during a flash sale, it is not merely a technical problem. It is a business loss that can run into billions of rupiah within minutes. Performance testing is the last line of defence before that scenario reaches production, and Apache JMeter is the most popular and capable open-source tool for the job.
This article is a comprehensive JMeter guide from scratch — installation and basic configuration, building test plans, running the various kinds of load test, and analysing results in a way you can act on. We use examples and scenarios relevant to Indonesian applications (banking, e-commerce, digital public services) so you can apply the material directly.
What Is Performance Testing, and Why Does It Matter?
Performance testing is the process of evaluating how a system behaves under a given workload. The goal is not to find functional bugs but to answer critical questions such as:
- How many concurrent users can the application serve before response time exceeds the threshold?
- What happens when load reaches 2x or 3x normal capacity?
- Is there a memory leak or resource degradation when the application runs for 24 hours non-stop?
- Which component is the bottleneck — the application server, the database, or the network?
The Performance Testing Concepts module covers these theoretical foundations in depth. Here are the types of performance testing you need to understand:
Load Testing
Simulating normal to peak workload to verify the system meets its performance requirements (response time, throughput, error rate). Example: testing whether an internet banking system can handle 5,000 concurrent users with response times under 3 seconds.
Stress Testing
Pushing the system beyond normal capacity to find the breaking point and understand behaviour under overload. Example: what happens to an e-commerce platform when traffic surges 10x during a flash sale?
Endurance Testing (Soak Testing)
Running normal load over a long period (8-72 hours) to detect problems that only emerge over time — memory leaks, connection pool exhaustion, log file growth. Example: running a banking transaction simulation for 48 hours to confirm no performance degradation.
Spike Testing
Simulating a sudden, drastic traffic surge. Example: how a civil service recruitment registration system behaves when 100,000 users arrive simultaneously in the first second of opening.
JMeter Setup and Configuration, Step by Step
The JMeter Setup & Configuration module covers installation and optimal configuration end to end. Here is the walkthrough:
Installation
- Prerequisite: Install Java JDK 8 or higher. Verify by running
java -versionat the command prompt or terminal - Download JMeter: Get the latest version from
jmeter.apache.org. Choose the binary (.zip for Windows, .tgz for Linux/Mac) - Extract: Unzip to a directory of your choice (for example
C:\JMeteror/opt/jmeter) - Run: Execute
jmeter.bat(Windows) orjmeter.sh(Linux/Mac) from thebin/folder
Optimal Configuration for Heavy Load Testing
JMeter's default configuration is not optimal for load testing with thousands of users. The tuning to apply:
- JVM heap size: Edit
jmeter.batorjmeter.shand raise the heap to at least 2GB:-Xms2g -Xmx4g. For tests above 5,000 threads, use 4-8GB - Non-GUI mode: Always run load tests in non-GUI mode. The GUI consumes significant resources and limits how many threads you can simulate. Use:
jmeter -n -t testplan.jmx -l results.jtl -e -o report/ - Disable listeners at runtime: Listeners (View Results Tree, Graph Results) consume large amounts of memory. Turn them off while the test runs and enable them only for debugging
- Properties file: Edit
jmeter.propertiesto optimise:httpclient4.retrycount=0,httpsampler.max_redirects=5,summariser.interval=30
A lesson from the field: We once supported a digital bank's QA team who complained that "JMeter can only handle 500 threads." On investigation, the problem was not JMeter but the configuration: they were running in GUI mode with 10 active listeners, a default 512MB heap, and View Results Tree recording every response body. After tuning the configuration, the same machine ran 5,000 threads without difficulty.
Building a Test Plan, Component by Component
A test plan is the blueprint of your load test. The Creating Test Plans module covers each component in detail:
Thread Group
The Thread Group is the base component defining the number of virtual users (threads), the ramp-up period, and the iteration count:
- Number of threads: How many virtual users to simulate. Start small (50-100) for a baseline, then scale up
- Ramp-up period: The time in seconds to start all threads. With 1,000 threads and a 100s ramp-up, JMeter starts 10 threads a second. Too fast a ramp-up can produce a false spike
- Loop count: How many times each thread runs the scenario. Set to "Infinite" for duration-based testing and use the scheduler's duration
- Scheduler: Enable it to control test duration precisely (30 minutes, an hour)
Thread Group configuration for common scenarios:
- Baseline test: 100 threads, 60s ramp-up, 5 minute duration
- Normal load: 500 threads, 120s ramp-up, 30 minute duration
- Peak load: 2,000 threads, 300s ramp-up, 30 minute duration
- Stress test: 5,000 threads, 600s ramp-up, 60 minute duration
Samplers
Samplers are the components that send requests to the server. The most commonly used:
- HTTP Request: For web application testing. Configure protocol (HTTP/HTTPS), server name, port, path, method (GET/POST/PUT/DELETE), parameters, and body data
- JDBC Request: For testing a database directly. Useful for measuring query performance
- JSR223 Sampler: For custom logic in Groovy. Extremely flexible, but use it carefully
For HTTP Request, several configurations matter:
- HTTP Header Manager: Add the headers you need (Content-Type, Authorization, Accept). Make sure they match what the real application sends
- HTTP Cookie Manager: Essential for applications using session-based authentication
- HTTP Request Defaults: Set a default server name and port so you need not repeat them in every sampler
Assertions
Assertions validate that the server response matches expectations:
- Response Assertion: Verify the response code (200, 201), the body (contains particular text), or a header
- Duration Assertion: Flag requests whose response time exceeds a threshold (over 3 seconds, say)
- JSON Assertion: For API testing — validating that the JSON response has the right structure and values
- Size Assertion: Verify response size (useful for detecting truncated responses)
Listeners
Listeners collect and display test results:
- View Results Tree: For debugging — showing individual requests and responses. Do not enable it while a load test runs
- Summary Report: A summary table with average response time, throughput, and error rate per sampler
- Aggregate Report: Like the Summary Report, with percentiles added (90th, 95th, 99th)
- Generate HTML Report: The
-e -ooptions in non-GUI mode produce a comprehensive, well-presented HTML report
Load Test Scenarios for Indonesian Applications
The Load/Stress/Endurance Testing module works through the following scenarios hands-on:
Scenario 1: Internet Banking on Payday
Payday (the 25th-28th) is peak period for internet banking. The test scenario:
- User flow: Login → check balance → interbank transfer → OTP confirmation → logout
- Thread configuration: 3,000 threads (normal baseline: 500), 300s ramp-up, 60 minute duration
- Think time: Add a Constant Timer or Gaussian Random Timer (averaging 5 seconds) between steps to simulate real user behaviour
- Success criteria: Average response time under 3 seconds for the main page, under 5 seconds for a transfer, error rate below 0.5%, zero timeouts on the OTP step
- Data variation: Use CSV Data Set Config to supply varying combinations of username, transfer amount, and destination bank
Scenario 2: E-Commerce Flash Sale
A flash sale creates a distinctive traffic pattern — a massive surge in the first seconds, then sustained high load:
- User flow: Landing page → product page → add to cart → checkout → payment
- Thread configuration: The Ultimate Thread Group plugin — 5,000 threads in a spike pattern: 2,000 threads in the first 10 seconds, then ramping to 5,000 over 5 minutes
- Correlation: Use a Regular Expression Extractor or JSON Extractor to capture dynamic values (CSRF token, session ID, cart ID) from earlier responses
- Success criteria: Product page response under 2 seconds, checkout flow under 8 seconds end to end, zero data corruption (no overselling), error rate below 1%
Scenario 3: Public Service Systems — Civil Service or School Registration
Public service systems face extreme spike testing — hundreds of thousands of users arriving at once when registration opens:
- User flow: Access the page → login/register → complete the form → upload documents → submit
- Thread configuration: 10,000+ threads with a very aggressive ramp-up (30 seconds). Use distributed testing
- File upload testing: Use HTTP Request with multipart/form-data to simulate document upload
- Distributed testing: Use JMeter remote testing — 1 controller plus 3-5 load generators to produce very high load
Distributed Testing: Beyond One Machine
A single JMeter machine has a practical ceiling around 5,000-10,000 threads, depending on hardware and test plan complexity. To simulate higher load, use distributed testing:
- Architecture: One controller machine sends the test plan to several load generator machines (slaves). Each slave runs the plan independently and returns results to the controller
- Setup: Install the same JMeter version on every machine. On the controller, edit
jmeter.properties:remote_hosts=slave1_ip,slave2_ip,slave3_ip - Start the slaves: On each slave, run
jmeter-server - Run the test: From the controller:
jmeter -n -t test.jmx -R slave1,slave2,slave3 -l results.jtl - Considerations: Make sure the firewall permits connections between machines (port 1099 by default), and that network latency between them is low (ideally the same LAN or VPC)
Analysing Results: From Data to Insight
The Results Analysis & Reporting module covers interpreting load test results and communicating the findings to stakeholders:
Key Metrics
- Response time (latency): The time from sending a request to receiving the first response. Watch the average, median, 90th percentile, and 99th percentile. A large gap between average and 99th percentile signals inconsistent performance
- Throughput: Requests successfully processed per second. Throughput falling as thread count rises indicates a bottleneck
- Error rate: The percentage of failed requests. Target: below 0.5% for normal load, below 2% for a stress test. A sudden spike marks the breaking point
- Concurrent users versus response time graph: The most important plot — showing where response time begins climbing significantly (the saturation point)
- Bandwidth: Data transfer rate — important for evaluating whether the network is the bottleneck
Common Problem Patterns
- Response time rising linearly with threads: Probably a CPU bottleneck at the application server. Check: CPU utilisation approaching 100%
- Response time spiking abruptly: Connection pool exhaustion or a thread pool limit reached. Check: active database connections
- Error rate rising gradually: A memory leak — the application is running out of heap over time. Check: JVM memory usage trend
- Throughput reaching a plateau: A bottleneck in one component — database, network, or I/O. Use monitoring tools (Grafana, New Relic) to identify it
A real scenario: The QA team at an Indonesian e-commerce company reported that a load test "passed" — average response time of 1.5 seconds at 2,000 concurrent users. When we reviewed the data more closely, the 99th percentile response time turned out to be 25 seconds. That means 1% of users (20 of 2,000) had a very poor experience. In a flash sale with 200,000 users, that is 2,000 people hitting a timeout. The lesson: never look only at the average, always check the percentiles.
What the Course Covers
The Performance & Load Testing with JMeter course at Frans Training builds performance testing competency from the foundations to advanced work, with hands-on practice using real application scenarios. The module map:
- Module 1 — Performance Testing Concepts: Types of performance test, key metrics, requirement gathering, the test strategy document, and integration with the SDLC
- Module 2 — JMeter Setup & Configuration: Installation, optimal configuration, plugin management, JVM tuning, and environment setup for various scenarios
- Module 3 — Creating Test Plans: Thread Groups, Samplers, Config Elements, Assertions, Listeners, Logic Controllers, Timers, pre/post processors, and correlation techniques
- Module 4 — Load/Stress/Endurance Testing: Running the various test types, distributed testing, parameterisation with CSV Data Set, scripting in Groovy, and server-side monitoring
- Module 5 — Results Analysis & Reporting: Interpreting metrics, identifying bottlenecks, HTML report generation, and writing a performance test report that is actionable for both technical and non-technical stakeholders
Related Courses to Broaden Your QA Skills
- Performance & Load Testing with JMeter — The main performance testing course, from zero to proficient
- Web Automation Testing with Selenium & Cypress — Functional test automation to complement performance testing
- API Testing with Postman & REST Assured — In-depth API testing, complementing API load testing in JMeter
- QA Process Management & Test Planning — Testing strategy and planning holistically within the SDLC
FAQ: Performance Testing with JMeter
Can JMeter be used to test mobile applications?
JMeter does not simulate a mobile application's UI directly. It is highly effective, however, for testing the backend and APIs a mobile app consumes. By recording traffic from the mobile app through a proxy (the JMeter HTTP(S) Test Script Recorder), you can simulate thousands of mobile users hitting the backend API simultaneously. For mobile UI performance testing, consider Appium or Android Profiler.
What is the maximum number of threads one JMeter machine can run?
It depends on hardware, test plan complexity, and JMeter configuration. As a rule of thumb: with 16GB RAM, an 8-core CPU, and an optimised test plan (non-GUI mode, listeners disabled), one machine can run 5,000-10,000 threads for HTTP testing. For more, use distributed testing. Never judge JMeter's capacity from GUI mode — the GUI is only for developing and debugging test plans.
How do you handle dynamic values (CSRF token, session ID) in JMeter?
Use a post-processor to extract dynamic values from an earlier response, then reference them as variables in later requests. Regular Expression Extractor for HTML responses, JSON Extractor for API responses, and XPath Extractor for XML/SOAP. This is called "correlation" and is one of the most important skills in performance testing.
How does JMeter differ from other performance testing tools such as Gatling or k6?
JMeter's strengths: (1) a GUI making test plan creation possible without coding, (2) a very large community and rich plugin ecosystem, (3) support for many protocols (HTTP, JDBC, FTP, SOAP, REST, WebSocket). Gatling and k6 are stronger on a scripting-based approach (more maintainable in CI/CD), better resource efficiency per thread, and more modern reporting out of the box. The choice depends on your needs and your team's capability. We recommend JMeter for teams starting out in performance testing.
How do you integrate JMeter into a CI/CD pipeline?
JMeter runs in non-GUI mode from the command line, which suits CI/CD integration well. Run it through Jenkins, GitLab CI, or GitHub Actions using: jmeter -n -t testplan.jmx -l results.jtl -e -o report/. Add a threshold check — fail the pipeline if average response time exceeds 3 seconds or error rate exceeds 1%, for example. The JMeter Maven Plugin also simplifies integration for Java projects.
This article was written by the Frans Training instructor team, based on experience conducting performance testing for applications across Indonesian industries. Last updated April 2026.