Nginx下WordPress運行緩慢的解決方法：wordpress運行緩慢優(yōu)化的方法
1. 減少插件的使用
這是首要的一點。大部分人往往都沒足夠的代碼知識，更不可能做到每個插件的代碼化，故大部分人都在用大量插件等。大部分的插件都會進行數(shù)據(jù)查詢與生成，這在頁面生成過程中 將耗費時間。如果剛好你的主機限制比較嚴格的話（為了均衡資源使用率），這個時間甚至?xí)兊帽容^長。減少插件是非常必要的優(yōu)化手段之一
2. 減少HTTP請求
每一次對于JS，CSS等文件的訪問都是一次HTTP請求。插件用得少，HTTP請求數(shù)自然就更少。速度自然快了
WP在每一次的頁面訪問時，都會判斷插件的使用情況。讓W(xué)P做更少的判斷就等于做更少的數(shù)據(jù)查詢。解放它的負擔(dān)吧。
3. 謹慎的選擇主題或手動優(yōu)化
許多主題雖然漂亮但在優(yōu)化方面做得并不算好，各種JS，各種CSS，各種背景圖片，各 種空行，各種冗余，這些都會影響到載入速度。不過這并不意味著不能選擇絢麗的主題，而是主題應(yīng)該要基本滿足以下要求，或者你手動修改它使其滿足以下要求：
合并CSS和JS：將多個CSS合并為1個。
合并背景圖片：使用CSS Sprites將大部分的背景圖片合并為1個文件，同樣是減少HTTP請求，減少文件體積，加快渲染時間。
減少數(shù)據(jù)查詢：能用HTML直接輸出的地方就不要搞個數(shù)據(jù)查詢。
合理的JS和CSS位置：合理的將一些JS和CSS放置到網(wǎng)頁底部。
優(yōu)化主題的背景圖片
4. 減少外部資源的使用
外部資源就是不在自己服務(wù)器上的資源。使用太多的外部資源會遇到以下問題：
解析DNS的時間變長
每一個域名都是需要DNS解析才能夠正常工作。如果網(wǎng)站上的內(nèi)容同時需要加載a.com，b.com，c.com，d.com這些網(wǎng)站的資源，那就 需要更多的時間去分別解析每個域名的DNS，建立連接。而同樣的，如果自己的站點是a.com，如果同時加載1.a.com，2.a.com這些類似的域名，也同樣會加長DNS解析時間。外部資源是不可能 基本避免的，但能少則少。
外部資源的加載速度不可控制
這主要是針對一些國外站點的內(nèi)容而言，比如fickr，twitter等，因為眾所周知的原因，加載它們的資源會明顯減慢載入速度。而國內(nèi)的站點相對來說速度還算是比較快。
5. 減少數(shù)據(jù)庫查詢，或使用數(shù)據(jù)庫緩存插件
許多的插件都需要數(shù)據(jù)庫查詢，上面關(guān)于插件和主題的部分也提到了優(yōu)化代碼盡量減少數(shù)據(jù)庫的查詢次數(shù)。如果不懂，可以考慮使用數(shù)據(jù)庫緩存，它能夠?qū)?shù)據(jù)庫的查詢內(nèi)容緩存起來
需要注意的是，數(shù)據(jù)庫緩存插件不要和靜態(tài)化緩存插件一起使用。因為兩者都是數(shù)據(jù)緩存內(nèi)容減少查詢，如果一起用就等于重復(fù)勞動。
6， 使用頁面靜態(tài)化緩存插件
靜態(tài)化緩存插件和數(shù)據(jù)庫緩存插件的原理差不多，都是將內(nèi)容提前整理好并生成靜態(tài)的文件，當需要的時候直接拿出來，而不需要再去查找、生成，浪費時間。緩存過的靜態(tài)文件基本上可以等同于一張靜態(tài)圖片，不需要執(zhí)行太多復(fù)雜的內(nèi)容。
還有一些其他優(yōu)化的方法等，使用GZIP壓縮網(wǎng)頁、優(yōu)化博客文章圖片、使用CDN分布式網(wǎng)絡(luò)加速靜態(tài)文件等。
安裝wordpress插件檢查緩慢原因
本站運行一段時間后，每次訪問首頁最多時候需要20秒鐘以后上， 訪問一個單獨文章頁面也要10秒，簡直不可接受，基本都要崩潰了， 最后下定決心 解決它。
通過查閱大量資料， 參照前面一節(jié)的辦法對系統(tǒng)做了優(yōu)化。
1. 首先屏蔽 基本插件，發(fā)現(xiàn)系統(tǒng)問題依然存在， 打開首頁速度依然在10秒鐘左右
2. 通過httpwatch檢查http請求情況，發(fā)現(xiàn)訪問首頁中，獲取php頁面時間是9秒鐘， 打開圖片、js、css等時間是2～3秒鐘左右， 因此不是http請求過多造成的。
3. 打開mysql數(shù)據(jù)庫的慢查詢，檢查數(shù)據(jù)庫的慢查詢情況，發(fā)現(xiàn)多數(shù)查詢都比較快，對一些查詢做了測試，速度非?？?。因此數(shù)據(jù)庫因素也可以排除了。
實在沒辦法了， 最后考慮找wordpress插件來研究一下在顯示首頁中都發(fā)生了那些內(nèi)容，然后看看那里占用時間最長， 然后有針對的慢慢優(yōu)化，只好這么干了。
到了wordpress網(wǎng)站，搜索 debug插件， 搜索了很多，試用了很多，都不太符合自己的要求。最后發(fā)現(xiàn)了一個插件"Debug Queries"，按照wp的 慣下載并且安裝，最后路下圖，點擊啟用按鈕開啟插件。
安裝完成插件后，打開網(wǎng)站首頁，查看效果發(fā)現(xiàn)沒有任何變化
最后打開一個文章頁面，在文章頁面最下面發(fā)現(xiàn)了久久尋找的東西，路下圖：
圖中已經(jīng)用不同顏色的區(qū)域做了一些標注
紅 域： time：0.000xxxx 查詢需要的時間
綠 域： Query： 查詢的sql語句
Call from： require，xxx 調(diào)用順序等等
然后下面是另外的調(diào)用。 頁面顯示了本次頁面顯示過程調(diào)用了那些函數(shù)以及調(diào)用過程，及需要的時間（數(shù)據(jù)庫的查詢時間，根據(jù)這個時間及總時間我們計算出php花費的時間）
最后頁面路下圖：
藍色部分：是本次訪問數(shù)據(jù)查詢時間 匯總， 可以看到查詢共花費了0.24秒， 發(fā)生了83次查詢（這個也說明wp插件帶來性能的問題，只是目前系統(tǒng)中數(shù)據(jù)量較少，還不至于影響系統(tǒng)的性能）
綠色部分：是本次用戶訪問過程中總體時間的匯總，這里統(tǒng)計的應(yīng)該是包括了php的總體時間。
紅色部分：是本次訪問的總時間
紫色部分： 本次訪問中花費在php程序中消耗的百分比。97.5%
黃色部分：是本次訪問中花費在MySQL數(shù)據(jù)庫上時間的百分比 2.5%
從上面數(shù)據(jù)中我們可以看到， 一次10秒鐘的用戶訪問中， mysql花費時間僅僅占用了2.5%因此可以肯定這次10秒鐘的訪問問題出在mysql以外的環(huán)節(jié)上， 主要應(yīng)該是php的問題。
重新啟動php進程解決緩慢問題
從上面部門的分析中我們已經(jīng)可以了解到問題很可能出在php上面，排查php問題，不是我的專長，因此決定重新啟動php進程看一下效果。
1. 查找php進程
輸入 su – 命令， 切換端到root帳號下
在輸入： ps -ef | grep php 命令，查看php進程，如下
從圖中我們可以了解到php進程id 是 26765， 進程名稱php-fpm（這個是nginx需要的php程序）。
2. 查找php進程的啟動路徑
輸入如下命令 lsof -p 8584（這里的8584是在進行問題解決時php進程的id，上面26765還是最近寫文章是查找的進程的id）
3. 關(guān)閉進程
kill -9 8584 關(guān)閉老的php進程
有的時候php開辟了很多進程， 不好關(guān)閉，可以采用下面的辦法進行
killall php-fpm （本站就是采用這個辦法進行的）
4. 重新啟動php進程
輸入如下命令
/usr/ in/php-fpm 重新啟動進程