// LOAD TESTING — Expected number of users
// Simulates normal and peak production traffic
// Goal: Verify the system meets SLA under expected load
// Example: 2,000 virtual users for 30 min, response time < 2s

// STRESS TESTING — Beyond system capacity
// Goal: Find max capacity and how the system fails
// Example: Increase users 2,000 → 5,000 → 10,000

// SPIKE TESTING — Sudden burst of traffic
// Simulates flash sales, breaking news, viral events
// Example: Jump from 500 to 5,000 users in 10 seconds

// ENDURANCE (SOAK) TESTING — Sustained load over time
// Runs expected load for 8-72 hours continuously
// Goal: Detect memory leaks, connection pool exhaustion
// Example: 1,500 users for 24 hours straight

// PERFORMANCE TESTING (umbrella term)
// ├── Load Testing        → expected user volume
// ├── Stress Testing      → beyond capacity
// ├── Spike Testing       → sudden traffic burst
// ├── Endurance Testing   → sustained load over time
// ├── Scalability Testing → growth handling
// └── Baseline Testing    → benchmark before changes

// Performance testing answers: "How does the system behave?"
// Load testing answers: "Can it handle the expected traffic?"

// BASELINE TESTING — Establish normal performance metrics
// Run a controlled test with fixed conditions (500 users, 30 min)
//   ┌─────────────────────────┬──────────┐
//   │ Metric                  │ Value    │
//   ├─────────────────────────┼──────────┤
//   │ Avg Response Time       │ 1.2s     │
//   │ 90th Percentile         │ 2.1s     │
//   │ Throughput              │ 450 req/s│
//   │ Error Rate              │ 0.3%     │
//   │ CPU Utilization         │ 65%      │
//   └─────────────────────────┴──────────┘
// After changes, run the SAME test and compare
// Key rule: Change ONE variable at a time

// VERTICAL SCALING (Scale Up) — More CPU/RAM on same server
// HORIZONTAL SCALING (Scale Out) — More servers behind load balancer

// Test approach — find the "knee" point:
// Users:    100   200   500   1000  2000  3000
// Resp(ms): 200   210   280   450   1200  5000
//                                    ↑ Knee point
// Answers: "How many servers do we need for Black Friday?"

// 1. RESPONSE TIME — Web pages: < 2s | APIs: < 200ms
//    Measure: Average, Median, 90th/95th/99th percentile
// 2. THROUGHPUT — requests/second (req/s) or TPS
//    Higher is better — only if error rate stays low
// 3. ERROR RATE — Acceptable: < 1% | Critical: > 5%
// 4. CONCURRENT USERS — Active at the same time
//    10,000 registered ≠ 10,000 concurrent (typically 5-10%)
// 5. CPU — Healthy: < 70% | Warning: 70-85% | Critical: > 85%
// 6. MEMORY — Healthy: < 75% | Watch: steady increase = leak
// 7. NETWORK — High latency + low CPU = network bottleneck

// 10 API requests (ms): 150, 160, 170, 180, 190, 200, 210, 220, 250, 2500
// AVERAGE = 423ms — looks acceptable!
// But 1 user waited 2,500ms — average HIDES this
// 90TH PERCENTILE = 250ms (90% completed within this time)
// 95TH PERCENTILE = 2500ms — reveals the real problem!

// SLA DEFINITION USING PERCENTILES:
// ┌──────────────────────────────────────────┐
// │ P90 response time < 2s                   │
// │ P95 response time < 3s                   │
// │ P99 response time < 5s                   │
// │ Error rate < 1% | Throughput > 500 req/s │
// └──────────────────────────────────────────┘
// "Average < 2s" = bad SLA | "P90 < 2s" = good SLA

// CPU BOUND — CPU > 85%, response time scales with load
// Causes: Inefficient algorithms, excessive logging
// Fix: Code optimization, caching, async processing

// MEMORY BOUND — High memory, frequent GC, OOM errors
// Causes: Memory leaks, large object caching, session bloat
// Fix: Fix leaks, tune GC, increase heap (short-term)

// I/O BOUND — Low CPU + low memory + high response time
// Causes: Unindexed queries, full table scans, disk latency
// Fix: Add indexes, query optimization, read replicas

// NETWORK BOUND — Low server usage + high latency
// Causes: Bandwidth saturation, large payloads, DNS delays
// Fix: Compression, CDN, payload optimization

// Diagnostic order: CPU → Memory → I/O → Network
// Tools: top/htop, VisualVM, iostat, slow query log, APM

// Test Plan → Thread Group → Samplers → Listeners → Assertions

// Thread Group:
// ┌─────────────────────────────────────────┐
// │ Threads: 500 | Ramp-Up: 60s | Loops: 10│
// │ Duration: 1800s (30 min)                │
// └─────────────────────────────────────────┘
// 500 users over 60s = ~8 new users/second

// HTTP Request: GET https://api.example.com/api/v1/products
// Listeners: Summary Report, Aggregate Report
// Assertions: Status = 200, Duration < 3000ms
// Config: HTTP Header Manager, Cookie Manager, CSV Data Set

// JMETER — Open Source, Java, GUI, huge community
//   Protocols: HTTP, JDBC, JMS, FTP, SOAP, REST
//   Best for: Teams needing a free, versatile tool

// LOADRUNNER — Enterprise, Licensed ($$$)
//   Protocols: SAP, Citrix, Oracle + advanced analytics
//   Best for: Large enterprises, legacy protocol testing

// GATLING — Open Source, Scala DSL, lightweight
//   Excellent reports, CI/CD friendly
//   Best for: Developer-centric teams, CI/CD pipelines

// K6 — Open Source, JavaScript, cloud-native
//   Modern API, Grafana integration, excellent DX
//   Best for: API testing, cloud-native apps

// Budget + GUI → JMeter | Enterprise → LoadRunner
// Dev team + CI/CD → Gatling or k6 | API-first → k6

// ┌──────────┐     ┌──────────────┐
// │  MASTER   │────→│  SLAVE 1     │ → 1000 users
// │ (Control) │────→│  SLAVE 2     │ → 1000 users
// │           │────→│  SLAVE 3     │ → 1000 users
// └──────────┘     └──────────────┘  Total: 3000

// Setup:
// 1. Same JMeter version on all machines
// 2. Slaves: start ./jmeter-server
// 3. Master jmeter.properties:
//    remote_hosts=192.168.1.10,192.168.1.11,192.168.1.12
// 4. CLI (non-GUI for actual tests):
//    jmeter -n -t test.jmx -R 192.168.1.10,192.168.1.11
//           -l results.jtl -e -o report_folder
// CSV files must exist on each slave | Port 1099 must be open

// Server returns: { "sessionToken": "abc123xyz789" }
// Without correlation: hardcoded token → 401 error
// With correlation: extract token dynamically

// JMeter Regular Expression Extractor:
// ┌─────────────────────────────────────────────┐
// │ Reference Name:    sessionToken              │
// │ Regular Expression: "sessionToken":"(.+?)"   │
// │ Template:          $1$                       │
// │ Default Value:     TOKEN_NOT_FOUND           │
// └─────────────────────────────────────────────┘

// JMeter JSON Extractor (cleaner for JSON APIs):
// Variable: sessionToken | JSON Path: $.sessionToken

// Use: Authorization: Bearer ${sessionToken}
// Common values: Session IDs, CSRF tokens, OAuth tokens,
// transaction IDs, pagination cursors

// CSV Data Set Config (most common):
// test_users.csv: username,password,accountId
//                 user001,pass001,ACC001
//                 user002,pass002,ACC002

// ┌─────────────────────────────────────────────┐
// │ Filename:       test_users.csv               │
// │ Variable Names: username,password,accountId   │
// │ Delimiter: , | Recycle on EOF: True          │
// │ Sharing Mode:   All threads                  │
// └─────────────────────────────────────────────┘
// Use: {"username":"${username}","password":"${password}"}

// JMeter Functions:
// ${__Random(1,100,)}          — random number
// ${__RandomString(8,abcdef,)} — random string
// ${__UUID()}                   — unique identifier

// PATTERN 1: Login Once, Reuse Session (recommended)
// setUp Thread Group → POST /login → JSON Extractor
// → BeanShell: props.put("authToken", vars.get("token"))
// Main Thread Group: ${__property(authToken)}

// PATTERN 2: Per-User Login with Cookie Manager
// HTTP Cookie Manager auto-handles session cookies
// POST /login → GET /dashboard → GET /api/data

// PATTERN 3: OAuth Token with Refresh
// Login → extract access_token + refresh_token
// If Controller: check expiry → refresh if needed

// Key: Separate login time from transaction response time
// Use Transaction Controller to isolate business flows
// Pre-generate tokens for large-scale tests

// 1. DATABASE QUERIES — Most common cause
//    Slow query log, EXPLAIN ANALYZE, missing indexes
//    Fix: Add indexes, optimize queries, read replicas

// 2. CONNECTION POOL EXHAUSTION
//    Pool max = 20, but 500 users need connections
//    480 requests queue → high response time
//    Fix: Increase pool size, optimize query duration

// 3. THREAD CONTENTION / BLOCKING
//    Threads waiting on synchronized blocks
//    Fix: Reduce synchronization, concurrent data structures

// 4. EXTERNAL API CALLS
//    Waiting for slow payment gateway, email service
//    Fix: Async calls, circuit breakers, timeouts, caching

// 5. NETWORK LATENCY
//    Many small queries adding network overhead
//    Fix: Batch queries, co-locate services

// Approach: Start with database, work through each layer

// METHOD 1: Production Analytics
// Concurrent = (Peak Hourly Users × Avg Session) / 3600
// = (8,000 × 300s) / 3600 = 667 concurrent users
// Load test (1.5x): 1,000 | Stress test (3x): 2,000

// METHOD 2: Business Requirements
// "Must support 10,000 concurrent users"
// Load: 10,000 | Stress: 15,000-20,000

// METHOD 3: Little's Law — L = λ × W
// 100 users/sec × 5 sec avg = 500 concurrent

// RAMP-UP: Do NOT start all users at once
// 100 users (5 min) → 250 (5 min) → 500 (10 min) → 1000 (15 min)
// Monitor at each step — stop if errors spike