Architecture Overview¶
NGINX is a high-performance, event-driven web server and reverse proxy. Understanding its architecture is essential for effective configuration and module development.
Core Design Principles¶
1. Event-Driven, Non-Blocking¶
NGINX uses an asynchronous, event-driven model rather than threads:
- Single thread handles thousands of connections
- Non-blocking I/O for all operations
- Minimal memory overhead per connection (~256 bytes)
2. Master/Worker Process Model¶
┌─────────────────────────────────────────────────────────┐
│ Master Process │
│ • Reads configuration • Manages workers │
│ • Binds privileged ports • Handles signals │
└─────────────────────────┬───────────────────────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Worker │ │ Worker │ │ Worker │
│ 1 │ │ 2 │ │ N │
└─────────┘ └─────────┘ └─────────┘
│ │ │
└─────────────────┴─────────────────┘
│
Event Loop
(epoll/kqueue)
3. Modular Architecture¶
Everything in NGINX is a module:
- Core modules: events, http, stream, mail
- HTTP modules: proxy, fastcgi, gzip, ssl, rewrite
- Filter modules: headers, gzip, ssi, charset
Key Sections¶
| Section | Description |
|---|---|
| Process Model | Master/worker architecture, signals, graceful reload |
| Event Loop | epoll/kqueue, non-blocking I/O, timers |
| Request Lifecycle | HTTP phases, handlers, filters |
Quick Facts¶
| Metric | Value |
|---|---|
| Connections per worker | 10,000+ typical |
| Memory per connection | ~256 bytes |
| Request throughput | 100,000+ req/sec |
| Context switches | Minimal (single-threaded) |
Learning Path¶
- Process Model - How NGINX manages processes
- Event Loop - The heart of NGINX performance
- Request Lifecycle - How requests flow through phases
- Core APIs - C structures and functions