Load Testing

Overview

Load testing measures how applications perform under expected and peak user loads. The practice simulates multiple concurrent users accessing an application to identify performance bottlenecks, resource limitations, and scalability issues before they impact production systems.

Load testing differs from other performance testing types through its focus on expected traffic patterns. While stress testing pushes systems to breaking points and spike testing examines sudden traffic bursts, load testing validates behavior under realistic operational conditions. A load test might simulate 1,000 concurrent users browsing an e-commerce site, adding items to carts, and completing purchases to verify the system handles typical Friday evening traffic.

The practice emerged from the need to predict production behavior in development environments. Applications that perform well with single users often degrade under concurrent load due to resource contention, inefficient database queries, memory leaks, or inadequate caching strategies. Load testing exposes these issues in controlled environments where debugging and optimization occur without affecting real users.

Modern load testing encompasses several dimensions: concurrent users, requests per second, data volume, geographic distribution, and sustained duration. A complete load test profile includes ramp-up periods where virtual users gradually join, sustained load periods maintaining stable traffic, and ramp-down phases. This approach reveals performance characteristics across different load levels rather than testing only at peak capacity.

# Basic load test concept
def simulate_load(users:, duration:)
  start_time = Time.now
  
  threads = users.times.map do |user_id|
    Thread.new do
      while Time.now - start_time < duration
        perform_user_action(user_id)
        sleep(rand(1..5))
      end
    end
  end
  
  threads.each(&:join)
end

Key Principles

Load testing operates on several fundamental principles that determine test effectiveness and result validity.

Realistic Traffic Patterns: Load tests must replicate actual user behavior patterns. Real users don't simultaneously hammer a single endpoint; they navigate through multiple pages, pause to read content, submit forms, and exhibit varied timing between actions. Load tests incorporating think time (delays between requests) and varied user journeys produce more accurate performance predictions than tests that simply blast a single URL.

Incremental Load Ramping: Applying full load instantly masks important performance characteristics. Systems often handle sudden spikes differently than gradually increasing load. Incremental ramping from baseline to peak load reveals the point where performance degradation begins, identifies resource saturation thresholds, and exposes issues like connection pool exhaustion that appear only after sustained operation.

Metrics Collection: Load testing generates multiple metric types. Response time metrics include mean, median, 95th percentile, and 99th percentile values. Throughput metrics measure requests per second and data transfer rates. Error metrics track failure rates and error types. Resource metrics monitor CPU utilization, memory consumption, database connections, and network bandwidth. Collecting these metrics throughout the test reveals correlations between load levels and system behavior.

Environment Parity: Load test environments should mirror production infrastructure. Testing against a single application server provides limited insight into how a load-balanced production cluster performs. Database configurations, network topology, caching layers, and external service integrations affect performance under load. Significant environment differences produce test results that don't predict production behavior.

Baseline Establishment: Every load test requires a baseline measurement. Running tests against known-good application versions establishes performance expectations. Subsequent tests compare against this baseline to detect regressions. Without baselines, teams cannot determine whether 500ms response times represent acceptable performance or significant degradation.

Statistical Significance: Single test runs produce unreliable results. Network conditions, background processes, and system state variations affect measurements. Running multiple test iterations and calculating statistical distributions separates real performance characteristics from random variation.

# Load test with ramping and metrics
class LoadTestRunner
  def initialize(target_url)
    @target_url = target_url
    @response_times = []
    @errors = []
  end
  
  def run(max_users:, ramp_duration:, test_duration:)
    ramp_rate = max_users.to_f / ramp_duration
    start_time = Time.now
    active_threads = []
    
    # Ramp up phase
    while Time.now - start_time < ramp_duration
      users_to_start = (ramp_rate * (Time.now - start_time)).to_i - active_threads.size
      
      users_to_start.times do
        active_threads << start_user_thread
      end
      
      sleep(1)
    end
    
    # Sustained load phase
    sleep(test_duration)
    
    # Collect results
    active_threads.each(&:join)
    analyze_results
  end
  
  private
  
  def start_user_thread
    Thread.new do
      loop do
        start = Time.now
        begin
          response = HTTP.get(@target_url)
          @response_times << Time.now - start
          @errors << response.code unless response.code == 200
        rescue => e
          @errors << e.message
        end
        sleep(rand(2..10)) # Think time
      end
    end
  end
  
  def analyze_results
    sorted_times = @response_times.sort
    {
      mean: sorted_times.sum / sorted_times.size,
      median: sorted_times[sorted_times.size / 2],
      p95: sorted_times[(sorted_times.size * 0.95).to_i],
      p99: sorted_times[(sorted_times.size * 0.99).to_i],
      error_rate: @errors.size.to_f / @response_times.size
    }
  end
end

Implementation Approaches

Load testing implementations range from simple scripts to complex distributed systems. The approach selection depends on application scale, test complexity requirements, and team capabilities.

Script-Based Testing: Writing custom test scripts provides maximum flexibility and control. Ruby scripts using HTTP libraries can simulate user behavior, implement custom logic, and integrate with existing test suites. This approach works well for straightforward applications with simple user flows. The trade-off involves maintaining script code as applications evolve and handling distributed load generation manually.

Tool-Based Testing: Dedicated load testing tools provide features like distributed load generation, real-time metrics dashboards, and result analysis. Tools handle infrastructure complexity, allowing teams to focus on test scenarios. The trade-off involves learning tool-specific configuration languages and potential licensing costs. Tools often provide better scalability than custom scripts but less flexibility for complex test logic.

Cloud-Based Testing: Cloud load testing services generate load from distributed geographic locations, simulating realistic user distribution. These services scale to thousands of concurrent users without infrastructure investment. The approach works well for validating global application performance and handling unpredictable load requirements. Trade-offs include recurring costs and dependency on external services.

Production Traffic Replay: Capturing and replaying production traffic provides the most realistic load patterns. This approach uses actual user behavior rather than simulated patterns. Traffic replay works well for regression testing and validating infrastructure changes. The complexity involves sanitizing sensitive data, handling non-idempotent operations, and managing data consistency.

Hybrid Approaches: Combining multiple approaches addresses different testing needs. Teams might use lightweight scripts for continuous integration, detailed tool-based tests for release validation, and cloud services for capacity planning. This strategy balances cost, complexity, and test coverage.

Tools & Ecosystem

The load testing ecosystem includes tools spanning simple benchmarking utilities to enterprise platforms.

Apache Bench (ab): A command-line tool for basic HTTP benchmarking. Apache Bench measures request throughput and response times for single endpoints. The tool's simplicity makes it ideal for quick performance checks during development.

ab -n 1000 -c 100 http://example.com/api/users

wrk: A modern HTTP benchmarking tool supporting Lua scripting for complex request patterns. wrk generates significant load from single machines and provides detailed latency distributions.

Gatling: A Scala-based load testing tool with an expressive DSL for defining test scenarios. Gatling generates detailed HTML reports and supports protocol flexibility beyond HTTP. The tool integrates well with continuous integration pipelines.

JMeter: An established Java-based load testing platform with GUI and command-line interfaces. JMeter supports multiple protocols, distributed testing, and extensive plugin ecosystem. The tool's maturity provides stability but requires Java runtime management.

Locust: A Python-based load testing tool defining user behavior in Python code. Locust provides distributed testing capabilities and web-based monitoring. The Python scripting makes it accessible to teams familiar with the language.

Ruby-Specific Tools: The Ruby ecosystem includes several load testing libraries and tools.

rack-attack: A Rack middleware for throttling and blocking abusive requests. While primarily defensive, rack-attack aids load testing by implementing rate limiting that tests must validate.

siege: A command-line HTTP load testing utility available as a gem. Siege provides basic concurrent request generation and response time measurements.

# Using Ruby HTTP libraries for load testing
require 'http'
require 'concurrent'

class SimpleLoadTest
  def initialize(url, concurrency: 10)
    @url = url
    @concurrency = concurrency
    @results = Concurrent::Array.new
  end
  
  def run(requests:)
    pool = Concurrent::FixedThreadPool.new(@concurrency)
    
    requests.times do
      pool.post do
        start_time = Time.now
        response = HTTP.get(@url)
        duration = Time.now - start_time
        
        @results << {
          status: response.code,
          duration: duration,
          size: response.body.to_s.bytesize
        }
      end
    end
    
    pool.shutdown
    pool.wait_for_termination
    
    print_results
  end
  
  private
  
  def print_results
    durations = @results.map { |r| r[:duration] }
    
    puts "Requests: #{@results.size}"
    puts "Successful: #{@results.count { |r| r[:status] == 200 }}"
    puts "Failed: #{@results.count { |r| r[:status] != 200 }}"
    puts "Mean response time: #{durations.sum / durations.size}s"
    puts "Min: #{durations.min}s"
    puts "Max: #{durations.max}s"
  end
end

k6: Although written in Go, k6 deserves mention for its JavaScript-based test scripting and excellent Ruby application compatibility. k6 provides cloud execution and detailed metrics analysis.

Artillery: A modern Node.js-based load testing toolkit with YAML configuration. Artillery supports complex scenarios and integrates well with CI/CD pipelines.

Ruby Implementation

Ruby applications benefit from Ruby-native load testing tools that integrate with existing test frameworks and development workflows.

HTTP Client Libraries: Ruby's HTTP client libraries form the foundation of custom load testing scripts. The http gem provides a chainable API for HTTP requests, while rest-client offers simplicity for basic scenarios. faraday provides middleware support for request/response processing.

require 'http'
require 'benchmark'

class EndpointLoadTest
  def initialize(base_url)
    @base_url = base_url
    @client = HTTP.persistent(@base_url)
  end
  
  def test_endpoint(path, method: :get, payload: nil, iterations: 100)
    results = []
    
    iterations.times do
      result = Benchmark.measure do
        case method
        when :get
          @client.get(path)
        when :post
          @client.post(path, json: payload)
        when :put
          @client.put(path, json: payload)
        end
      end
      
      results << result.real
    end
    
    calculate_statistics(results)
  end
  
  private
  
  def calculate_statistics(times)
    sorted = times.sort
    {
      count: times.size,
      mean: times.sum / times.size,
      median: sorted[sorted.size / 2],
      min: sorted.first,
      max: sorted.last,
      p95: sorted[(sorted.size * 0.95).to_i],
      p99: sorted[(sorted.size * 0.99).to_i]
    }
  end
end

Concurrent Request Generation: Ruby's concurrency primitives enable parallel request generation. Threads provide straightforward concurrency for I/O-bound load testing. The concurrent-ruby gem offers advanced concurrency patterns including thread pools and futures.

require 'concurrent'
require 'http'

class ConcurrentLoadTest
  def initialize(url, thread_pool_size: 50)
    @url = url
    @pool = Concurrent::FixedThreadPool.new(thread_pool_size)
    @metrics = Concurrent::Hash.new
    @mutex = Mutex.new
  end
  
  def execute(total_requests:, requests_per_second:)
    interval = 1.0 / requests_per_second
    start_time = Time.now
    
    total_requests.times do |i|
      @pool.post { perform_request }
      
      # Throttle to maintain target RPS
      expected_time = start_time + (i * interval)
      sleep_time = expected_time - Time.now
      sleep(sleep_time) if sleep_time > 0
    end
    
    @pool.shutdown
    @pool.wait_for_termination
    
    @metrics
  end
  
  private
  
  def perform_request
    start = Time.now
    begin
      response = HTTP.timeout(10).get(@url)
      duration = Time.now - start
      
      @mutex.synchronize do
        @metrics[response.code] ||= []
        @metrics[response.code] << duration
      end
    rescue HTTP::TimeoutError
      @mutex.synchronize do
        @metrics[:timeout] ||= []
        @metrics[:timeout] << Time.now - start
      end
    end
  end
end

Scenario-Based Testing: Complex applications require testing user workflows rather than individual endpoints. Scenario-based testing simulates complete user journeys including authentication, navigation, and transactions.

class UserScenarioTest
  def initialize(base_url)
    @base_url = base_url
  end
  
  def run_scenario(user_count:, duration:)
    threads = user_count.times.map do |id|
      Thread.new { simulate_user(id, duration) }
    end
    
    threads.each(&:join)
  end
  
  private
  
  def simulate_user(user_id, duration)
    client = HTTP.persistent(@base_url)
    start_time = Time.now
    
    # Login
    response = client.post('/login', json: {
      username: "user#{user_id}",
      password: 'password'
    })
    
    token = JSON.parse(response.body)['token']
    authenticated_client = client.auth("Bearer #{token}")
    
    # Execute user journey
    while Time.now - start_time < duration
      # Browse products
      authenticated_client.get('/products')
      sleep(rand(2..5))
      
      # View product detail
      product_id = rand(1..100)
      authenticated_client.get("/products/#{product_id}")
      sleep(rand(3..8))
      
      # Add to cart (20% probability)
      if rand < 0.2
        authenticated_client.post('/cart/items', json: {
          product_id: product_id,
          quantity: rand(1..3)
        })
        sleep(rand(1..3))
      end
    end
  ensure
    client&.close
  end
end

Rails-Specific Testing: Rails applications require consideration of session management, CSRF tokens, and cookies. Load tests for Rails apps must handle these authentication mechanisms.

require 'capybara'
require 'selenium-webdriver'

class RailsLoadTest
  def initialize(app_url)
    @app_url = app_url
    Capybara.app_host = app_url
    Capybara.default_driver = :selenium_headless
  end
  
  def test_user_flow(concurrent_users:)
    threads = concurrent_users.times.map do
      Thread.new do
        session = Capybara::Session.new(:selenium_headless)
        
        # Navigate to sign-in
        session.visit('/users/sign_in')
        
        # Fill and submit form with CSRF token
        session.fill_in 'Email', with: 'test@example.com'
        session.fill_in 'Password', with: 'password'
        session.click_button 'Sign In'
        
        # Perform authenticated actions
        10.times do
          session.visit('/dashboard')
          sleep(rand(2..5))
          
          session.click_link 'Settings'
          sleep(rand(1..3))
        end
      ensure
        session&.driver&.quit
      end
    end
    
    threads.each(&:join)
  end
end

Practical Examples

API Endpoint Load Testing: Testing a REST API endpoint requires validating response times and error rates under load. This example measures performance of a user listing endpoint.

require 'http'
require 'concurrent'
require 'benchmark'

class APILoadTest
  attr_reader :results
  
  def initialize(api_url)
    @api_url = api_url
    @results = {
      response_times: Concurrent::Array.new,
      status_codes: Concurrent::Hash.new(0),
      errors: Concurrent::Array.new
    }
  end
  
  def test_users_endpoint(concurrent_requests: 100, total_requests: 1000)
    pool = Concurrent::FixedThreadPool.new(concurrent_requests)
    
    total_requests.times do
      pool.post do
        execute_request('/api/v1/users')
      end
    end
    
    pool.shutdown
    pool.wait_for_termination
    
    generate_report
  end
  
  private
  
  def execute_request(path)
    time = Benchmark.measure do
      response = HTTP.get("#{@api_url}#{path}")
      @results[:status_codes][response.code] += 1
      @results[:response_times] << Benchmark.measure { }.real
    end
    
    @results[:response_times] << time.real
  rescue StandardError => e
    @results[:errors] << e.message
  end
  
  def generate_report
    times = @results[:response_times].sort
    
    {
      total_requests: times.size,
      successful_requests: @results[:status_codes][200],
      failed_requests: @results[:errors].size,
      mean_response_time: times.sum / times.size,
      median_response_time: times[times.size / 2],
      p95_response_time: times[(times.size * 0.95).to_i],
      p99_response_time: times[(times.size * 0.99).to_i],
      max_response_time: times.last,
      status_codes: @results[:status_codes].to_h,
      errors: @results[:errors].uniq
    }
  end
end

# Execute test
test = APILoadTest.new('https://api.example.com')
results = test.test_users_endpoint(concurrent_requests: 50, total_requests: 500)

puts "Mean response time: #{(results[:mean_response_time] * 1000).round(2)}ms"
puts "95th percentile: #{(results[:p95_response_time] * 1000).round(2)}ms"
puts "Success rate: #{(results[:successful_requests].to_f / results[:total_requests] * 100).round(2)}%"

Database Query Performance Under Load: Applications often perform well until database queries execute concurrently. This example tests database performance with parallel query execution.

require 'active_record'
require 'concurrent'

ActiveRecord::Base.establish_connection(
  adapter: 'postgresql',
  database: 'production_db',
  pool: 50
)

class User < ActiveRecord::Base
  has_many :orders
end

class DatabaseLoadTest
  def test_complex_query(iterations: 100, concurrency: 20)
    pool = Concurrent::FixedThreadPool.new(concurrency)
    query_times = Concurrent::Array.new
    
    iterations.times do
      pool.post do
        start_time = Time.now
        
        # Complex query with associations
        User.includes(:orders)
            .where(active: true)
            .where('created_at > ?', 30.days.ago)
            .order(last_login_at: :desc)
            .limit(50)
            .to_a
        
        query_times << Time.now - start_time
      end
    end
    
    pool.shutdown
    pool.wait_for_termination
    
    analyze_query_performance(query_times)
  end
  
  private
  
  def analyze_query_performance(times)
    sorted = times.sort
    
    {
      queries_executed: times.size,
      mean_time: times.sum / times.size,
      median_time: sorted[sorted.size / 2],
      slowest_query: sorted.last,
      queries_over_1s: times.count { |t| t > 1.0 }
    }
  end
end

# Run test
test = DatabaseLoadTest.new
results = test.test_complex_query(iterations: 200, concurrency: 30)
puts "Mean query time: #{(results[:mean_time] * 1000).round(2)}ms"
puts "Slow queries (>1s): #{results[:queries_over_1s]}"

E-commerce Checkout Flow: Testing complete user workflows reveals performance issues that single-endpoint tests miss. This example simulates the checkout process including product browsing, cart management, and order placement.

require 'http'

class CheckoutFlowTest
  def initialize(base_url, api_token)
    @base_url = base_url
    @client = HTTP.auth("Bearer #{api_token}")
    @flow_metrics = []
  end
  
  def simulate_checkout_flows(user_count: 50)
    threads = user_count.times.map do |i|
      Thread.new { execute_checkout_flow(i) }
    end
    
    threads.each(&:join)
    analyze_flow_performance
  end
  
  private
  
  def execute_checkout_flow(user_id)
    metrics = { user_id: user_id, steps: {} }
    start_time = Time.now
    
    # Step 1: Browse products
    step_start = Time.now
    response = @client.get("#{@base_url}/api/products?category=electronics")
    metrics[:steps][:browse_products] = Time.now - step_start
    return unless response.status == 200
    
    products = JSON.parse(response.body)
    product = products.sample
    
    # Step 2: View product details
    step_start = Time.now
    @client.get("#{@base_url}/api/products/#{product['id']}")
    metrics[:steps][:view_details] = Time.now - step_start
    
    # Step 3: Add to cart
    step_start = Time.now
    @client.post("#{@base_url}/api/cart", json: {
      product_id: product['id'],
      quantity: rand(1..3)
    })
    metrics[:steps][:add_to_cart] = Time.now - step_start
    
    # Step 4: View cart
    step_start = Time.now
    cart_response = @client.get("#{@base_url}/api/cart")
    metrics[:steps][:view_cart] = Time.now - step_start
    
    # Step 5: Checkout
    step_start = Time.now
    @client.post("#{@base_url}/api/checkout", json: {
      payment_method: 'credit_card',
      shipping_address: generate_address
    })
    metrics[:steps][:checkout] = Time.now - step_start
    
    metrics[:total_time] = Time.now - start_time
    @flow_metrics << metrics
  end
  
  def generate_address
    {
      street: "#{rand(1..9999)} Test St",
      city: 'Test City',
      state: 'TC',
      zip: '12345'
    }
  end
  
  def analyze_flow_performance
    successful_flows = @flow_metrics.select { |m| m[:steps].size == 5 }
    
    {
      total_users: @flow_metrics.size,
      successful_checkouts: successful_flows.size,
      success_rate: (successful_flows.size.to_f / @flow_metrics.size * 100).round(2),
      avg_total_time: successful_flows.sum { |m| m[:total_time] } / successful_flows.size,
      step_averages: calculate_step_averages(successful_flows)
    }
  end
  
  def calculate_step_averages(flows)
    steps = flows.first[:steps].keys
    
    steps.map { |step|
      avg = flows.sum { |f| f[:steps][step] } / flows.size
      [step, avg]
    }.to_h
  end
end

Common Pitfalls

Insufficient Think Time: Load tests that hammer endpoints without pauses between requests create unrealistic traffic patterns. Real users spend time reading content, filling forms, and making decisions. Tests without think time generate artificial concurrency that doesn't match production behavior. The result: passing load tests followed by production failures when real user patterns create different resource contention.

Testing Wrong Environments: Running load tests against development databases with minimal data produces misleading results. Query performance degrades as table sizes grow. An endpoint returning results in 50ms against 1,000 database rows might timeout against 10,000,000 production rows. Load tests must use production-scale datasets.

Ignoring Ramp-Up: Applying maximum load immediately misses critical performance characteristics. Applications often handle sudden spikes differently than sustained load increases. Connection pools, caches, and auto-scaling systems need time to adapt. Tests starting at maximum capacity miss the gradual degradation that reveals bottlenecks.

# Pitfall: No ramp-up
def bad_load_test
  threads = 1000.times.map { Thread.new { make_request } }
  threads.each(&:join)
end

# Correct: Gradual ramp-up
def good_load_test(max_users: 1000, ramp_duration: 300)
  threads = []
  users_per_second = max_users.to_f / ramp_duration
  
  ramp_duration.times do |second|
    target_users = (users_per_second * (second + 1)).to_i
    new_users = target_users - threads.size
    
    new_users.times do
      threads << Thread.new { make_request }
    end
    
    sleep(1)
  end
  
  threads.each(&:join)
end

Measuring Only Averages: Mean response times hide performance problems. An endpoint averaging 200ms might include 95% of requests completing in 100ms and 5% timing out at 30 seconds. Users experiencing timeouts don't care about the mean. Load tests must measure and report percentiles, particularly 95th and 99th percentiles where issues manifest.

Cached vs Uncached Performance: First requests after deployment often perform differently than subsequent requests. Application code loads lazily, caches warm up, and JIT compilation occurs. Load tests must include warm-up phases that don't contribute to measurements, ensuring tests measure steady-state performance rather than cold-start behavior.

Single Point of Failure: Load testing from a single machine limits the maximum achievable concurrency and introduces single points of failure. The load generator might become the bottleneck, exhausting file descriptors, network connections, or CPU resources. Distributed load generation from multiple machines provides more realistic traffic distribution and higher maximum load.

Neglecting Monitoring: Running load tests without monitoring application internals provides incomplete information. Response times indicate problems but not causes. Tests must collect application metrics including database query counts, cache hit rates, external API call durations, and resource utilization. These metrics guide optimization efforts.

Test Data Pollution: Load tests creating database records without cleanup corrupt datasets for subsequent tests. Production databases shouldn't contain thousands of test orders or fake user accounts. Implement proper test data isolation or cleanup procedures.

# Proper test data cleanup
class LoadTestWithCleanup
  def initialize(base_url)
    @base_url = base_url
    @created_records = []
  end
  
  def run_test
    # Execute test, tracking created records
    test_user = create_test_user
    @created_records << { type: 'user', id: test_user['id'] }
    
    # Perform test actions
    perform_test_actions(test_user)
  ensure
    cleanup_test_data
  end
  
  private
  
  def cleanup_test_data
    @created_records.each do |record|
      HTTP.delete("#{@base_url}/api/#{record[:type]}s/#{record[:id]}")
    end
  end
end

Reference

Load Test Metrics

Load Test Types

Ruby Load Testing Gems

Common HTTP Status Codes in Load Tests

Load Test Execution Checklist