高性能框架gevent和gunicorn在web上的應用及性能測試

WSGI Server有哪些：

比如 Flask，webpy，Django、CherryPy 都帶着 WSGI server 。當然性能都不好，自帶的web server 更多的是測試用途, 發布時則使用生產環境的 WSGI server或者是聯合nginx做uwsgi 。

 

誠如那個WSGI的定義所說的，協議定義了一套接口來實現服務器端與應用端通信的規范化（或者說是統一化）。這是怎樣的一套接口呢？很簡單，尤其是對於應用端。

源地址 http://rfyiamcool.blog.51cto.com/1030776/1276364

神器 Gunicorn是一個Python WSGI UNIX的HTTP服務器。這是一個預先叉工人模式，從Ruby的獨角獸（Unicorn）項目移植。該Gunicorn服務器與各種Web框架兼容，我們只要簡單配置執行，輕量級的資源消耗，以及相當迅速。它的特點是與各個web結合緊密，部署特別方便。 缺點也很多，不支持HTTP 1.1，並發訪問性能不高。

安裝 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 #from http://rfyiamcool.blog.51cto.com

 

在多核服務器上，為了支持更多的並發訪問並充分利用資源，可以使用更多的 gunicorn 進程：

 

gunicorn -w 8 code:application

這樣就可以啟動8個進程同時處理HTTP請求，提高系統的使用效率及性能。

另外， gunicorn 默認使用同步阻塞的網絡模型(-k sync)，對於大並發的訪問可能表現不夠好， 它還支持其它更好的模式，比如：gevent或meinheld。

源地址 http://rfyiamcool.blog.51cto.com/1030776/1276364

#  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'

 

python 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()

先跑本身的demo ~ 

源地址 http://rfyiamcool.blog.51cto.com/1030776/1276364

結果是：

結果還算可以~    當然跑的實例也簡單~

 

cpu的損耗，不小哈~

其次的問題是，flask的web server在壓力下出現回應的錯誤。。。 我以前測試 tornado web.py flask django botto的壓力，讓朋友寫的cc工具做的測試。。。

結果是  tornado確實很牛，然后是flask，接着是web.py，最爛的是django

django本身的抗壓確實讓人蛋疼，還好大家在nginx做負載。

單實例測試完了，咱們開始測試 高性能神器 gunicorn 做wsgi

啟動后會出現：

2013-08-12 21:59:34 [2097] [INFO] Starting gunicorn 17.5 2013-08-12 21:59:34 [2097] [DEBUG] Arbiter booted 2013-08-12 21:59:34 [2097] [INFO] Listening at: http://127.0.0.1:5000 (2097) 2013-08-12 21:59:34 [2097] [INFO] Using worker: sync 2013-08-12 21:59:34 [2102] [INFO] Booting worker with pid: 2102 2013-08-12 21:59:34 [2103] [INFO] Booting worker with pid: 2103 2013-08-12 21:59:34 [2104] [INFO] Booting worker with pid: 2104 2013-08-12 21:59:34 [2105] [INFO] Booting worker with pid: 2105

我們再來測試下性能~

上次用了6秒左右，這次用gunicorn達到了2.4秒左右。。。。。 這速度對比，已經很明了了~

要是還想提高速度，可以改gun.conf配置文件中的worker數目。

 

cpu的損耗是平均到各個進程，而不是獨立在flask的web server上

 

 

現在我們開始測試gevent 作為wsgi 網關接口的實力~ 

 

flask的一個demo~

 

gevent wsgi的配置，我先簡單的做下配置。。。。

大家想看實例的話，可以去gevent的官網的wsgi的demo   那邊還附有編程的接口。。。

 

from gevent.wsgi import WSGIServer from a import app http_server = WSGIServer(('', 11111), app) http_server.serve_forever()

源地址 http://rfyiamcool.blog.51cto.com/1030776/1276364

我們開始測試更牛逼的gevent的並發能力 。

服務端：

客戶端：

 

看到秒數了吧~    啥也不說了~    大家都懂了~

我們稍微調節一下~ 

 

事實上, gunicorn 調用 gevent workers 的代碼類似這樣的原理(uwsgi+gevent 也是差不多的做法).

#!/usr/bin/env python
# coding:utf-8 import sys import os import gevent import gevent.monkey import gevent.wsgi import gevent.server gevent.monkey.patch_all() import socket import multiprocessing def app(environ, start_response): start_response('200 OK', [('Content-Type','text/plain')]) yield str(socket.getaddrinfo('xiaorui.cc', 80)) def handle_signals(): gevent.sleep(sys.maxint) if __name__ == '__main__': listenner = gevent.server._tcp_listener(('', 8002), backlog=500, reuse_addr=True) for i in xrange(multiprocessing.cpu_count()*2): server = gevent.wsgi.WSGIServer(listenner, app, log=None) process = multiprocessing.Process(target=server.serve_forever) process.start() handle_signals()

uwsgi現在也支持gevent的方式:

 

uwsgi --plugins python,gevent --gevent 100 --socket :3031 --module myapp

總之，gunicorn和gevent，或者是gunicorn+gevent的合體 都是很值得嘗試的東西。

 

源地址 http://rfyiamcool.blog.51cto.com/1030776/1276364

下圖是我推薦的網絡框架~ 這個框架和uwsgi的方式很像的，都是在nginx pass_proxy到app的前端口，然后用uwsgi或者是gunicorn來協同處理 。

server {
    listen 80;
    server_name xiaorui.cc;
                                                                                                                                                                                                                                                                                                                                                       
    root /www/xiaorui;
                                                                                                                                                                                                                                                                                                                                                       
    access_log xiaorui/access.log;
    error_log xiaorui/error.log;
                                                                                                                                                                                                                                                                                                                                                       
    location / {
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; if (!-f $request_filename) { proxy_pass http://127.0.0.1:8000; break; } }

前端Nginx負載，幾個核就跑幾個Gunicorn進程，gunicorn相對后面的app又可以給出幾個進程。

比起 uWSGI 來說，Gunicorn對於“協程”也就是Gevent的支持會更好更完美。

方便以后業務的擴展和運營精細化。性能上Gunicorn+Gevent不會比uWSGI弱多少，畢竟后者純C能只有這么點性能也不容易，比起WSGI Server里面最強的Bjoern而言，Gunicorn也有對應的Meinheld這種利器，況且后者對於HTTP協議的支持比Bjoern更完善。Gevent雖然不是異步框架里面性能最好的，但是絕對是最完善的，社區活躍度也非常高，加上方便的monkey_patch，使得大多數應用不用改代碼就能方便地平移過來。這2者結合可以就保證了穩定性，又能有較好性能的組合。

想簡單擴展就用 Gunicorn+Gevent，想麻煩折騰就用nginx 做uwsgi或gunicorn的組合 。