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

需要知道的內容（最佳實踐和問題）

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

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

?? ?如果打算托管多個應用，使用Emperor

??? 使用uwsgitop或者相似的東西來監控你的apps

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

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

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

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

?? ?常常檢查你的內存使用。--memory-report 選項非常有用。

?? ?如果你打算使用unux sockets，記住它們是標準的文件對象。這意味著它們有權限，所以web服務器要可以寫。

?? ?不要用root運行uwsgi。它們明顯可以用root運行，但是確保它們降權使用 --uid 和--gid選項。

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

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

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

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

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

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

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

uwsgi基礎——最佳實踐和問題