Project 10: HTTP Load Tester

A load testing tool that generates thousands of concurrent HTTP requests, measures latency percentiles (p50, p95, p99), throughput, and error rates. Supports configurable request rates and connection pools.

Quick Reference

Attribute Value
Primary Language C++
Alternative Languages Go, Rust
Difficulty Level 3: Advanced
Time Estimate 2 weeks
Knowledge Area Concurrent Connections, Statistics, Benchmarking
Tooling wrk/ab alternative
Prerequisites Projects 5, 9

What You Will Build

A load testing tool that generates thousands of concurrent HTTP requests, measures latency percentiles (p50, p95, p99), throughput, and error rates. Supports configurable request rates and connection pools.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Managing many concurrent connections → maps to connection pool, epoll
  • Accurate timing measurements → maps to high-resolution clocks, avoiding skew
  • Rate limiting → maps to token bucket or leaky bucket algorithms
  • Computing latency percentiles → maps to histogram data structures

Key Concepts

  • Latency Percentiles: “Systems Performance” Chapter 2 - Gregg
  • Connection Pooling: HTTP keep-alive reuse
  • Rate Limiting: Token bucket algorithm
  • HDR Histogram: https://hdrhistogram.org/

Real-World Outcome

$ ./loadtest http://localhost:8080/api/users -c 100 -d 30s -r 1000
Load testing http://localhost:8080/api/users
Concurrency: 100 connections
Duration: 30 seconds
Target rate: 1000 req/s

Running...

Summary:
  Total requests: 30,000
  Successful: 29,847 (99.5%)
  Failed: 153 (0.5%)

Latency:
  Min:    0.5ms
  Mean:   2.3ms
  p50:    1.8ms
  p95:    5.2ms
  p99:    12.4ms
  Max:    145.3ms

Throughput:
  Requests/sec: 995.8
  Bytes/sec: 4.2 MB

Errors:
  Connection refused: 45
  Timeout: 108

$ ./loadtest http://api.example.com/search -c 500 --duration 60s --rate 5000

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_CPP_NETWORK_PROGRAMMING.md
  • “Systems Performance” by Brendan Gregg