Event‑driven architecture

  1. The worker waits for events on the listen and connection sockets.
  2. Events occur on the sockets and the worker handles them:
    • An event on the listen socket means that a client has started a new chess game. The worker ** creates a new connection socket **.
    • An event on a connection socket means that the client has made a new move. The worker responds promptly.

@Note: better detailed graph in reference-2

nginx_architecture

NGINX_worker

NGINX_request

NGINX_nonblocking

On restart or update

When the master process receives a SIGHUP, it does two things:

  1. Reloads the configuration and forks a new set of worker processes. These new worker processes immediately begin accepting connections and processing traffic (using the new configuration settings).
  2. Signals the old worker processes to gracefully exit. The worker processes stop accepting new connections. As soon as each current HTTP request completes, the worker process cleanly shuts down the connection (that is, there are no lingering keepalives). Once all connections are closed, the worker processes exit.

NGINX_load-config NGINX_load-binary

Reference: