在本地windows機器開發的django專案執行正常，放到伺服器上後響應超慢，花了一整個工作日沒找到原因（非常絕望），又花了一整個週末才找到原因和臨時解決辦法，如果你的專案超慢可以參考一下解決思路。
排查過程：
1.懷疑是python環境問題，到伺服器上各種虛擬環境版本進行嘗試，無果。
2.因為用了mysql資料庫，開始用pymysql包連線改動了一些引數，擔心是驅動問題導致資料庫查的慢，更換mysqlclient包後，響應依舊慢。
3.擔心是有什麼報錯導致慢，於是艱難地開啟了debug模式（由於用了pymysql所以開啟debug模式也會有個報錯），開啟之後django反應慢但沒有任何報錯，絕望~
4.都說用uwsgi中介軟體部署django能加快響應速度，嘗試之，沒用。
5.作為運維人員的思路來了-整個鏈路監控吧，看看哪個環節慢了。在網上找到了django效能監控工具django-silk，裝上之後發現只能看到請求耗時、sql查詢耗時，sql查詢耗時就幾ms，也不慢啊，哭死！
6.是不是模板渲染或者**有問題導致慢呢？
views.py中新建乙個方法，不做任何處理，直接返回乙個字串，依舊慢!
7.從客戶端發出請求到views.py處理計算這個過程很慢？
views.py的處理函式中增加print('test')，在瀏覽器中重新整理網頁後，檢視django輸出，請求後要15s才能看到列印test。
8.客戶端到伺服器網路慢？
伺服器上新建乙個空白的django專案，執行在相同的埠上，反應正常，網路沒問題。
9.從django接受到請求到views.py進行邏輯處理中間這個過程很慢！中間經過了django中介軟體middleware的處理，中介軟體導致的慢？
依次注釋掉能注釋的中介軟體，然後刷請求看瀏覽器發出請求到django輸出test的延時。
發現注釋掉乙個自定義的中介軟體後，django很快就能輸出test（看到了希望）。但是正常業務處理方法響應依舊慢。
10.自定義中間做了什麼，怎麼會耗費這麼長時間？
檢視中介軟體**，發現每次請求進來django進來以後，都要查詢資料庫，判斷當前的url路徑是否需要進行認證。
但這也是一次簡單的資料庫查詢而已啊，為什麼會這麼慢，而且前面django-silk中也顯示資料庫查詢響應很快？
有一點可以肯定的是django查資料庫這個動作耗費了大量的時間！
11.既然查詢資料庫這個過程慢，那抓個到資料庫的包看一下？
12.由於公司的db是由dba負責的，而且現在也是週末，所以暫時沒辦法繼續深挖db原因。接下來怎麼辦呢，怎麼解決django響應慢的問題？
在伺服器上繼續抓包，想對比一下主機上其他應用查詢mysql有什麼差異，發現其他應用連線mysql時一樣會有5s的延時。在分析包的過程中發現別的應用會傳送ping這樣的請求，咦，這不是心跳包嗎？別的應用是不是有會話保持啥的？所以沒看出來響應慢？
13.給django也設定一下資料庫長連線會話保持試一下？
將引數設定為2個小時，再次實驗。啟動django後，第一次請求還是很慢，但後面的請求就加快了，問題得到了臨時解決！
todo: 至於資料庫為什麼要15s才響應連線，這個上班後再找dba了解具體原因。
20200531更新：連線mysql慢的原因
mysql建立連線之前會根據連線的ip反向查詢對應的主機名，這一步會涉及dns反向解析（如果本地hosts檔案沒有指定就會找其他伺服器查詢），這個過程會消耗時間。於是登陸資料庫所在主機，通過命令"nslookup ip位址"分別查詢本地ip和伺服器ip，本地ip查詢結果很快返回（不在乙個網段找不到），伺服器ip結果非常慢直到超時否沒返回，這就解釋了為什麼前文【windows機器反應快，linux反應慢】的問題。至於為什麼反向解析伺服器ip這麼慢，這個問題就不再繼續挖下去了，應該是網管沒有配置好相關的解析吧。
解決辦法：禁用反向解析，找到mysql的配置檔案/etc/my.cnf，增加一行配置，重啟以後資料庫響應速度就完美了。
[mysqld]
skip-name-resolve
既然這個反向解析這麼耗時，為什麼還要有這個流程呢？
還記得mysql的授權命令嗎：
grantallpriviledgeson*.*to"user"@"%"identifiedby"pass"
@後面的%就代表任意的主機名和ip位址，對！這個地方是可以根據主機名來授權的，如果把反向dns解析關掉了，這裡就會有問題，授權的時候就只能根據ip進行授權啦~
記一次詭異的HTTP響應
問題描述 1.通常我們會想到是不是因為中文?2.通過測試，發現不包含中文的返回最終響應的也是亂碼。3.目前為止排除了編碼問題，檢視閘道器日誌，應用日誌，發現閘道器拿到的資料全部亂碼，但是應用返回確是全部正常，問題查到這兒，基本將問題定位到閘道器和服務之間的互動可能不太正常。通過抓包工具，發現了伺服器...
記一次 MySQL 的慢查優化
最近遇見乙個 mysql 的慢查問題，於是排查了下，這裡把相關的過程做個總結。我首先檢視了 mysql 的慢查詢日誌，發現有這樣一條 query 耗時非常長 大概在 1 秒多 而且掃瞄的行數很大 10 多萬條資料，差不多是全表了 select from tgdemand demand t1 wher...
記一次慢查詢引發的事故
首先，測試環境上線新版本，並且通過黑盒測試以及功能測試。然後，我們就上線了新的版本。但是在執行3天後，整個伺服器大部分介面都失效了，基本上都是timeout。檢查伺服器情況 cpu基本上佔滿了。接著查了資料庫狀態，通過mysql命令show processlist 存在大量的waiting for ...