使用uwsgi 部署python web服務

uwsgi， wsgi協議的一個很好的實現，源碼在這裏:https://github.com/unbit/uwsgi

c語言編寫，有興趣能夠研究下。

 

上DEMO：

wsgi_server.py

def application(env, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    return 'hello world'

應用：

使用uwsgi部署以上應用：

uwsgi --http 0.0.0.0:9090 -p 4 -l 100 -M -R 100000  -z30 -L --wsgi-file  wsgi_server.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 4

而後瀏覽器訪問： http://localhost:9090/ 便可。

 

優點：

提升併發訪問支持(-p 進程數， --threads  線程數)

提升服務運行穩定性(--daemonize)

 

安裝

pip install uwsgi
pip install uwsgitop

uwsgi--uwsgi服務器

uwsgitop--uwsgi服務器性能查看工具，用法:

配合以上例子

uwsgitop 127.0.0.1:1717

 

參數詳細說明

官方文檔：http://uwsgi-docs.readthedocs.io/en/latest/Options.html

不錯的中文文檔：http://www.cnblogs.com/zhouej/archive/2012/03/25/2379646.html

挑幾個重點：

--wsgi-file , 指定wsgi入口文件

 

-p  , workers個數，也是進程數， 按照慣例可默認設爲核數，可是不是最優配置須要經過 uwsgitop來查看（我的以爲uwsgitop沒啥用）。

--threads , 線程數， 每一個進程的線程數，進程的任務用線程的模式完成。因爲用c編寫，所以不用擔憂GIL的問題， 但linux上不存在線程，線程本質來說是僞進程（且存在上下文切換成本），所以不建議使用。

（用了後，再用uwsgitop監控時，可經過鍵盤的「A」鍵查看線程的資源佔用狀況）

--listen (-l), 內核監聽(listen)網絡隊列的長度，受文件操做系統最大的網絡鏈接數（net.core.somaxconn） 的限制， 長度越大意味着在高併發的環境下，丟失請求越少。

--cpu-affinity, cpu友好，即進程在運行時不切換核（切換意味着時間成本）

 

--stats,  監控程序的url，只有設置了這個參數之後才能用 uwsgitop 1717來觀看監控

--memory-report, 開啓內存佔用報告（uwsgitop中能夠看到） 

--master(-M), 啓動主進程，方便管理全部進程， 能夠配合--pidfie 使用。方便中止(uwsgi --stop /tmp/uwsgi.pid)/重啓uwsgi ( uwsgi --reload /tmp/uwsgi.pid)

 

--daemonize, 增長守護進程，使web服務更加穩定。參數爲日誌文件的路徑。

--disable-loggin, 不記錄請求信息的日誌。只記錄錯誤以及uWSGI內部消息到日誌中。

 

其餘略，能夠本身逐一嘗試。

 

用途

flask必需搭配使用咯。

django建議使用，默認支持，有默認的wsgi.py文件生成。

1. flask 

uwsgi -s /tmp/uwsgi.sock --manage-script-name --mount /=xxx_project:app --http 0.0.0.0:9091

xxx_project換爲具體的項目文件頂層文件夾。

 

2. django

 django官方介紹。

即

uwsgi --chdir=/path/to/project/site_app  --module=site_app.wsgi:application  --env DJANGO_SETTINGS_MODULE=site_app.settings

 uwsgi官方介紹：http://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html#test-your-django-project。

即

uwsgi --http :8000 --module web_app.wsgi

相對來講後者簡單粗暴。

 

進一步的併發提高

+nginx，

爲啥呢？看這裏：http://www.oschina.net/translate/serving-python-web-applications?lang=eng

即：

I was pretty proud when we got API response times down to 40ms on average. When I say API I’m only talking about the time it takes from it hitting the Python server, to the server returning it’s response to the proxy.
Unfortunately, it quickly became apparent that there were capacity issues when we started getting more traffic for larger spikes. We’d hit bumpy response times that were no longer consistent, but we still had about 30% memory and 60% cpu to spare on the web nodes.

即：實測發現，uwsgi彷佛不能充分的利用cpu和內存來達到無上限的併發。有必定瓶頸，而且到達瓶頸後，cpu和內存還剩下不少！

那爲了充分利用資源不妨多開幾個uwsgi服務咯。

老外實測發現： 與其讓一個uwsgi服務跑10個進程，不如開10個uwsgi服務，而後用nginx作負載均衡！

After quite a few tweaks, what we eventually settled on was managing a larger amount of uwsgi processes, and letting nginx load balance them (vs letting uwsgi itself load balance).

What this means, is that instead of doing uwsgi –processes=10, we ran 10 separate uwsgi processes.

The result was a beautiful, consistent 20ms average response time.

固然這個有待驗證。

簡單說，就是uwsgi自己的負載均衡沒有nginx牛逼。因此閹割掉不用。

所以uwsgi退化成了wsgi服務器。

 

 

nginx 咋配置，略。

 

轉載請註明來自：http://www.cnblogs.com/Tommy-Yu/p/5647730.html，謝謝！