Understanding Python Web Deployment: CGI, FastCGI, WSGI, uWSGI & Gunicorn

While PHP deployment is straightforward, Python web deployment involves many tools and protocols, making it more complex.

CGI

Common Gateway Interface (CGI) is a standard that lets a web server execute external programs and return their output to the browser. It creates a new process for each request, which can lead to high resource consumption.

CGI workflow:

Browser requests a URL that points to a CGI program.

Server executes the specified CGI program.

The program processes the request, often using user input.

The program formats the result as an HTTP response (usually HTML).

Server returns the response to the browser.

Python provides a cgi module for native CGI support.

FastCGI

FastCGI is an improved, scalable version of CGI that keeps interpreter processes alive, avoiding the overhead of spawning a new process per request. It can be up to five times faster than CGI and supports distributed execution.

FastCGI workflow:

Web server loads a FastCGI process manager (e.g., PHP‑FPM, spawn‑cgi).

The manager starts multiple CGI interpreter processes and waits for connections.

When a request arrives, the manager selects an interpreter and forwards the request.

The interpreter processes the request and returns the output to the web server.

WSGI

Python Web Server Gateway Interface (WSGI) defines a simple, universal interface between web servers and Python web applications or frameworks. It separates the server (gateway) from the application, allowing middleware to modify requests or responses.

WSGI middleware can:

Rewrite environment variables and route requests.

Run multiple applications in one process.

Provide load balancing and remote processing.

Perform post‑processing such as applying XSLT.

WSGI essentially acts as Python’s CGI wrapper, enabling any WSGI‑compatible server to run any WSGI‑compatible application.

WSGI component diagram:

uWSGI

uWSGI is a full‑stack server that implements the uWSGI, WSGI, HTTP, and other protocols. It is highly extensible, supports many languages, and offers features such as ultra‑fast performance, low memory usage, multi‑app management, detailed logging, and customizable process control.

Very high performance.

Low memory footprint (about half of Apache mod_wsgi).

Supports managing multiple applications.

Extensive logging for performance analysis.

Highly configurable (memory limits, graceful restarts, etc.).

Gunicorn

Gunicorn (Green Unicorn) is a pre‑forking Python WSGI HTTP server originally derived from the Ruby Unicorn project. It works with many frameworks (e.g., Django) and is simple to start.

Design:

A master process spawns several worker processes.

The master controls worker lifecycle; workers handle requests.

Workers can use different I/O models (sync, gevent, eventlet, etc.).

Source structure highlights the Arbiter (master) initializing configuration, setting up signals, creating sockets, and spawning workers that process HTTP requests via the WSGI application.

Tornado

Tornado is both a Python web framework and an asynchronous, non‑blocking HTTP server. It can serve dynamic content directly or be used with other frameworks (e.g., Flask) via its built‑in WSGI support ( tornado.wsgi.WSGIContainer).

wsgiref

The wsgiref module in the Python standard library provides a reference implementation of a WSGI server, used by Django’s development server.

Choosing a Deployment Strategy

When deploying a Django application, common choices are Nginx + uWSGI or Nginx + Gunicorn (the latter often managed by supervisord). For Tornado, Nginx + Gunicorn is also used. Because of Python’s GIL, production deployments typically use a multi‑process model (one master, multiple workers).