Open Source

10 items

nginxweb-serverreverse-proxyload-balancerhttpperformancecachingintermediate

Nginx: High-Performance Web Server and Reverse Proxy

The event-driven web server that handles millions of concurrent connections - powering 34% of the web

C|21,000 stars|Updated January 2024|40 min read

View on GitHub

Summary

Nginx (pronounced "engine-x") solves the C10K problem - handling 10,000+ concurrent connections efficiently. Unlike Apache's process-per-connection model, Nginx uses an event-driven, non-blocking architecture where a single worker process handles thousands of connections using epoll/kqueue. This makes Nginx extremely memory-efficient (2.5MB per 10K idle connections vs 2.5GB for Apache). Beyond serving static files, Nginx excels as a reverse proxy, load balancer, and API gateway.

Key Takeaways

Event-Driven Architecture

One worker process handles thousands of connections using non-blocking I/O and event notifications (epoll on Linux, kqueue on BSD). No thread-per-connection overhead means predictable memory usage regardless of connection count.

Master-Worker Process Model

A master process manages configuration and worker lifecycle. Workers are independent - if one crashes, others continue serving. This enables zero-downtime configuration reloads and binary upgrades.

Modular Request Processing

Request handling is split into phases (post-read, rewrite, access, content, log). Modules hook into specific phases, enabling clean separation between authentication, caching, proxying, and logging.

Nginx was created by Igor Sysoev in 2002 to solve Rambler's (Russian search engine) scaling problems. At the time, Apache dominated the web server market but struggled with high concurrency - the C10K problem.

The C10K Problem: How do you handle 10,000+ simultaneous connections on a single server?

Apache's approach: one process (or thread) per connection - 10,000 connections = 10,000 processes - Each process: ~2-10MB memory overhead - Result: 20-100GB RAM just for connection handling - Context switching kills performance

Nginx's approach: event-driven, non-blocking I/O - 10,000 connections = 1 worker process - Memory: ~2.5KB per connection - Result: ~25MB for 10,000 connections - No context switching between connections

Apache vs Nginx Connection Handling

Common use cases today:

Static file server: Serve HTML, CSS, JS, images with minimal resource usage
Reverse proxy: Forward requests to backend application servers
Load balancer: Distribute traffic across multiple backends
SSL/TLS termination: Handle encryption at the edge
API gateway: Rate limiting, authentication, request routing
Caching proxy: Cache responses to reduce backend load
HTTP/2 and gRPC proxy: Protocol translation

Summary

Key Takeaways

Event-Driven Architecture

Master-Worker Process Model

A master process manages configuration and worker lifecycle. Workers are independent - if one crashes, others continue serving. This enables zero-downtime configuration reloads and binary upgrades.

Modular Request Processing

Request handling is split into phases (post-read, rewrite, access, content, log). Modules hook into specific phases, enabling clean separation between authentication, caching, proxying, and logging.

Efficient Static File Serving

Nginx uses sendfile() to transfer files directly from disk to network socket without copying to user space. Combined with memory-mapped files and open file caches, it achieves near-hardware-limit throughput.

Upstream Connection Pooling

When proxying, Nginx maintains persistent connections to backend servers. This eliminates TCP handshake overhead and enables efficient HTTP/2 multiplexing to backends that only support HTTP/1.1.

Shared Memory Zones

Workers share state through shared memory zones - used for caching, rate limiting, and session persistence. Lock-free data structures minimize contention between workers.

Deep Dive

The C10K Problem: How do you handle 10,000+ simultaneous connections on a single server?

Apache vs Nginx Connection Handling

Common use cases today:

Static file server: Serve HTML, CSS, JS, images with minimal resource usage
Reverse proxy: Forward requests to backend application servers
Load balancer: Distribute traffic across multiple backends
SSL/TLS termination: Handle encryption at the edge
API gateway: Rate limiting, authentication, request routing
Caching proxy: Cache responses to reduce backend load
HTTP/2 and gRPC proxy: Protocol translation

Trade-offs

Aspect	Advantage	Disadvantage
Event-driven architecture	Handles 10K+ connections with minimal memory (2.5KB/conn vs 2MB/conn for process-per-connection)	Long-running synchronous operations (like slow disk I/O) can block other connections in the same worker
Single-threaded workers	No locking overhead, predictable performance, simple debugging	Cannot utilize CPU parallelism within a single connection; complex async code
Configuration language	Declarative, easy to read, supports includes and variables	Not a full programming language - limited logic capabilities compared to Lua/OpenResty
Static configuration	Configuration is validated at reload time - no runtime config errors	Dynamic upstream changes require reload or Plus subscription; no API for runtime changes in OSS
Shared memory zones	Efficient cross-worker state sharing for caching, rate limiting, sessions	Fixed size at startup; running out of zone space causes errors
OSS vs Plus	Core functionality is free and open source	Active health checks, dynamic reconfiguration, advanced metrics require paid Nginx Plus

Open Source

Redis: In-Memory Data Structure Store

Apache Kafka: Distributed Event Streaming Platform

Kubernetes: Container Orchestration Platform