Type UWSGI; Press Enter; What Happens?

You’re a knowledgeable Python web application developer, but how does that web application get served to the world? For many of us, uWSGI is the magic that makes our app available, and in this talk we’ll look at how uWSGI works with the OS and the networking stack to make the magic happen.

Notes: * Intro: * Type uwsgi, press enter, what happens? * Section 1: Type uwsgi * Django-admin.py create * Python manage.py runserver * You know that, somehow, when you visit localhost:8000, you see your website. * Let’s get that experience with uwsgi. * Run uwsgi * Haha, try again with an actual callable and some flags * Run uwsgi, plus the uwsgi application name that Django says to use, plus a port number saying 8000 * Great, it’s serving requests * But it also printed this stuff about max workers * Section 2: About uwsgi workers * Start with a brief overview of the process model we covered in “Type Python” * Each uwsgi worker is a Python process * how uwsgi spawns processes (also, briefly, why?) * Uwsgi keeps a list of * [‘busy’, ‘available’, ‘available’, ‘available’] * When a request comes into uwsgi, it finds some available worker * Uwsgi uses whatever.foo.bar notation because it is asking a Python interpreter to import that * …therefore if you start uwsgi in the wrong directory, or without your virtualenv, you could find yourself sad * Section 3: Networking * What does it mean for a request to come in? * how uswgi binds to the port - what even is a port? What is port binding? * (arguably use diagrams from http://homeserver.io/ !!!) * Expand a bit on our model of what a “file descriptor” or “file like object” is * how uswgi binds to the port - what even is a port? What is port binding? * When does uwsgi calls accept() * Should we say TCP SYN ACK? Or just forget it? * This diagram applies to manage.py runserver, too * How uwsgi handles passing requests into workers and responses back from workers * How uwsgi updates its understanding of the state of each worker * Section 4: Why don’t people just use python manage.py runserver? * Millisecond-based timing of django manage.py runserver * Django accept()s the connection * Runserver parses the HTTP request and creates a Django request object * Django view computes the response * Runserver parses the response object and converts it to text HTTP * Runserver streams the text HTTP back to the user * Also, we should say how we timed this because everyone will want to know * Millisecond-based timing of uwsgi with 1 process * Same as above * More processes, same timing * Diagram of a bottle neck * Benchmarks or something to motivate talking about performance * Things that aren’t slow * Asdf * Things that can be meaningfully slow * Section 5: This is like everything else