Chapter 10: Practice: Load Test a Web App
You have done excellent technical work. But none of it matters if you cannot communicate it. A performance test report is your deliverable -- it is what stakeholders, developers, and management will read and act on. I have seen brilliant performance engineers get ignored because their report was a 50-page dump of JMeter screenshots with no narrative. And I have seen average testers drive major infrastructure changes because they wrote a clear, actionable 3-page report.
Write for three audiences in the same document. The VP reads the first half-page and gets the verdict. The tech lead reads sections 3-5 and understands what to fix. The developer reads the appendix and gets the data they need to debug. Structure your report so each audience finds what they need without reading the whole thing.
================================================================
PERFORMANCE TEST REPORT
================================================================
System: Shopping Portal -- Checkout Flow
Test Date: [YYYY-MM-DD]
Tested By: [Your Name]
Environment: [Staging / Pre-production]
Tool: Apache JMeter 5.6.3
================================================================
1. EXECUTIVE SUMMARY
--------------------
The Shopping Portal checkout flow was tested under three
scenarios: expected peak load (100 users), stress load
(250 users), and spike load (50 -> 300 -> 50 users).
Verdict: CONDITIONAL PASS
The system meets all SLAs at the expected peak of 100
concurrent users. However, the system breaks down at
approximately 180 concurrent users, providing only 1.8x
headroom above expected peak. Two critical bottlenecks
were identified in the Search and Checkout endpoints.
Recommendation: Fix the two identified bottlenecks before
the Diwali sale to achieve at least 2.5x headroom.
2. TEST CONFIGURATION
---------------------
Load Profile:
- Baseline: 10 users, 10s ramp-up, 2 min duration
- Load test: 100 users, 60s ramp-up, 10 min duration
- Stress test: 250 users, 120s ramp-up, 10 min duration
- Spike test: 50 base + 250 spike (10s ramp), 5 min total
Test Data:
- 250 unique test accounts (CSV parameterization)
- 15 search terms (varied result counts)
- Gaussian random think time: 2-4 seconds
Environment:
- App Server: 4 vCPU, 8 GB RAM, Ubuntu 22.04
- Database: PostgreSQL 15, 2 vCPU, 4 GB RAM
- Network: same data center, < 1ms latency
- Note: Production has 8 vCPU, 16 GB RAM -- results
should be proportionally better in production
3. RESULTS SUMMARY
------------------
| Baseline | Load | Stress | SLA
--------------------+----------+---------+---------+---------
Avg Response Time | 340ms | 980ms | 3,200ms | --
p95 Response Time | 520ms | 1,800ms | 9,100ms | < 3,000
p99 Response Time | 680ms | 2,400ms | 22,100 | < 5,000
Error Rate | 0.0% | 0.3% | 4.6% | < 1.0%
Throughput (RPS) | 15 | 42 | 74 | > 30
Max Capacity | -- | -- | ~180u | --
4. BOTTLENECKS IDENTIFIED
-------------------------
Bottleneck #1: Product Search (HIGH PRIORITY)
- Symptom: p95 jumped from 280ms to 6,900ms (2,464%)
- Root cause: Full table scan on products table when
search term does not match indexed columns
- Impact: At 200+ users, search becomes unusable
- Fix: Add composite index on (name, category, description)
- Expected improvement: 70-80% response time reduction
Bottleneck #2: Checkout (HIGH PRIORITY)
- Symptom: 12.3% error rate at 250 users, p99 of 22s
- Root cause: Database row-level locks during inventory
check + order creation (long transaction scope)
- Impact: Revenue loss from failed checkouts
- Fix: Reduce transaction scope, use optimistic locking
for inventory, move non-critical writes to async queue
- Expected improvement: 5x throughput increase
Bottleneck #3: Login (MEDIUM PRIORITY)
- Symptom: 5.1% error rate at 250 users
- Root cause: Password hashing (bcrypt) is CPU-intensive,
saturates CPU when many users login simultaneously
- Impact: Users cannot login during traffic spikes
- Fix: Implement login rate limiting, add session caching
to reduce re-authentication frequency
5. SPIKE TEST RESULTS
---------------------
Recovery time after spike: 45 seconds
Errors during spike arrival: 8.2% (first 30 seconds)
Post-spike behavior: Returned to baseline within 60 seconds
Verdict: Acceptable recovery, but error rate during spike
is too high. Connection pool exhaustion during rapid ramp.
6. RECOMMENDATIONS
------------------
Immediate (before Diwali sale):
[1] Add database index on products search columns
[2] Optimize checkout transaction scope
[3] Increase database connection pool from 20 to 50
Short-term (next sprint):
[4] Implement Redis caching for product search results
[5] Add connection pool monitoring and alerting
[6] Configure auto-scaling triggers at 70% CPU
Long-term (next quarter):
[7] Move to async order processing architecture
[8] Implement CDN for static assets
[9] Add database read replicas for search queries
7. APPENDIX
-----------
A. JMeter HTML Report links (baseline, load, stress, spike)
B. Server monitoring dashboards
C. Database slow query log excerpts
D. Test plan (.jmx) and test data (.csv) files
E. Raw result files (.jtl)
================================================================Q: How do you present performance test results to non-technical stakeholders?
A: I structure the report with the executive summary on the first half-page -- verdict (pass/conditional pass/fail), maximum supported user count, and the top risk. I avoid technical jargon and translate metrics into business impact: instead of "p99 is 22 seconds," I say "1 in 100 customers will wait over 22 seconds, and at our projected traffic, we could see approximately 500 failed checkout attempts per hour during the sale." I use a simple traffic light system -- green for metrics meeting SLA, yellow for close to SLA, red for exceeding SLA. I prioritize recommendations by business impact and effort, presenting quick wins first. For example, "adding a database index takes 30 minutes and would improve search performance by 70-80%" is more compelling than a vague "optimize the database." I always include a clear next-steps section with owners and timelines.
Key Point: A great performance test report has a half-page executive summary, quantified bottlenecks with specific fix recommendations, and raw data attached for developers. Write for three audiences: VP, tech lead, and developer.
Key Point: Your report is your deliverable. Lead with the verdict, quantify every finding, recommend specific fixes, and structure it for three audiences: executives, tech leads, and developers.