了解現代 WordPress 服務器堆棧

你還記得你什麼時候可以只用一個 Apache 服務器和 PHP 運行一個“快速”的 WordPress 網站嗎？ 是的，那是那些日子！ 那時的事情要簡單得多。

現在，一切都必須以閃電般的速度加載！ 訪問者對加載時間的期望與以往不同。 緩慢的網站可能會對您或您的客戶產生嚴重影響。

關於 SmashingMag 的進一步閱讀：

• 正確的 WordPress 文件系統權限和所有權
• 輕鬆移動 WordPress 網站
• 如何使用 MAMP 在本地開發 WordPress
• 使用 WordPress 自己動手做緩存方法

因此， WordPress 服務器堆棧多年來必須不斷發展，以跟上這種對速度的需求。 作為這種演變的一部分，必須在其發動機中添加一些齒輪。 一些較舊的齒輪也必須更換。

結果是，今天的 WordPress 服務器堆棧看起來與幾年前完全不同。 為了更好地理解它，我們將詳細探索這個新堆棧。 您將看到各個部分如何組合在一起以快速構建 WordPress 網站。

概述

在深入研究之前，讓我們縮小並查看大圖。 這個新的 WordPress 服務器堆棧是什麼樣的？ 好吧，這是答案：

上圖很好地概述了現代 WordPress 服務器堆棧的外觀。 在高層次上，我們可以將正在發生的事情分為三個方面：

• 瀏覽器和 WordPress 之間的請求-響應週期；
• WordPress（這是 PHP 運行時執行的腳本）；
• WordPress 和 MySQL 數據庫之間的查詢-結果循環。

現代 WordPress 服務器堆棧的作用就是優化這三個方面。 這些優化使一切加載速度更快。 最好的部分是有幾種方法可以做到這一點。 （耶！）

在大多數情況下，這些優化涉及在您的服務器上安裝新服務。 有時，這些服務需要插件的幫助才能與 WordPress 進行交互。 有時您只需安裝一個插件就可以擺脫困境。 您將在本文中看到許多不同的選項。

請求-響應週期

一切從瀏覽器開始。 假設您要查看modern.wordpress-stack.org的主頁。 您的瀏覽器將首先向託管它的 Web 服務器發送 HTTP 請求。 在另一端，Web 服務器將接收您的請求並將其轉換為 HTTP 響應。

第一個響應應該始終是modern.wordpress-stack.org主頁的HTML 內容（除非出現錯誤）。 但是，您的瀏覽器的工作還沒有完成。 不，該主頁仍然需要更多文件，最常見的是 CSS、JavaScript 和圖像文件。

因此，瀏覽器將發送對這些文件的請求。 Web 服務器將響應請求的文件（同樣，只要沒有錯誤）。 這個循環將一直持續到瀏覽器有足夠的信息來呈現主頁。 這個循環發生得越快，網站加載的速度就越快。

現在，這是一個明顯的簡化，但它是大多數 WordPress 網站的工作方式。

優化請求-響應週期

好吧，這給我們帶來了一個顯而易見的問題，我們如何讓 Web 服務器更快地執行這個循環？ 這是一個很好的問題，也是現代 WordPress 服務器堆棧存在的部分原因。

堆棧的存在是因為您不能僅僅讓 Web 服務器更快。 Web 服務器也是一個調度程序。 它可以接收請求並將其轉發給其他服務。

這些其他服務通常是這個請求-響應週期的瓶頸。 對於 WordPress，這個瓶頸是 PHP，這就是為什麼優化請求-響應週期歸結為兩件事。 我們希望網絡服務器：

• 接收盡可能少的請求，
• 向 PHP 轉發盡可能少的請求。

現代 WordPress 服務器堆棧專注於最後一個。 它希望向 PHP 轉發盡可能少的請求。 這將是優化堆棧的主要目標。

我們專注於第二個目標，因為堆棧不能對第一個目標做太多事情； 它對其沒有直接影響。 第二個問題可以通過 Web 服務器的配置或現代開發技術來解決。

請求-響應週期的堆棧元素

那麼，哪些棧元素可以幫助我們減少轉發給 PHP 的請求呢？ 嗯，特別是兩個堆棧元素將幫助我們實現這個目標：Web 服務器和 HTTP 緩存。

網絡服務器

我們已經談論了很多關於 Web 服務器的內容。 Web 服務器領域有三大玩家：

• 阿帕奇
• 互聯網信息服務 (IIS)
• nginx

這些共同構成了 Internet 上 Web 服務器市場份額的 90% 以上。 我們將專注於 Apache 和 nginx。 雖然 IIS 可用於運行 WordPress，但它並不常見，因為它僅適用於 Windows，而且大多數 WordPress 服務器使用 Linux。

這給我們留下了 Apache 和 nginx。 在 WordPress 的整個生命週期中，Apache 一直是推薦的 Web 服務器。 我們有 LAMP 堆棧（Linux、Apache、MySQL 和 PHP），它在計算機和服務器上運行 WordPress。

但在幕後，事情正在發生變化。 鎮上來了一個新玩家，它的名字叫 nginx。 Automattic 和 WordPress.com 自 2008 年以來一直在使用它。它是運行最大比例的高流量網站（其中很多都運行 WordPress）的 Web 服務器。 這就是為什麼許多高端託管公司和頂級 WordPress 代理使用它作為他們的網絡服務器的原因。

並不是說 Apache 是一個糟糕的 Web 服務器。 有 Apache 專家可以使其在大量流量下運行良好。 開箱即用或使用標準 WordPress 配置時，它的效果並不好。

同時，nginx 的唯一目的是處理大量流量。 這就是 Igor Sysoev 在 Rambler 工作時開始這個項目的原因。

nginx 更好地處理更多流量的原因之一是它使用 FastCGI 與 PHP 進行通信。 什麼是 FastCGI？ 它是一種讓 PHP 作為獨立於 Web 服務器的服務運行的協議。

默認情況下，Apache 不這樣做。 每次 Web 服務器收到請求時，它都需要啟動 PHP 運行時進程——即使是圖像、JavaScript 和 CSS。 這減少了服務器可以處理的請求數量以及處理它們的速度。

這違背了我們之前看到的現代 WordPress 服務器堆棧的目標之一。 堆棧需要保持請求-響應循環時間盡可能短。 為每個請求加載 PHP，即使它不需要它，也違背了這個目標。 因此，如果您使用 Apache，請查看 FastCGI。

HTTP/2是您應該了解的另一個重要的 Web 服務器功能。 它是 HTTP 的下一個版本，支持我們整個請求-響應週期的協議。

在 HTTP/2 到來之前，瀏覽器只能與 Web 服務器建立六個連接。 每個連接一次只能處理一個請求。 因此，在實踐中，請求-響應週期的上限為每個週期六個請求。

這是一個真正的問題。 大多數網站在其周期中有幾十個請求。 開發人員和系統管理員找到了解決此限制的巧妙方法。

一種更廣為人知的解決方法是結合 CSS 和 JavaScript 文件的做法。 在理想情況下，這會將對 CSS 和 JavaScript 文件的請求總數減少到兩個：一個用於 JavaScript，一個用於 CSS。

對於 HTTP/2，這不是必需的。 HTTP/2 允許每個連接無限數量的請求。 這允許在初始 HTML 響應之後的所有額外請求同時發生。

這具有巨大的性能影響。 許多優化服務器堆棧的工作都集中在請求-響應週期上。 通過將周期數減少到少數幾個，HTTP/2 為我們完成了大量工作。

HTTP 緩存

現代 WordPress 服務器堆棧中最重要的部分是 HTTP 緩存。 在 WordPress 世界中，我們也稱此頁面緩存。 HTTP 緩存的目的是緩存對請求的響應。 這是什麼意思？

好吧，讓我們回到我們之前的例子。 瀏覽器發送一個對modern.wordpress-stack.org主頁的請求，Web 服務器接收該請求並將其轉發給 PHP。

這種情況的問題是 Web 服務器是愚蠢的。 它總是將它收到的所有請求轉發給 PHP——不管大多數請求是否會產生相同的響應。

這正是訪問者未登錄時發生的情況。對於 Web 服務器來說，它們都是不同的請求，但它並不關心。 它會將它們全部轉發給 PHP，PHP 將為所有這些生成相同的響應。

這太可怕了！ 正如我們之前看到的，PHP 是我們請求-響應週期的真正瓶頸。 在收到初始主頁響應之前，您的瀏覽器無法發送其後續請求。 默認情況下，我們不能讓 Web 服務器將所有內容都轉發到 PHP。

這就是 HTTP 緩存的用武之地。它位於 Web 服務器和 PHP 之間。 它的工作是檢查 Web 服務器接收到的每個請求並查找緩存的響應。 如果沒有，它會將請求轉發給 PHP，然後緩存 PHP 生成的響應。

這大大減少了請求-響應週期時間，使網站加載速度更快。 它還允許 Web 服務器處理更多並發請求而不會崩潰。

HTTP緩存的不同風格

在這一點上，你應該想知道，“我怎樣才能讓這個寶貝盡快在我的服務器上？！” 好消息是在 WordPress 服務器上安裝 HTTP 緩存非常容易。 它是選項範圍最廣的組件。

安裝頁面緩存插件

最簡單的方法是安裝頁面緩存插件。 您有幾個選項可供選擇：

• 蝙蝠緩存
• 超高速緩存
• 緩存啟動器
• WP火箭
• WP 超級緩存
• W3 總緩存

除了 WP Rocket 之外的所有插件都可以作為 WordPress 目錄中的免費插件使用。 因此，您可以安裝一個並立即進行測試。 話雖如此，在四個插件中，最好的一個是 WP Rocket。 雖然它是一個付費插件，但它所做的不僅僅是創建一個 HTTP 緩存。 這些其他好處放大了 HTTP 緩存所做的工作。

頁面緩存插件如何工作？

所有這些插件都利用了 WordPress 為緩存提供的插件。 這個緩存插件允許插件在 WordPress 內部創建一個 HTTP 緩存系統。 緩存插件需要兩件事才能工作。

首先， advanced-cache.php文件需要在wp-content文件夾中。 那是實際的文件。 但與大多數 WordPress 插件不同，這個插件默認情況下不會啟動。 WordPress 還需要WP_CACHE常量為true才能加載插件。 在大多數情況下，您可以在wp-config.php中進行設置。

上圖顯示了當您使用緩存插件啟用插件時會發生什麼。 WordPress 在加載過程中加載wp-settings.php中的插件。 這已經足夠早了，WordPress 還沒有做任何耗時的事情。

然後緩存插件將檢查它是否已經緩存了對請求的響應。 如果有，它將返回緩存的響應。 如果沒有，它將打開 PHP 輸出緩衝，並且 WordPress 將繼續加載。

現在，輸出緩衝是一個有趣的系統。 它的作用是在字符串變量中捕獲 PHP 腳本的所有輸出，直到發生以下兩種情況之一：

• 您告訴 PHP 使用內置函數之一停止緩衝其輸出，
• PHP 腳本完成並需要向瀏覽器返迴響應。

緩存插件依賴於後一種情況。 它希望 WordPress 完成它的工作，然後在 PHP 將其發送回瀏覽器之前緩存整個輸出。 您可以在下圖中看到該過程。

讓 Web 服務器執行此操作

下一個選項是在 Web 服務器級別添加 HTTP 緩存。 它的工作方式是 Web 服務器將緩存對轉發到 PHP 的請求的所有響應。 這個解決方案比緩存插件更好，因為它根本不需要接觸 PHP。

上圖概述了 Web 服務器中的情況。 Web 服務器接收請求並檢查 HTTP 緩存。 如果響應已被緩存，HTTP 緩存會將其發回。

否則，它會將請求轉發給 PHP 模塊（通常是 FastCGI）。 它將請求傳遞給 WordPress，以便它可以生成響應。 然後，HTTP 緩存模塊將在返回的路上緩存該響應。

Apache 和 nginx 都具有添加 HTTP 緩存系統的能力。 nginx 是內置的。Apache 是一個單獨的模塊，您需要將其添加到 Apache 安裝中。

關於如何將 Apache 模塊與 PHP 或 WordPress 一起使用的信息並不多。 這可能是因為它在 Apache 人群中不受歡迎，或者可能是因為它存在一些問題。 至少有一個長期存在的問題仍然存在。

同時，nginx HTTP 緩存系統是健壯且有據可查的。 您可以將其用作普通的 HTTP 緩存或用作較小但有效的微緩存。 這只是 nginx 成為當今首選 Web 服務器的另一個原因。

將清漆添加到堆棧

什麼是清漆？ 它是一個專用的 HTTP 緩存服務器（或者，正如其開發人員喜歡的那樣，它是 HTTP 加速器）。 大多數高流量網站和高級託管公司都使用它作為他們的 HTTP 緩存解決方案。

他們使用它是因為它功能強大並且提供了最大的靈活性。 Varnish 有自己的配置語言，稱為 VCL。 它使您可以控制緩存過程的每個元素。 Varnish 還附帶了許多工具，用於分析緩存在做什麼以及它是如何執行的。

這些是使用它與僅使用內置 Web 服務器 HTTP 緩存之間的主要區別。 內置的 Web 服務器 HTTP 緩存性能超級好，但也非常基礎。 除了幾個配置選項之外，您沒有太多控制權。

然而，這種能力和靈活性是有代價的。 Varnish 也是最複雜的 HTTP 緩存選項。 它除了緩存 HTTP 響應什麼都不做。 它不處理大多數 WordPress 開發人員想要（或應該想要）的 SSL 終止。 這意味著當我們使用現代 WordPress 服務器堆棧時，它會變得更加複雜。

上圖說明了這種額外的複雜性。 現在，我們的 WordPress 服務器堆棧中還有兩個組件：Varnish 和反向代理。

反向代理可以克服 Varnish 對 SSL 的限制。 它位於 Varnish 前面並解密我們的服務器收到的請求。 您也可以將這種類型的反向代理稱為 SSL 終止代理。 然後代理將這些解密的請求發送給 Varnish 進行處理。

一旦請求到達 Varnish，VCL 配置文件就會啟動。它們是 Varnish 的大腦。 例如，他們告訴它如何：

• 分析、清理和修改傳入請求；
• 尋找緩存的響應；
• 分析、清理和修改來自 WordPress 的返迴響應；
• 緩存這些返回的響應；
• 處理從緩存中刪除一個或多個響應的請求。

最後一個尤為重要。 Varnish 沒有辦法知道 WordPress 何時要從緩存中刪除頁面。 因此，默認情況下，如果您對帖子進行更改並更新它，訪問者將繼續看到相同的緩存頁面。 幸運的是，有一個插件可以從 Varnish 緩存中刪除頁面。

WordPress

好的，我們對modern.wordpress-stack.org主頁的請求已經訪問了WordPress。 它經歷了我們剛剛介紹的請求-響應週期。 HTTP 緩存盡其所能找到要發回的 HTTP 響應。

但是沒有緩存的 HTTP 響應發送回瀏覽器。 那時，HTTP 緩存別無選擇。 它必須將 HTTP 請求轉發給 WordPress。

現在一切都在 WordPress 手中。 WordPress 必須將我們的 HTTP 請求轉換為 HTTP 響應並將其發送回 HTTP 緩存。 正如我們之前看到的，這是我們整個現代 WordPress 服務器堆棧的主要瓶頸。

造成這種瓶頸的原因有兩個。 WordPress 有很多 PHP 代碼要執行。 這很耗時，而且 PHP 做的越慢，花費的時間就越長。

另一個瓶頸是 WordPress 需要執行的數據庫查詢。 數據庫查詢是昂貴的操作。 數量越多，WordPress 的速度就越慢。 這將是查詢結果循環的最後一部分的重點。

優化 PHP 運行時

讓我們回到 PHP。 目前，WordPress 的最低要求為 PHP 5.2。 這個版本的 PHP 已經快 10 年了！ （PHP 團隊在 2011 年停止支持它。）

PHP 團隊這些年來一直沒有閒著。 已經進行了許多性能改進，尤其是在過去幾年中。 讓我們看看你現在可以做些什麼來優化它。

使用最新版本的 PHP

您可以做的最簡單的事情是升級您的 PHP 版本。 版本 5.4、5.5 和 5.6 都看到了性能改進。 最大的改進是從 5.3 到 5.4。 切換到它使 WordPress 的性能大大提高。

安裝操作碼緩存

操作碼緩存是另一種加速 PHP 的方法。 作為一種服務器端腳本語言，PHP 有一個很大的缺陷：每次執行時都需要編譯一個 PHP 腳本。

解決這個問題的方法是緩存編譯後的 PHP 代碼。 這樣，PHP 就不必在每次執行時都編譯它。 這是操作碼緩存的工作。

在 PHP 5.5 之前，PHP 沒有捆綁操作碼緩存。 您必須自己在服務器上安裝它。 這是使用更新版本的 PHP 更好的另一個原因。

切換到下一代編譯器

您可以做的最後一件事是切換到兩個下一代編譯器之一：Facebook 的 HHVM 或 PHP 7，最新版本的 PHP。 （為什麼選擇 PHP 7？說來話長。）

Facebook 和 PHP 團隊從頭開始構建了這兩個編譯器。 他們想利用更現代的編譯策略。 HHVM 使用即時編譯，而 PHP 7 使用提前編譯。 兩者都比優秀的 PHP 5 提供了令人難以置信的性能改進。

HHVM 是幾年前第一個出現的。 許多頂級主機都使用它取得了很大的成功，將其作為主要的 PHP 編譯器。

不過，值得強調的是，HHVM 不是官方的 PHP 編譯器。 它不是 100% 與 PHP 兼容。 原因是 HHVM 不僅僅是為了支持 PHP 而設計的。 它也是 Facebook 的 Hack 編程語言的編譯器。

PHP 7 是官方的 PHP 編譯器。 它已經很久沒有出現了。 PHP 團隊於 2015 年 12 月發布了它。這並沒有阻止一些 WordPress 託管公司已經支持它。

好消息是 WordPress 本身 100% 兼容這兩種編譯器！ 壞消息是，並非所有插件和主題都是如此，因為 WordPress 的最低 PHP 版本仍然是 5.2。

沒有什麼會迫使作者讓他們的插件或主題與這些編譯器一起工作。 所以，你不能全力以赴。 您的堆棧應始終回退到 PHP 5。

查詢-結果循環

此時，PHP 運行時正在遍歷所有 WordPress PHP 文件並執行它們。 但是，這些 WordPress PHP 文件不包含任何數據。 它們僅包含 WordPress 代碼。

問題是 WordPress 將其所有數據存儲在 MySQL 數據庫中。 因此，要獲得它，PHP 運行時需要查詢該數據庫。 MySQL 服務器返回該查詢的結果，然後 PHP 運行時繼續執行 WordPress PHP 文件……嗯，也就是說，直到它再次需要數據。

這種來回可能會發生幾十次到幾百次。 （如果是後者，您可能想與您的開發人員交談！）這就是為什麼它是一個主要瓶頸。

優化查詢-結果週期

這裡的優化目標是通過 PHP 加快 WordPress 文件的執行時間。 這就是數據庫查詢有問題的地方。 它們往往比僅僅運行普通的 PHP 代碼需要更多的時間（除非你的代碼正在做一些令人髮指的事情）。

解決此問題的明顯方法是減少 WordPress 需要執行的查詢數量。 這總是值得的！ 但這不是現代 WordPress 服務器堆棧可以提供的幫助。

我們可能無法減少 WordPress 的查詢數量，但我們也並非沒有選擇。 堆棧仍然有兩種方法可以幫助我們優化查詢結果週期。 它可以首先減少對數據庫的查詢次數。 對於那些進入數據庫的查詢，它可以減少運行它們所需的時間。

這兩個選項都是為了做同樣的事情：讓 PHP 盡可能少地等待來自數據庫的結果，這將使 WordPress 本身更快。

查詢-結果循環的堆棧元素

讓我們看看查詢結果循環中涉及的不同堆棧元素。 堆棧的這一部分不太複雜。 但它仍然涉及不止一個組件——即 MySQL 數據庫服務器和對象緩存。

MySQL 數據庫服務器

幾年前，MySQL 數據庫服務器對每個人來說都意味著同樣的事情。 這是一台安裝了 MySQL 服務器的服務器。 但近年來情況發生了很大變化。

各個團體對甲骨文管理 MySQL 項目的方式不滿意。 因此，每個小組都對其進行了分叉並創建了自己的版本，您可以改為“加入”。 結果是現在有幾個 MySQL 數據庫服務器。

新的“官方” MySQL 服務器是 MariaDB 服務器。 它是社區開發的 MySQL 服務器版本。 社區計劃保持與 MySQL 服務器項目的完全兼容性。

MySQL 的另一個流行替代品是 Percona 服務器。 與 MariaDB 不同，Percona 更像是 MySQL 的一個分支。 它的開發者並不反對 MySQL 項目本身。 他們只想專注於提高 MySQL 的性能。 MariaDB 團隊後來將其中一些性能改進合併到 MariaDB 項目中。

在一天結束時，您可以選擇您喜歡的那個。 Percona 服務器和 MariaDB 服務器之間的性能沒有差異（無論如何對我們大多數人來說）。 它們的性能都比 MySQL 好。 然而，Percona 確實與 Oracle 項目保持了更密切的兼容性。

影響性能的是 WordPress 數據庫使用的存儲引擎。 存儲引擎控制數據庫服務器如何管理它存儲的數據。 您還可以為每個數據庫表設置不同的存儲引擎； 您不必為整個數據庫使用相同的數據庫。

數據庫服務器有多個存儲引擎。 我們不會查看所有這些。 我們只對兩個感興趣：InnoDB 和 MyISAM。

默認情況下，WordPress 使用默認的 MySQL 數據庫引擎。 在 MySQL 5.5 之前，該引擎是 MyISAM。 如果您運行一個小型 WordPress 網站，那麼 MyISAM 就可以了。 一旦網站規模擴大，MyISAM 就會遇到性能問題。 那時，InnoDB 是數據庫引擎的唯一選擇。

InnoDB 的唯一問題是它需要進行一些調整才能發揮最佳性能。 如果您正在運行大型數據庫服務器，則可能需要進行一些調整。 對我們來說幸運的是，有一個工具可以幫助解決這個問題。

MySQLTuner 是一個分析數據庫服務器的小腳本。 它將生成報告並為您提供調整建議。

對象緩存

優化查詢結果週期的工作首當其衝的是對象緩存。 對象緩存的工作是存儲獲取或生成耗時的數據。 正如您可能猜到的那樣，數據庫查詢是一個完美的候選者。

WordPress 大量使用對象緩存。 假設您使用get_option從數據庫中獲取選項。 WordPress 只會在數據庫中查詢該選項一次。 下次有人需要它時，它不會再次查詢它。

相反，WordPress 將從對象緩存中獲取查詢結果。 這是 WordPress 為減少需要進行的數據庫查詢而採取的主動步驟。 但這不是一個萬無一失的解決方案。

雖然 WordPress 會盡力利用對象緩存，但插件或主題並非必須如此。 如果一個插件或主題進行了大量的數據庫查詢並且沒有緩存結果，則堆棧對此無能為力。

在這種情況下，大多數數據庫查詢將來自 WordPress 本身。 因此，您將從 WordPress 對對象緩存的內置使用中獲得極大的幫助。 這就是為什麼它是現代 WordPress 服務器堆棧的重要元素。

現在，對象緩存的一個問題是它不會默認保存它存儲的數據。 它只是在 PHP 執行所有 WordPress 文件時將數據存儲在內存中。 但是一旦 PHP 進程終止，它存儲在內存中的所有數據都會被清除。

這一點都不理想。 對象緩存可以長時間保持有效，因此您不想將其限制為單個請求。 解決方案是使用持久對象緩存。

持久對象緩存通常以插件的形式出現。 該插件將利用object-cache.php插件來完成其工作。 這個插件允許插件作者更改對象緩存的默認行為。

然後插件將對象緩存連接到持久數據存儲。 他們通過替換默認對象緩存的獲取和保存功能來做到這一點。 對象緩存不是將數據保存和獲取到內存，而是從該存儲中進行。

持久對象緩存插件

如今，有兩種流行的用於持久對象緩存的數據存儲選項：

• 內存緩存（插件）
• Redis（插件）

這兩個數據存儲都使用 RAM 進行存儲，這使得它們快如閃電。 事實上，它們的性能與默認對象緩存的性能相當。

唯一的問題是它們沒有預裝在服務器上。 他們的 PHP 擴展也沒有（Redis 是可選的）。 您需要先安裝一個，然後才能使用相應的 WordPress 插件。

你應該安裝哪一個？ 實際上，對於對象緩存，兩者之間沒有太大區別。 過去，流行的選項是 Memcached。 在過去的幾年裡，這種情況發生了變化。 Redis 添加了許多特性，使其成為對象緩存的首選。

獲得您自己的現代 WordPress 服務器

那麼，如何獲得自己的服務器呢？ 顯而易見的方法是從頂級 WordPress 託管公司獲得一個。 這些公司希望保持在 WordPress 託管業務的最前沿，這促使他們採用最新的突破和技術。

但是，如果您想要一個而不破壞銀行怎麼辦？ 任何願意自己動手並為託管支付更少費用的人都可以使用一些工具。 讓我們看看他們。

WordPress 的 DebOps

DebOps for WordPress 是我為幫助任何人構建現代 WordPress 服務器而構建的工具。 它的使命是讓社區中的任何人都可以使用現代 WordPress 服務器堆棧。 這就是為什麼我試圖讓它盡可能易於使用。 您不需要任何系統管理知識即可使用它。

DebOps for WordPress 使用以下內容配置服務器：

• HHVM（直到 PHP 7 成為官方 Linux 存儲庫）
• 瑪麗亞數據庫
• nginx
• 雷迪斯
• 漆

該工具不僅僅是使用最新技術配置服務器。 它還負責為您保護服務器。 這是人們在管理自己的服務器時經常忽略的事情。

易引擎

EasyEngine 是一個命令行工具，旨在幫助您在服務器上設置 WordPress 網站。 EasyEngine 的偉大之處在於它的靈活性：您可以使用它來設置我們迄今為止研究過的幾乎任何服務器技術組合。

例如，它允許您使用 HHVM 或 PHP 7 設置服務器。它允許您在 Memcached 和 Redis 之間選擇用於持久數據存儲。 它允許您安裝管理員工具，例如 phpMyAdmin。

在創建 WordPress 網站時，它還提供了大量選項。 你可以告訴它使用插件或 nginx 設置一個帶有 HTTP 緩存的網站。 所有這些靈活性是 EasyEngine 如此受歡迎的工具的原因。

格子

Trellis 是由 Roots 開發的工具。 與 DebOps 一樣，它使用一組特定的服務器技術配置服務器：

• 瑪麗亞數據庫
• 內存緩存
• nginx
• nginx HTTP 緩存（可選）
• PHP 7

關於 Trellis 的一件事是它與 Bedrock 的關係，Bedrock 是 Roots 構建的另一種工具。 Bedrock 是圍繞“十二要素應用程序”原則構建 WordPress 網站的樣板。

Roots 團隊創建了 Trellis，以使人們能夠配置使用基岩結構 WordPress 網站的服務器。 您不能在正常的 WordPress 安裝中使用它，因此請記住這一點。

時代變了

如您所見，如今 WordPress 服務器有更多的移動部件！ 但這並不一定是絕望的原因。 它並不像看起來那麼糟糕，因為您並不總是需要使用所有部件。

這就是為什麼本文的大部分內容都在討論這些部分如何協同工作。 關鍵是讓你能夠做出自己的決定。 使用這些知識來決定您需要使用哪些部件以及何時使用。 這樣，您也將擁有一個快速的 WordPress 網站。