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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在安裝完成 Locust 后，我們需要在項(xiàng)目的根目錄下創(chuàng)建一個(gè) 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

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

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

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

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

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

上面的 Locust 壓測(cè)顯示 Apache 創(chuàng)建了大量的進(jìn)程來處理請(qǐng)求。

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

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

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

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

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

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

我們?cè)谔摂M機(jī)上安裝 WooCommerce 并基于 Apache 2.4 默認(rèn)的 prefork 和 mod_php 配置發(fā)送 1200 請(qǐng)求進(jìn)行負(fù)載測(cè)試。

首先，我們?cè)?https://tools.pingdom.com/ 網(wǎng)站對(duì) libapache2-mod-php7 和 mpm_prefork_module 進(jìn)行測(cè)試：

然后，我們對(duì) MPM 的 evnet 模塊僅需測(cè)試。

這需要將 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 獨(dú)立于 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 虛擬機(jī)：

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

端口號(hào)需要與 php-fpm 配置保持一致 /etc/php/7.0/fpm/pool.d/www.conf?？梢詮?這里 了解 PHP-FPM 配置。

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

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

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

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

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

以下引用自 Apache 官方文檔：

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

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

AllowOverride None

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

AllowOverride All

更多使用技巧：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

proxy_http_version 1.1;
proxy_set_header Connection "";

nginx upstream 連接由 ngx_http_upstream_module 模塊管理。

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

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

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

我們所用的 Nginx 虛擬主機(jī)配置如下：

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ù)和請(qǐng)求頭轉(zhuǎn)發(fā)到 php-fpm 進(jìn)程管理器，最后一行設(shè)置了請(qǐng)求的代理方式 - 通過本地網(wǎng)絡(luò)套接字完成。

這對(duì)于多服務(wù)器它很實(shí)用，因?yàn)?nginx 可以對(duì)遠(yuǎn)程服務(wù)器進(jìn)行代理轉(zhuǎn)發(fā)。

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

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

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

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

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

location /assets {
    gzip_static on;
}

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

通過這種方式，在 CPU 周期內(nèi)無需在每個(gè)請(qǐng)求時(shí)動(dòng)態(tài)的對(duì)文件進(jìn)行壓縮處理。

如果不涉及講解如何進(jìn)行緩存配置，那么對(duì) 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 塊級(jí)指令中。proxy_cache_path 參數(shù)可以是任何緩存保存的路徑。 levels 設(shè)置 Nginx 可以緩存什么層級(jí)目錄。出于性能考量，兩層目錄通常就可以了。因?yàn)槟夸涍f歸處理非常消耗資源。keys_zone 參數(shù)用于識(shí)別共享內(nèi)存的緩存鍵名，10m 表示該鍵名能夠使用的內(nèi)存大?。?0 MB 通常就夠了；這不是實(shí)際緩存內(nèi)容的空間大?。？蛇x的 max_size 指令設(shè)置緩存的內(nèi)容上限 - 這里是 10GB。如果未設(shè)置該值，則會(huì)占用所有可用的存儲(chǔ)空間。inactive 指令設(shè)置數(shù)據(jù)未被命中時(shí)可被緩存的有效期。

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

proxy_cache my_cache;

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

proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;

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

proxy_cache_* 用于靜態(tài)資源緩存，不過通常我們希望能夠緩存動(dòng)態(tài)內(nèi)容 - 如 CMS 或其他應(yīng)用。此時(shí)，我們可以使用 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;

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

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

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

另外，在 server 指令下的 .php 塊指令里，我們會(huì)添加如下內(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)主題的 會(huì)議，還有好多免費(fèi)的 電子書。

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

Apache vs Nginx Performance: Optimization Techniques