gunicorn的worker介绍
上一篇文章已经说了，gunicorn采用pre-worker的work model，gunicorn默认使用同步的工作模式。这意味着当你创建的子进程都被长时间占用，就会出现其他请求被阻塞的情况；因此针对这种情况，gunicorn也提供了多种异步的worker。
worker有下面几种可选实现，不过对于用户来说是完全透明的
- sync worker # 每个进程同时只处理一个请求
- thread worker # 通过在一个进程里面开辟多个线程来响应多个请求. 对应gthread.py
- greenlet worker # 没有使用python原生线程而是使用eventlet或是gevent协程来响应多个请求，对应geventlet.py和ggevent.py
- tornado worker # tornao 提供的asyncio worker, 对应gtornado.py 一般情况下这种类型适用于那些采用tornado框架的应用，因此一般不建议作为wsgi服务器。
- aiohttp # aiohttp 提供的asyncio worker, 对应gaiohttp.py
thread worker处理请求同时受限于thread number以及max connections, 后面几种实现不受限于thread number仅受限于max connections.
对于默认的同步类型，性能是非常低的，在cpu和带宽方面会消耗资源的。这就意味着你的应用不可能无节制地做任何事。
为了提高性能，可以处理高并发请求，我们使用gevent处理即可。官方建议Nginx+gunicorn性能最好。
gevent我后续还要好好研究一下。
关于进程的数量
要试图做这样的事，你预期多少个客户端就启用多少个worker。gunicorn只需要启用4–12个workers，就足以每秒钟处理几百甚至上千个请求了。
在处理请求时，gunicorn依靠操作系统来提供负载均衡。通常我们推荐的worker数量是：(2 x $num_cores) + 1，这个公式很简单，它是基于给定的核心处理器数量，在其他worker处理请求时，每个worker将从socket那进行读写操作。
很显然，你的硬件环境和应用将影响到worker数量。我们推荐先采用上述公式来安排，在应用启动之后，然后再通过TTIN和TTOU这两个信号来调整worker数量。（关于信号的类型，在gunicorn介绍一文中已经提过）
记住：太多的worker，因为要进行大量的切换，必定耗费资源，肯定会在某一个时刻，让你的整个系统急剧降低性能。
把配着一些写上：
设置按照优先级排序分别是：命令行，配置文件(python)，框架本身。大部分 设置 比较常规，下面这些设置有点意思：
- worker_connections # 单个进程可以同时处理的最大连接数
- max_requests # 单个进程处理最大请求数，超过就会重启，目的是"This is a simple method to help limit the damage of memory leaks"
- max_requests_jitter # 在上面基础上加上random(0, max_requests_jitter)偏差，为了避免所有worker同时重启
- timeout # 单个进程空闲时间超过这个阈值就会重启，可能是为了解决整个worker因为bug挂住导致长时间不响应。
- preload_app # 在master就加载application. 好处是可以加快worker启动速度，但是坏处就是如果代码升级需要将master也重启。
- reload # 代码发生变化就会立即reload. 和preload_app选项冲突，推荐只在开发环境下面使用。
- check_config # 检查配置文件是否正确
- logger_class # 默认使用gunicorn.glogging.Logger.
- statsd_host # 可以向 statsd 汇报服务器性能状况. 具体可以看 这里
- Server Hooks # gunicorn定义了一系列hooks允许在各个阶段添加自己代码
微信分享/微信扫码阅读
