gunicorn
1.Gunicorn设计
Gunicorn 是一个 master 进程，spawn 出数个工作进程的 web 服务器。master 进程控制工作进程的产生与消亡，工作进程只需要接受请求并且处理。这样分离的方式使得 reload 代码非常方便，也很容易增加或减少工作进程。 工作进程这块作者给了很大的扩展余地，它可以支持不同的IO方式，如 Gevent,Sync 同步进程，Asyc 异步进程，Eventlet 等等。master 跟 worker 进程完全分离，使得 Gunicorn 实质上就是一个控制进程的服务。
2.Gunicorn源码结构
从 Application.run() 开始，首先初始化配置，从文件读取，终端读取等等方式完成 configurate。然后启动 Arbiter，Arbiter 是实质上的 master 进程的核心，它首先从配置类中读取并设置，然后初始化信号处理函数，建立 socket。然后就是开始 spawn 工作进程，根据配置的工作进程数进行 spawn。然后就进入了轮询状态，收到信号，处理信号然后继续。这里唤醒进程的方式是建立一个 PIPE，通过信号处理函数往 pipe 里 write，然后 master 从 select.select() 中唤醒。
工作进程在 spawn 后，开始初始化，然后同样对信号进行处理，并且开始轮询，处理 HTTP 请求，调用 WSGI 的应用端，得到 resopnse 返回。然后继续。
Sync 同步进程的好处在于每个 request 都是分离的，每个 request 失败都不会影响其他 request，但这样导致了性能上的瓶颈。
没有对错，找个框架入门好了~
flask 上手快，插件多，但是随着项目的深入，慢慢就是变成一个 django，绝对的
django 一上来就是大而全，但胜在什么都有，什么都不用自己折腾
tornado 这货从一出生就开始用到现在，没有啥好也没啥不好，就是用习惯了。flask 的上手快是以各种插件为代价的，模板你要去找 jinja 吧？ orm 要找 sqlachemy 吧？这些都需要你自己去熟悉一下
而且，各种用 flask 和 django 的同学可能忽略了一个基本是事实就是，如果你有工作需要深入到源代码的话，那么 tornado 是一个极好的参考。django 的代码体系复杂而且庞大我就不说了，看 flask 的代码底层还要考虑 Werkzeug，其基于全局变量的 context 处理起来其实也不容易的。
顺便的，部署 tornado 的项目可以少拖一个 gunicorn 或者 uwsgi 之如此类，少很多坑
上面那些提及到性能的同学，完全没有必要进行对比。在 pypy/aiohttp/uvloop 的加持下，不是我非要针对谁，你们说的性能都是垃圾。