其实比如 Flask，webpy，Django、CherryPy 都带着 WSGI server 。当然性能都不好，自带的web server 更多的是测试用途, 线上发布时，则使用高性能的 wsgi server或者是联合nginx做uwsgi 。
诚如那个WSGI的定义所说的，协议定义了一套接口来实现服务器端与应用端通信的规范化（或者说是统一化）。这是怎样的一套接口呢？很简单，尤其是对于应用端。
神器 Gunicorn是一个Python WSGI UNIX的HTTP服务器。这是一个预先叉工人模式，从Ruby的独角兽（Unicorn）项目移植。该Gunicorn服务器与各种Web框架兼容，我们只要简单配置执行，轻量级的资源消耗，以及相当迅速。它的特点是与各个web结合紧密，部署特别方便。
那么首先安装 gunicorn ~
pip install gunicorn
这里我们说下 gunicorn 的用法，最简单的运行方式就是：
gunicorn code:application
其中code就是指code.py，application就是那个wsgifunc的名字。
这样运行的话， gunicorn 默认作为一个监听 127.0.0.1:8000 的web server，可以在本机通过： http://127.0.0.1:8000 访问。
如果要通过网络访问，则需要绑定不同的地址（也可以同时设置监听端口）：
gunicorn -b 10.2.20.66:8080 code:application
在多核服务器上，为了支持更多的并发访问并充分利用资源，可以使用更多的 gunicorn 进程：
gunicorn -w 8 code:application
这样就可以启动8个进程同时处理HTTP请求，提高系统的使用效率及性能。
另外， gunicorn 默认使用同步阻塞的网络模型(-k sync)，对于大并发的访问可能表现不够好， 它还支持其它更好的模式，比如：gevent或meinheld。
# gevent gunicorn -k gevent code:application # meinheld gunicorn -k egg:meinheld#gunicorn_worker code:application
当然，要使用这两个东西需要另外安装，具体请参考各自的文档。
以上设置还可以通过 -c 参数传入一个配置文件实现。
gunicorn 的配置文件
[root@66 tmp]# cat gun.conf import os bind = '127.0.0.1:5000' workers = 4 backlog = 2048 worker_class = "sync" debug = True proc_name = 'gunicorn.proc' pidfile = '/tmp/gunicorn.pid' logfile = '/var/log/gunicorn/debug.log' loglevel = 'debug'
这里使用FLask简单写了一个web例子
[root@66 tmp]# cat xiaorui.py
from flask import Flask
from flask import render_template_string
import os
from werkzeug.contrib.fixers import ProxyFix
app = Flask(__name__)
@app.route('/')
def index():
return "worked!"
app.wsgi_app = ProxyFix(app.wsgi_app)
if __name__ == '__main__':
app.run()
单实例测试下，首先先用单纯的flask 自带的web服务器做下测试，会看到压力大的时候出现socket的问题，因为他是单进程单线程的
那接着，咱们使用gunicorn来启动。
用flask做测试的时候，2000个连接用了将近6秒左右，这次用gunicorn达到了2.4秒左右。。。。。 这速度对比，已经很明了了~
要是还想提高速度，可以改gun.conf配置文件中的worker数目。
cpu的损耗是平均到各个进程。数目一定不要过多，毕竟多进程对于系统的调度消耗比较大。
event wsgi的配置，我先简单的做下配置。。。。
大家想看实例的话，可以去gevent的官网的wsgi的demo 那边还附有编程的接口。。。
from gevent.wsgi import WSGIServer
from a import app
http_server = WSGIServer(('', 11111), app)
http_server.serve_forever()
另外提一下，uwsgi现在也支持gevent的方式。
上面是gunicorn常用的架构，前端Nginx负载，几个核就跑几个Gunicorn进程，gunicorn相对后面的app又可以给出几个进程。
比起uWSGI来说，Gunicorn对于“协程”也就是Gevent的支持会更好更完美。
方便以后业务的扩展和运营精细化。性能上Gunicorn+Gevent不会比uWSGI弱多少，毕竟后者纯C能只有这么点性能也不容易，比起WSGI Server里面最强的Bjoern而言，Gunicorn也有对应的Meinheld这种利器，况且后者对于HTTP协议的支持比Bjoern更完善。Gevent虽然不是异步框架里面性能最好的，但是绝对是最完善的，社区活跃度也非常高，加上方便的monkey_patch，使得大多数应用不用改代码就能方便地平移过来。这2者结合可以就保证了稳定性，又能有较好性能的组合。
