Apache vs NGINX - 誰在性能方面獲勝？

已發表: 2022-04-02

Apache 與 NGINX 是最熱門的爭論之一（自 NGINX 發布以來），因為它們都是世界上最常見的 Web 服務器之一，其次是 LiteSpeed 和 OpenLiteSpeed。

Apache 和 NGINX 為全球近 60% 的網站提供支持。 Apache 與 NGINX 在性能和功能方面相似。 另一方面，它們的架構、安全性和性能都是不同的。

在這兩個服務器之間進行選擇可能很困難，因為它們都很出色。 因為每個 Web 服務器都有自己的優點和缺點，所以盡可能選擇最佳選項至關重要。

您還可以在此處查看 openlitespeed 與 nginx 的辯論。

目錄

Apache 與 NGINX 速度比較

在深入研究 Apache 與 NGINX 的爭論之前。 我們先做一個簡單的速度測試，我們將在下面的場景中進行測試。

  • 讓我們測試一個 5 KBytes 的小靜態文件
  • 1MB大小的靜態文件
  • 測試一個簡單的 PHP Hello World 應用程序
  • 為 WordPress 對 Apache 和 NGINX 進行基準測試

我們使用相同的程序來測試 openlitespeed 與 nginx。 OpenLiteSpeed 確實是 NGINX 的絕佳替代品，因為它也支持基本的.htaccess重寫規則，因此您可以輕鬆地從 Apache 遷移到 OpenLiteSpeed。

讓我們測試一個 5 KBytes 的小靜態文件

最終判決：兩台服務器的小靜態文件執行相同。

阿帕奇

阿帕奇與 NGINX

NGINX

1MB大小的靜態文件

最終判決：NGINX 顯然贏得了大型靜態文件。

阿帕奇

NGINX

測試一個簡單的 PHP Hello World 應用程序

最終判決：兩台服務器的性能與 hello world php 應用程序相同。

阿帕奇

NGINX

為 WordPress 對 Apache 和 NGINX 進行基準測試

最終判決：NGINX 顯然贏得了 WordPress 網站。 您可以使用本指南來加快您的 WooCommerce 商店

阿帕奇

NGINX

測試結果 - Apache vs NGINX

正如我們在測試中看到的，NGINX 在速度方面相對優於 Apache。 結果是：

1.測試一個5KBytes的小靜態文件：

在這個測試中，我們看到 Apache 和 NGINX 都給出了相對相同的結果。

2. 測試一個大小為 1MB 的大型靜態文件：

在本次測試中，我們看到 NGINX 的速度比 Apache 快多了。 NGINX 的平均響應時間要短得多。

3. 測試一個簡單的 PHP Hello World 應用程序

在這個測試中，我們看到 Apache 和 NGINX 都給出了相對相同的結果。

4. 為 WordPress 測試 Apache 與 NGINX

在這個測試中，我們看到 NGINX 的平均響應時間比 Apache 短得多，因此它的速度比 NGINX 更快。

阿帕奇

有一個開發人員社區將 Apache 維護為開源 Web 服務器。 它使用流程驅動的架構，為每個連接請求創建一個新線程。
此外，Apache 提供了多種可用於增加 Web 服務器功能的模塊。 Apache 快速、可靠、安全且高度可定制，通過使用擴展和模塊來滿足不同環境的需求。

連接處理架構

Apache 有許多控制如何處理客戶端請求的多處理模塊（Apache 稱為 MPM）。 從本質上講，這使管理員能夠快速切換連接處理架構。

  • mpm-Prefor：這個多處理模塊 (MPM) 實現了一個非線程的預分叉 Web 服務器。 每個服務器進程都可以響應傳入的請求，並且服務器池的大小由父進程管理。 它適用於需要避免線程以使用非線程安全庫的站點。 它也是隔離每個請求的最佳 MPM，確保一個問題不會影響其他請求。
  • mpm-worker：一個混合多進程多線程服務器由這個多處理模塊（MPM）實現。 與基於進程的服務器相比，它可以使用更少的系統資源來處理大量請求，因為它使用線程來傳遞請求。 通過保持許多進程可用，每個進程都有許多線程，它保留了基於進程的服務器的大部分穩定性。
  • mpm-event：事件多處理模塊 (MPM) 旨在通過將某些處理委託給偵聽器線程來允許同時處理多個請求，從而釋放工作線程以服務新請求。
    Apache 具有靈活的設計，允許您從各種連接和請求處理算法中進行選擇。 隨著互聯網格局的變化，所呈現的選擇主要是服務器發展和並發需求增加的產物。

靜態與動態內容

Apache 服務器可以使用其標準的基於文件的機制來處理靜態內容。 上述 MPM 方法主要負責這些程序的執行。

Apache 可以通過在其每個工作實例中包含特定於語言的處理器來額外處理動態內容。 這使它能夠在不使用 Web 服務器內的外部組件的情況下執行動態內容。 動態可加載模塊可用於啟用這些動態處理器。

因為 Apache 可以在內部處理動態內容，動態處理配置通常更容易。 如果內容需求發生變化，模塊可以很容易地被替換，並且通信不需要與額外的軟件協調。

分佈式與集中式配置

通過分析和解釋內容文件夾本身的隱藏文件中的指令，Apache 添加了一個選項以允許在每個目錄的基礎上進行進一步配置。 .htaccess文件是這些文件的名稱。

因為這些文件位於內容文件夾中，Apache 在請求文件的路徑的每個組件中查找.htaccess文件並應用在那裡找到的指令。 這有效地實現了分散式 Web 服務器設置，這通常用於 URL 重寫、訪問限制、授權和身份驗證，甚至緩存策略。

雖然前面的所有示例都可以在主 Apache 配置文件中設置，但.htaccess文件提供了許多優點。 首先，因為每次在請求路徑中遇到它們時都會對其進行評估，因此無需重新加載服務器即可實現它們。 其次，它使非特權用戶能夠控制他們自己的 Web 內容的特定部分，而無需授予他們對配置文件的完全權限。

某些 Web 軟件（例如內容管理系統）現在可以輕鬆自定義其環境，而無需訪問中央配置文件。 共享主機提供商利用它來控制核心設置，同時為客戶提供對其特定目錄的訪問權限。

文件與基於 URI 的解釋

Apache 可以將請求解釋為物理文件系統資源或需要更抽象評估的 URI 目標。 一般來說，Apache 使用<Directory>或<File>塊作為前者，而<Location>塊用於更抽象的資源。

因為 Apache 是從頭開始構建為 Web 服務器的，所以默認情況下它將請求解釋為文件系統資源。 要查找實際文件，它從文檔根目錄開始，並在主機和端口號之後附加請求部分。 在 Web 上，文件系統層次結構本質上由可用的文檔樹表示。

當請求與底層文件系統不匹配時，Apache 提供了許多選項。 例如，別名指令可用於映射到不同的位置。 使用<Location>塊而不是文件系統允許您直接使用 URI。 正則表達式變體也可用於在文件系統中更靈活地應用配置。

儘管 Apache 可以在底層文件系統和 webspace 上工作，但它更喜歡使用文件系統技術。 一些設計決策反映了這一點，例如使用 .htaccess 文件進行每個目錄的設置。

模數

Apache 中的模塊系統允許您在服務器運行時動態加載和卸載模塊以滿足您的需求。 Apache 核心始終存在，但可以啟用或禁用模塊、添加或刪除功能以及連接到主服務器。

這個特性被 Apache 用於廣泛的任務。 由於平台的成熟，它帶有一個龐大的模塊庫。 例如，Mod php 將 PHP 解釋器嵌入到每個正在運行的 worker 中，並可用於更改服務器的部分基本功能。

另一方面，模塊不僅僅處理動態內容。 他們可以重寫 URL、驗證客戶端、加固服務器、記錄、緩存、壓縮、代理、限制速率和加密數據，以及其他功能。 它們可以在不增加大量工作的情況下提供增強的功能。

支持、兼容性、生態系統和文檔

因為 Apache 已經存在了這麼久，所以對它有很多支持。 對於涉及將 Apache 連接到其他軟件的核心服務器和基於任務的情況，可以訪問大量的第一方和第三方文檔庫。

除了文檔之外，許多工具和 Web 項目還包含在 Apache 環境中引導自身的工具。 這可能在項目本身或您的發行版的打包團隊維護的包中提供。

由於其市場份額和可用時間； Apache 通常會從第三方項目中獲得更多支持。 管理員也更有可能使用 Apache，這不僅是因為它的廣泛使用，還因為許多人的職業生涯都是在共享主機環境中開始的，由於.htaccess分佈式管理功能，Apache 實際上僅在其中使用。

Apache 與 NGINX 的優勢

許多網站管理員和開發人員更喜歡 Apache 而不是 NGINX，因為它更老。 它與 Windows、Unix 和 Linux 操作系統兼容。

• 對於提供動態素材，這是一個出色的性能。
• 動態加載和卸載模塊。
• 提供每個目錄的.htaccess 文件，可用於否決系統範圍的設置。
• 出色的支持和文檔。
• 該模型使用每個進程一個連接的方法。
• 它包括mod_evasive 和mod_security 模塊，增加了額外的安全層。

Apache 與 NGINX 的缺點

• 無法同時處理大量請求。
• 與 NGINX 相比，顯示靜態內容需要更長的時間。
• 它提供了廣泛的設置和管理功能。 因此，它不適合新手。
• 具有大量流量的網站存在性能問題。

NGINX

為了克服“C10k”問題，俄羅斯程序員 Igor Sysoev 發明了 NGINX。 Igor 實現了他的目標：NGINX 可以輕鬆管理超過 10,000 個並發連接。 為了更好地處理新連接，NGINX 具有事件驅動和異步設計。 NGINX 是一個提供很多功能的 Web 服務器。 下面列出了其中的一些：

• HTTP 緩存和負載平衡器
• Apache 和其他網絡服務器的前端代理。
• HTTP、HTTPS、SMTP、POP3 和 IMAP 協議均由該反向代理服務器提供服務。

自發布以來，NGINX 因其低資源使用率和在低成本硬件上有效擴展的能力而越來越受歡迎。 NGINX 是一個 Web 服務器，專門用於快速提供靜態材料，旨在將動態請求轉發到更適合此類任務的軟件。

連接處理架構

NGINX 在 Apache 之後出現，對大規模站點將面臨的並發問題有了更好的理解。 NGINX 是使用異步、非阻塞、事件驅動的連接處理算法從頭開始構建的，以利用這些信息。

NGINX 生成工作進程，每個工作進程都能夠處理數万個連接。 工作進程通過開發一種定期檢查和處理事件的快速循環機制來實現這一點。 通過將實際工作與連接分離，每個工作人員只有在發生新事件時才能專注於連接。

每個worker的連接都放置在事件循環中，它們與其他連接共存。 事件在循環內異步處理，允許以非阻塞方式完成工作。 該鏈接在關閉後從循環中刪除。

得益於其連接處理方法，NGINX 可以用最少的資源擴展得非常遠。 由於服務器是單線程的，並且不會生成額外的進程來處理每個新連接，因此內存和 CPU 使用率保持相對恆定，即使服務器處於巨大壓力下也是如此。

靜態與動態內容

NGINX 沒有對動態內容處理的原生支持。 NGINX 必須將 PHP 和其他動態內容請求傳遞給外部處理器進行處理，然後等待返回的渲染內容。 然後可以將結果通知客戶。

對於管理員來說，這意味著 NGINX 和處理器之間的通信必須使用 NGINX 理解的協議之一（http、FastCGI、SCGI、uWSGI、memcache）進行配置。 這會使事情變得更複雜一些，尤其是在估計允許的連接數時，因為對處理器的每次調用都需要一個新的連接。

另一方面，這種策略提供了一些好處。 動態解釋器的開銷只存在於動態材料中，因為它不包含在工作進程中。 靜態內容可以以直接的方式發送，僅在必要時諮詢口譯員。 這對於 Apache 也是可能的，但它消除了上一節中提到的好處。

分佈式與集中式配置

NGINX 不理解.htaccess文件，也沒有辦法在主配置文件之外評估每個目錄的配置。 雖然不如 Apache 方法通用，但它有其自身的一組優點。

與目錄級設置的.htaccess方法相比，性能的提高是最顯著的增益。 對於每個請求，服務器將檢查每個父目錄中的這些文件，這些文件通向標準 Apache 設置中的請求文件，該設置允許在任何目錄中訪問.htaccess 。 如果此搜索出現一個或多個.htaccess文件，則必須讀取並處理它們。 NGINX 可以通過執行單個目錄查詢和通過不允許目錄覆蓋（假設文件在傳統目錄結構中找到）為每個請求讀取文件來更快地服務請求。

另一個好處是它是安全的。 分配目錄級配置訪問權限還將安全責任分散到各個用戶，這些用戶可能會或可能不會被信任以正確執行此操作。 通過確保管理員可以完全控制 Web 服務器，您可以避免在授予他人訪問權限時可能出現的幾個安全錯誤。

如果您擔心這些問題，請記住您可以在 Apache 中禁用.htaccess解釋。

文件 VS 基於 URI 的解釋

NGINX 被設計為作為 Web 服務器和代理服務器運行。 由於這兩個工作所需的架構，它主要與 URI 一起工作，在必要時轉換為文件系統。

這可以從某些情況下構建和處理 NGINX 配置文件的方式中看出。
NGINX 沒有辦法為文件系統目錄指定配置，因此它解析 URI。

例如，服務器和位置塊是 NGINX 最重要的配置塊。 服務器塊負責解釋請求的主機，而位置塊負責匹配主機和端口之後的 URI 部分。 該請求現在作為 URI 而不是文件系統位置進行處理。

對靜態文件的所有請求最終都必須映射到磁盤上的某個位置。 NGINX 選擇將首先處理請求的服務器和位置塊，然後將文檔根與 URI 結合起來，根據設置根據需要進行修改。

這可能看起來很相似，但是將請求主要解釋為 URI 而不是文件系統位置使 NGINX 更容易用作 Web、郵件和代理服務器。 NGINX 是通過定義它應該如何響應某些請求模式來設置的。 NGINX 在準備好發送請求之前不會檢查文件系統，這就是不支持.htaccess文件的原因。

模塊

NGINX 也有一個模塊系統，但是它與 Apache 的有很大不同。 NGINX 中的模塊不能動態加載，因此必須選擇它們並編譯到核心軟件中。
因此，NGINX 對許多用戶的適應性將大大降低。 對於那些不願在其發行版的標準打包方案之外維護自己構建的軟件的用戶來說尤其如此。 雖然大多數發行版的軟件包都包含最常用的模塊，但如果您需要非標準模塊，則必須自己從源代碼構建服務器。

另一方面，NGINX 模塊仍然非常有價值，因為它們允許您通過僅包含您想要使用的功能來準確指定您想要從服務器獲得的內容。 一些用戶可能還認為這種方法更安全，因為無法將任意組件連接到服務器。 如果您的服務器曾經處於可以想像的情況，那麼幾乎可以肯定它已經受到損害。

NGINX 模塊中的許多功能與 Apache 模塊中的功能相同。 代理支持、壓縮、速率限制、日誌記錄、重寫、地理定位、身份驗證、加密、流媒體和郵件功能都可以通過 NGINX 模塊獲得。

支持、兼容性、生態系統和文檔

由於 NGINX 的高性能，隨著越來越多的人使用它，NGINX 越來越受歡迎，但它在某些關鍵領域仍有一些工作要做。

因為大部分早期的開發和文檔都是俄語的，過去很難找到 NGINX 的大量英文文檔。 隨著對該項目的興趣增加，文檔已經充實，並且目前在 NGINX 站點上和通過第三方提供了大量的管理資源。

第三方應用程序的支持和文檔變得越來越廣泛，並且包維護者開始提供在某些情況下自動配置 Apache 和 NGINX 的選項。 配置 NGINX 以與其他軟件一起操作通常很簡單，即使沒有支持，只要記錄項目的需求（權限、標題等）。

NGINX 的優勢

NGINX Web 服務器簡單、輕量、快速。 專為高流量網站設計。

• 使用事件驅動的非阻塞架構，使用較少的 CPU 和內存。
• 它包括大量針對靜態內容的優化和服務選項。 因此，它提供靜態內容的速度比 Apache 快 2.5 倍，並且使用的內存更少。
• 它在多處理器系統中表現出色。
• 內置配置選項可防止 DDoS 攻擊。

NGINX的缺點

• 無法原生處理動態內容。
• 可用的模塊數量較少。
• 支持Linux 和Unix 操作系統，但Windows 支持受到限制。
• NGINX 不支持 Apache 支持的.htaccess文件。
• 缺乏日誌監控軟件——只需將日誌保存到必須手動導航的文件中。

一起使用 Apache 和 NGINX

在查看了 Apache 和 NGINX 的優缺點之後，您應該能夠確定哪種服務器更適合您的需求。 然而，許多用戶發現同時使用兩台服務器可以讓他們利用每台服務器的優勢。

本次合作的標準配置是使用 NGINX 作為 Apache 前面的反向代理。 這將使 NGINX 能夠處理所有客戶端請求。 這利用了 NGINX 的快速處理速度和一次管理大量連接的能力。

這些文件將快速直接地提供給客戶端以獲取 NGINX 擅長的靜態內容。 NGINX 將對動態內容（例如 PHP 腳本）的請求代理到 Apache，Apache 將處理結果並提供呈現的頁面。 然後可以通過 NGINX 將材料返回給客戶端。

對於許多用戶來說，這種設計效果很好，因為它允許 NGINX 充當分揀機。 它將處理它可以處理的任何請求並傳遞那些它不知道如何處理的請求。 我們可以通過減少要求 Apache 服務器處理的請求數量來減少 Apache 進程或線程被佔用時發生的一些阻塞。

您可以通過根據需要添加更多後端服務器來擴展這種安排。 NGINX 可以簡單地設置為將請求轉發到服務器池，從而提高配置的容錯性和性能。

何時使用 Apache 與 NGINX？

如本文所述，Apache 和 NGINX 都是功能強大、適應性強且全方位的優秀 Web 服務器。 對於高流量的網站，Apache 最適合提供動態素材，而 NGINX 最適合提供靜態內容或媒體流。 就這麼簡單：

什麼時候可以使用 Apache

• 如果您使用共享託管計劃。
• 如果您喜歡一個擁有大量資源的樂於助人的社區，那麼這裡就是您的理想去處。
• Apache 在 Web 開發人員中很受歡迎，因為它設置簡單。

什麼時候可以使用 NGINX

• 如果您有 VPS 或專用服務器。
• 您是擁有大量靜態內容的熱門網站的所有者。
• 如果您想管理傳入流量並將其分發到速度較慢的上游服務器。

Apache 與 NGINX：2022 年你應該為你的服務器選擇哪一個？

您的託管公司提供的任何一個都是您應該使用的。 在許多情況下，您將別無選擇。 許多網絡提供商都遵循相同的策略，如果您在 Apache 與 NGINX 之間做出決定，您應該遵循這些策略：

• 如果您想託管需要不斷設置的服務器，或者如果您想為用戶提供配置選項，Apache 是一個不錯的選擇。
• 另一方面，如果您想要超快的性能、堅如磐石的安全性以及管理配置而不是您的用戶的能力，那麼 NGINX 是您的最佳選擇。

由於其基礎架構，Apache 在性能方面可以佔用更多 RAM。 在高流量的情況下，NGINX 會表現得更好，尤其是在需要管理大量靜態素材的情況下。

如果您依賴緩存來存儲和提供內容，NGINX 可能是理想的解決方案。 請記住，NGINX 不能提供動態素材； 因此，您的性能將受到服務器使用的代理的有效性的影響。

結論

如您所見，Apache 和 NGINX 功能強大、適應性強且有能力。 評估您的個人需求並測試您希望看到的模式是為您選擇合適服務器的主要標準。

在這些項目中，原始性能、功能和實施每個項目所需的時間存在顯著差異。 然而，它們通常是一系列不容忽視的權衡的結果。 最後但同樣重要的是，沒有萬能的 Web 服務器，因此請選擇適合您需求的選項。