摘要：服務(wù)器市場份額。子進程負(fù)責(zé)創(chuàng)建由指令設(shè)置的服務(wù)器線程，同時還負(fù)責(zé)監(jiān)聽接收到的請求，并將請求分發(fā)給處理線程。在版本引入了模塊，這個模塊基于模塊創(chuàng)建的，并加入了獨立的監(jiān)聽線程來管理請求處理完成后的休眠的連接?；谑录姆?wù)器完勝。

譯文首發(fā)于 Apache 與 Nginx 性能對比：Web 服務(wù)器優(yōu)化技術(shù)，轉(zhuǎn)載請注明出處。

多年前 Apache 基金會 Web 服務(wù)器 簡稱「Apache」,由于使用者眾多幾乎等同于「Web 服務(wù)器」。httpd（含義是簡單的 http 進程）是它在 Linux 系統(tǒng)上的守護進程 - 同時它被預(yù)裝到主流的 Linux 發(fā)行版中。

Apache 初版于 1995 年發(fā)布，它在 維基百科 描述如下，「它在萬維網(wǎng)（WWW）發(fā)展初期發(fā)揮了至關(guān)重要的作用」。從 W3techs 統(tǒng)計結(jié)果來看，它依然是最常用的 Web 服務(wù)器軟件。不過，依據(jù) 過去十年的發(fā)展趨勢 和 與其它服務(wù)器解決方案比較 的報告的結(jié)果來分析，不難發(fā)現(xiàn)它的市場份額正在逐年下降。盡管，Netcraft 和 Builtwith 這兩家提供的報告略有不同，但不得不承認(rèn) Apache 市場份額的縮減與 Nginx 服務(wù)器份額在增長這一事實。

Nginx 讀作「engine x」- 由 Igor Sysoev 在 2004 年發(fā)布，最初的愿景就是取代 Apache 在 Web 服務(wù)器市場上的領(lǐng)導(dǎo)地位。在 Nginx 的網(wǎng)站上有一篇值得一讀的 文章，對兩款服務(wù)器進行了比較。一開始 Nginx 只是作為 Apache 某些功能的補充，主要提供靜態(tài)文件服務(wù)支持。得益于它積極的擴展在 Web 服務(wù)器領(lǐng)域相關(guān)功能的全方位支持，這使得它能夠穩(wěn)步增長。

Nginx 通常被用作 反向代理、負(fù)載均衡 和 HTTP 緩存 服務(wù)器。CDN 和 視頻提供商使用它來構(gòu)將性能強勁的內(nèi)容分發(fā)系統(tǒng)（CDN: content delivery system）。

Apache 在其不短的發(fā)展歷程中，提供了許多 有用的模塊。眾所周知管理 Apache 服務(wù)器對開發(fā)者極其友好。動態(tài)模塊加載 能夠在無需重新編譯主服務(wù)器文件的基礎(chǔ)上，將模塊編譯并添加到 Apache 擴展中。通常，這些模塊位于 Linux 發(fā)行版?zhèn)}庫中，在使用系統(tǒng)包管理器安裝后，便可以通過諸如 a2enmod 這樣的命令，將其添加到擴展中。Nginx 服務(wù)器到目前為止，依然無法靈活的實現(xiàn)動態(tài)添加模塊的功能。當(dāng)我們閱讀 如何在 Nginx 服務(wù)器設(shè)置 HTTP/2 指南 時，你就會發(fā)現(xiàn)模塊需要在構(gòu)建 Nginx 時，通過設(shè)置參數(shù)選項，才能將其添加進 Nginx 服務(wù)器。

另一個讓 Apache 保持住市場份額的功臣就是 .htaccess 重寫文件。它就像 Apache 服務(wù)器的萬金油一樣，使其成為共享托管技術(shù)的首選方案，因為 .htaccess 重寫支持在目錄級別上控制服務(wù)器配置。在 Apache 服務(wù)器上的每個目錄都能夠配置自己的 .htaccess 文件。

在這點上 Nginx 不僅沒有相應(yīng)的解決方案，而且由于重寫性能低、命中率不高而 不被推薦。

1995–2005 Web 服務(wù)器市場份額。 數(shù)據(jù)由 Netcraft 提供

LiteSpeed 即 LSWS 是 Web 服務(wù)器市場的另一個競爭者，它兼具 Apache 的靈活性與 Nginx 的性能。支持 Apache 風(fēng)格的 .htaccess、mode_security 和 mode_rewrite 模塊，另外它還支持共享設(shè)置。它的設(shè)計初衷是替代 Apache 服務(wù)器，并且能夠和 cPanel 和 Plesk 組合使用。從 2015 年開始提供 HTTP/2 支持。

LiteSpeed 有三個版本，OpenLiteSpeed、LSWS 保準(zhǔn)版和 LSWS 企業(yè)版。標(biāo)準(zhǔn)版和企業(yè)版還提供了可選的 緩存解決方案，它可以和 Varnish 與 LSCache 一較長短。LSCache 是服務(wù)器內(nèi)置的緩存解決方案，通過 .htaccess 重寫規(guī)則配置進行控制。并且，它還提供了內(nèi)置預(yù)防 DDoS 攻擊的解決方案。這個功能同它的事件驅(qū)動架構(gòu)設(shè)計一起成為這款服務(wù)器的競爭力保障，不僅能夠滿足以 性能為導(dǎo)向的服務(wù)提供商需求，還能兼顧小型服務(wù)器或網(wǎng)站架設(shè)市場。

當(dāng)我們優(yōu)化系統(tǒng)時，我們無法忽視硬件配置。無論選擇哪種解決方案，我們都需要擁有足夠的 RAM，這點至關(guān)重要。當(dāng) Web 服務(wù)器進程或類似 PHP 解釋器程序無可用的 RAM 時，它們就會進行交換（swapping）即需要使用硬盤來補充 RAM 內(nèi)存的不足。這會導(dǎo)致每當(dāng)訪問這塊內(nèi)存區(qū)域時都會帶來訪問延遲。于是便引出了第二個優(yōu)化點 - 硬盤。使用 SSD 固態(tài)硬盤來構(gòu)建網(wǎng)站是提升性能的又一關(guān)鍵。此外，我們還應(yīng)考慮 CPU 可用性和服務(wù)器數(shù)據(jù)中心同目標(biāo)用戶的距離。

想要深入研究硬件優(yōu)化方法，可以查看 Dropbox 的好文。

htop 是一個監(jiān)控當(dāng)前服務(wù)器性能及每個進程詳細(xì)信息的實用工具，它能夠在 Linux、Unix 和 macOS 系統(tǒng)上運行，并為我們以不同顏色區(qū)分出不同的進程狀態(tài)。

其它的監(jiān)控工具如 New Relic，提供全套的監(jiān)控解決方案；Netdata 一款開源的監(jiān)控解決方案，兼具擴展性、細(xì)粒度指標(biāo)和可定制的 Web 儀表盤，適用于小型的 VPS 系統(tǒng)和網(wǎng)絡(luò)服務(wù)器的監(jiān)控。它可以通過郵件、Slack、pushbullet、Telegram 和 Twilio 等方式給任何應(yīng)用或系統(tǒng)進程發(fā)送警告消息。

Monit 是另一款開源的系統(tǒng)監(jiān)控工具，可以通過配置在重啟進程、重啟系統(tǒng)或任何我們關(guān)心事件時給我們的發(fā)送提示信息。

AB - Apache Benchmark - 是一款有 Apache 基金會提供的簡單的壓測工具，其它壓測工具還有 Siege。這篇文章 詳細(xì)講解了如何同時安裝這兩款工具，可以閱讀 這篇文章 學(xué)習(xí) AB 工具的高級使用技巧，如果需要研究 Siege 可以閱讀 此文。

如果你鐘愛 Web 應(yīng)用，可以使用 Locust 這款基于 Python 的測試工具，一樣可以很方便的對網(wǎng)站進行性能測試。

在安裝完成 Locust 后，我們需要在項目的根目錄下創(chuàng)建一個 locusfile:

from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000

然后使用如下命令啟動服務(wù)：

locust --host=https://my-website.com

使用壓測工具時需要注意：這些工具可能造成 DDoS 攻擊，所以需要在測試網(wǎng)站時進行限制。

Apache 可以追溯到 1995 年和互聯(lián)網(wǎng)的早期階段，當(dāng)時的服務(wù)器將接收的 HTTP 請求傳入到 TCP 連接上并重新生成一個新進程并響應(yīng)這個請求。當(dāng)眾多的請求被接收，也就意味著需要創(chuàng)建處理它們的 worker 進程。由于創(chuàng)建新 worker 進程的系統(tǒng)開銷巨大，所以 Apache 服務(wù)器的技術(shù)人員設(shè)計了 prefork 模式，并預(yù)先生成多個 worker 進程解決重新創(chuàng)建的問題。不過將每個進程嵌入到動態(tài)語言的解釋器（如 mod_php）中依然造成大量的資源消耗，這使得 Apache 服務(wù)器經(jīng)常會出現(xiàn) 服務(wù)器崩潰 的問題。這是因為單個 worker 進程只能同時處理一個連接。

這個模塊在 Apache 的 MPM 系統(tǒng)中稱為 mpm_prefork_module。從 Apache 官網(wǎng)可以了解到，這個模塊僅需極少的 配置 即可完成工作，因為它能夠自動調(diào)整，其中最關(guān)鍵的是將 MaxRequestWorkers 指令值配置的足夠大，這樣可以處理更多的請求，但是還需要保證有每個 worker 進程有足夠的物理 RAM 可用。

上面的 Locust 壓測顯示 Apache 創(chuàng)建了大量的進程來處理請求。

不得不說，這個模塊是 Apache 聲名狼藉的罪魁禍?zhǔn)?，它可能?dǎo)致資源利用率低下的問題。

在 Apache 第二版中引入了兩個新的 MPM 模塊，試圖解決 prefork 模式所帶來的問題。即 worker 模塊 或曰 mpm_worker_module 以及 event 模塊。

worker 模塊不再基于進程模型，而是一種混合了進程-線程（process-thread）處理模式。下面引用自 Apache 官網(wǎng):

單個進程（父進程）負(fù)責(zé)啟動子進程（worder 進程）。子進程負(fù)責(zé)創(chuàng)建由 ThreadsPerChild 指令設(shè)置的服務(wù)器線程，同時還負(fù)責(zé)監(jiān)聽接收到的請求，并將請求分發(fā)給處理線程。

這種模式能提升資源利用率。

在 2.4 版本 Apache 引入了 - event 模塊，這個模塊基于 worker 模塊創(chuàng)建的，并加入了獨立的監(jiān)聽線程來管理 HTTP 請求處理完成后的休眠的 keepalive 連接。它是一種異步非阻塞模型，內(nèi)存占用小?？梢詮?這里 了解這個版本的信息。

我們在虛擬機上安裝 WooCommerce 并基于 Apache 2.4 默認(rèn)的 prefork 和 mod_php 配置發(fā)送 1200 請求進行負(fù)載測試。

首先，我們在 https://tools.pingdom.com/ 網(wǎng)站對 libapache2-mod-php7 和 mpm_prefork_module 進行測試：

然后，我們對 MPM 的 evnet 模塊僅需測試。

這需要將 multiverse 加入到 /etc/apt/sources.list：

deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner

隨后，執(zhí)行 sudo apt-get update 來安裝 libapache2-mod-fastcgi 和 php-fpm。

sudo apt-get install libapache2-mod-fastcgi php7.0-fpm

由于 php-fpm 獨立于 Apache 服務(wù)器，所以需要重啟服務(wù)：

sudo service start php7.0-fpm

然后，關(guān)閉 prefork 模塊，啟用 event 模式和 proxy_fcgi:

sudo a2dismod php7.0 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi

將下面的代碼加入到 Apache 虛擬機：

    SetHandler "proxy:fcgi://127.0.0.1:9000/"

端口號需要與 php-fpm 配置保持一致 /etc/php/7.0/fpm/pool.d/www.conf。可以從 這里 了解 PHP-FPM 配置。

現(xiàn)在，我們調(diào)整 mpm_evnet 配置選項 /etc/apache2/mods-available/mpm_event.conf，記住我們的 mini-VPS 資源在測試上受限 - 所以需要減少一些默認(rèn)值。有關(guān)指令的詳細(xì)信息可以查看 指令文檔，關(guān)于 event 模塊的可以閱讀 這個章節(jié)。記住，重啟服務(wù)會消耗大量的內(nèi)存資源。MaxRequestWorkers 指令設(shè)置最大請求數(shù)限制：將 MaxConnectionsPerChild 設(shè)置為非零非常重要，它可以防止內(nèi)存泄露。

        StartServers              1
        MinSpareThreads          30
        MaxSpareThreads          75
        ThreadLimit              64
        ThreadsPerChild          30
        MaxRequestWorkers        80
        MaxConnectionsPerChild   80

使用 sudo service apache2 restart 重新啟動服務(wù)器，如果我們修改了如 ThreadLimit 這類指令，我們還需要顯示的停止和啟動服務(wù) sudo service apache2 stop; sudo service apache2 start。

在 Pingdom 上的測試結(jié)果顯示頁面加載時間縮短了一半以上。

禁用 .htaccess：.htaccess 允許在無需重啟服務(wù)時對根目錄下的每個目錄多帶帶進行配置。所以，服務(wù)器接收請求后會遍歷所有目錄，查找 .htaccess 文件，這會導(dǎo)致性能下降。

以下引用自 Apache 官方文檔：

通常，僅當(dāng)你的主服務(wù)器配置文件沒有進行相應(yīng)的訪問控制時才需要使用 .htaccess 文件。... 一般，需要盡可能避免使用 .htaccess 文件。當(dāng)需要使用 .htaccess 文件時，都可以在主服務(wù)器配置的 directory 配置節(jié)點去執(zhí)行配置

解決方案是到 /etc/apache2/apache2.conf 禁用重寫功能：

AllowOverride None

如果需要在特定目錄啟用重寫功能，可以到虛擬主機配置文件中指定節(jié)點啟用：

AllowOverride All

更多使用技巧：

使用 mod_expire 控制瀏覽器緩存 - 通過設(shè)值 expires 響應(yīng)頭。

關(guān)閉 HostNameLookups 功能 - HostNameLookups 自 Apache 1.3 器默認(rèn)關(guān)閉 off，由于它會導(dǎo)致性能下降，所以直接關(guān)閉就好。

Apache2buddy 是一個簡單的腳本，我們可以運行并獲得調(diào)整系統(tǒng)的提示：curl -sL https://raw.githubusercontent... | perl

Nginx 是一款 事件驅(qū)動（event-driven） 非阻塞模式的 Web 服務(wù)器。下面摘自 Hacker News：

與事件循環(huán)相比 fork 子進程消耗更多系統(tǒng)資源?；谑录?HTTP 服務(wù)器完勝。

這個言論引發(fā)了對 Hacker News 的吐槽，從我的經(jīng)驗來看，從 Apache 的 mpm_prefork 切換到 Nginx 可以保證網(wǎng)站不宕機。簡單的將 Web 服務(wù)器切換到 Nginx 就可做到這點。

可以從 這里 獲取 Nginx 架構(gòu)的全面分析。

Nginx 推薦將 worker 進程數(shù)量設(shè)置為 PC 的 核心數(shù)（類似 Apache 的 mpm_event 配置），將 /etc/nginx/nginx.conf 配置文件中 worker_processes 指令設(shè)置為 auto （默認(rèn)為 1）。

worker_connections 設(shè)置單個 worker 進程能夠處理的連接數(shù)。默認(rèn)為 512，不過通常可以增加處理連接數(shù)量。

keepalive 連接數(shù) 一樣會影響服務(wù)器性能，在基準(zhǔn)測試中一般看不到這個 請求頭。

從 Nginx 網(wǎng)站了解到：

HTTP keepalive 連接數(shù)是能夠有效減少延遲提升 web 頁面加載速度的優(yōu)化性能手段。

創(chuàng)建新的 TCP 連接會 消耗資源 - 尤其是啟用安全的 HTTPS 加密協(xié)議。HTTP/2 協(xié)議通過 復(fù)用特性 可以減少資源消耗。復(fù)用已經(jīng)創(chuàng)建好的連接能夠降低請求時間。

Apache 的 mpm_prefork 和 mpm_worker 對比 keepalive 事件循環(huán)在并發(fā)處理能力上存在不足。所以在 Apache 2.4 中引入 mpm_event 模塊對此進行了修復(fù)，然而對于 Nginx 事件驅(qū)動是唯一默認(rèn)處理模式。Nginx 的 worker 進程可以同時處理數(shù)千個連接，如果使用它作為反向代理或負(fù)載均衡器的話，Nginx 還可以使用本地 keepalive 連接池，而無需使用 TCP 連接所帶來的開銷。

keepalive_requests 指令用于設(shè)置單個客戶端能夠在一個 keepalive 連接上處理的請求數(shù)量。

keepalive_timeout 設(shè)置空閑 keepalive 連接保持打開的時間。

keepalive 是關(guān)于 upstream（上游） 服務(wù)器和 Nginx 連接有關(guān)的配置 - 當(dāng) Nginx 充當(dāng)代理或負(fù)載均衡服務(wù)器角色時。表示在空閑狀態(tài) upstream 服務(wù)器在單個 worker 進程中支持的 keepalive 連接數(shù)。

當(dāng)使用 upstream keepalive 連接處理請求時，需要將如下指令添加到 nginx 主配置文件中：

proxy_http_version 1.1;
proxy_set_header Connection "";

nginx upstream 連接由 ngx_http_upstream_module 模塊管理。

如果我們的客戶端應(yīng)用需要不斷輪詢服務(wù)端應(yīng)用進行數(shù)據(jù)更新，可以通過 keepalive_requests 和 keepalive_timeout 增加連接數(shù)。同時 keepalive 指令值不應(yīng)太大，這樣就能夠保證其他的 upstream 服務(wù)器也能夠處理其它請求。

這些配置需要基于不同的應(yīng)用的測試結(jié)果來進行多帶帶配置。這或許就是 keepalive 沒有默認(rèn)值的原因。

默認(rèn)情況下，nginx 使用多帶帶的 PHP 進程將 HTTP 請求轉(zhuǎn)發(fā)到 PHP 文件。這種場景就是代理（類似 Apache 需要設(shè)置 php7.0-fpm）。

我們所用的 Nginx 虛擬主機配置如下：

location ~ .php$ {
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
}

由于 FastCGI 與 HTTP 是不同的協(xié)議，前兩行配置是將一些參數(shù)和請求頭轉(zhuǎn)發(fā)到 php-fpm 進程管理器，最后一行設(shè)置了請求的代理方式 - 通過本地網(wǎng)絡(luò)套接字完成。

這對于多服務(wù)器它很實用，因為 nginx 可以對遠(yuǎn)程服務(wù)器進行代理轉(zhuǎn)發(fā)。

但是，如果我們將網(wǎng)站托管在一臺服務(wù)器上時，我們就應(yīng)該使用 UNIX 套接字來監(jiān)聽 php 進程：

fastcgi_pass unix:/var/run/php7.0-fpm.sock;

UNIX 套接字相比 TCP 連接有更好的 性能，從安全角度來講這個設(shè)置也是更優(yōu)的選擇。你可以從 Rackspace 站點的 這篇文章 掌握更多配置細(xì)節(jié)。

這個技巧同樣適用于 Apache 服務(wù)器?？梢缘?這里 進行學(xué)習(xí)。

gzip_static：在 web 服務(wù)器優(yōu)對靜態(tài)文件進行壓縮處理是公認(rèn)的行之有效的技術(shù)。這表示我們對大文件做出讓步，會對哪些超過指定大小的文件進行壓縮處理，因為這些文件在請求時消耗更多的資源。Nginx 提供一個 gzip_static 指令，允許我們使用服務(wù)器的 gzip 壓縮工具對文件進行壓縮 - 壓縮后的文件擴展名為 .gz 而非不同文件：

location /assets {
    gzip_static on;
}

這樣 Nginx 服務(wù)器會長時間 style.css 壓縮成 style.css.gz 文件（此時我們需要自己處理解壓）。

通過這種方式，在 CPU 周期內(nèi)無需在每個請求時動態(tài)的對文件進行壓縮處理。

如果不涉及講解如何進行緩存配置，那么對 Nginx 講解就是不是完整的。由于 Nginx 緩存非常高效，以至于諸多系統(tǒng)管理員認(rèn)為使用多帶帶的 HTTP 緩存 都是多余的（如 Varnish）。Nginx 緩存配置也十分簡單。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g
  inactive=60m;

這些指令配置在 server 塊級指令中。proxy_cache_path 參數(shù)可以是任何緩存保存的路徑。 levels 設(shè)置 Nginx 可以緩存什么層級目錄。出于性能考量，兩層目錄通常就可以了。因為目錄遞歸處理非常消耗資源。keys_zone 參數(shù)用于識別共享內(nèi)存的緩存鍵名，10m 表示該鍵名能夠使用的內(nèi)存大?。?0 MB 通常就夠了；這不是實際緩存內(nèi)容的空間大?。?。可選的 max_size 指令設(shè)置緩存的內(nèi)容上限 - 這里是 10GB。如果未設(shè)置該值，則會占用所有可用的存儲空間。inactive 指令設(shè)置數(shù)據(jù)未被命中時可被緩存的有效期。

設(shè)置完成后，將緩存鍵名添加到 server 或 location 指令塊就好了：

proxy_cache my_cache;

Nginx 容錯層能夠通知源服務(wù)器或 upstream 服務(wù)器在服務(wù)器出錯或關(guān)閉時從緩存中獲取命中的數(shù)據(jù)：

proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;

有關(guān) server 和 location 指令對于緩存的配置細(xì)節(jié)可以閱讀 這里。

proxy_cache_* 用于靜態(tài)資源緩存，不過通常我們希望能夠緩存動態(tài)內(nèi)容 - 如 CMS 或其他應(yīng)用。此時，我們可以使用 fastcgi_cache_* 指令來代替 proxy_cache_*：

 fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=my_cache:10m inactive=60m;
 fastcgi_cache_key "$scheme$request_method$host$request_uri";
 fastcgi_cache_use_stale error timeout invalid_header http_500;
 fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
 add_header NGINX_FASTCGI_CACHE $upstream_cache_status;

上面的最后一行會設(shè)置響應(yīng)頭，來告知我們內(nèi)容是否從緩存中獲取。

然后，在我們的 server 或 location 塊中，我們可以為緩存設(shè)置一些無需緩存的場景 - 例如，當(dāng)請求 URL 中存在查詢字符串時：

if ($query_string != "") {
    set $skip_cache 1;
}

另外，在 server 指令下的 .php 塊指令里，我們會添加如下內(nèi)容：

    try_files $uri =404;
    include fastcgi_params;

    fastcgi_read_timeout 360s;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    fastcgi_pass unix:/run/php/php7.0-fpm.sock;

    fastcgi_index index.php;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
    fastcgi_cache my_cache;
    fastcgi_cache_valid  60m;

以上，fastcgi_cache* 和 fastcgi_no_cache 就配置完可緩存和不可緩存的所有規(guī)則。

你可以從 Nginx 官網(wǎng) 文檔 中獲取這些指令的指引。

要了解更多信息，Nginx 提供了相關(guān)主題的 會議，還有好多免費的 電子書。

我們試圖介紹一些有助于我們改進 Web 服務(wù)器性能的技術(shù)，以及這些技術(shù)背后的理論。但是這個主題才涉及皮毛：我們還沒有涵蓋 Apache 和 Nginx 或多服務(wù)器有關(guān)如何設(shè)置反向代理的講解。使用這兩種服務(wù)器實現(xiàn)最佳方式是依據(jù)測試和分析特定的案例來進行選擇。這是一個永無止境的話題。

Apache vs Nginx Performance: Optimization Techniques