Visualizing load and performance test results
As an application approaches release, load and performance tests verify whether it can actually deliver the target performance. Most test tools (JMeter, LoadRunner, and others) provide aggregate statistics per scenario, but it is hard to identify "which transaction, which section is the bottleneck" from a service perspective. Combining WhaTap Monitoring lets you visualize test results in real time at the service and transaction level and pinpoint bottlenecks and error causes.
4 types of load and performance tests
| Type | Purpose |
|---|---|
| Load test | Verify performance and stability at expected peak traffic |
| Stress test | Find the breaking point, recovery behavior, and failure thresholds |
| Spike test | Check the response to sudden traffic surges and drops |
| Endurance test | Detect leaks and accumulation issues under long-running load |
Key measurement metrics
- Response time — Average, p95, p99
- Throughput (TPS, Transactions per Second)
- Error rate
Test tool reports alone make it hard to answer "why did the average response time spike in this scenario?" You need tracing at the individual transaction level.
Using WhaTap together
① Run the load with a test tool
Run the scenario with your team's tool — JMeter, LoadRunner, k6, Locust, and so on. The test tool handles load generation and aggregate statistics.
② Visualize at the service level in WhaTap
If the WhaTap agent is installed on the target application, transactions generated during the test are collected in real time.
Menus to use:
- Application dashboard — TPS, response time, and error rate trends at the service level
- Hitmap transaction — Response distribution per time range; spot anomalies instantly
- Transaction trace — Call stack and SQL, HTTP, and external call timings for a slow transaction
- DB connection status and slow SQL — Cross-check DB-side bottlenecks
- Heap memory and active stack — Check GC, memory, and thread bottlenecks
③ Identify the cause → rerun the test → compare
Compare hitmap patterns, transaction traces, and dashboard numbers between before and after improvement over the same period to quantify the tuning effect.
Usage scenarios
Pre-release load test
- Reproduce expected peak traffic with the test tool.
- Track TPS, response time, and error rate in real time on the WhaTap dashboard.
- When errors spike or response time surges, use the transaction trace to analyze the root cause immediately.
- Use the results as baseline records for the release verification scenario.
Performance regression detection
- Test under the same load conditions as the previous version.
- Compare key metrics (TPS, p95, error rate) quantitatively.
- If a regression appears, identify the slower sections through the transaction trace.
Bottleneck identification and tuning loop
- Anomaly cluster in the hitmap → trace for root cause → code, SQL, or index fix → rerun and compare
- Run improvement cycles based on measurement, not intuition.
Next steps
- Deep dive on hitmap and trace → Exploring Hitmap Transaction
- Check DB-side bottlenecks → DB connection delay and Connection Pool, Database real-time visibility
- Memory and GC analysis → Heap memory alert
- Use test results as a release criterion → Release verification scenario