WSGI, the Pre-Fork Model & Worker Classes

A Production WSGI Server

Gunicorn ("Green Unicorn") runs Python web applications in production, implementing WSGI — the standardized interface (PEP 3333) between Python web servers and applications. Because it's WSGI-compliant and framework-agnostic, it can serve Flask, Django, or any other WSGI application without framework-specific configuration. Framework dev servers (Flask's app.run()) aren't built for production concurrency, hardening, or process management, which is exactly what Gunicorn adds.

Master Process & Pre-Forked Workers

gunicorn --workers 5 --bind 0.0.0.0:8000 myapp:app

A master process forks a pool of worker processes ahead of time and distributes incoming requests among them — avoiding the overhead of forking per request. The master is purely a supervisor: it spawns, monitors, and restarts workers, never handling application requests itself. A common starting heuristic for worker count is (2 x num_cores) + 1, keeping cores saturated while accounting for workers blocked on I/O.

Sync vs. Async Worker Classes

The default sync worker handles exactly one request at a time — concurrency comes from having multiple worker processes. For I/O-bound workloads with many slow or long-lived connections, async worker classes (gevent, eventlet) let a single worker multiplex many connections via greenlets, yielding during I/O waits — genuinely CPU-bound work sees little benefit from this, since it's still bounded by available cores (and the GIL within a process).