Scripts built. Data prepared. Assertions configured. Correlation working. Now we run. But we do NOT start with 100 users. That is like testing a new car by immediately driving it at 200 km/h on the highway. First, you take it around the parking lot.
The baseline test has two purposes. First, it validates that your test plan actually works -- all requests succeed, correlation is functioning, assertions pass. Second, it captures "healthy" performance numbers under minimal load. These numbers become your reference point for everything that follows.
# Create results directory
mkdir -p results/baseline
# Run baseline test -- 10 users, 10s ramp-up, 1 loop
# Override thread group properties via command line
jmeter -n -t shopping-portal-load-test.jmx \
-Jthreads=10 \
-Jrampup=10 \
-Jduration=120 \
-Jloops=1 \
-l results/baseline/results.jtl \
-e -o results/baseline/html-report
echo "Baseline test complete!"
echo "Open results/baseline/html-report/index.html in browser"After the baseline runs, open the HTML report and check three things:
Error rate = 0%. If ANY request failed, stop here and fix the test plan. Do not proceed to load testing with a broken script.
Response times look reasonable. Homepage in under 1 second, API calls in a few hundred milliseconds. These are your baseline numbers.
Throughput is consistent. No wild spikes or drops. If throughput is erratic with only 10 users, you have a test design problem.
All transaction names appear in the report. If a transaction is missing, its Transaction Controller might be misconfigured.
Check the Response Times Over Time graph. It should be flat and stable. Any upward trend with just 10 users indicates a problem.
If your baseline has even 1% error rate, do NOT proceed to load testing. Every error in the baseline will multiply at scale. A 1% error rate with 10 users might become 15% with 100 users because the root cause is often a race condition or data issue that gets worse under concurrency.
The baseline passed with flying colors? Great. Now we simulate the expected peak load. For our Diwali sale scenario, that is 100 concurrent users shopping simultaneously.
# Create results directory
mkdir -p results/load-test
# Run load test -- 100 users, 60s ramp-up, 10 min duration
jmeter -n -t shopping-portal-load-test.jmx \
-Jthreads=100 \
-Jrampup=60 \
-Jduration=600 \
-Jloops=5 \
-l results/load-test/results.jtl \
-e -o results/load-test/html-report
echo "Load test complete!"
echo "Open results/load-test/html-report/index.html in browser"| Metric | Healthy Sign | Warning Sign | Critical Problem |
|---|---|---|---|
| Error Rate | < 0.1% | 0.1% - 1% | > 1% -- something is breaking |
| p95 Response Time | Within SLA targets | 10-20% above SLA | > 2x SLA -- significant degradation |
| Throughput | Stable or slight growth | Declining over time | Dropping sharply -- system saturated |
| Response Time Over Time | Flat line | Gradual upward slope | Hockey stick curve -- resource leak |
| Active Threads Over Time | Follows ramp-up pattern | Threads stuck (not completing) | Thread count plateau -- connection pool exhausted |
The real insight comes from comparing the two runs. Here is what a typical comparison looks like:
Transaction | Baseline (10u) p95 | Load (100u) p95 | Change | SLA | Status
---------------------+--------------------+-----------------+---------+--------+-------
01_Homepage | 450ms | 1,200ms | +167% | < 2s | PASS
02_Login | 320ms | 890ms | +178% | < 2s | PASS
03_Search | 280ms | 1,450ms | +418% | < 1.5s | WARN
04_ProductDetail | 190ms | 520ms | +174% | < 2s | PASS
05_AddToCart | 150ms | 380ms | +153% | < 1s | PASS
06_ViewCart | 210ms | 560ms | +167% | < 2s | PASS
07_Checkout | 890ms | 2,800ms | +215% | < 3s | WARN
08_OrderConfirmation | 180ms | 430ms | +139% | < 2s | PASS
Overall Error Rate: 0.0% 0.3% < 0.5% | PASS
Overall Throughput: 15 RPS 42 RPS > 30 | PASSSee those "WARN" entries? Search response time jumped 418% and is close to breaching the SLA. Checkout is at 2.8 seconds against a 3-second SLA -- barely passing. These are early warning signs. The application works at 100 users, but these two endpoints are under strain. If we add more users, they will be the first to break.
Always save the raw .jtl result files, not just the HTML reports. You might need to re-analyze the data later, generate custom graphs, or compare specific transactions. The .jtl file is your source of truth.
Q: Why do you run a baseline test before a load test? What do you look for in the baseline?
A: A baseline test serves two purposes. First, it validates the test plan works correctly -- zero errors confirms that correlation, parameterization, and assertions are all functioning. A broken script at 10 users produces chaos at 100 users and you cannot distinguish script bugs from application performance issues. Second, the baseline captures "healthy" performance numbers under minimal load. These numbers become the reference point for comparing load test results. When I see that Search response time went from 280ms (baseline) to 1,450ms (load test) -- a 418% increase -- I know exactly where degradation is happening. Without the baseline, the 1,450ms number is just a number with no context.
Key Point: Always run baseline first with 0% error rate before load testing. Compare every metric between baseline and load test -- the percentage change reveals exactly where the application degrades under pressure.
Key Point: Baseline first, load test second. The comparison between the two reveals exactly which endpoints degrade and by how much.