Load Testing.
Interview cheat sheet.

Load testing evaluates system performance under expected and peak user loads, identifying bottlenecks before production. Master performance metrics, testing tools (JMeter, K6, Locust), load patterns, bottleneck analysis, and result interpretation to ensure applications meet performance SLAs and scale effectively.

Definition: A type of performance testing that simulates real-world load on any software, application, or website to determine how it behaves under expected and peak load conditions.

Key Purpose: Identify performance bottlenecks before production deployment.

Response Time Metrics

• Average Response Time: Mean time for all requests
• Peak Response Time: Maximum response time recorded
• Percentiles (P90, P95, P99): Response time for 90%, 95%, 99% of requests

Throughput Metrics

• Requests per Second (RPS): Number of requests handled per second
• Transactions per Second (TPS): Business transactions completed per second
• Bandwidth: Data transferred per second

Resource Metrics

• CPU Utilization: Percentage of CPU used
• Memory Usage: RAM consumption
• Disk I/O: Read/write operations
• Network I/O: Network bandwidth usage

Error Metrics

• Error Rate: Percentage of failed requests
• Error Types: 4xx, 5xx HTTP errors
• Timeout Rate: Requests that exceeded time limit

graph LR
    A[1. Define Goals] --> B[2. Create Test Plan]
    B --> C[3. Setup Test Environment]
    C --> D[4. Create Test Scripts]
    D --> E[5. Execute Tests]
    E --> F[6. Monitor & Collect Data]
    F --> G[7. Analyze Results]
    G --> H[8. Report Findings]

Detailed Steps:

1. Define Goals

   • Expected concurrent users
   • Response time SLAs
   • Throughput requirements

2. Create Test Plan

   • Test scenarios
   • Load patterns
   • Success criteria

3. Setup Environment

   • Production-like setup
   • Monitoring tools
   • Test data preparation

4. Create Scripts

   • User workflows
   • Think time
   • Data parameterization

5. Execute Tests

   • Gradual ramp-up
   • Sustained load
   • Gradual ramp-down

Open Source

• JMeter: Java-based, GUI and CLI support
• Gatling: Scala-based, code-as-configuration
• Locust: Python-based, distributed testing
• K6: JavaScript-based, developer-centric

Commercial

• LoadRunner: Enterprise solution by Micro Focus
• NeoLoad: Continuous performance testing
• BlazeMeter: Cloud-based, CI/CD integration

<!-- Simple HTTP Test Plan -->
<TestPlan>
  <ThreadGroup>
    <numThreads>100</numThreads>
    <rampUp>10</rampUp>
    <duration>300</duration>
    
    <HTTPSampler>
      <domain>api.example.com</domain>
      <path>/users</path>
      <method>GET</method>
    </HTTPSampler>
    
    <ResponseAssertion>
      <responseCode>200</responseCode>
      <responseTime>1000</responseTime>
    </ResponseAssertion>
  </ThreadGroup>
</TestPlan>

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)  # Think time
    
    @task(3)
    def view_products(self):
        self.client.get("/products")
    
    @task(1)
    def view_product_details(self):
        product_id = random.randint(1, 1000)
        self.client.get(f"/products/{product_id}")
    
    def on_start(self):
        # Login once per user
        self.client.post("/login", {
            "username": "testuser",
            "password": "testpass"
        })

import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
  stages: [
    { duration: '2m', target: 100 },  // Ramp up
    { duration: '5m', target: 100 },  // Stay at 100
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% under 500ms
    http_req_failed: ['rate<0.1'],    // Error rate < 10%
  },
};

export default function() {
  let response = http.get('https://api.example.com/users');
  
  check(response, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  
  sleep(1); // Think time
}

Test Design

• ✅ Use realistic test data
• ✅ Include think time between requests
• ✅ Simulate realistic user behavior
• ✅ Test with production-like environment

Execution

• ✅ Start with small load, gradually increase
• ✅ Run tests multiple times for consistency
• ✅ Monitor both client and server metrics
• ✅ Test during different times/conditions

Analysis

• ✅ Look for trends, not just averages
• ✅ Correlate metrics (CPU vs response time)
• ✅ Identify bottlenecks systematically
• ✅ Compare with baseline results

Virtual User Calculation

Formula: Virtual Users = (Hourly Sessions × Average Session Duration) / 3600

Example Calculation:

• 10,000 sessions/hour
• 5 minutes average session
• VU = (10,000 × 300) / 3600 = 833 concurrent users

Considerations:

• Peak hour traffic patterns
• Geographic distribution
• User behavior variations

Concurrent vs Simultaneous Users

• Concurrent Users: Total users with active sessions (including think time)
• Simultaneous Users: Users making requests at exact same moment
• Conversion Rule: Simultaneous ≈ 10-20% of concurrent
• Impact: Server resources, connection pools, database locks

Dynamic Data Handling Strategies

Parameterization

• CSV data files for user credentials
• Database queries for test data
• Random data generation functions

Correlation

// JMeter Example
Regular Expression Extractor:
  Reference Name: sessionId
  RegEx: sessionId=([^&]+)
  Template: $1$
  
// Usage: ${sessionId}

Data Management

• Unique data per virtual user
• Data recycling strategies
• Cache simulation considerations

Little's Law Application

Formula: L = λ × W

• L: Average number of users in system
• λ: Average arrival rate (users/second)
• W: Average time in system (seconds)

Practical Uses:

• Validate test results consistency
• Capacity planning calculations
• Queue theory applications
• Performance baseline establishment

Memory Leak Detection

Detection Techniques

• Heap Monitoring: Track heap usage trends over time
• GC Analysis: Frequent full GC indicates issues
• Object Growth: Monitor object creation/destruction rates
• Profiler Integration: Use during load tests for deep analysis

Warning Signs

• Continuously increasing memory usage
• Declining throughput over time
• Increasing response times
• OutOfMemoryError occurrences

1. Executive Summary

   • Pass/Fail status
   • Key findings
   • Recommendations

2. Test Configuration

   • Environment details
   • Test scenarios
   • Load pattern

3. Results

   • Response times (with percentiles)
   • Throughput achieved
   • Error rates
   • Resource utilization

4. Analysis

   • Bottlenecks identified
   • Performance vs SLAs
   • Scalability insights

5. Recommendations

   • Short-term fixes
   • Long-term improvements
   • Capacity planning

# Example: GitLab CI with K6
load_test:
  stage: performance
  script:
    - k6 run --out cloud script.js
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  artifacts:
    reports:
      performance: k6-results.json

Think Time = (Total Test Duration × VUsers - Total Requests Time) / Total Requests

Pacing = (Test Duration × VUsers) / Total Transactions Required

Throughput = Total Requests / Test Duration

Error Rate = (Failed Requests / Total Requests) × 100

Apdex Score = (Satisfied + Tolerating/2) / Total Samples

⚠️ Response time increases linearly with load → Synchronization issues
⚠️ Sudden spike in errors at specific load → Resource limit reached
⚠️ Memory continuously increasing → Memory leak
⚠️ CPU 100% but low throughput → Inefficient code
⚠️ Database connections maxed out → Connection pool issues

Technical Excellence

• Metrics Mastery: Understand percentiles (P50, P90, P99) over averages
• Tool Proficiency: Hands-on experience with at least 2 tools
• Scripting Skills: Demonstrate correlation, parameterization
• Analysis Capability: Identify bottlenecks from metrics
• Cloud Experience: Distributed load generation, auto-scaling

Business Alignment

• Impact Communication: "20% slower checkout = 5% revenue loss"
• Cost-Benefit Analysis: Balance performance vs infrastructure costs
• Risk Assessment: Identify critical user journeys
• SLA Understanding: Response time, availability targets
• Stakeholder Language: Translate technical metrics to business impact

Problem-Solving Approach

1. Systematic Investigation: Isolate → Investigate → Resolve
2. Baseline Establishment: Always compare against known good state
3. Incremental Testing: Start small, gradually increase load
4. Root Cause Analysis: Don't just treat symptoms
5. Documentation: Clear reports with actionable recommendations

Key Discussion Points

• Production Readiness: How to validate before release
• Continuous Monitoring: APM tools, alerting strategies
• Capacity Planning: Growth projections, scaling strategies
• Performance Budget: Setting and maintaining limits
• DevOps Integration: Shift-left performance testing

Questions to Ask Interviewers

• What are the current performance SLAs?
• What is the expected user growth?
• Are there specific performance pain points?
• What monitoring tools are in place?
• How is performance testing integrated in CI/CD?