gunicron可以搭載不同worker, 對於非同步worker支持greenlet. 但為什麼官方文檔不推薦搭載tornado worker?
gunicorn本質上是一個進程管理器，其後端可以搭載不同類型的worker,同步的非同步的~~對於非同步的workder, 原生態支持greenlet worker. 但是為什麼官網不推薦搭載tornado worker? 我看了一下tornado worker的源碼，就是啟動了一個ioloop來接收請求~~ 而且其又是自主監聽/accept 請求的，那epoll的性能也不會有任何損耗！官網所說的不建議原因會損失其async性能，但是我的疑問是：這損耗在什麼地方？？
你好，Gunicorn 文檔的原文是這麼寫的
There』s also a Tornado worker class. It can be used to write applications using the Tornado framework. Although the Tornado workers are capable of serving a WSGI application, this is not a recommended configuration.
我理解的意思是 tornado 可以跟 WSGI application 相配合，但是並不推薦這樣這麼使用。不推薦的是 tornado 可以跟 WSGI 的配合的 worker，而不是不推薦使用 tornado 的 worker。至於為什麼不推薦 tornado 的文檔也許可以解釋
In WSGI mode asynchronous methods are not supported. This means that it is not possible to useAsyncHTTPClient, or the tornado.auth or tornado.websocket modules.
瀉藥，其實答案很簡單……
如果你要做一個通用的進程管理容器，最重要的一點是內部包含的東西應該有一致性介面……
首先我們看sync和async（evenlet和gevent），後者打了猴子補丁之後和前者基本一致，而且能發揮出非同步的特性對不對。
OK，再看tornado，它也是非同步的啊，它是epoll啊，但是，最可惜的就是這個但是，tornado的非同步實現是自己的那一套風格。
這就蛋疼了，並非不能在gunicorn裡面把socket fd加入tornado的ioloop，但是，這沒任何意義。比起自動化隱式非同步的gevent/evenlet，tornado對上層應用的耦合要強得多。普通情況下，一個猴子補丁能讓前者應用平滑在非同步和同步之間切換，壓根感覺不到庫的本身。而tornado你這樣玩不來。
我曾經修正過gevent-tornado的庫，同等情況下測試比當時的純gevent和純tornado性能都要低。tornado我個人的看法更近似於libev的python版，拋開本身攜帶的web.py風格的framework就是個純種的epoll上層驅動。gevent/eventlet則不同，他們做了更高層的封裝，掩蓋了細節，代碼寫起來一致性更好。
就像，即便有app介面，有幾個用tornado去驅動其他framework跑應用的？
綜上，這其實得怪Python非同步庫都沒一個統一標準，個玩個的。比如asyncio就是tornado的內核實現一樣，gevent/evenlet又是另一套。gunicorn遵從最大一致性原則的話，和sync模型差異太大的tornado模型支持度不佳也就顯而易見了。因為 Tornado 沒有 monkey patch 而已。
Tornado 的 WSGIContainer 有問題。https://groups.google.com/forum/#!msg/python-tornado/Yxb_YmF8Y2s/gdmK55hPF4cJ
上面說的對，各有各的IO處理.
推薦閱讀：