Chapter 10: Practice: Load Test a Web App
A fast wrong answer is worse than a slow correct one. I once reviewed a load test where the team proudly reported "95th percentile response time is 200ms across all endpoints!" Impressive -- until I looked at the actual responses. The server was returning 200 OK with a JSON body of {"error": "Service unavailable"} for 40% of requests. The test was measuring how fast the error handler could produce error messages. Not useful.
We need three types of assertions to ensure our test results are meaningful:
| Assertion Type | What It Checks | JMeter Element | Example |
|---|---|---|---|
| Response Code | HTTP status is what we expect | Response Assertion | Status = 200 for successful requests |
| Response Content | Body contains expected data | JSON Assertion / Response Assertion | $.products array exists in search results |
| Response Time | Request completes within SLA | Duration Assertion | Homepage loads in < 3000ms |
Transaction | Status | Content Check | Duration SLA
---------------------+--------+-----------------------------+-------------
01_Homepage | 200 | (HTML body is not empty) | < 3000ms
02_Login | 200 | $.token exists | < 2000ms
03_Search | 200 | $.products is array | < 2000ms
04_ProductDetail | 200 | $.name exists | < 2000ms
05_AddToCart | 200 | $.cartId exists | < 1000ms
06_ViewCart | 200 | $.items is array | < 2000ms
07_Checkout | 200 | $.orderId exists | < 3000ms
08_OrderConfirmation | 200 | $.status exists | < 2000msDuration assertions mark individual requests as failed if they exceed the threshold. This is useful for identifying SLA breaches during the test, but it also inflates your error rate. If your SLA says "p95 response time < 2 seconds," then by definition 5% of requests are allowed to exceed that. But Duration Assertions will mark every request over 2 seconds as a failure, making your error rate look terrible.
My recommendation: use Response Assertions (status code + content) always. Use Duration Assertions only during baseline runs. For load and stress tests, analyze percentile response times in the Aggregate Report instead. This keeps your error rate clean and your SLA analysis separate.
Q: How do you define and validate SLAs in your performance tests?
A: I define SLAs in collaboration with stakeholders before testing begins, covering response time percentiles (p95, p99), error rate thresholds, and minimum throughput requirements. In JMeter, I implement Response Assertions for functional correctness (status codes, expected JSON fields) on all requests. For response time SLAs, I prefer analyzing percentiles from the Aggregate Report rather than using Duration Assertions, because percentile-based SLAs expect some requests to exceed the threshold. Duration Assertions mark every slow request as a failure, which inflates the error count. After the test, I compare Aggregate Report percentiles against the SLA targets and flag any breaches in the report with specific recommendations.
Key Point: Assertions ensure you are measuring correct responses, not fast errors. Use Response Assertions for functional correctness and Aggregate Report percentiles for SLA validation. Duration Assertions are useful but can inflate error rates.
Key Point: Always validate response correctness with assertions, not just speed. A fast error response is not a passing test.