WordPress 文章超過10萬就會(huì)負(fù)載很高，是不是不適合做大網(wǎng)站？ _生活知道

這個(gè)問題是所有使用 WordPress 建站到一定規(guī)模之后都會(huì)碰到的問題，一般人的對(duì)此問題也都是泛泛而談，都是那些常見的處理方式，沒有具體如何去定位 WordPress 慢這個(gè)問題的方法，定位之后如何解決也沒有。
我也接過很多 WordPress 優(yōu)化的單子，所以我結(jié)合自己經(jīng)驗(yàn)決定講講自己是如何處理的。
基礎(chǔ)優(yōu)化
首先提供三點(diǎn)簡單的優(yōu)化建議：
將 WordPress 更新到 6.1，因?yàn)?WordPress 6.1 無需插件即可實(shí)現(xiàn)站點(diǎn) 0 SQL，這個(gè)操作是最直接最有效的。WordPress 性能優(yōu)化的基礎(chǔ)是一款速度夠快的主題，很多 WordPress 站點(diǎn)速度很慢，絕大部分原因就是主題。對(duì) WordPress 進(jìn)行基本的優(yōu)化，WordPress 性能優(yōu)化：為什么我的博客比你的快，我這篇文章已經(jīng)做了非常詳細(xì)的介紹，主要是兩點(diǎn)：使用 CDN 對(duì)動(dòng)靜態(tài)資源進(jìn)行分離和使用 Memcached 來緩存 WordPress 數(shù)據(jù) 。可能的原因
做了上面三點(diǎn)簡單的基礎(chǔ)優(yōu)化的操作之后，速度還是很慢，那應(yīng)該如何辦？根據(jù)我的經(jīng)驗(yàn)，WordPress 速度太慢，一般來說可能是下面這些原因：
頁面的 SQL 請(qǐng)求太多了，把數(shù)據(jù)庫的請(qǐng)求池耗盡了。HTTP 請(qǐng)求太多，并且都沒有做緩存，占用了太多的服務(wù)器資源。主題或者插件的 PHP 程序代碼沒寫好，甚至有死循環(huán)，直接卡死。Log 程序
如何定位這些問題呢？工欲善其事，必先利其器，所以我寫了一個(gè) WordPress 各種 Log 記錄的插件，專門來定位這些問題：

文章插圖
如上圖所示，首先這個(gè)插件會(huì)每天孜孜不倦記錄程序的錯(cuò)誤或者警告，這樣我就可以根據(jù)這個(gè)錯(cuò)誤來優(yōu)化和健壯程序，很多時(shí)候，用戶是無法清洗反饋清楚自己的錯(cuò)誤的，只是說程序有問題，通過 Log 反而容易定位代碼的，比如上面的 PHP log ：
我截取其中一段，就可以記錄一個(gè) PHP Warning 信息，PHP 數(shù)組 Undefined index 的問題，具體發(fā)生在哪個(gè)文件哪一行，具體的回調(diào)過程，請(qǐng)求的時(shí)間，地址，來源，Post 提交的數(shù)據(jù)都記錄一下，對(duì)解決問題是幫助非常大。
上圖中還有 weapp 和 weixin 相關(guān)的 log，是我為了區(qū)分方便處理，把微信公眾號(hào)和微信小程序插件相關(guān)的錯(cuò)誤拆分到不同的文件，然后每個(gè)文件都加上日期，這樣每天的 log 都會(huì)被記錄下來。
定位問題
你肯定會(huì)問，這個(gè) log 記錄系統(tǒng)和 WordPress 慢有什么關(guān)系？
其實(shí)大有關(guān)系了，通過 Log 是定位問題最好的方法，為了解決程序慢的問題，我還專門對(duì)超過5秒才能打開頁面的做了詳細(xì)的記錄。
我會(huì)記錄這個(gè)頁面，調(diào)用的時(shí)間，地址，傳遞的 POST 數(shù)據(jù)（如有），來源和具體耗時(shí)多少秒：

文章插圖
這個(gè)慢查詢 Log 會(huì)記錄這個(gè)頁面的所有 SQL 請(qǐng)求，共有多少條 SQL 請(qǐng)求，每條 SQL 具體是什么，耗時(shí)以及調(diào)用棧：

文章插圖
如果有 HTTP 請(qǐng)求，慢查詢 Log 也會(huì)記錄所有的 HTTP 請(qǐng)求，每條 HTTP 請(qǐng)求的鏈接，參數(shù)，耗時(shí)和調(diào)用棧：

文章插圖
解決問題
定位了問題之后，解決起來就非常方便了。
如果是 SQL 請(qǐng)求太多，是不是在 for 循環(huán)里面做了 SQL 請(qǐng)求？如果是，就應(yīng)該在 for 循環(huán)之前，就應(yīng)該通過所有 id 一次獲取數(shù)據(jù) ，這樣就不會(huì)一次耗盡數(shù)據(jù)庫線程。
如果是 HTTP 請(qǐng)求太慢，是不是可以把請(qǐng)求的結(jié)果緩存到 Memcached 中，這樣下次就無需遠(yuǎn)程的 HTTP 請(qǐng)求，直接從內(nèi)存中獲取即可。
舉個(gè)具體的例子，一般來說相關(guān)文章是通過文章的標(biāo)簽的相關(guān)來生成的，這樣就需要使用到文章和標(biāo)簽的關(guān)聯(lián)表（wp_term_relationships）和文章表（wp_posts）進(jìn)行連表查詢，根據(jù)文章相關(guān)度進(jìn)行排序，我見過一些文章數(shù)和標(biāo)簽數(shù)多的站點(diǎn)，這樣的一條 SQL 查詢經(jīng)常會(huì) 5-10 秒，這樣的慢查詢經(jīng)常把站點(diǎn)搞掛。
【W(wǎng)ordPress 文章超過10萬就會(huì)負(fù)載很高，是不是不適合做大網(wǎng)站？】我是如何優(yōu)化的呢？放棄連表的，首先獲取當(dāng)前文章的標(biāo)簽，然后從文章和標(biāo)簽的關(guān)聯(lián)表（wp_term_relationships）根據(jù)這些標(biāo)簽獲取最相關(guān)的文章 ID，并且多獲取一些，比如要獲取5篇，我就至少獲取10篇，然后把獲取的文章 ID ，從文章表（wp_posts）中獲取具體的數(shù)據(jù)，舍棄到那些不符合文章類型和狀態(tài)的，剩下的就符合要求了，剩下的不夠，就繼續(xù)上述的方法在找一些直至數(shù)量夠了。這樣通過 PHP 腳本進(jìn)行優(yōu)化，相關(guān)文章造成的性能問題就能得到完美的解決。