WordPress作為一款知名的CMS管理系統(tǒng)，在全球范圍內(nèi)廣泛部署，據(jù)說全球超過四分之一的網(wǎng)站基于WordPress創(chuàng)建，比如美國白宮官網(wǎng)也是基于WordPress創(chuàng)建的。WordPress具備很多優(yōu)點(diǎn)，比如使用簡單、資源豐富；但作為一款標(biāo)準(zhǔn)的CMS系統(tǒng)，由于需要考慮很多場景需求，因此從性能上來講，原版的WordPress性能上并沒有優(yōu)勢。

近期，某客戶網(wǎng)站是多年前基于WordPress創(chuàng)建的官網(wǎng)，之前是運(yùn)在linux服務(wù)器上，最近他們單位自己機(jī)房使用的是windows服務(wù)器。結(jié)果遷移上去后，明顯變得卡不少，原來基本上是秒開，現(xiàn)在還要進(jìn)度條轉(zhuǎn)一兩秒。

一般來講，只要水平不是太差的開發(fā)人員，自研的程序在性能上是優(yōu)于這些現(xiàn)成的CMS系統(tǒng)的，因此除官網(wǎng)外我們微構(gòu)網(wǎng)絡(luò)基本采用自研開發(fā)的網(wǎng)站程序（現(xiàn)在官網(wǎng)項(xiàng)目也基本采用自研程序）。在通常WordPress卡主要原因是有如下幾個(gè)原因：

1、前端引用了google等境外服務(wù)器的資源，比如谷歌字體文件。

這個(gè)因素基本在國內(nèi)采用WordPress的網(wǎng)站都不存在了，因?yàn)槿绻嬖诰W(wǎng)站將卡得沒法用，因?yàn)檫@些資源被防火墻攔截了，是無法訪問的。因此大家，都是在創(chuàng)建項(xiàng)目后基本上就屏蔽或者用國內(nèi)的鏡像資源替代這些資源了。

2、數(shù)據(jù)庫操作造成的卡頓。

雖然WordPress的數(shù)據(jù)庫操作，性能確實(shí)不高，但WordPress的定位就是博客程序，所以從這個(gè)程序設(shè)計(jì)上就不是定位高性能，隨便一個(gè)頁面就是幾十次查詢操作。但即便是這樣，在并發(fā)不高的網(wǎng)站，基本上不會(huì)因?yàn)檫@個(gè)原因造成的卡。

接下來就開始排查流程了，首先要排除上述兩個(gè)常見因素。被攔截的前端資源這個(gè)因素不存在，因?yàn)樵趌inux服務(wù)器上是沒問題的；數(shù)據(jù)庫操作問題理論上也不是，因?yàn)檫@種官網(wǎng)訪問量并不高，而且在原來服務(wù)器上也沒問題。

然后刪除所有代碼，進(jìn)行程序空載測試。也就是所有的自定義代碼全部刪除，僅僅只加載WordPress核心程序。結(jié)果發(fā)現(xiàn)竟然還是要1秒以上。

當(dāng)然WordPress空載的時(shí)候，核心程序也會(huì)進(jìn)行數(shù)據(jù)庫操作，監(jiān)測的sql語句如下3條：

在加上通過調(diào)試wp-blog-header.php這個(gè)核心入庫文件發(fā)現(xiàn)，即便禁止程序進(jìn)行后續(xù)輸出操作，頁面執(zhí)行時(shí)間也超過一秒。也就是只要執(zhí)行wp-blog-header.php中的

require_once( dirname(__FILE__) . '/wp-load.php' );

就要一秒以上，這顯然非常不正常。繼續(xù)追蹤溯源調(diào)試，最后發(fā)現(xiàn)是這樣的鏈路：

//文件：/wp-load.php
require_once( ABSPATH . 'wp-config.php' );
//文件：/wp-config.php
require_once(ABSPATH . 'wp-settings.php');
//文件：/wp-settings.php
require_wp_db();
//文件：/wp-includes/load.php
$wpdb = new wpdb( DB_USER, DB_PASSWORD, DB_NAME, DB_HOST );
//文件：/wp-includes/db.php
mysqli_real_connect( $this->dbh, $host, $this->dbuser, $this->dbpassword, null, $port, $socket, $client_flags );

也就是最終造成卡的就是mysqli_real_connect這個(gè)方法了，而這個(gè)方法是php自帶的一個(gè)方法，作用是建立數(shù)據(jù)庫鏈接。從中可以看出還是程序與數(shù)據(jù)庫之間存在問題，為了驗(yàn)證這個(gè)問題。我們編寫了一小段不基于任何框架或程序的測試代碼，代碼如下：

<?php
$t1=microtime(true);
$h=mysqli_init();
$r=mysqli_real_connect( $h, 'localhost', 'root', 'password', null, '3306' );
var_dump($r);
$t2=microtime(true);
var_dump($t2-$t1);

這段代碼的意義就是在于建立一個(gè)數(shù)據(jù)庫鏈接，然后查看建立這個(gè)鏈接所需要花的時(shí)間，測試結(jié)果如下：

也就是僅僅建立一個(gè)數(shù)據(jù)庫鏈接所需要的時(shí)間就是1秒多，因此造成前面所說的卡的主要原因就是在進(jìn)行建立數(shù)據(jù)庫鏈接時(shí)所花費(fèi)的時(shí)間。通過查找相關(guān)資料得知，造成這個(gè)原因一個(gè)常見問題就是由于在配置數(shù)據(jù)庫鏈接的時(shí)候，host填寫的是localhost而不是127.0.0.1，只需要修改為127.0.0.1即可。

使用127.0.0.1時(shí)所話的時(shí)間都是個(gè)位數(shù)毫秒級，這個(gè)時(shí)間幾乎可以忽略不計(jì)。當(dāng)然很多標(biāo)準(zhǔn)的程序默認(rèn)數(shù)據(jù)庫配置信息就是填寫localhost，而為什么某些情況就不行呢。可以參考我們發(fā)布的下一篇文章。