NGINX ARCHITECTURE

NGINX Process Architecture

MASTER PROCESS

Child Processes

Shared memory is used for cache, session persistence, rate limits, session log

CM CL W W W W

Cache Manager Cache Loader Worker processes handle HTTP

and other network traffic

Inside the NGINX Worker Process

Non Blocking, event-driven processing engine HTTP, Mail and

Stream (TCP) proxy

WEB, EMAIL
STREAM STATE HTTP STATE MAIL STATE
and
TCP traffic MACHINE MACHINE MACHINE

FastCGI, uWSGI. SCGI,

Auxiliary threads for blocking operations memcached gateway
(e.g. disk I/O)

Static Content Access and Error

and disk cache log to disk and syslog

Life of an HTTP Request

INTERNET REQUESTS

Read Request Headers

SSL and SPDY decrypt encrypted traffic
(Apply keepalive management and
bandwidth shaping to all client traffic)

Log
Access and
session log
Identify
Configuration Block
Request matching and rewriting

Response Filters Apply Rate Limits

gzip, SSI, headers,
Internal redirects
Rate and concurrency
image_filter, sub, etc…
and subrequests
limiting

Perform Authentication
Internal and external
access control

Generate Content
Generate response locally, or
proxy/gateway to an upstream service

Concurrency Control Load Balancing

Keepalive Management Session Persistence
Response Caching Health Checks and Retries

Upstream Services
HTTP, HTTPS, FastCGI, uWSGI, SCGI, memcached

BLOCKING AND NON-BLOCKING I/O

Most web application platforms use blocking (waiting) I/O NGINX uses a Non-Blocking “Event-Driven” architecture

Listen Sockets (port 80, 443, etc) Listen Sockets & Connection Sockets

Wait for an event (epoll or kqueue)

Wait for an event (epoll or kqueue)
Event on Listen Socket: Event on Connection Socket:
accept new connection socket
read wait until request is read accept new data in read buffer? read
write wait until response is written
wait wait on KeepAlive connection set to be non-blocking space in write buffer? write

on error... add to the socket list error or timeout? close

& remove from socket list
close

Each worker can only process one active connection at a time An NGINX worker can process hundreds of thousands
of active connections at the same time

UPDATING CONFIGURATION, UPGRADING NGINX

Load new configuration with no downtime

Master starts new
worker processes with
new configurations

W W W W W W

NGINX keeps on running

Master Master with new configuration, and
no interruption in service

W W W W W W

Old worker processes complete

Update configuration on disk existing transactions and then
SIGHUP master or nginx –s reload exit gracefully

Load new NGINX binary with no downtime

SIGQUIT the old

Update NGINX Master process and
binary on disk it will terminate
W W SIGUSR2 master W W W W gracefully W W

Master Master (Old) Master (New) Master (New)

W W W W W W W W

New and old instances of NGINX run in

parallel and both will handle connections