針對伺服器負載最佳化 WordPress 的步驟？

問題描述

除了安裝 W3 Total Cache 還是另一個快取外掛，我可以採取哪些步驟來確保我的主題和站點儘可能快地執行。

最佳解決方案

您可以在 Nginx 上安裝 WordPress 。有一些資源可以幫助：

•  nginx Compatibility plugin
•  HOWTO: Install WordPress On Nginx –
•  Slicehost discussion
•  How To Speed Up WordPress With Nginx And WP Super Cache
•  WordPress on nginx + lighttpd + FastCGI + php
•  Nginx as a front-end proxy cache for WordPress

來自最後一個連結的一些效能資訊 (與其他連結似乎有點不同)：

So I decided to put a proxy in front
of wordpress to static cache as much
as possible. ALL non-authenticated
traffic is served directly from the
nginx file cache, taking some requests
(such as RSS feed generation) from 6
pages/second to 7000+ pages/second.
Oof. Nginx also handles logging and
gzipping, leaving the heavier backend
apaches to do what they do best: serve
dynamic wordpress pages only when
needed.

…

On nginx – it』s so efficient it』s
scary. I』ve never seen it use more
than 10 to 15 meg of RAM and a blip of
CPU, even under our heaviest load. Our
ganglia graphs don』t lie: we halved
our memory requirements, doubled our
outgoing network throughput and
completely leveled out our load. We
have had basically no problems since
we set this up.

次佳解決方案

將 client-side 設定為 css，image，JavaScript 等等，不需要為每個頁面檢視重新下載。這到目前為止，我的網站載入時間最大的不同。最快的下載是從未發生的下載…

# BEGIN Expire headers
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 7200 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 2592000 seconds"
  ExpiresByType text/javascript "access plus 2592000 seconds"
  ExpiresByType application/x-javascript "access plus 2592000 seconds"
  ExpiresByType text/html "access plus 7200 seconds"
  ExpiresByType application/xhtml+xml "access plus 7200 seconds"
</IfModule>
# END Expire headers

# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
  <FilesMatch ".(ico|jpe?g|png|gif|swf|gz)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch ".(css)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch ".(js)$">
    Header set Cache-Control "max-age=2592000, private"
  </FilesMatch>
<filesMatch ".(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers

你可以 pre-gzip 你可以合理的一切 (7-zip 是一個很好的工具) 將其上傳到與您剛剛壓縮的檔案相同的位置。更改.htaccess 以提供 pre-gzipped 檔案，如下所示。這裡需要注意的是，如果/當您更新內容時，需要記住 re-gzip 。除了解析.htaccess 之外，這會削減 CPU 開銷。

RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]

這只是一個原始的答案。這個主題有很多變化。我發表了這篇文章，並在 http://icanhazdot.net/2010/03/23/some-wordpress-stuff/中增加了更多的 in-depth 文章。閱讀更重要的是，我指出的參考資料 – 他們是好的資源。

請注意，如果您經常修補，則使用者將需要重新整理其快取。

一個我發現非常有用的外掛是 wp-minify 。用這個觀看的東西是你應該排除 page-specific 專案 (聯絡表單，首頁滑塊等)，所以你不是 re-downloading 的每一頁的整套 css，JS 等。這是一個很好的方法來縮小，組合和壓縮您的基準 CSS，JS 等。它減少了 http 請求很多。 Wp-minify 與超級快取一起播放以及上面詳細介紹的到期標題。

在 Firebug(Firefox) 或類似的應用程式中使用 Yslow 可以監視您的 http 請求，以及什麼是和未壓縮的。看看那裡的到期標題。你很快會看到你能改善什麼。

第三種解決方案

最小化您執行的外掛數量，只有您真正需要的外掛數量。特別要注意的是，即使在頁面上沒有使用該程式碼的外掛，也可以在每個頁面載入 JavaScript 和 CSS 程式碼。

如果你是從頭開始建立自己的主題，打破下來你的 CSS，以便在需要時只需要為特定的頁面模板或檢視型別 (單後，檔案，類別等) 功能只載入。

配置 W3TC 使用 CDN(如 Amazon CloudFront 或 W3TC 支援的其他任何一個) 。

看看 Minify 選項是否適合你 (某些外掛生成不會很好地縮小的 js / css，所以一定要在啟用 minify 功能後測試你的網站) 。

如果您完全控制了 MySQL 伺服器，請確保已啟用 query_cache 。使用 MySQL tuning script 找到其他方法來最佳化您的資料庫配置。

如果使用 CDN 由於某些原因是有問題的，請在 apache 設定中配置 mod_expires 。為靜態型別 (如影像，CSS，JavaScript，影片，音訊等) 設定有效期限。

第四種方案

執行 memcached 並使用 object cache 來減少資料庫查詢的數量。這將快取來自資料庫的資料，而不是頁面。不知道 w3-total-cache 是否已經這樣做了。

確保您正在執行像 APC 這樣的操作碼快取。 (還有幾個可用。)

第五種方案

除了使用像 wp-cache 這樣的磁碟快取外掛之外，將您的部落格放在其上設定了”noatime” 屬性的主機捲上。否則，SSH 進入您的主機 (如果您的 Webhost 提供)，並且每隔幾天定期在您的檔案上執行此命令：

chattr -R +A ~/*

〜/ *表示 「我的目錄下的檔案」 。您可以根據需要更改該路徑。如果您的 webhost 提供了這一點，您還可以在 cpanel 中的 cron 作業中進行設定。

有關 atime 屬性的更多資訊，請參閱 this 。它大大加快了 Linux 磁碟讀取效能。

有時你的網站被蜘蛛打了。您可以使用像 SpyderSpanker 或 Chennai Central 這樣的工具來篩選出無法為您的網站帶來更多頁面排名的蜘蛛，並將其放慢速度，然後透過傳送它們來排除好蜘蛛 (如 Google，Bing 等) HTTP 304 未修改訊息。

我看到的另一件事就是寫得不好的外掛。如果您學習如何建立外掛，您將開始看到一些外掛的編碼效率低下，甚至找到時間空間，例如填充和填充並從未被清除的資料庫表，儲存諸如傳入連線資料之類的東西。

除了這裡的所有其他解決方案之外，您還可以透過將其連線到多個網路節點 PC 上來建立您的部落格的 WordPress Web 場，所有 PC 節點都連線到單個資料庫，並且檔案的一個磁碟卷 (例如透過 NFS 安裝的卷) ) 。檢視 Ultra Monkey 如何獲得一切。

第六種方案

頭頂上有幾個答案：

1) 儘量/可行地連線 JavaScript 和 CSS，最大限度地減少瀏覽器對主機的 HTTP 請求數量。

2) 儘可能多地解除安裝與第三方 CDN 一樣的影像/媒體，尤其是在使用共享主機時。

3) 嘗試減少您在首頁上顯示的帖子數量，以減少總渲染時間。

3a) 嘗試使用主題，在主頁和所有其他較舊的帖子中提供一些精選帖子作為摘錄。

第七種方案

快取 WordPress 選單還可以提升效能。特別是如果你有很多的頁面或一個巨大的選單結構，這應該被考慮。

做兩個簡單的步驟。首先，建立一個獲取或建立選單的功能，而不是直接呼叫 wp_nav_menu 。

function get_cached_menu( $menuargs ) {

    if ( !isset( $menuargs['menu'] ) ) {

        $theme_locations = get_nav_menu_locations();
        $nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
        $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
        $transient = 'menu_' . $termslug->slug . '_transient';

    } else {

        $transient = 'menu_' . $menuargs['menu'] . '_transient';

    }


    if ( !get_transient( $transient ) ) { // check if the menu is already cached

        $menuargs['echo'] = '0'; // set the output to return
        $this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
        echo $this_menu; // output the menu for this run
        set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved

    } else {

        echo get_transient( $transient ); // just output the cached version

    }

}

在您的主題中，用 get_cached_menu 替換 wp_nav_menu 。現在，每次呼叫選單時，都有一個 Databasequery，而不是整個 Menubuilding 。

選單不會經常更改 – 但是您也必須掛鉤到 wp_update_nav_menu 操作中以刪除舊的瞬變。

像這樣做：

add_action('wp_update_nav_menu', 'my_delete_menu_transients');

function my_delete_menu_transients($nav_menu_selected_id) {

    $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );

    $transient = 'menu_' . $termslug->slug . '_transient';

    delete_transient( $transient );

}

選單將在下一次呼叫頁面時生成 – 並使用快取版本，直到有人再次更新選單。

更新版本

感謝 @helgatheviking 指出了 s s 和 ID 之間的錯誤。我更新了這些功能，因此它與 theme_position 和 menu(用於選單的直接呼叫) 一起工作。

選單始終以選單的名稱儲存，而不是主題中的位置。

第八種方案

使用被修剪以最佳化的資料庫類。我們用自己的程式碼做了很好的經驗，以減少記憶體使用和資料庫訪問速度。除此之外，您還可以透過一些小的更改來最佳化資料庫結構本身。

資料庫類程式碼的一部分可以在 wordpress trac 中找到，它沒有將它變成核心 (Ticket #11799 and related) 。

第九種方案

對於高度被販賣的網站，您應該調整所有 MySQL 緩衝區為現在的內容。無論 WordPress 的版本，the MySQL layer can have its configuration computed 。

實際上，如果你有 InnoDB 資料沒有啟用 innodb_file_per_table，you need to cleanup InnoDB by segmenting each table into its own physical tablespace 。可以做體面的 MySQL 調優 even if you have a limited hardware 。有 many scenarios for doing such InnoDB optimizations 。

IMHO，您不能為 my.cnf 規劃好設定，而不知道要配置的資料量。您必須定期將生產中的當前資料集載入到分段環境中，執行最佳化，並刪除在生產伺服器的 my.cnf 中配置的數字。

第十種方案

您可以啟用全域性 output compression 。如果瀏覽器支援，這將 gzip 自動出現的所有內容。這大大減少了傳輸檔案的大小，但卻增加了 CPU 負載。

參考文獻

• Steps to Optimize WordPress in Regard to Server Load?

注：本文內容整合自 Google/Baidu/Bing 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。