pythonuwsgi部署以及优化

这篇⽂章其实两个⽉之前就应该⾯世了，但是最近琐事、烦⼼事太多就⼀直懒得动笔，拖到现在才写

⼀、uwsgi、wsgi、fastcgi区别和联系

⼆、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制定的域名访问代码

五、参数优化

我这边最终启动的命令如下：

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 ofprocesses or threads to use. It is very much application and system dependent. Simple math like processes = 2 * cpucores will not beenough. You need to experiment with various setups and be prepared constantly monitor your apps. uwsgitop could be a great tool to find thebest 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 inyour application. If you do not do this, the communication socket with your webserver may be clobbered. If you are lazy you can usethe 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给⼒。