最近使用uwsgi出了一些问题，于是测试下Gunicorn测试对比下
环境
一颗cpu 1g内存 Centos系统 Django作为后端应用，Gunicorn默认模式和异步模式，响应基本是无阻塞类型
测试的request是一个加密操作，对url中的几个参数做一个ase加密
说明：下面的模拟阻塞模式，类似于你的请求中有很多调用第三方api的场景，因为网络延迟导致响应比较长
测试命令
ab -n 10000 -c 100 -r 'http://127.0.0.1:8888/account/ulogin/3/?wlanuserip=127.0.0.1&wlanacname=&ssid=cmcc&wlanparameter=ffffffffffff'
#模拟阻塞的模式下 -n 1000
ab -n 1000 -c 100 -r 'http://127.0.0.1:8888/account/ulogin/3/?wlanuserip=127.0.0.1&wlanacname=&ssid=cmcc&wlanparameter=ffffffffffff'
1
2
3
Gunicorn 同步异步测试
应用启动参数
默认模式
gunicorn -b 0.0.0.0:8888 wsgi:application
异步模式
gunicorn -b 0.0.0.0:8888 -k 'gevent' wsgi:application
1
2
3
4
5
测试统计
数字含义:总时间 qps 错误数
请求处理无阻塞：
默认模式worker： 27.5s,364,0; 26.3s,261,0
异步模式worker：31.9s,312,0; 31s,314,0
每个请求增加0.1秒的阻塞之后：
默认模式： 已经下降到 不到10的qps
异步模式： 仍然可以和之前的速度相当 300qps左右
Gunicorn设计 对使用同步还是异步worker，使用多少worker都有详细的建议
uWSGI同步异步测试
应用启动参数
#同步模式
uwsgi --http :8888 --module wsgi --process 1 -l 1000
#异步模式
uwsgi --http :8888 --module wsgi -l 1000 --async 100 --ugreen #原始的阻塞没有什么提升
1
2
3
4
5
测试统计
数字含义:总时间,qps,错误
一般请求：
默认模式: 26s, 385,0；26.2s, 380, 0
异步模式: 26.8s, 373, 0; 25.9s, 385, 0
每个请求0.1s阻塞请求下：
默认模式：109s,9,0; 103s,9.6,0
异步模式：104s, 9.6,0; 106s, 9.2,0 #基本跟同步模式没啥区别
uWSGI文档async说明 开头给出了一个警告：如果你的app不是时间驱动的话，使用这种模式是不对的。说白了，uwsgi的事件模式其实对应的是后端的事件框架，例如用gevent选项，后端是gevent才有效，如果后端是django，其实怎么配置没有多大区别，并没有对django的wsgi做了异步操作。
总结
在响应时间较短的应用中，uWSGI+django是个不错的组合(测试的结果来看有稍微那么一点优势)，但是如果有部分阻塞请求 Gunicorn+gevent+django有非常好的效率， 如果阻塞请求比较多的话，还是用tornado重写吧。
gunicorn是这样，不使用gevent的话，由nginx收集http请求，然后由gunicorn通过wsgi API调用用户代码处理这个请求，最后将结果送给nginx。这是gunicorn的最简单使用，有个benchmark显示这种方式的效率是非常低的。如果用户的程序包含了某些阻塞调用，比如数据库服务啊什么，那效率跟python自带的SimpleHTTPServer简直差不多。
gunicorn -k gevent 就厉害了。同样由nginx收集HTTP请求(不必需)，然后gunicorn为每个客户请求起一个纤程(greenlet)，再调用用户代码处理这个请求。好处是只要仔细选择第三方包，不怕数据库阻塞了。与apache为每个客户请求起一个线程(或者进程)相比，gunicorn -k gevent大节省内存使用量和同步开销。
gunicorn -k gevent-wsgi 差不多，只是底层使用libevent收集HTTP请求。
php、c#、java方面有没有类似的解决方案？反正我知道j2ee是不行的。
我在想，如果搭配memcached/redis之类的缓存，能不能轻松解决c10k问题呢？与其它的方案相比，gunicorn支持全功能的各种web框架，不需要对旧的程序做大规模的修改，这是大亮点吧。
不知道有没有将它应用到生产环境的同学来说一说。