針對服務器負載優化 WordPress 的步驟？

問題描述

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

最佳解決方案

您可以在 Nginx 上安裝 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 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。

針對服務器負載優化 WordPress 的步驟？