文/公子肥馬輕裘
想象一下：你剛剛發布了一篇博文，並分享到了社交網絡。然後，這篇文章恰巧被大 V 看中再次分享了出去，立即吸引了數百粉絲的目光，引導他們湧入了你的網站。看到這麼多的訪客量，以及它們的評論，你內心激動不已。突然之間，你的網站掛掉了，滿屏的數據連接錯誤……
或者假想另一種情景：你一直很努力地創業，某一天，一個大 V 在社交網絡表達了對貴公司的喜愛之情，字裡行間滿滿的贊歎。關注這個大 V 的粉絲心動了，又湧入了你的網站。不幸的是，點擊連接後卻無法進入你的網站，或者進入後無法注冊用戶，甚至頁面響應超時，無法獲取產品的序列號。盡管你在社交網絡上對此非常誠懇地表達了歉意，但粉絲們都不會再有興趣。
這些假想其實非常普遍。在我的工作中，就經常發現，當網站信息在社交網站流傳開來的時候，移動設備的訪問請求就會驟增。這也表明，在社交網絡中，越來越多的人開始使用移動設備，而不是傳統的桌面應用。此外，大多數的移動用戶都在使用公共 Wi-Fi 以及其他低速網絡來訪問網站。所以，快速加載網站的任何優化措施，都會有利於用戶的訪問。
在本文中，我會向你介紹 Varnish 網頁應用加速器（Varnish Web application accelerator）——這是一個免費、簡單的工具，有助於改善大規模突發性訪問狀態下的響應能力。
亮點
對於大多數的網站來說，眾多用戶請求訪問的核心內容大都是一致的——尤其是每天都會更新內容的門戶網站。不用多說你也會理解，圖片、CSS 和 JavaScript，這些靜態資源往往有較長的緩存周期期（譯者注：有利於在不同頁面間復用）。但你可能沒有深入思考過，通常在博客平台或者是內容管理系統中，響應用戶的請求後，所返回的數據內容，大多也是相同的。
來自社交網絡的用戶進入一個博客後，並不會請求完全一致的信息。除了圖片、JavaScript 和 CSS，這些信息還包括 PHP 動態生成的內容，以及從數據庫查詢到的數據。訪問博客中的某一篇文章，所需要發送的每一條請求，不僅僅是在獲取網絡服務器提供的靜態資源，還需要使用 PHP 腳本，使用數據庫連接以及數據庫表單檢索等功能。
數據庫連接的數量越多，Apache 需要處理的進程就會越多，而總的處理能力是有限的。相應的，訪客的數量越多，服務就會越不穩定，掙到的錢就會越少。
這就是類似 Varnish 的 HTTP 反向代理服務器發揮作用的地方。如此一來，從浏覽器發出的請求，不再直接到達創建和維護網頁的服務器，而是到達 HTTP 緩存服務器。如果緩存服務器中存在所需頁面，那麼直接從服務器的內存返回相應的資源，不再動用 Apache 服務器和數據庫。如果所需頁面不在緩存中，那麼就像傳統方式一樣，使用 Apache 服務器來處理。Apche 處理完成之後，就會將這個頁面保存到 HTTP 緩存服務器中，等到下一次請求相同頁面時就可以直接返回了。
將頁面保存在內存中，其響應速度遠快於將其保存在硬盤中。此外，當請求的頁面位於 HTTP 緩存服務器中時，就無需調用 PHP 或者數據庫來處理相關操作。這也讓 PHP 和 服務器能夠有更多的性能來處理更繁重的進程和連接。比如，上面提到的被大 V 稱贊的那家初創公司面臨的窘境，眾多粉絲點擊的鏈接其實只是網站中的少數幾個頁面——而這些完全可以保存在高速緩存服務器中，當需要時可以直接從內存響應請求。此時，准備注冊的用戶就會感到整個流程非常順利，因為後台腳本和數據庫連接的處理能力非常寬裕，完全不受突發性請求的影響。
原理
下面這個示意圖，展示了 Apache 服務器響應請求後生成站點內容的基本流程。在這個例子中，為了請求相同的頁面，一共從浏覽器發送了五條指令給 Apache，而 Apache 對每條請求都做了詳細的處理。
是的，Apache 處理了每一條請求——圖像，CSS，JavaScript 和 HTML 文件。如果 PHP 中有某個文件，就會解析一次。如果需要請求數據庫的信息，那麼就要執行一次數據連接，進行 SQL 查詢等操作。最終，在 Apache 返回給浏覽器信息之前，數據庫返回相關信息組裝成完整的頁面。
如果我們在 Apache 之前使用 Varnish，就可以組成這樣的一個流程：
如果浏覽器請求的資源和頁面已經存在緩存中，那麼 Varnish 就會直接從內存返回這些資源，而 Apache、PHP 和 MySql 完全不需要進行重復