NGINX + Flask, without Gunicorn?

Question

I am new to this, but by comparing the code of gunicorn with flask/werkzeug, I fail to understand the real benefit of inserting gunicorn between nginx and flask. Would like to get some expert opinions on this.

For what I understand so far, it boils down to comparing gunicorn with werkzeug's dev server. In short, I fail to understand why werkzeug's server is called a dev server, while gunicorn is considered prod ready. The argument for choosing gunicorn over werkzeug that I can think of:

1. Performance. Gunicorn is based on prefork model, while werkzeug can spin off a thread or process on the fly for each request. But Stevens had a comparison in his UNP book, and prefork was not a clear winner in his tests. Spinning off a thread (not process) on linux should be fairly cheap, without the need to handle the pre-forked process pool. So for CPU bound services, the python GIL makes werkzeug's threading model less attractive, but for IO bound services, werkzeug should be good enough?
2. Gunicorn supports gevent/eventlet/tornado, while werkzeug does not. But since asyncio is becoming a native in python 3, these green threads libraries seem less crucial?
3. Security? again I am no expert on this, but nginx seems a good defender already? Besides, gunicorn does not seem to provide extra protection in this regard, compared to werkzeug's dev server.
4. SSL. Flask and werkzeug server does not seem to handle this. But nginx can handle this already, so flask does not need to?
5. Unix socket. Werkzeug's server does not seem to handle unix socket. So if nginx need to forward traffic to backend with unix sockets, either because it's the only way or because it's the most efficient way, then it seems a good argument for gunicorn.

Are the reasons above valid? What are the other reasons?

Btw, I have read SO post 1 and SO post 2 but they do not seem to fully answer my questions yet.

Novosibirsk

I'd add a reason 0: The program tells you not to use it in production on every start. And BTW the Django project gave a clear statement on their very similar dev server. – Austral

Totally w KD on that. I’m thinking that the dev server is probably a hot reload type - change a file, server reloads it, without you needing to stop + restart. Great in dev, but lotsa moving parts, maybe not so great in prod. Might even be security implications. Good question, but... don’t. Also Nginx config can be a bit of a pain but wsgi (w Django) was not part of the complexity at all - it’s just a port you route to. – Masters

I agree, even flask's website recommends gunicorn/waitress. I am just curious what exactly makes werkzeug's dev server that much inferior than those other two for a prod env. – Novosibirsk

Answer 1

Werkzeug can use multiple processes, but spins up a new process on each request. That's great if you're slapping something together that so thoroughly pollutes its environment that discarding the process after each request is necessary, but isn't the most performance-friendly approach to deploying an app.

gunicorn (or uwsgi, which I prefer) provides process management that's considerably more flexible than what Werkzeug provides.

You might be convinced, though, by throwing together a simple app, setting it up for 4 processes using werkzeug for one experiment, and gunicorn or uwsgi for the other, and then measuring its performance as you throw traffic at it.

Yongyoni

So it is a performance thing? Are you assuming the server workload is CPU bound, or regardless? – Novosibirsk

My assumption, which is perhaps off base, is that you're approaching things theoretically, and that a bit of grounded experimentation might carry you further, faster. – Yongyoni

@DaveW.Smith I want to try this, but can you recommend a way to 'throw traffic' at it and measure the performance difference? – Academe

I've used httpd.apache.org/docs/2.4/programs/ab.html in the past, but I'm not up on what the current options are. – Yongyoni