Testing how applications behave and perform under various load, stress, and real-world conditions.
Performance testing is critical but often done last or skipped. A beautifully designed system that can't handle 100 concurrent users is worthless. Performance issues directly impact business: Slow sites lose customers, crashes cause data loss, timeouts frustrate users. Amazon's research: 100ms delay = 1% sales loss. Facebook: 1 second delay = 2% decline in traffic.
| Metric | Description | Formula | Industry Benchmark | Example |
|---|---|---|---|---|
| Response Time (Latency) | How long user waits for response | Time from request sent to response received | Web: <200ms is excellent, <1s is good, >3s is unacceptable | User clicks 'Login' ā Server processes ā Response received = 150ms |
| Throughput | How many requests/transactions completed per second | Total requests processed / Total time | Web API: 1000-10000 req/sec typical | API can process 5000 requests per second |
| Concurrent Users | How many users can use system simultaneously | Peak load the system can handle | E-commerce: 10,000 concurrent during Black Friday sale | System handles 1000 concurrent users without degradation |
| CPU Usage | Processor utilization under load | CPU cycles used / Total CPU capacity | Healthy: 60-80%, warning: >80%, critical: >90% | At 1000 users, CPU usage 75% (room to grow) |
| Memory Usage | RAM consumed by application | Used memory / Total available | Healthy: <70%, warning: 70-85%, critical: >85% | App uses 4GB of 8GB available |
| Error Rate | Percentage of failed requests under load | (Failed requests / Total requests) Ć 100 | Acceptable: <0.1% errors, target: 0% errors | At 5000 concurrent users, 0.05% requests fail (1 in 2000) |
| Name | Description | Purpose | Example | Expected Outcome | Tools |
|---|---|---|---|---|---|
| Load Testing | Test under expected/normal production load | Verify system meets performance requirements under typical conditions | E-commerce site during normal day: 1000 concurrent users expected | Response time <500ms, CPU <70%, no errors | JMeter, LoadRunner, Gatling |
| Stress Testing | Test beyond maximum expected load to find breaking point | Identify failure threshold and graceful degradation | E-commerce Black Friday sale: 100,000 concurrent users (10x normal) | System degrades gracefully (shows 'wait in queue'), doesn't crash | JMeter, LoadRunner, Locust |
| Spike Testing | Sudden dramatic increase in load | Verify system recovers from traffic spikes | Traffic normally 100 users, suddenly jumps to 50,000 (viral post) | Handles spike, doesn't crash, recovers to normal | JMeter with spike configuration |
| Endurance/Soak Testing | Run system under moderate load for extended period | Find memory leaks, resource exhaustion over time | Run 10,000 transactions per hour for 24 hours | Memory usage stays constant, no gradual degradation | JMeter, custom scripts |
| Ramp-up Testing | Gradually increase load over time | Identify at what load point system starts struggling | Start with 0 users, add 100 users every minute until failure | Identify exact threshold (e.g., system OK until 8000 users) |
E-commerce site went down during Black Friday sale
Normal capacity: 1000 concurrent users ā 100ms response time. Expected Black Friday: 5000 concurrent. Actual: 50,000 concurrent (viral post). System received 50x normal load. Expected response time: 100ms Ć 50 = 5 seconds. Actual: System hung and crashed.
1) Load test at 50,000 concurrent. 2) Identify bottleneck (database query taking too long?). 3) Optimize (add caching, database indexing). 4) Re-test. 5) Implement auto-scaling (add more servers dynamically). 6) Set up circuit breaker (return 'try later' instead of crashing).
| Step | Details | Example |
|---|---|---|
| 1. Identify Performance Requirements | What's acceptable response time? How many concurrent users? What's peak load? | Requirement: API must respond in <200ms for 95% of requests at 10,000 concurrent users |
| 2. Design Load Model | How do users behave? Constant load? Ramp-up? Spikes? | 0-2 min: 0ā1000 users (ramp-up), 2-5 min: 1000 users (steady), 5-6 min: 1000ā5000 (spike) |
| 3. Create Test Scripts | Script realistic user workflows | Login ā Search products ā Add to cart ā Checkout ā Payment ā Logout |
| 4. Set Up Monitoring | Collect metrics: response time, CPU, memory, error rate | JMeter collects metrics, push to monitoring dashboard |
| 5. Execute Load Test | Run test and collect data | JMeter generates load for 30 minutes, records all metrics |
| 6. Analyze Results | Compare actual vs requirements, identify bottlenecks | Response time 500ms vs requirement 200ms. Database queries slow. CPU >90%. |
| 7. Identify Bottleneck | Where's the problem? Database? Network? Code? | Slow query in product search. Missing database index. |
| 8. Optimize & Re-test | Fix performance issues and re-run test | Add index, response time now 150ms. Meets requirement. |
| Issue | Description | Impact | Solution |
|---|---|---|---|
| N+1 Query Problem | Code queries database in a loop instead of batch | 1000 requests ā 1001 database queries instead of 2 | Use JOIN queries, batch operations, caching |
| Missing Database Indexes | Searching without indexes is slow | Query takes 5 seconds to find 1 record in million-row table | Add index on frequently searched columns |
| Memory Leak | Application keeps using more memory over time | Server starts with 2GB usage, grows to 8GB after hours, crashes | Profile code, find objects not being garbage collected |
| Inefficient Algorithm | Algorithm has poor time complexity | Sorting 1 million items using O(nĀ²) instead of O(n log n) | Use better algorithm (QuickSort instead of BubbleSort) |
| No Caching | Computing same result repeatedly | 200ms to compute user profile, times 10,000 users = 2000 seconds | Cache computation for 5 minutes, reuse for all requests |
| Synchronous Operations | Waiting for slow operations to complete | Each request waits 3 seconds for email sending | Make asynchronous (queue email, send in background) |
| Tool | Best For | Drawback |
|---|---|---|
| Apache JMeter | Open-source, free, supports all protocols | Steep learning curve |
| LoadRunner | Enterprise, advanced features | Expensive licensing |
| Gatling | Modern tool, code-based, CI/CD friendly | Scala syntax may be unfamiliar |
| Locust | Python-based, simple scripting | Newer tool, less mature |
| K6 | Cloud-based, JavaScript, developer-friendly | Requires subscription for advanced features |
Your checkout API responds in 100ms with 100 users, but 2 seconds with 1000 users. Expected: <500ms even at 1000 users. Diagnose and fix.
š Performance issues found under load, not with single user. Always load test before release. Slow = broken. Dead = worse.
Performance testing is advanced topic. Strong understanding separates senior testers from juniors.