記一次Django響應超慢的解決過程
在本地windows機器開發(fā)的Django項目運行正常,放到服務器上后響應超慢,花了一整個工作日沒找到原因(非常絕望),又花了一整個周末才找到原因和臨時解決辦法,如果你的項目超慢可以參考一下解決思路。
排查過程:
1.懷疑是Python環(huán)境問題,到服務器上各種虛擬環(huán)境版本進行嘗試,無果。
2.因為用了mysql數(shù)據(jù)庫,開始用pymysql包連接改動了一些參數(shù),擔心是驅動問題導致數(shù)據(jù)庫查的慢,更換mysqlclient包后,響應依舊慢。
3.擔心是有什么報錯導致慢,于是艱難地開啟了debug模式(由于用了pymysql所以開啟debug模式也會有個報錯),開啟之后Django反應慢但沒有任何報錯,絕望~
4.都說用uwsgi中間件部署Django能加快響應速度,嘗試之,沒用。
5.作為運維人員的思路來了-整個鏈路監(jiān)控吧,看看哪個環(huán)節(jié)慢了。在網(wǎng)上找到了django性能監(jiān)控工具django-silk,裝上之后發(fā)現(xiàn)只能看到請求耗時、sql查詢耗時,sql查詢耗時就幾ms,也不慢啊,哭死!
6.是不是模板渲染或者代碼有問題導致慢呢?
views.py中新建一個方法,不做任何處理,直接返回一個字符串,依舊慢!
7.從客戶端發(fā)出請求到views.py處理計算這個過程很慢?
views.py的處理函數(shù)中增加print('test'),在瀏覽器中刷新網(wǎng)頁后,查看Django輸出,請求后要15s才能看到打印test。
8.客戶端到服務器網(wǎng)絡慢?
服務器上新建一個空白的Django項目,運行在相同的端口上,反應正常,網(wǎng)絡沒問題。
9.從Django接受到請求到views.py進行邏輯處理中間這個過程很慢!中間經(jīng)過了django中間件middleware的處理,中間件導致的慢?
依次注釋掉能注釋的中間件,然后刷請求看瀏覽器發(fā)出請求到Django輸出test的延時。
發(fā)現(xiàn)注釋掉一個自定義的中間件后,Django很快就能輸出test(看到了希望)。但是正常業(yè)務處理方法響應依舊慢。
10.自定義中間做了什么,怎么會耗費這么長時間?
查看中間件代碼,發(fā)現(xiàn)每次請求進來Django進來以后,都要查詢數(shù)據(jù)庫,判斷當前的url路徑是否需要進行認證。
但這也是一次簡單的數(shù)據(jù)庫查詢而已啊,為什么會這么慢,而且前面django-silk中也顯示數(shù)據(jù)庫查詢響應很快?
有一點可以肯定的是Django查數(shù)據(jù)庫這個動作耗費了大量的時間!
11.既然查詢數(shù)據(jù)庫這個過程慢,那抓個到數(shù)據(jù)庫的包看一下?
一頓操作后發(fā)現(xiàn),當接收到請求后服務器會給數(shù)據(jù)庫發(fā)一點數(shù)據(jù),然后過了10多s后又發(fā)了一堆數(shù)據(jù),等這一堆數(shù)據(jù)打傳輸完后瀏覽器上網(wǎng)頁就返回了,這肯定跟響應慢有聯(lián)系!深挖!
linux上抓包保存到文件,下載到windows上用wireshark分析發(fā)現(xiàn):當Django收到用戶請求后,會主動與數(shù)據(jù)庫主機進行tcp連接,三次握手很快就成功了,然后等待了15s才收到MySQL的greet信息,才進行后續(xù)的sql查詢。這說明服務器很快就與數(shù)據(jù)庫主機建立了連接,但mysql應用等了15s才響應。此處不理解的,可以詳細看一下MySQL協(xié)議。
12.由于公司的DB是由DBA負責的,而且現(xiàn)在也是周末,所以暫時沒辦法繼續(xù)深挖DB原因。接下來怎么辦呢,怎么解決Django響應慢的問題?
在服務器上繼續(xù)抓包,想對比一下主機上其他應用查詢MySQL有什么差異,發(fā)現(xiàn)其他應用連接MySQL時一樣會有5s的延時。在分析包的過程中發(fā)現(xiàn)別的應用會發(fā)送ping這樣的請求,咦,這不是心跳包嗎?別的應用是不是有會話保持啥的?所以沒看出來響應慢?
13.給Django也設置一下數(shù)據(jù)庫長連接會話保持試一下?
百度上關于這塊的文章都比較老了,都是通過sqlalchemy的連接池管理可以保持數(shù)據(jù)庫的長連接和復用,要改源碼操作起來比較麻煩。而且都是Django 1.4時代的解決辦法了,現(xiàn)在都Django2.2了,官方有沒有提供長連接的機制支持呢?百度和查官方文檔后發(fā)現(xiàn)配置數(shù)據(jù)庫連接信息時有個可選參數(shù)叫“CONN_MAX_AGE”,默認情況下值為0,即數(shù)據(jù)庫查詢連接用完之后就釋放掉了,新的查詢又要重新建立一次連接。
將參數(shù)設置為2個小時,再次實驗。啟動Django后,第一次請求還是很慢,但后面的請求就加快了,問題得到了臨時解決!
Todo: 至于數(shù)據(jù)庫為什么要15s才響應連接,這個上班后再找DBA了解具體原因。
寄語:這次問題排查真的很艱難,嘗試了各種辦法,花了很多時間,終于通過抓包找到了相關的原因。講真,通過這次問題的排查讓我有增加了很多Django的知識!希望能對你有所幫助。
20200531更新:連接mysql慢的原因
為什么mysql響應這么慢,百度一番后發(fā)現(xiàn)原因
mysql建立連接之前會根據(jù)連接的ip反向查找對應的主機名,這一步會涉及DNS反向解析(如果本地hosts文件沒有指定就會找其他服務器查詢),這個過程會消耗時間。
于是登陸數(shù)據(jù)庫所在主機,通過命令"nslookup IP地址"分別查詢本地IP和服務器IP,本地IP查詢結果很快返回(不在一個網(wǎng)段找不到),服務器IP結果非常慢直到超時否沒返回,這就解釋了為什么前文【windows機器反應快,linux反應慢】的問題。至于為什么反向解析服務器IP這么慢,這個問題就不再繼續(xù)挖下去了,應該是網(wǎng)管沒有配置好相關的解析吧。
解決辦法:禁用反向解析,找到mysql的配置文件/etc/my.cnf,增加一行配置,重啟以后數(shù)據(jù)庫響應速度就完美了。
[mysqld] skip-name-resolve
既然這個反向解析這么耗時,為什么還要有這個流程呢?
還記得mysql的授權命令嗎:
grant all priviledges on *.* to "user"@"%" identified by "pass"
@后面的%就代表任意的主機名和ip地址,對!這個地方是可以根據(jù)主機名來授權的,如果把反向DNS解析關掉了,這里就會有問題,授權的時候就只能根據(jù)ip進行授權啦~
到此這篇關于記一次Django響應超慢的解決過程的文章就介紹到這了,更多相關Django響應超慢內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
- 在Django的View中使用asyncio的方法
- 詳解多線程Django程序耗盡數(shù)據(jù)庫連接的問題
- Django生成數(shù)據(jù)庫及添加用戶報錯解決方案
- python自動化測試三部曲之request+django實現(xiàn)接口測試
- 社區(qū)版pycharm創(chuàng)建django項目的方法(pycharm的newproject左側沒有項目選項)
- Django連接本地mysql數(shù)據(jù)庫(pycharm)的步驟
- Django實現(xiàn)文章詳情頁面跳轉代碼實例
- Django如何使用asyncio協(xié)程和ThreadPoolExecutor多線程
相關文章
python?argparse的使用步驟(全網(wǎng)最全)
argparse是python的一個命令行參數(shù)解析包,在代碼需要頻繁修改參數(shù)時,方便使用,主要用法就是在命令行輸入自己想要修改的參數(shù),這篇文章主要介紹了python?argparse的使用步驟(全網(wǎng)最全),需要的朋友可以參考下2023-04-04tensorflow 報錯unitialized value的解決方法
今天小編就為大家分享一篇tensorflow 報錯unitialized value的解決方法,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-02-02Gauss-Seidel迭代算法的Python實現(xiàn)詳解
這篇文章主要介紹了Gauss-Seidel迭代算法的Python實現(xiàn)詳解,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2019-06-06DataFrame窗口函數(shù)rolling()的用法
這篇文章主要介紹了DataFrame窗口函數(shù)rolling()的用法,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-02-02