在提供快速加載的 WordPress 網站方面，快取至關重要。一個經過優化的頁面快取可以顯著提高訪問者的加載時間，並減少伺服器負載。這是一個雙贏的局面！然而，並非所有的頁面快取解決方案都是相等的。在 WordPress.org 上簡單搜索“快取”插件就會返回數千個結果。但是，當涉及到為您的網站提供頁面快取時，WordPress 快取插件並非唯一選擇。事實上，WordPress 快取插件通常無法像基於伺服器的解決方案（如 Varnish 或 Nginx FastCGI）那樣表現出色。

在本文中，我們將比較 Varnish 與 Nginx FastCGI 快取，看看哪個能夠脫穎而出。在此過程中，我們還將對未啟用快取的 WordPress 進行基準測試，並為了保險起見，將 WordPress 快取插件加入混合。我選擇了 Simple Cache，因為顧名思義，它很容易設置。

如果您跟隨了我們的在 Ubuntu 22.04 上安裝 WordPress 的系列文章，您可能對這個技術棧很熟悉，但這裡有個圖表供您參考：

Varnish 與 Nginx 的快取比較

在開始基準測試之前，讓我們回顧一下我們將要比較的每項技術以及為什麼我們要用它們進行快取。

Varnish Cache 是一個開源的 Web 前端加速器或快取反向代理。它安裝在處理 HTTP 請求的 Web 伺服器前面，並設置為快取響應內容。它還被設計為非常快速的，根據官方文檔，其內容傳遞速度可以根據架構提高 300 到 1000 倍。

Nginx 的主要功能是充當 Web 伺服器。它可以處理反向代理，快取，媒體流以及充當負

載均衡器等。多年來，Nginx 不斷發展，從一個簡單的 Web 伺服器演變為設計用於最大穩定性和性能。今天，我們將配置我們的 Nginx 作為一個將請求傳遞給 PHP-FPM 的 Web 伺服器。FastCGI（Nginx 和 PHP-FPM 之間用於通信的協議）快取將被配置為將 PHP-FPM 的響應快取為靜態 HTML 文件，Nginx 可以在後續請求中直接提供服務。

如您所見，它們在功能上並不完全相同。Varnish 專門針對快取進行設計，而 Nginx 是一個具有內置快取功能的 Web 伺服器。儘管 Nginx 不直接依賴其他任何東西，但 Varnish 確實需要像 Apache 或 Nginx 這樣的 Web 伺服器才能運行。

我們如何對快取進行基準測試？

ApacheBench 是由 Apache 軟件基金會設計的命令行界面工具，最初是為了測試 Apache 的性能而創建的。

本文中的所有測試都將使用相同的選項，除了對未配置快取的 WordPress 進行測試。這樣做的原因是因為將這麼多並發請求直接發送到 PHP 和 MySQL 將只會增加平均響應時間，這對 PHP 的性能並不公平。

arduinoCopy code

ab -n 10000 -c 100 https://siteunderload.com/

這將模擬 10,000 個請求，並發請求為 100。也就是說，ApacheBench 將一次發送 100 個請求的批次，共發送 10,000 個請求。對於未經快取的版本，我將使用 20 個請求的並發數。

運行 ApacheBench 將輸出類似於以下的結果：

ApacheBench CLI 輸出

在本文中，我們主要關注 每秒請求數 和 連接時間。我們將對每個測試進行 10 次，並使用平均值進行比較。

我們還只會對 HTTPS 進行基準測試，因

為這個時候每個網站都應該使用它，無論是性能還是安全性。如今，由於 Let’s Encrypt 的普及，HTTPS 幾乎無處不在，這是一件好事！

伺服器堆疊

所有基準測試都將使用相同的伺服器堆疊，其中包括以下軟件：

DigitalOcean 2GB（每月 10 美元）
Ubuntu 20.04
PHP 7.4.14
Nginx 1.18.0
MariaDB 10.4.17
Varnish 6.2.1
WordPress 5.6，Twenty Twenty-One

我們已經使用 DigitalOcean 一段時間了，但如果您有興趣，我們還對比了一下找到最適合 WordPress 的伺服器提供商。

在不需要當前一組基準測試的情況下，Varnish 將完全被禁用。由於 Varnish 無法這樣做，Nginx 將用於終止 HTTPS 請求。這將導致以下配置：

Nginx:443 > Varnish:80 > Nginx:8080

注意，我們的 Nginx 作為代理伺服器終止 HTTPS。有其他代理可以執行此功能，但我選擇 Nginx 是為了將移動部件數量降至最低。

我們將對四種不同情況進行測試：

WordPress – 無快取
Simple Cache – 通過 WordPress 插件進行快取
FastCGI Cache – Nginx
Varnish – 使用 Nginx 進行 HTTPS 終止的 Varnish

每秒請求數

不出所料，未經快取的 WordPress 表現不佳，這是由於數據庫伺服器造成的瓶頸。通過啟用頁面快取，簡單地將數據庫伺服器從方程式中去除，可以使請求量幾乎增加 10 倍。Varnish 通過確保請求不必由 PHP 處理進一步改善了性能。然而，由於 Nginx HTTPS 終止的額外步驟，Varnish 在原始吞吐量（每秒請求數）方面遠遠落後於 Nginx。僅使用 Nginx 可以實現最佳吞吐量。

顯示未

經快取的 WordPress 每秒請求數最少的圖表平均響應時間

每秒請求數量較高並不意味著請求完成速度較慢，這就是為什麼要同時測量響應時間的原因。平均響應時間是請求完成所需的總時間。

當伺服器處於高負載時，平均響應時間通常會增加。這是因為伺服器通常只能處理有限數量的並發連接，這通常是由於 CPU 或內存瓶頸。當超過此數量時，所有其他連接都將排隊並在資源可用時進行處理。如果這些請求排隊等待時間過長，它們將超時。

一般而言，請求生命週期中的移動部件越少，平均響應時間就越低。這就是為什麼 Nginx FastCGI 快取性能如此出色，因為它只需要從磁盤（由於 Linux 頁面快取，很可能已經在內存中快取）提供靜態文件。沒有快取的 WordPress 網站的請求將觸及 Nginx、PHP 和後端的數據庫伺服器。使用快取插件，您只需觸及 Nginx 和 PHP。通過 Nginx FastCGI Cache 或 Varnish 進行頁面快取，您只需觸及 Nginx 或 Varnish。

顯示未經快取的 WordPress 平均響應時間最長的圖表最後的想法

在比較 Varnish 與 Nginx FastCGI 快取時，Nginx 在高性能方面是明確的優勝者。它不僅能夠處理更多的每秒請求，而且平均每個請求快了 59 毫秒。

然而，性能並非唯一的考慮因素，配置的簡單程度呢？通常，WordPress 插件在這方面表現最好，不包括 W3 Total Cache，其控制面板很難使用。雖然 Nginx FastCGI 快取相對容易配置，但它需要伺服器上的 sudo 權限。另一方面，由於需要 HTTPS 終止，Varnish 設置要複雜得多。

如果 Varnish 速度不是最快的解決方案，並且設置最為困難，為什麼還要選擇它呢？ Varnish 仍然是通過 Varnish 配置語言（VCL）處理更複雜的緩存失效規則的最佳選擇。然而，除非您正在設置需要複雜緩存結構的 Web 應用程序，如電子商務平台，或者服務許多與緩存混合的動態內容，否則通常不需要。

在 Tenten，我們選擇更長的緩存持續時間（7 天），並在內容更新時清除整個緩存。我們發現這種解決方案比嘗試確定應從緩存中清除哪個 Web 頁面或哪些頁面要簡單得多，這會因文章存檔和分頁而變得很快複雜。

綜合考慮所有因素，Nginx FastCGI 快取仍然是我們首選的解決方案，這就是為什麼我們幾年前就從我們的伺服器上移除了 Varnish，現在僅依賴 Nginx。這也是我們通過 Tenten 配置的每台伺服器的設置方式。