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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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