上一章我們實現了nginx+uWSGI+Flask的應用部署，並且研究了一下uWSGI啓動的進程，這一章聊一下uWSGI的一些特性和需要注意的地方
本章概覽
- uWSGI與多線程application的關係
- uWSGI啓動的應用如何加載虛擬環境中的包
- 永遠不要使用root
- 一個釋放work的優化方式——卸載
- 如何讓uWSGI支持多版本的Python應用。
uWSGI與多線程
如果在啓動uWSGI的時候沒有設置threads參數，那麼uWSGI將不會啓動Python的全局解釋器鎖（GIL），所以uWSGI application中生成的線程將不會運行。這種情況下，可以使用參數來強制uWSGI啓用GIL。只需要添加--enable-threads選項（在ini文件中是enable-threads = true）
虛擬環境
如果應用程序使用了虛擬環境中的包，那麼uWSGI在啓動應用程序的時候可能無法正常引入虛擬環境中的包。同樣，這種情況下也可以使用參數來指定所使用的虛擬環境，添加參數：virtualenv = <path>
安全性
永遠避免使用root用戶啓動uWSGI
卸載
uWSGI提供了一個卸載子系統，可以儘快將可能的任務從你的worker卸載，交給一個純C的線程。比如從文件系統發送一個靜態的文件，從網絡發送數據給客戶端等。卸載子系統非常複雜，但是對用戶是透明的。如果想嘗試，只需要加一個配置項即可：--offload-threads <n>。這裏<n>是生成的線程數（每個CPU對應一個線程是個不錯的開始）。
當卸載線程啓動，程序會自動匹配可以的優化項進行卸載。
我們在上一章的flaskapp.ini文件中增加這個配置項：offload-threads = 1
[uwsgi]
socket = 127.0.0.1:3031
chdir = /home/zhr/disk1/study/blog_code/uwsgi/p3_uwsgi/
wsgi-file = flaskapp.py
processes = 4
threads = 2
offload-threads = 1
stats = 127.0.0.1:9191
然後運行命令uwsgi --ini flaskapp.ini，可以看到如下log：
可以看到，uWSGi爲每個worker啓動了一個offload線程。
讓uWSGI支持不同的Python版本
uWSGI包含了一個很小的內核和多種多樣的插件。插件可以在uWSGI的bin文件運行時動態加載。當我們編譯一個爲Python應用程序使用的uWSGI bin文件的時候，一系列的Python插件被安裝到了這個bin文件中，這造成一個問題，我們無法使用一個uWSGI的bin文件支持多個Python版本的應用程序。
最好的解決方案是我們可以編譯一個獨立於Python語言的uWSGI內核，然後爲每個Python版本編譯一系列的插件。然後在運行的過程中選擇插件。
可以使用下面的命令編譯一個語言無關的uWSGI：
make PROFILE=nolang
然後可以爲每個Python版本編譯一個包含插件的動態鏈接庫，比如：
PYTHON=python3.4 ./uwsgi --build-plugin "plugins/python python34" PYTHON=python2.7 ./uwsgi --build-plugin "plugins/python python27" PYTHON=python2.6 ./uwsgi --build-plugin "plugins/python python26"
這會生成三個文件：python34_plugin.so，python27_plugin.so，python26_plugin.so。將這些文件拷貝到需要的路徑（默認情況下，uWSGI在當前工作路徑搜索插件）
現在可以在配置文件的最上面添加插件路徑和要選擇的插件：
[uwsgi]
plugins-dir = <path_to_your_plugin_directory>
plugin = python26
這樣，uWSGI在運行時會加載python26_plugin.so插件。
