这篇文章其实两个月之前就应该面世了，但是最近琐事、烦心事太多就一直懒得动笔，拖到现在才写
一、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给力。