Python Web 程式的部署方案
綜合而言, 高效能的Python web站點部署方式首推 nginx + uwsgi
apache + mod_wsgi 是簡單穩定但效能一般的方式
API伺服器 可以直接使用tornado或者gevent
mod_python
非常原始的cgi模式部署python已經沒有什麼好介紹了。對於不太追求效能的管理系統和網站來說，使用 Apache 部署是一個不錯的選擇。較早的時候，使用 mode_python 部署python的web應用十分流行,在Django 0.96 的時候官方文件甚至推薦這種方式。
它將Python直譯器嵌入到Apache server,以提供一個訪問Apache server內部的介面。mod_python 在現在看來效能是不佳的，每一個http請求 mod_python 都會由一個程序初始化python直譯器、載入程式碼、執行、然後銷燬程序。
mod_wsgi
如果非要用Apache來部署python應用，mod_wsgi是一個更好的選擇。WSGI 全稱是 Web Server Gateway Interface ,由 PEP-333 定義。 基本上所有的python web框架都實現了wsgi介面，用mod_wsgi 能部署任何實現了wsgi的框架。實際上，不需要任何框架也可以用mod_wsgi 部署python程式。使用mod_wsgi的daemon模式，python程式會常駐記憶體，不會有很大的初始化和銷燬程序方面的開銷，所以效能是好於mod_python的。綜合來說，使用Apache部署python web程式，推薦使用mod_wsgi的daemon模式。
Fastcgi
先說觀點：不建議用fastcgi的方式部署Python web。
前幾年由於lighttpd風頭正勁和豆瓣的成功案例，fastcgi是一種很流行的部署方式。fastcgi與具體語言無關，也與web伺服器無關。是一種通用的部署方式。fastcgi是對於cgi的增強，CGI程式執行在獨立的程序中，並對每個Web請求建立一個程序。面對大量請求，程序的大量建立和消亡使作業系統效能大大下降。
與為每個請求建立一個新的程序不同，FastCGI使用持續的程序來處理一連串的請求。這些程序由FastCGI伺服器管理，而不是web伺服器。 當進來一個請求時，web伺服器把環境變數和這個頁面請求透過一個socket比如FastCGI程序與web伺服器都位於本地）或者一個TCP connection（FastCGI程序在遠端的server farm）傳遞給FastCGI程序。
主流的web伺服器，Apache,lighttpd,nginx 都支援fastcgi，在幾年前，lighttpd的mod_fcgi模組效能強勁，lighttpd+fastcgi十分流行。無論是python,ruby還是php，都有大量的站點使用這種方式部署。由於nginx的崛起，現在很少有人使用lighttpd了。
fastcgi 並不是專門為python設計，並不是所有的python框架天然的支援fastcgi，通常需要flup這樣的容器來配適。flup由python編寫，和專門的c實現的wsgi容器比起來效能顯得相當不堪。fastcgi的穩定性對於新興的wsgi容器來說也有差距。無論從哪個方面來看，部署python web程式，fastcgi 都已經是過去式。
uwsgi
前幾年nginx還未內建uwsgi模組的時候，部署uwsgi還是一件挺麻煩的事情。隨著能夠在nginx中直接使用uwsgi模組，uwsgi已經是最可靠，最方便的高效能python web程式的部署方式了。
在1U的四核XEON伺服器上，一個簡單的wsgi handler甚至能用AB壓到8000以上的qps,這已經是完爆tornado,接近gevent的效能了。 同時，uwsgi的穩定性極好。之前我們有個每天500w-1000w動態請求的站點使用uwsgi部署非常穩定，在一個渣HP 1U 伺服器上，基本不用管它。
上面提到的部署方式都是相對於web網站的方式，在移動網際網路的時代，我們需要的是高效能的API服務，上面這些都是過時的東西。
tornado
tornado 號稱高效能，如果拿他寫網站，其實一般般，只不過跟uwsgi加一些簡單框架差不多而已。它真正的作用，是用來寫API伺服器和長連線的伺服器。
由於tornado能夠直接處理http請求，很多人直接拿他來裸奔直接提供服務。這種方式是不可取的，單執行緒的tornado只能利用cpu的一個核心，並且一旦阻塞直接就廢了。通常情況下，由supervisor啟動多個tornado程序，透過nginx進行反向代理負載均衡。nginx 1.14 以後的版本反向代理支援長連線，配合tornado的comet效果很好。
tornado還有一些比較奇葩的用法，比如用來做wsgi容器之類的。
gevent
gevent是一個神器，能做的事情很多。在web方面，處理http請求，用起來其實跟tornado差不多，但是要簡陋很多，cookie之類的都沒有。用gevent寫的一些API服務，部署方式還是類似tornado，用supervisor管理多個守護程序，透過nginx做負載均衡。 同樣的它的奇葩用法也和tornado一樣，可以當wsgi容器用。
Python Web 程式的部署方案
綜合而言, 高效能的Python web站點部署方式首推 nginx + uwsgi
apache + mod_wsgi 是簡單穩定但效能一般的方式
API伺服器 可以直接使用tornado或者gevent
mod_python
非常原始的cgi模式部署python已經沒有什麼好介紹了。對於不太追求效能的管理系統和網站來說，使用 Apache 部署是一個不錯的選擇。較早的時候，使用 mode_python 部署python的web應用十分流行,在Django 0.96 的時候官方文件甚至推薦這種方式。
它將Python直譯器嵌入到Apache server,以提供一個訪問Apache server內部的介面。mod_python 在現在看來效能是不佳的，每一個http請求 mod_python 都會由一個程序初始化python直譯器、載入程式碼、執行、然後銷燬程序。
mod_wsgi
如果非要用Apache來部署python應用，mod_wsgi是一個更好的選擇。WSGI 全稱是 Web Server Gateway Interface ,由 PEP-333 定義。 基本上所有的python web框架都實現了wsgi介面，用mod_wsgi 能部署任何實現了wsgi的框架。實際上，不需要任何框架也可以用mod_wsgi 部署python程式。使用mod_wsgi的daemon模式，python程式會常駐記憶體，不會有很大的初始化和銷燬程序方面的開銷，所以效能是好於mod_python的。綜合來說，使用Apache部署python web程式，推薦使用mod_wsgi的daemon模式。
Fastcgi
先說觀點：不建議用fastcgi的方式部署Python web。
前幾年由於lighttpd風頭正勁和豆瓣的成功案例，fastcgi是一種很流行的部署方式。fastcgi與具體語言無關，也與web伺服器無關。是一種通用的部署方式。fastcgi是對於cgi的增強，CGI程式執行在獨立的程序中，並對每個Web請求建立一個程序。面對大量請求，程序的大量建立和消亡使作業系統效能大大下降。
與為每個請求建立一個新的程序不同，FastCGI使用持續的程序來處理一連串的請求。這些程序由FastCGI伺服器管理，而不是web伺服器。 當進來一個請求時，web伺服器把環境變數和這個頁面請求透過一個socket比如FastCGI程序與web伺服器都位於本地）或者一個TCP connection（FastCGI程序在遠端的server farm）傳遞給FastCGI程序。
主流的web伺服器，Apache,lighttpd,nginx 都支援fastcgi，在幾年前，lighttpd的mod_fcgi模組效能強勁，lighttpd+fastcgi十分流行。無論是python,ruby還是php，都有大量的站點使用這種方式部署。由於nginx的崛起，現在很少有人使用lighttpd了。
fastcgi 並不是專門為python設計，並不是所有的python框架天然的支援fastcgi，通常需要flup這樣的容器來配適。flup由python編寫，和專門的c實現的wsgi容器比起來效能顯得相當不堪。fastcgi的穩定性對於新興的wsgi容器來說也有差距。無論從哪個方面來看，部署python web程式，fastcgi 都已經是過去式。
uwsgi
前幾年nginx還未內建uwsgi模組的時候，部署uwsgi還是一件挺麻煩的事情。隨著能夠在nginx中直接使用uwsgi模組，uwsgi已經是最可靠，最方便的高效能python web程式的部署方式了。
在1U的四核XEON伺服器上，一個簡單的wsgi handler甚至能用AB壓到8000以上的qps,這已經是完爆tornado,接近gevent的效能了。 同時，uwsgi的穩定性極好。之前我們有個每天500w-1000w動態請求的站點使用uwsgi部署非常穩定，在一個渣HP 1U 伺服器上，基本不用管它。
上面提到的部署方式都是相對於web網站的方式，在移動網際網路的時代，我們需要的是高效能的API服務，上面這些都是過時的東西。
tornado
tornado 號稱高效能，如果拿他寫網站，其實一般般，只不過跟uwsgi加一些簡單框架差不多而已。它真正的作用，是用來寫API伺服器和長連線的伺服器。
由於tornado能夠直接處理http請求，很多人直接拿他來裸奔直接提供服務。這種方式是不可取的，單執行緒的tornado只能利用cpu的一個核心，並且一旦阻塞直接就廢了。通常情況下，由supervisor啟動多個tornado程序，透過nginx進行反向代理負載均衡。nginx 1.14 以後的版本反向代理支援長連線，配合tornado的comet效果很好。
tornado還有一些比較奇葩的用法，比如用來做wsgi容器之類的。
gevent
gevent是一個神器，能做的事情很多。在web方面，處理http請求，用起來其實跟tornado差不多，但是要簡陋很多，cookie之類的都沒有。用gevent寫的一些API服務，部署方式還是類似tornado，用supervisor管理多個守護程序，透過nginx做負載均衡。 同樣的它的奇葩用法也和tornado一樣，可以當wsgi容器用。