uWSGI 是一個(巨大的) C 應用，所以你需要一個 C 編譯器(比如 gcc）和python-dev。

把它部署到 HTTP 端口 9090

現在運行 uWSGI 來啟動一個會把請求傳遞給你的 WSGI 應用的 HTTP 服務器/路由器。

uwsgi --http :9090 --wsgi-file foobar.py

添加并發和監控

你想做的第一件事可能就是增加并發(uWSGI 默認啟動一個單獨的進程和一個單獨的線程)。

你可以通過 --processes 選項或者 --threads (或者兩個選項都使用)來增加更多的進程或者線程。

uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2

這將會產生 4 個進程(每個進程 2 個線程)，一個主進程(當你的進程死掉時會重新 spawn 一個新的)以及 HTTP 路由器(見前面)。

一個重要的任何就是監控。知道發生了什么在生產環境中是極其重要的。stats 子系統允許你 用 JSON 輸出 uWSGI 的內部數據：

uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191

向你的應用發送幾個請求然后 telnet 到 9191 端口，你將得到大量有趣的信息。你可能想要使用 “uwsgitop” (使用pipinstall你就能得到它)，這是一個類似 top 的工具，用于監控應用實例。

一般架構：

結論：

使用execute_from_command_line方式啟動django應用時, 會先加載urls, 從而會加載我們寫的業務代碼(views中的代碼); 然后再加載中間件代碼. 在應用啟動完成時, 所有相關代碼都已經被加載入內存。

使用get_wsgi_application方式啟動django應用時, 會先加載中間件代碼, 這與1中的是完全相反的。 此時, 我們的業務代碼仍然沒有被加載, 直到第一個請求過來。 如果我們在代碼中, 使用了未加載的代碼中的全局變量, 就會出現莫名其妙的bug

RUNSERVR

官方文檔解釋django自帶的server默認是多線程

測試

python3 manage.py runserver 0.0.0.0:8000

django開兩個接口,第一個接口sleep(20),另一個接口不做延時處理(大概耗時幾毫秒)

先請求第一個接口,緊接著請求第二個接口,第二個接口返回數據,第一個接口20秒之后返回數據

證明django的server是默認多線程

python3 manage.py runserver 0.0.0.0:8000 --nothreading

重復上述步驟

#4 使用 uWSGI 服務器啟動 django

#4.1 啟動 uWSGI

# 在django項目目錄下 Demo工程名

uwsgi --http 0.0.0.0:8000 --file Demo/wsgi.py

經過上述的步驟測試,發現在這種情況下啟動django項目,uWSGI也是單線程,訪問接口需要"排隊"

不給uWSGI加進程,uWSGI默認是單進程單線程

#4.2 給uWSGI加進程數

uwsgi --http 0.0.0.0:8000 --file Demo/wsgi.py --processes 4 --threads 2

# processes: 進程數 # processes 和 workers 一樣的效果

# threads : 每個進程開的線程數

1

2

3

4

經過測試,接口可以"同時"訪問,uWSGI提供多線程

#5 總結關于django的多線程問題

Python因為GIL的存在,在一個進程中,只允許一個線程工作,導致單進程多線程無法利用多核

多進程的線程之間不存在搶GIL的情況,每個進程有一個自己的線程鎖,多進程多GIL

單進程多線程的python應用可以實現并發,但是不存在并行

多進程的多處理器的python應用可能存在并行,至于并發還是并行,有操作系統決定,如果分配單處理器處理多進程,那就是并行,如果分配給多處理器那就是并行

Nginx+uWSGI可以實現python高并發

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的django多线程_Django两种启动方式(runserver和uwsgi)的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。