Chapter 10: Practice: Load Test a Web App
Before you touch JMeter, you need to think. The biggest mistake junior performance testers make is jumping straight into building test plans without understanding what they are testing and why. Your manager does not care that you can make JMeter send 1,000 requests per second. They care whether customers can complete checkout during the Diwali sale.
Open the Shopping Portal and use it like a customer would. Browse around. Search for products. Add things to cart. Go through checkout. As you do this, think about one question: "If this flow breaks, does the business lose money?" If the answer is yes, that flow needs performance testing.
For our Shopping Portal, here are the critical flows ranked by business impact:
| Priority | Flow | Business Impact | Why It Matters |
|---|---|---|---|
| P0 | Search -> Product -> Add to Cart -> Checkout | Direct revenue loss | If checkout fails, customers abandon and buy elsewhere |
| P1 | User Login / Registration | Blocks all authenticated flows | Users cannot buy if they cannot log in |
| P1 | Product Search | Discovery failure | Users cannot find products, they leave |
| P2 | Homepage Load | First impression | Slow homepage increases bounce rate |
| P2 | Product Detail Page | Conversion impact | Slow product pages reduce add-to-cart rate |
| P3 | Order History | Customer support load | Users call support if they cannot see their orders |
For this capstone project, we will focus on the P0 flow: the complete shopping journey from login through checkout. This is the flow that directly generates revenue and is the most complex, involving multiple API calls, state management (cart), and data dependencies (product IDs, order IDs).
Let us map out every single step a real user takes, along with the API calls each step triggers. This is your script blueprint.
User opens the homepage (GET /) -- browser loads HTML, CSS, JS, images
User logs in (POST /api/auth/login) -- receives session token / auth cookie
User searches for a product (GET /api/products?q=laptop) -- receives product list
User clicks a product (GET /api/products/{productId}) -- receives product details
User adds product to cart (POST /api/cart) -- sends productId and quantity
User views cart (GET /api/cart) -- sees all items with prices
User proceeds to checkout (POST /api/checkout) -- submits shipping and payment details
User views order confirmation (GET /api/orders/{orderId}) -- sees order summary
SLAs are not something you invent -- they come from the business. But for a practice project, here are realistic SLAs modeled after typical e-commerce applications:
| Metric | Target | Acceptable | Failure |
|---|---|---|---|
| Homepage p95 response time | < 2 seconds | < 3 seconds | > 3 seconds |
| Search p95 response time | < 1.5 seconds | < 2.5 seconds | > 2.5 seconds |
| Add to Cart p95 response time | < 1 second | < 1.5 seconds | > 1.5 seconds |
| Checkout p95 response time | < 3 seconds | < 5 seconds | > 5 seconds |
| Overall error rate | < 0.1% | < 0.5% | > 1% |
| Throughput at peak load | > 50 RPS | > 30 RPS | < 20 RPS |
In real projects, always get SLAs signed off by stakeholders BEFORE you start testing. Nothing is worse than finishing a test and having someone say "well, 3 seconds is too slow for us" when you assumed 5 seconds was fine. Get it in writing.
Remember workload modeling from Chapter 9? Here is our model for the Shopping Portal based on "expected Diwali sale traffic":
| Parameter | Baseline | Load Test | Stress Test | Spike Test |
|---|---|---|---|---|
| Concurrent Users | 10 | 100 | 250 | 50 -> 300 -> 50 |
| Ramp-up Period | 10 seconds | 60 seconds | 120 seconds | 10 seconds |
| Test Duration | 2 minutes | 10 minutes | 10 minutes | 5 minutes |
| Think Time | 2-4 seconds | 2-4 seconds | 2-4 seconds | 1-2 seconds |
| Loops | 1 | 5 | 5 | 3 |
Key Point: Test planning is 50% of the work. A well-planned test with clear SLAs and a realistic workload model produces actionable results. A poorly planned test produces numbers nobody trusts.
Key Point: Identify business-critical flows, define measurable SLAs, and model realistic workloads before building any test scripts.