uwsgi

                                      爲何不使用mod_wsgi

wsgi能夠當作一種編程標準，而不是一個socket協議，他不一樣於fastcgi它是一個通訊協議

Python web程序，佈署起來常見的有兩種方法：

1.一種是使用框架自己自帶的的server服務器調用wsgi接口來調用咱們的web app應用程序，而由於咱們的框架開發能力有限，不可能開發出一套很穩定，負載功能等各方面能力都很強的server服務器，只能開發除一個簡單的測試用的server服務器。

在生產環境中：這就決定了咱們必須佈署並使用一個外部的性能很高的服務器，作爲咱們的python web app應用程序的服務器。

2.使用各類http服務器的mod_wsgi模塊來運行連接各類python web app應用程序。可是使用mod_wsgi模塊功能簡單，不能監控，負載能力也不強，性能也不強，並且很佔用內存，配置起來也很麻煩，能夠這麼理解，這個項目組的人員只是兼職開發了這麼一個模塊，因此性能不高，不如專業開發這種接口模塊的人員開發的功能模塊強，這個功能模塊就是uWSGI。

uWSGI，既不用wsgi協議也不用fcgi協議，而是自創了一個uwsgi的協議棧相似於PHP中的php-cgi同樣能統一監聽同一個端口，進行統一負載平衡和管理，提升了性能，節省了部署功夫，並且聽說該協議棧大約是fcgi協議的10倍那麼快，有個比較見下圖，

 

爲何咱們要使用uWSGI（這也是一個常常要被問到的問題）

Because：由於：

咱們uWSGI的目標是：要想成爲一個完整的集成各類功能的web應用程序佈署中間件，他要有各類層級，他的功能要包括：

1. 進程管理
2. 一個長時間運行的web 應用程序app任務的自動管理（對於長時間運行的web app任務的穩定性要提除出各類解決辦法）

 

         3.uWSGI RPC Stack：uWSGI想要包含一個完成的遠程調用協議棧。

         4.Clustering 集羣功能：能使用集羣功能

1. LoadBalancing：負載均衡：能夠直接管理並調用好幾個app。
2. Monitoring：監控功能：具備對對各個web app應用程序的監控功能。
3. Resource Limiting：資源限制功能，好比負載均衡調用好幾個app，能夠分別對他們進行資源限制，好比網速，每一個app單位時間內的調用請求次數進行限制，這樣能提升咱們好幾個web app集合的總體性能。

 

以及其餘一些使人煩惱的平常任務，好比你要委託給外部腳本和其餘須要調用系統才能查看的任務，好比前面的監控功能。

 

因此：若是你想尋找一個簡單使用的適用於WSGI,PSGI或者是Rack協議的server，uWSGI可能不適合你，那就不要選擇uWSGI了。可是，若是你創建一個堅固，快速，容易部署並能配合達到一個各類性能最優化的負載均衡部署，你可能會發現本身須要uWSGI。

 

uWSGI最好的定義：就是網絡應用程序的瑞士軍刀。

 

這是一種什麼協議：

 

uwsgi 是 根據SCGI衍生出來的一種新的協議：

 

能在集羣環境中使用他們嗎

 

能使用集羣功能是uWSGI協議棧的一個主要特色，咱們能夠將多個實例部署在不一樣的服務器上，並利用負載均衡設備你的服務器/代理/路由器，您能把您的負載分配。像uWSGI RPC遠程調用系統能棧系統容許你快速調用的遠程節點上的功能，uWSGI協議棧系統容許你在多個節點上選出一個主節點進行方便配置管理。

 

超時設定

 

超時設定功能是保證集羣節點高可用性的一個關鍵功能。

 

Uwsgi幫助：

 

uWSGI是一個包換數百個功能選項的巨大工程。你應該作好準備，不是每件事都會在第一槍中出現。尋求幫助，尋求幫助，尋求幫助。若是你感到沮喪，不要浪費時間抱怨咆哮-而不是簡單地加入列表，並請求幫助。這是開源的，若是你只抱怨，那你什麼也作不成。

 

來信請寫明你的操做系統，CPU架構，web服務器，uWSGI版本，uWSGI命令行配置選項或者是命令行配置內容。

 

寫明你的配置文件選項對於咱們查找問題很是有幫助，或者是你本身從新安裝一遍或者是從新配置一遍。

 

官網：

 

uWSGI性能很高，不要懷疑他的性能。

 

用了uWSGI，咱們的應用程序是否運行的更快？

 

這不大可能，Web應用程序運行性能的最大瓶頸是應用程序自己。若是想要更快的環境，優化代碼或使用緩存或集羣之類的技術。咱們這樣說uWSGI快是指他在處理信息的時候引用了一個很小的信息頭在信息處理和調度結構上。

 

uWSGI在配置的時候對性能和穩定性影響最關鍵的參數是什麼？

 

uWSGI默認配置已經很好了，若是你想性能更瘋狂，能夠調下優。

 

1. 增長或減小延時時間
2. 增長線程功能，若是你不須要的話，最好別開啓多線程。
3. 若是你只運行一個app，最好別開啓多個解釋器。
4. 在生產環境中必定要開啓主進程，看的進程管理使用那一章節。
5. 增長works進程數並不必定能增長性能，這還得看你的機器性能，IO綁定，CPU性能等。

 

爲何不簡單的使用HTTP協議

 

一個最簡單的答案就是：HTTP解析速度慢，很是慢。Web服務器已經解析了http協議，並且已經有性能很高的http服務器，咱們不必再解析開發一次，的uWSGI協議是很是簡單的解析一個機器，而HTTP是解析一我的很容易。當人類被用做服務器，咱們將放棄uWSGI協議在HTTP協議支持。全部這一切說，你能夠用uWSGI經過本地HTTP的支持，FastCGI和ZeroMQ 也是如此。

 

uWSGI爲何支持多種配置方式：

 

uWSGI試圖給工程師儘量多的選擇，以使用各類各樣的環境，由於不少基礎設施環境已經搭好了，擁有多種配置方法只是咱們實現這一目標的一種方式。

 

uwsgi支持多種服務器，他本身也能夠做爲http服務器簡單的解析HTTP請求

 

 

 

1 首先nginx 是對外的服務接口，外部瀏覽器經過url訪問nginx,

 

2nginx 接收到瀏覽器發送過來的http請求，將包進行解析，分析url，若是是靜態文件請求就直接訪問用戶給nginx配置的靜態文件目錄，直接返回用戶請求的靜態文件，

 

  若是不是靜態文件，而是一個動態的請求，那麼nginx就將請求轉發給uwsgi,uwsgi 接收到請求以後將包進行處理，處理成wsgi能夠接受的格式，併發給wsgi,wsgi 根據請求調用應用程序的某個文件，某個文件的某個函數，最後處理完將返回值再次交給wsgi,wsgi將返回值進行打包，打包成uwsgi可以接收的格式，uwsgi接收wsgi 發送的請求，並轉發給nginx,nginx最終將返回值返回給瀏覽器。

 

3要知道第一級的nginx並非必須的，uwsgi徹底能夠完成整個的和瀏覽器交互的流程，可是要考慮到某些狀況

 

  1 安全問題，程序不能直接被瀏覽器訪問到，而是經過nginx,nginx只開放某個接口，uwsgi自己是內網接口，這樣運維人員在nginx上加上安全性的限制，能夠達到保護程序的做用。

 

  2負載均衡問題，一個uwsgi極可能不夠用，即便開了多個work也是不行，畢竟一臺機器的cpu和內存都是有限的，有了nginx作代理，一個nginx能夠代理多臺uwsgi完成uwsgi的負載均衡。

 

  3靜態文件問題，用django或是uwsgi這種東西來負責靜態文件的處理是很浪費的行爲，並且他們自己對文件的處理也不如nginx好，因此整個靜態文件的處理都直接由nginx完成，靜態文件的訪問徹底不去通過uwsgi以及其後面的東西。