高性能框架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的組合 。