Gunicorn as WSGI server in Django - Step-by-Step Execution

Concept Flow - Gunicorn as WSGI server

Start Gunicorn Command

↓

Gunicorn Loads WSGI App

↓

Gunicorn Creates Worker Processes

↓

Workers Listen for HTTP Requests

↓

Request Received

↓

Worker Calls Django WSGI Application

↓

Django Processes Request

↓

Response Returned to Worker

↓

Worker Sends HTTP Response to Client

↓

End

Gunicorn starts, loads the Django WSGI app, creates workers that listen for requests, then workers handle requests by calling Django and sending back responses.

Execution Sample

Django

gunicorn myproject.wsgi:application
# Gunicorn starts and runs Django app
# Listens for HTTP requests
# Handles requests with workers

This command starts Gunicorn as the WSGI server to run the Django application and handle incoming HTTP requests.

Execution Table

Step	Action	Gunicorn State	Worker State	Django App State	Output
1	Run 'gunicorn myproject.wsgi:application'	Starting master process	No workers yet	Not loaded	Gunicorn master process starts
2	Gunicorn loads WSGI application	Master process loaded app	No workers yet	WSGI app loaded	Ready to spawn workers
3	Gunicorn spawns worker processes	Master running	Workers spawned and listening	WSGI app ready	Workers ready for requests
4	HTTP request arrives	Master running	Worker receives request	Waiting for call	Request received by worker
5	Worker calls Django WSGI app	Master running	Worker processing request	Processing request	Django app processes request
6	Django returns response	Master running	Worker has response	Response ready	Response generated
7	Worker sends HTTP response	Master running	Worker sends response to client	Idle	Client receives HTTP response
8	Wait for next request	Master running	Workers listening	Idle	Ready for next request
9	Shutdown command received	Master shutting down	Workers terminating	App closing	Gunicorn stops

💡 Gunicorn stops when shutdown command is received or process is killed

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	After Step 7	Final
Gunicorn Master	Not running	Running, app loaded	Running, workers spawned	Running	Running	Stopped
Worker Processes	None	None	Spawned, listening	Processing request	Sent response	Terminated
Django WSGI App	Not loaded	Loaded	Loaded	Processing request	Idle	Closed
HTTP Request	None	None	None	Received	Responded	None

Key Moments - 3 Insights

Why does Gunicorn create multiple worker processes?

Gunicorn creates multiple workers (see Step 3) so it can handle many requests at the same time without waiting for one to finish before starting another.

What happens when a worker receives an HTTP request?

At Step 4, the worker listens and receives the request, then calls the Django WSGI app to process it (Step 5), ensuring the request is handled properly.

Why does the Django app appear 'idle' after sending a response?

After sending the response (Step 7), the Django app waits for the next request, so it is idle until called again by a worker.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of the worker processes after Step 3?

A Spawned and listening for requests

B Not created yet

C Processing a request

D Terminated

💡 Hint

Check the 'Worker State' column at Step 3 in the execution table.

At which step does the Django WSGI app process the HTTP request?

A Step 4

B Step 6

C Step 5

D Step 7

💡 Hint

Look at the 'Django App State' column to see when it is 'Processing request'.

If Gunicorn did not spawn multiple workers, what would change in the execution table?

A Django app would never load

B Workers would be 'None' after Step 3

C Master process would not start

D HTTP requests would be processed faster

💡 Hint

Refer to the 'Worker Processes' variable in variable_tracker after Step 3.

Concept Snapshot

Gunicorn is a WSGI server that runs Django apps.
It starts a master process and spawns multiple worker processes.
Workers listen for HTTP requests and call the Django WSGI app.
Django processes requests and returns responses via workers.
Multiple workers allow handling many requests at once.
Gunicorn stops when shutdown is triggered.

Full Transcript

Gunicorn acts as a WSGI server for Django by starting a master process that loads the Django WSGI application. It then creates multiple worker processes that listen for incoming HTTP requests. When a request arrives, a worker receives it and calls the Django WSGI app to process the request. Django generates a response which the worker sends back to the client. After sending the response, the worker waits for the next request. This setup allows handling many requests concurrently. Gunicorn stops when a shutdown command is received.