這篇文章其實兩個月之前就應該面世了，但是最近瑣事、煩心事太多就一直懶得動筆，拖到現在才寫
一、uwsgi、wsgi、fastcgi區別和聯系
參見之前的文章 http://www.cnblogs.com/sky20081816/p/3309925.html
二、uwsgi的安裝
建議用pip 或者easy_install安裝，這樣避免了很多的麻煩，我是直接用 pip install uwsgi來安裝的。如果你想要用源碼安裝的話到官網http://projects.unbit.it/uwsgi/ 下載安裝
今天遇到在centos6.4下用pip安裝失敗的情況，結果發現由於centos6.4的python版本還是2.6.6導致。因此centos6.4要升級python版本到2.7才行 (2013-11-25補充)
三、demo演示
demo1 ： 最簡單的
demo2 ：http參數獲取的
四、調試
1、自己做webserver
uwsgi --http :9090 --wsgi-file {you process file}，這樣就啟動了，你可以 curl localhost:9090來測試它了
2、前端用nginx代理
uwsgi --socket 127.0.0.1:9090 --wsgi-file {you process file}
這個時候nginx的配置如下
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:9090;
}
然后就可以通過nginx制定的域名訪問代碼
五、參數優化
首先參考下官網的 things to know : http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html
我這邊最終啟動的命令如下：
uwsgi --socket 127.0.0.1:9090 -p 16 -l 8192 -M -R 100000 -z30 -L --wsgi-file app.py --max-apps 65535 --stats 127.0.0.1:1717 --post-buffering 100M --cpu affinity --buffer-size 65535 --daemonize /tmp/uwsgi --pidfile /tmp/uwsgi.pid --memory-report --threads 16
1、-p
啟動16個進程,注意這里不是16核就啟動16個進程，要根據代碼實際運行情況來定奪 (There is no magic rule for setting the number of processes or threads to use. It is very much application and system dependent. Simple math like processes = 2 * cpucores will not be enough. You need to experiment with various setups and be prepared constantly monitor your apps. uwsgitop could be a great tool to find the best values.)
這里已經告訴你了，通過uwsgitop來判斷，至於如何用uwsgitop，下面我會講到
2、-l
linux內核監聽網絡隊列長度，這個稍微大一點
3、-M
master模式，啟動主進程
4、-R
--max-requests的簡寫， reload workers after the specified amount of managed requests。一個worker完成多少個請求以后就重啟
5、-z
--socket-timeout的縮寫 set internal sockets timeout
6、-L
--disable-logging的縮寫 disable request logging，禁掉請求的系統日志，調試模式下要打開，生產環境注意關閉，這個東西很影響效率
7、--wsgi-file
程序入口
8、--max-apps
set the maximum number of per-worker applications，這個沒啥特別大的意義，可不要
9、--stats 127.0.0.1:1717
監控程序的url，只有設置了這個參數以后才能用 uwsgitop 1717來觀看監控，類似於linux的top命令，后面會專門提到
10 --post-buffering
enable post buffering，if an HTTP request has a body (like a POST request generated by a form), you have to read (consume) it in your application. If you do not do this, the communication socket with your webserver may be clobbered. If you are lazy you can use the post-buffering option that will automatically read data for you. For Rack applications this is automatically enabled.
11、--cpu affinity
cpu親和，也就是一個進程盡量不要切換cpu，因為切換cpu會消耗，但是實際測試過程中這個參數影響不大
12、--buffer-size
set internal buffer size
13、--daemonize
以守護的形式運行uwsgi，運行的日志會保存在/tmp/uwsgi里面，記得啟動以后vim /tmp/uwsgi來看下是否有錯誤日志
14、--pidfile
uwsgi程序的進程id所保存的文件，當我想要關閉uwsgi的時候只需要 uwsgi --stop /tmp/uwsgi.pid即可，還有重啟uwsgi --reload /tmp/uwsgi.pid
15、 --memory-report
開啟內存報告，在uwsgitop命令下可以看到內存使用情況
16、--threads
開啟的線程數，要根據uwsgitop的監控情況來具體調整
六、監控
uwsgi提供了一個很nice的監控工具，uwsgitop。它的安裝也很簡單 pip install uwsgitop，安裝以后 它會存在於 /usr/local/python27/bin/uwsgitop
運行 /usr/local/python27/bin/uwsgitop :1717,出現下面的圖片
然后查看下cpu的使用率，內存使用了，STATUS有幾個是busy狀態的，再具體判斷使用幾個進程，幾個進程
七、壓測
之前我壓力測過，圖片不見了我就懶得上傳了
如果僅僅是demo1上的最簡單的功能，qps能夠達到4W+，當時我都驚呆了，但是后來涉及到復雜的邏輯，還有連接數據庫等情況下，它的效率跟nginx +php差不太多
八、總結
python做webserver我不是很推薦，因為python的數據結構限制的比較死，我就碰到過幾次編碼啊、json格式啊、unicode等問題。而且不同的python版本對於函數的支持也不一樣，比如說md5.
但是它也有好處就是如果用uwsgi的話部署很方便。
有利有弊吧，我總覺得python還是做一些大數據啊、統計分析啊、復雜運算啊比較給力，如果是做webserver還是php給力。