原文： http://projects.unbit.it/uwsgi/wiki/ThingsToKnow

需要知道的內(nèi)容（最佳實(shí)踐和問題）

??? --http 和 --http-socket 完全不一樣。 第一個產(chǎn)生一個附加的進(jìn)程（一個代理），將請求路由（routing） 到uwsgi實(shí)例上。第二個，設(shè)置uwsgi為原生的http。如果web服務(wù)器不支持uwsgi協(xié)議，你需要使用http（像webfaction 或者 heroku）--http-socket.如果你打算發(fā)布你的app（從1.3-dev版開始支持https）使用 http轉(zhuǎn)發(fā)、路由、代理、負(fù)載會很可靠。

??? 默認(rèn)的發(fā)送 SIGTERM（終止信號）的意思是“brutally-reload-it”，普通的apps在遇到SIGTERM會關(guān)閉。關(guān)閉uwsgi使用SIGINT or SIGQUIT.如果你不想這樣設(shè)置，你可以使用--die-on-term 選項(xiàng)。

?? ?如果打算托管多個應(yīng)用，使用Emperor

??? 使用uwsgitop或者相似的東西來監(jiān)控你的apps

??? uWSGI可以從代碼和插件中引入新功能。通常你發(fā)行版uwsgi包是模塊化的。這種情況下要記得加載需要的插件。如果看到'unavailable modifier requested'這樣的信息，意味著插件沒有加載上。如果使用distro-supplied包，雙擊來安裝。

??? 配置文件支持，變量，if邏輯和簡單循環(huán)。檢查ConfigLogic 和ParsingOrder

??? 為了轉(zhuǎn)發(fā)請求到指定的插件，web服務(wù)器需要床底一個魔法數(shù)，默認(rèn)數(shù)字是0（對應(yīng)python）。舉個栗子，轉(zhuǎn)發(fā)一個請求到psgi （perl）要設(shè)置modifier為5，或者加載psgi插件為‘0’。
?? ?規(guī)則沒有定義線程或進(jìn)程數(shù)目。這取決于應(yīng)用和系統(tǒng)以來。不要以為只是簡單的2*cpucores就夠了。你需要嘗試不同的設(shè)置，同時不斷的監(jiān)控你的app。uwsgitop是一個非常好的工具來找到這個最佳值。

??? 如果http請求有一個body（像post一個表單）你不讀取，那么socket和web服務(wù)器的通訊會被拖垮。如果你不想手動讀取，使用 --post-buffering選項(xiàng)，這樣會自動為你讀取這些數(shù)據(jù)。

?? ?常常檢查你的內(nèi)存使用。--memory-report 選項(xiàng)非常有用。

?? ?如果你打算使用unux sockets，記住它們是標(biāo)準(zhǔn)的文件對象。這意味著它們有權(quán)限，所以web服務(wù)器要可以寫。

?? ?不要用root運(yùn)行uwsgi。它們明顯可以用root運(yùn)行，但是確保它們降權(quán)使用 --uid 和--gid選項(xiàng)。

?? ?uwsgi 只要可能的情況下都用 fork() 來復(fù)制。默認(rèn)，他會在加載應(yīng)用后執(zhí)行 fork 。如果你不想使用 --lazy選項(xiàng)。開啟它，會知道uwsgi來加載應(yīng)用。lazy模式優(yōu)雅的重啟works：代替重載的是，每個worker輪流著reload。如果你使用'lazy app loading'，但你想維持標(biāo)準(zhǔn)的uwsgi重載行為，在1.3之后你可以使用 --lazy-apps 選項(xiàng)。

?? ?默認(rèn)的python插件不會初始化GIL，意味著你的app線程不會運(yùn)行。如果需要線程，記得開啟 --enable-threads .運(yùn)行uwsgi在多線程模式（--threads）會自動開啟線程支持。這是由于性能所引起的奇怪行為，并不可恥。

??? ?如果為一個請求開啟一個進(jìn)程，它會繼承一個worker的文件描述，包括socket連接web服務(wù)器或路由器。如果不想使用這個特性，設(shè)置--close-on-exec 選項(xiàng)。

?? ?Ruby的垃圾回收默認(rèn)實(shí)在每個請求后。這是一個拖慢你的apps的危險(xiǎn)策略（消耗CPU成本要低于內(nèi)存成本）。改變這個頻率使用 --ruby-gc <freq> option

?? ?在OpenBSD，NetBSD和FreeBSD(<9v版本)ipc信號使用的鎖子系統(tǒng)。這次操作系統(tǒng)分貝的信號量優(yōu)先。應(yīng)該提高默認(rèn)限制。如果你要運(yùn)行多個uwsgi實(shí)例就提高這些限制。freebsd 9以后都不需要設(shè)置。

?? ?不要在不同的uwsgi庫中編譯構(gòu)建插件（至少要確切的知道你要做什么）

?? ?默認(rèn)的uwsgi分配一個小的buffer（4k）來接收每個請求的頭信息。如果在日志中看見"invalid request block size"，它意味著你需要一個大一點(diǎn)的buffer。使用--buffer-size增長(到60K)：如果接收'21573' 作為你接收的塊大小，這意味著你使用htpp實(shí)例覆蓋了uwsgi協(xié)議！！！

uwsgi基礎(chǔ)——最佳實(shí)踐和問題