在本地windows機(jī)器開發(fā)的Django項目運行正常，放到服務(wù)器上后響應(yīng)超慢，花了一整個工作日沒找到原因（非常絕望），又花了一整個周末才找到原因和臨時解決辦法，如果你的項目超慢可以參考一下解決思路。

排查過程：

1.懷疑是Python環(huán)境問題，到服務(wù)器上各種虛擬環(huán)境版本進(jìn)行嘗試，無果。

2.因為用了mysql數(shù)據(jù)庫，開始用pymysql包連接改動了一些參數(shù)，擔(dān)心是驅(qū)動問題導(dǎo)致數(shù)據(jù)庫查的慢，更換mysqlclient包后，響應(yīng)依舊慢。 

3.擔(dān)心是有什么報錯導(dǎo)致慢，于是艱難地開啟了debug模式（由于用了pymysql所以開啟debug模式也會有個報錯），開啟之后Django反應(yīng)慢但沒有任何報錯，絕望~

4.都說用uwsgi中間件部署Django能加快響應(yīng)速度，嘗試之，沒用。

5.作為運維人員的思路來了-整個鏈路監(jiān)控吧，看看哪個環(huán)節(jié)慢了。在網(wǎng)上找到了django性能監(jiān)控工具django-silk，裝上之后發(fā)現(xiàn)只能看到請求耗時、sql查詢耗時，sql查詢耗時就幾ms，也不慢啊，哭死！

6.是不是模板渲染或者代碼有問題導(dǎo)致慢呢？

views.py中新建一個方法，不做任何處理，直接返回一個字符串，依舊慢!

7.從客戶端發(fā)出請求到views.py處理計算這個過程很慢？

views.py的處理函數(shù)中增加print('test')，在瀏覽器中刷新網(wǎng)頁后，查看Django輸出，請求后要15s才能看到打印test。 

8.客戶端到服務(wù)器網(wǎng)絡(luò)慢？

服務(wù)器上新建一個空白的Django項目，運行在相同的端口上，反應(yīng)正常，網(wǎng)絡(luò)沒問題。 

9.從Django接受到請求到views.py進(jìn)行邏輯處理中間這個過程很慢！中間經(jīng)過了django中間件middleware的處理，中間件導(dǎo)致的慢？

依次注釋掉能注釋的中間件，然后刷請求看瀏覽器發(fā)出請求到Django輸出test的延時。

發(fā)現(xiàn)注釋掉一個自定義的中間件后，Django很快就能輸出test（看到了希望）。但是正常業(yè)務(wù)處理方法響應(yīng)依舊慢。 

10.自定義中間做了什么，怎么會耗費這么長時間？

查看中間件代碼，發(fā)現(xiàn)每次請求進(jìn)來Django進(jìn)來以后，都要查詢數(shù)據(jù)庫，判斷當(dāng)前的url路徑是否需要進(jìn)行認(rèn)證。

但這也是一次簡單的數(shù)據(jù)庫查詢而已啊，為什么會這么慢，而且前面django-silk中也顯示數(shù)據(jù)庫查詢響應(yīng)很快？

有一點可以肯定的是Django查數(shù)據(jù)庫這個動作耗費了大量的時間！ 

11.既然查詢數(shù)據(jù)庫這個過程慢，那抓個到數(shù)據(jù)庫的包看一下？

一頓操作后發(fā)現(xiàn)，當(dāng)接收到請求后服務(wù)器會給數(shù)據(jù)庫發(fā)一點數(shù)據(jù)，然后過了10多s后又發(fā)了一堆數(shù)據(jù)，等這一堆數(shù)據(jù)打傳輸完后瀏覽器上網(wǎng)頁就返回了，這肯定跟響應(yīng)慢有聯(lián)系！深挖！

linux上抓包保存到文件，下載到windows上用wireshark分析發(fā)現(xiàn)：當(dāng)Django收到用戶請求后，會主動與數(shù)據(jù)庫主機(jī)進(jìn)行tcp連接，三次握手很快就成功了，然后等待了15s才收到MySQL的greet信息，才進(jìn)行后續(xù)的sql查詢。這說明服務(wù)器很快就與數(shù)據(jù)庫主機(jī)建立了連接，但mysql應(yīng)用等了15s才響應(yīng)。此處不理解的，可以詳細(xì)看一下MySQL協(xié)議。 

12.由于公司的DB是由DBA負(fù)責(zé)的，而且現(xiàn)在也是周末，所以暫時沒辦法繼續(xù)深挖DB原因。接下來怎么辦呢，怎么解決Django響應(yīng)慢的問題？

在服務(wù)器上繼續(xù)抓包，想對比一下主機(jī)上其他應(yīng)用查詢MySQL有什么差異，發(fā)現(xiàn)其他應(yīng)用連接MySQL時一樣會有5s的延時。在分析包的過程中發(fā)現(xiàn)別的應(yīng)用會發(fā)送ping這樣的請求，咦，這不是心跳包嗎？別的應(yīng)用是不是有會話保持啥的？所以沒看出來響應(yīng)慢？

13.給Django也設(shè)置一下數(shù)據(jù)庫長連接會話保持試一下？

百度上關(guān)于這塊的文章都比較老了，都是通過sqlalchemy的連接池管理可以保持?jǐn)?shù)據(jù)庫的長連接和復(fù)用，要改源碼操作起來比較麻煩。而且都是Django 1.4時代的解決辦法了，現(xiàn)在都Django2.2了，官方有沒有提供長連接的機(jī)制支持呢？百度和查官方文檔后發(fā)現(xiàn)配置數(shù)據(jù)庫連接信息時有個可選參數(shù)叫“CONN_MAX_AGE”，默認(rèn)情況下值為0，即數(shù)據(jù)庫查詢連接用完之后就釋放掉了，新的查詢又要重新建立一次連接。

將參數(shù)設(shè)置為2個小時，再次實驗。啟動Django后，第一次請求還是很慢，但后面的請求就加快了，問題得到了臨時解決！

Todo: 至于數(shù)據(jù)庫為什么要15s才響應(yīng)連接，這個上班后再找DBA了解具體原因。

寄語：這次問題排查真的很艱難，嘗試了各種辦法，花了很多時間，終于通過抓包找到了相關(guān)的原因。講真，通過這次問題的排查讓我有增加了很多Django的知識！希望能對你有所幫助。

20200531更新：連接mysql慢的原因

為什么mysql響應(yīng)這么慢，百度一番后發(fā)現(xiàn)原因

mysql建立連接之前會根據(jù)連接的ip反向查找對應(yīng)的主機(jī)名，這一步會涉及DNS反向解析（如果本地hosts文件沒有指定就會找其他服務(wù)器查詢），這個過程會消耗時間。

于是登陸數(shù)據(jù)庫所在主機(jī)，通過命令"nslookup IP地址"分別查詢本地IP和服務(wù)器IP，本地IP查詢結(jié)果很快返回（不在一個網(wǎng)段找不到），服務(wù)器IP結(jié)果非常慢直到超時否沒返回，這就解釋了為什么前文【windows機(jī)器反應(yīng)快，linux反應(yīng)慢】的問題。至于為什么反向解析服務(wù)器IP這么慢，這個問題就不再繼續(xù)挖下去了，應(yīng)該是網(wǎng)管沒有配置好相關(guān)的解析吧。

解決辦法：禁用反向解析，找到mysql的配置文件/etc/my.cnf，增加一行配置，重啟以后數(shù)據(jù)庫響應(yīng)速度就完美了。

[mysqld]
skip-name-resolve

既然這個反向解析這么耗時，為什么還要有這個流程呢？

還記得mysql的授權(quán)命令嗎：

grant all priviledges on *.* to "user"@"%" identified by "pass"

@后面的%就代表任意的主機(jī)名和ip地址，對！這個地方是可以根據(jù)主機(jī)名來授權(quán)的，如果把反向DNS解析關(guān)掉了，這里就會有問題，授權(quán)的時候就只能根據(jù)ip進(jìn)行授權(quán)啦~

到此這篇關(guān)于記一次Django響應(yīng)超慢的解決過程的文章就介紹到這了,更多相關(guān)Django響應(yīng)超慢內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！